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

[Anthony Liguori]

On Jan 29, 2012 8:41 PM, "John Williams" <address@hidden> wrote:
>
> >>>> 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.

I don't see how any of this is relevant.  Presumably, on real hardware, you have a rom bank wired to a specific physical address with ip fixed to an address which happens to be in that space?

Why not just use an emulated flash chip?

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

All systems have to bootstrap software some how.  Some device is reasonable for this.  This isn't emulated magic :-)

Regards,

Anthony Liguori

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