Messages in this thread | | | Date | Mon, 30 Jun 2008 15:34:48 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: Regression: boot failure on AMD Elan TS-5500 |
| |
H. Peter Anvin wrote: > 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.
Hm, yeah.
> 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.
Maybe it really does require the far jump immediately after setting PE in cr0...
Hm, I don't remember this paragraph being in vol 3a, section 8.9.1 before. Is it a recent addition?
Random failures can occur if other instructions exist between steps 3 and 4 above. Failures will be readily seen in some situations, such as when instructions that reference memory are inserted between steps 3 and 4 while in system management mode.
J
| |