On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
> As far as I could tell, "scan" simply caused the nonstandard video
> driver scan modules (unsafe probes) to be invoked. Since those modules
> are no longer present, there appeared to be no need for them. The VGA
> and VESA probes are safe.
It doesn't probe the hardware in dangerous ways. (Search for mode_scan
in video.S) It works by trying to set a mode via the normal
AH=0/AL=mode/int 0x10 method for all possible values of mode. It then
checks if the bios reports the new mode as being set and reads a few
standard vga registers to determine if it is a text mode. It's
completely independent of the CONFIG_VIDEO_SVGA stuff.
> > Would it make sense to just compile everything independent of config
> > options and determine what should be done at run-time? And/or separate
> > the bootcode related config-options and put them under EMBEDDED/TINY?
>
> It doesn't, because e.g. Voyager needs special A20 code, etc. I guess
> we could dynamically detect Voyager and then do that, but that would
> require testing.
Yeah, Voyager and Elan should be detected at runtime in that case. But
if one ever wants to do that, this would be a good time... This rewrite
needs thorough testing anyhow. ;)
> > If space is not that much of an issue, could you imagine putting
> > the decompression/relocation/misc.c code in setup too? This would
> > make it easier to start thinking of a new kernel image format without
> > breaking bootloaders that use a bzImage in the intended way.
>
> I don't think that's either desirable or practical. That code really
> wants ready addressability of the whole image.
Heh. I don't know about desirable, but it is not really impractical. The
Relocatable patches already introduced a small bit of 32-bit code in
setup (git-show 968de4f0 arch/i386/boot/setup.S). This has disappeared
in your rewrite, however.
That makes me wonder: (from arch/i386/boot/pmjump.S)
37 movw $__BOOT_DS, %cx
38
39 movl %cr0, %edx
40 orb $1, %dl # Protected mode (PE) bit
41 movl %edx, %cr0
42
43 movw %cx, %ds
44 movw %cx, %es
45 movw %cx, %fs
46 movw %cx, %gs
47 movw %cx, %ss
48
49 # Jump to the 32-bit entrypoint
50 .byte 0x66, 0xea # ljmpl opcode
51 2: .long 0 # offset
52 .word __BOOT_CS # segment
I thought the 32-bit jump was required to come before the segment loads.
Does this code load values from the gdt, or are they just loaded as real
mode segments? As long as it does not crash it does not matter, because
head.S reloads them again.
Thanks,
Greetings,
Alexander
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
