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@google.com [mailto:sjg@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@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: mercredi 17 juillet 2013 17:43 To: Rossier Daniel Cc: u-boot@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