[U-Boot] U-boot & x86 & coreboot

[Rossier Daniel <Daniel.Rossier@heig-vd.ch>]

Hi Simon,
(My first name is Daniel ;-)

I finally succeeded in booting u-boot on QEMU/x86 and even using tftp with networking.
And thanks for your tips.
First, I changed my version of qemu (from git back to 1.4.50) which solved the problem of eclipse/gdb. Now it works.

Then, using the "pc" machine of QEMU, coreboot defines the CAR address at 0x19200000 does not work on the emulated PC:
when U-boot tries to writes all information required by the GDT, it does not write anything at this address: that explains why
the system crashes on the instruction following the lgdt in setup_gdt (loading the GDT with all values at 0 makes any further access including code not possible).

So, I changed to 0x01200000 which still remains an accessible portion of RAM as configured by coreboot. I got the U-boot banner,
but still with some crashes. The following bug concerned the use of rdtsc instruction which is not supported by QEMU yet.
So I hardcoded a value like 0xf10 in get_tbclk_mhz() so that no access to tsc is necessary (ok, just for an approximation in a first time).
I was able to the the u-boot> prompt.

I also added CONFIG_E1000 to have the network enabled (e1000 is supported by the "pc" machine) in order to use tftp (I want to be able to
transfer some small piece of x86 code and test it in u-boot). And a new problem occurred:
tftp unconditionally leaded to an "access violation" return by the local tftp server of qemu. After some quite long hours of debugging, and comparing
with old version of U-boot, I found a bug in lib/vsprintf.c. In some case, the null-termination character is not set at the right place leading to a bad length of string.
I attached the patch which solved my problem.

I'm now able to transfer any file in U-boot/qemu/x86. Great! In a near future, I will also enable saveenv in order to preserve the environment in a flash file.

Cheers
Daniel


> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: mercredi 17 juillet 2013 23:56
> To: Rossier Daniel
> Subject: Re: [U-Boot] U-boot & x86 & coreboot
> 
> HI Rossier,
> 
> On Wed, Jul 17, 2013 at 3:16 PM, Rossier Daniel <Daniel.Rossier@heig-vd.ch>
> wrote:
> Hi Simon,
> 
> > -----Original Message-----
> > From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> > Sent: mercredi 17 juillet 2013 17:43
> > To: Rossier Daniel
> > Cc: u-boot at lists.denx.de
> > Subject: Re: [U-Boot] U-boot & x86 & coreboot
> >
> > Hi Rossier,
> >
> > On Wed, Jul 17, 2013 at 2:29 AM, Rossier Daniel <Daniel.Rossier@heig-
> vd.ch>
> > wrote:
> > Hi,
> >
> > I would like to run U-boot on x86 emulated QEMU-based environment. I
> > found some info regarding coreboot + U-boot integration, using U-boot as
> > payload, etc. but I was unable to start U-boot.
> > I'm using the 32-bits i686-pc-linux-gnu toolchain and I successfully cross-
> > compiled coreboot and started it on qemu-system-i386.
> > I also configured coreboot to use u-boot (ELF) as payload, but coreboot
> > performs a reset when U-boot should show up after loading.
> > Where could I have some information regarding that?
> >
> > There are post codes generated in x86 U-Boot which might help with
> > diagnosing this. I have not tried this on QEMU. But I suppose in that
> > environment it might be possible to watch execution and see where it is
> > going wrong.
> Actually, I was able to dig into further details during the execution.
> U-boot is starting its execution, but in early execution in setup_gdt,
> the execution of instruction at 0x1111491 leads to a traps (loading 0x18 to
> %ds).
> (see below for details)
> I don't really see an issue to execute this instruction.
> 
> I should have checked that you are using the latest mainline U-Boot?
> 
> I don't know why this doesn't work - could it be an emulator oddness?
> 
> Does it implement CAR (cache-as-ram) properly? Or could it be
> that?CONFIG_SYS_CAR_SIZE is not as big on QEMU?
> 
> 
> (gdb) si
> 0x01111491 in load_ds (segment=3) at cpu.c:61
> 61 ? ? ? ? ? ? ?asm volatile("movl %0, %%ds" : : "r" (segment *
> X86_GDT_ENTRY_SIZE));
> (gdb) info reg
> eax ? ? ? ? ? ?0x18 ? ? 24
> ecx ? ? ? ? ? ?0x19203f20 ? ? ? 421543712
> edx ? ? ? ? ? ?0x20 ? ? 32
> ebx ? ? ? ? ? ?0x19cf9320 ? ? ? 433034016
> esp ? ? ? ? ? ?0x19203f10 ? ? ? 0x19203f10
> ebp ? ? ? ? ? ?0x11dff0 0x11dff0
> esi ? ? ? ? ? ?0x7ebdc50 ? ? ? ?132897872
> edi ? ? ? ? ? ?0x1223b0 1188784
> eip ? ? ? ? ? ?0x1111491 ? ? ? ?0x1111491 <setup_gdt+135>
> eflags ? ? ? ? 0x2 ? ? ?[ ]
> cs ? ? ? ? ? ? 0x10 ? ? 16
> ss ? ? ? ? ? ? 0x18 ? ? 24
> ds ? ? ? ? ? ? 0x18 ? ? 24
> es ? ? ? ? ? ? 0x18 ? ? 24
> fs ? ? ? ? ? ? 0x18 ? ? 24
> gs ? ? ? ? ? ? 0x18 ? ? 24
> (gdb) info reg pc
> pc: 0x1111491
> (gdb) x/10i 0x1111491
> => 0x1111491 <setup_gdt+135>: ? mov ? ?%eax,%ds
> ? ?0x1111493 <setup_gdt+137>: ? mov ? ?%eax,%es
> ? ?0x1111495 <setup_gdt+139>: ? mov ? ?%eax,%gs
> ? ?0x1111497 <setup_gdt+141>: ? mov ? ?%eax,%ss
> ? ?0x1111499 <setup_gdt+143>: ? mov ? ?$0x20,%al
> ? ?0x111149b <setup_gdt+145>: ? mov ? ?%eax,%fs
> ? ?0x111149d <setup_gdt+147>: ? add ? ?$0x8,%esp
> ? ?0x11114a0 <setup_gdt+150>: ? pop ? ?%ebx
> ? ?0x11114a1 <setup_gdt+151>: ? ret
> ? ?0x11114a2 <x86_cpu_init_r>: ?call ? 0x11109d3 <cpu_init_interrupts>
> (gdb) si
> 0x0000fcb0 in ?? ()
> (gdb)
> 
> Do you have an idea?
> 
> By the way, I'm passing the file u-boot in ELF format directly to coreboot as
> ELF payload.
> Is it better to wrap the file u-boot.bin to get an ELF?
> 
> You can send u-boot-dtb.bin (need a device tree!) as a payload, using the --
> add-flat-binary option to cbfstool. That's what we do in Chrome OS.
> 
> 
> Thanks for your help
> 
> Daniel
> 
> Regards,
> Simon
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vsprintf.c.patch
Type: application/octet-stream
Size: 296 bytes
Desc: vsprintf.c.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130719/e85b3891/attachment.obj>