Jeremy Fitzhardinge wrote:
Looking at the beginning of startup_32, it seems ds is used before it is set:
startup_32:
cld
/* test KEEP_SEGMENTS flag to see if the bootloader is asking
* us to not reload segments */
testb $(1<<6), BP_loadflags(%esi)
jnz 1f
cli
movl $(__BOOT_DS),%eax
movl %eax,%ds
movl %eax,%es
movl %eax,%fs
movl %eax,%gs
movl %eax,%ss
1:
Since the testb instruction is a dereference, ds is implicitly used. If
I move the testb to after "movl %eax,%ds" it seems to work (not that it
would make any sense there, but just to prove the point).
1) Am I barking up the wrong tree?
2) If I'm right I have no idea what the correct solution is; it seems that
a chicken & egg issue is introduced.
Please advise. I am very new to all of this.
It's a bit odd that the boot loader neglected to set up ds properly, but changing the testb line to
testb $(1<<6), %cs:BP_loadflags(%esi)
should work. (Or perhaps a %ss: override would be better?)
I'm assuming that the GDT setup isn't completely mad and that the segments have the same base at least.
This should have been set up by the *boot code* (specifically lines 57-61 of arch/x86/boot/pmjump.S) since he's using a conventional boot loader (syslinux) so something is utterly fuggled up.
Using %cs: here should be safe, though (and *is* more conservative, after all, why otherwise bother reloading these segments at all?), but it still concerns me a great deal if this is broken in this way. It's definitely better than %ss:.
In particular, I'm wondering if the Elan CPU has any strange ordering requirements with regards to the protected mode transition that we're not obeying.