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

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

[Rossier Daniel]

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?
Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via "target remote localhost:1234".

Any hints welcome.
Thanks so much.

Cheers
Daniel

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

[Rossier Daniel]

Basically, should the coreboot-x86_config replace the use of coreboot ? Or, is coreboot still necessary?

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> bounces at lists.denx.de] On Behalf Of Rossier Daniel
> Sent: mercredi 17 juillet 2013 10:29
> To: u-boot at lists.denx.de
> Subject: [U-Boot] U-boot & x86 & coreboot
> 
> 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?
> Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot
> disassemble once connected via "target remote localhost:1234".
> 
> Any hints welcome.
> Thanks so much.
> 
> Cheers
> Daniel

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

[Simon Glass]

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.


> Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot
> disassemble once connected via "target remote localhost:1234".
>

Do you mean it cannot find the source files?

Regards,
Simon


>
> Any hints welcome.
> Thanks so much.
>
> Cheers
> Daniel
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>

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

[Simon Glass]

Hi Rossier,

On Wed, Jul 17, 2013 at 7:35 AM, Rossier Daniel
<Daniel.Rossier@heig-vd.ch>wrote:

>
> Basically, should the coreboot-x86_config replace the use of coreboot ?
> Or, is coreboot still necessary?
>

Yes coreboot is still necessary - it does the memory init and most of the
machine-specific stuff.


>
> > -----Original Message-----
> > From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> > bounces at lists.denx.de] On Behalf Of Rossier Daniel
> > Sent: mercredi 17 juillet 2013 10:29
> > To: u-boot at lists.denx.de
> > Subject: [U-Boot] U-boot & x86 & coreboot
> >
> > 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?
> > Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot
> > disassemble once connected via "target remote localhost:1234".
> >
> > Any hints welcome.
> > Thanks so much.
> >
> > Cheers
> > Daniel
>


Regards,
Simon

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

[Rossier Daniel]

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.

(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?

Thanks for your help

Daniel

> 
> Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot
> disassemble once connected via "target remote localhost:1234".
> 
> Do you mean it cannot find the source files?
> 
> Regards,
> Simon
> 
> 
> Any hints welcome.
> Thanks so much.
> 
> Cheers
> Daniel
> 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[Rossier Daniel]

By the way, the issue related to the debugger is that I'm unable to use it with Eclipse CDT (using gdbserver in Qemu). It leads to a seg fault in Qemu.
If you have an idea, I would appreciate.
Regards
Daniel

From: sjg@google.com<mailto:sjg@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<mailto: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 at heig-vd.ch<mailto: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.

Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via "target remote localhost:1234".

Do you mean it cannot find the source files?

Regards,
Simon


Any hints welcome.
Thanks so much.

Cheers
Daniel


_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de<mailto:U-Boot@lists.denx.de>
http://lists.denx.de/mailman/listinfo/u-boot

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

[Simon Glass]

On Wed, Jul 17, 2013 at 3:20 PM, Rossier Daniel
<Daniel.Rossier@heig-vd.ch>wrote:

>
> By the way, the issue related to the debugger is that I'm unable to use it
> with Eclipse CDT (using gdbserver in Qemu). It leads to a seg fault in Qemu.
> If you have an idea, I would appreciate.
>

No sorry, I don't use it. Perhaps ask on the Qemu mailing list? It seems
like an obvious thing to want to do...

- Simon

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

[Rossier Daniel]

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>

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

[Simon Glass]

Hi Daniel,

On Fri, Jul 19, 2013 at 1:49 AM, Rossier Daniel
<Daniel.Rossier@heig-vd.ch>wrote:

> 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.
>

Sound like a lot of progress!

Could you please send that patch to the mailing list? I did notice it but
have not got around to sending out one.


>
> 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.
>

Sounds great.

Regards,
Simon