Re: [Qemu-discuss] qemu -kernel u-boot.bin

[Peter Maydell]

On 10 June 2014 16:25, Matwey V. Kornilov <address@hidden> wrote:
> Only this instructions are executed:
>
>   >│0x60000000 <_start>                     mov    r0, #0
>                                                      │
>    │0x60000004 <_start+4>                   ldr    r1, [pc, #6397080]
>     ; 0x60000010 <_start+16>                         │
>    │0x60000008 <_start+8>                   ldr    r2, [pc, #6397080]
>     ; 0x60000014 <_start+20>                         │
>    │0x6000000c <_start+12>                  ldr    pc, [pc, #6397080]
>     ; 0x60000018 <_start+24>                         │
>
> Next stepi brings me to 0x60010000

This is entirely expected.

>>> qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1024 -kernel u-boot.bin
>>> -serial stdio

You said that u-boot.bin was a Linux kernel (that's what "-kernel"
means for non-ELF files), so we load your binary in accordance
with the documented requirements for booting a Linux kernel:
 * load kernel at offset 0x10000 in RAM
 * run a little stub code fragment to set r0 to 0, r1 to the board
   ID, r2 to the address of device tree / kernel ATAGS list, and
   then jump to the kernel start at offset 0x10000 into RAM

What you're seeing here is that we execute those four instructions
which are the stub code loader and then jump to where your
"kernel" starts.

If you don't want to be started like a kernel, don't use -kernel :-)

You could either (a) use an ELF file and take advantage of the
fact we just load ELF files at the address they're linked at and
then start at the ELF entrypoint or (b) If you're really trying to be
a boot rom you probably want to provide a complete 64MB flash
image via the "-pflash flash.bin" command line argument
(then don't use -kernel at all, and we'll start at address 0, which
is the flash, just as the real hardware does).

thanks
-- PMM