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