Cédric Le Goater <c...@fr.ibm.com> writes: > On 11/28/2015 08:59 AM, Benjamin Herrenschmidt wrote: >> On Fri, 2015-11-27 at 11:21 +0100, Alexander Graf wrote: >>> >>> How does real hardware store petitboot? If it's flash, you could pass it >>> in using -pflash and thus model things even more closely and allow users >>> to just take the ROM image as is. >> >> It is a flash image, we could use an Open Power machine flash image "as-is" >> provided we taught qemu to extract skiboot (aka OPAL) from it. > > Couldn't we add an offset argument to load_image_targphys() or make that > an extra routine ? If so, we could then load directly from an openpower > pnor file. > > I gave it a quick (and dirty) try and a powernv guest runs fine up to > petitboot with just : > > qemu-system-ppc64 -m 2G -M powernv -bios > ~/work/open-power/images/palmetto.pnor -nographic -nodefaults -serial stdio > > The pnor file is compiled from github. The patch is below (without the dirty > cut and paste I did in loader.c). The offset for the PAYLOAD and BOOTKERNEL > partitions are hard coded but I guess we don't need to read the flash > partition > table in qemu, not yet.
One downside to this is that if we don't fall back to being able to load skiboot.lid it becomes more annoying to boot a gcov enabled skiboot as typical PNOR layout only gives 1MB for skiboot, and gcov builds bloat that a *lot*. We probably don't want NVRAM writes going back to a single system wide PNOR image too, so while using pnor file is great for simulating what hardware does, may not work as the solution for long term model.
