[SeaBIOS] Problems with Linux payload

Curt Brune curt at cumulusnetworks.com
Thu Aug 28 19:58:57 CEST 2014


Kevin, Laszlo, Scott -

On Wed Aug 27 21:41, Scott Duplichan wrote:
> Laszlo Ersek [mailto:lersek at 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



More information about the SeaBIOS mailing list