Re: [Qemu-devel] [RFC PATCH 5/7] vl.c: added -kerndtb option

[John Williams]

>>>> There's an opportunity here - QEMU needs the cmdline ability to load
>>>> random binaries/elfs anyway, such as
>>>>
>>>> --load address@hidden
>>>
>>>
>>>
>>> Make an elf loader device if you desire this ability but I'm skeptical
>>> that
>>> it really is all that useful.
>>
>>
>> It is useful for non-Linux use-cases, of which there are many!
>
>
> It's not just a matter of loading an elf binary in memory.  You probably
> need to have a specific register state set in order to run non-Linux elf
> binaries which means you'll need binary specific logic.

The machine state at bootup is very well defined - it's whatever the TRM says!

An example may help.  We are working on the Xilinx Zynq model, dual
core Cortex A-9.  We currently are able to use QEMU for the entire
flow from

cold reset ->
bootrom ->
u-boot ->
Linux

In this flow, we don't want any magic initial state, we want QEMU to
model the CPU just like the real hardware.

Equivalently, we might like to kick directly into the kernel, SMP==2 and so on.

It makes no sense to me that we should somehow use a different machine
model just to model a different boot flow on the same hardware.

Another example, we are working on remoteproc/rpmsg support so that we
can run Linux on one core, and firmware on another.  We have this
working in QEMU today, except we had to hack around the ARM boot
code's assumptions that we always want the 2nd CPU to run an WFE/WIQ
loop.  This is only true if you are running Linux *and* you want QEMU
to fake the actions of a bootloader.

If you are modelling a cold start you want those two CPUs to race
until one of them reads the CPUID register puts itself to sleep, ie
just run the bootrom.

All of these use cases are not about virtualisation, but about system
modeling and emulation, which really is where QEMU is valuable in the
embedded space.

> If all of these binaries you want to run have a well known register state,
> they you can just use fw_cfg and a piece of firmware to read the binary
> (which is basically how -kernel works on target-i386).
>
>
>>
>> Can you explain how you'd see such a 'loader device' in practice?  How
>> does it get bound into the machine model?  How do we pass arguments to
>> it?
>
>
> You create a device via qdev (now QOM) that takes whatever properties you
> need.  You then do:
>
> -device elf-loader,base=0xa00000,file=my-elf-binary
>
> No different than adding a network card.

A network card is a tangible object, it can be present in the system.
The ELF loader is just emulator cruft, a necessary evil to get the
initial state of the machine.  Should it really be on a level footing
with actual devices?

Rgds,

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663