On Jan 29, 2012 8:41 PM, "John Williams" <john.willi...@petalogix.com> wrote: > > >>>> There's an opportunity here - QEMU needs the cmdline ability to load > >>>> random binaries/elfs anyway, such as > >>>> > >>>> --load file@address > >>> > >>> > >>> > >>> 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
