Kevin, Laszlo, Scott -
On Wed Aug 27 21:41, Scott Duplichan wrote:
Laszlo Ersek [mailto:lersek@redhat.com] wrote:
[snip]]Can you hex-dump the guest memory too, in both cases, starting from ]0xf4b78+0x18, and from 0x1ffec000+0x18, respectively, for 0x8 bytes? ]This would provide the segment descriptor in each case that the selector ]value 0x18 references.
I thought of the same, but then saw that gdb is actually dumping those:
0018 000f0000 0000ffff 00009b00 DPL=0 CS16 (causes reset) 0018 00000000 ffffffff 00c09300 DPL=0 DS (works)
Thanks all for your help, insight and education. It definitely is the segment descriptor referenced by selector 0x18 that is the problem. I will raise the issue on the coreboot list, but it looks to me that the cbfstool and the Linux trampoline it provides is not quite right.
The Linux kernel is pretty clear about its expectations about the segments from selector 0x18 -- from linux/Documentation/x86/boot.txt:
At entry, [...] a GDT must be loaded with the descriptors for selectors __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat segment; __BOOT_CS must have execute/read permission, and __BOOT_DS must have read/write permission; CS must be __BOOT_CS and DS, ES, SS must be __BOOT_DS;
The ramstage of coreboot just happens to setup the descriptor at selector 0x18 just so. The trampoline provided by the cbfstool for Linux payloads does not adjust the descriptor at selector 0x18.
From gdb I was able to poke in a valid descriptor for selector 0x18
and off it went without a hitch.
Thanks again.
Cheers, Curt