| Message ID | 565C925F.60306@fr.ibm.com |
|---|---|
| State | New |
| Headers | show |
On Mon, 2015-11-30 at 19:15 +0100, Cédric Le Goater wrote: > 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. In practice we should read the partition tables, I don't like hard coded offsets... But we should probably create a proper "flash driver" that does a bunch of this, and also adds the BMC style flash interface so OPAL can write to nvram. Cheers, Ben.
On 11/30/2015 09:09 PM, Benjamin Herrenschmidt wrote: > On Mon, 2015-11-30 at 19:15 +0100, Cédric Le Goater wrote: >> 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. > > In practice we should read the partition tables, I don't like hard > coded offsets... But we should probably create a proper "flash driver" > that does a bunch of this, and also adds the BMC style flash interface > so OPAL can write to nvram. yes that would be better but I don't measure what it takes to implement the LPC/AHB bridge to access the PNOR. C.
On Mon, 2015-11-30 at 22:24 +0100, Cédric Le Goater wrote: > > In practice we should read the partition tables, I don't like hard > > coded offsets... But we should probably create a proper "flash driver" > > that does a bunch of this, and also adds the BMC style flash interface > > so OPAL can write to nvram. > > yes that would be better but I don't measure what it takes to implement > the LPC/AHB bridge to access the PNOR. Yeah that's probably a little bit of work, but then there's also work being done to protect the flash using IPMI commands to do the flashing, so that could be an alternate option. I like emulating more of the BMC though, including the flash controller, as it would improve our testing coverage. Cheers, Ben.
Cédric Le Goater <clg@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.
On 12/07/2015 02:25 AM, Stewart Smith wrote: > Cédric Le Goater <clg@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*. I guess that what we can imagine having a bigger partition for skiboot in the case of gcov ? This will require a custom pnor build. Might be too complex. Or we could use a -pflash option to load the pnor and an optional -bios for skiboot if we want a custom one. > 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. we can use a memory backend to start with, which is also much simpler than having to handle the block backend like the cfi pflash is doing. a guest could use its own private pnor if a block backend is needed. C.
Index: qemu-powernv.git/hw/ppc/pnv.c =================================================================== --- qemu-powernv.git.orig/hw/ppc/pnv.c +++ qemu-powernv.git/hw/ppc/pnv.c @@ -69,7 +69,7 @@ #define FDT_ADDR 0x01000000 #define FDT_MAX_SIZE 0x00100000 -#define FW_MAX_SIZE 0x00400000 +#define FW_MAX_SIZE 0x04000000 #define FW_FILE_NAME "skiboot.lid" #define KERNEL_FILE_NAME "skiroot.lid" #define KERNEL_LOAD_ADDR 0x20000000 @@ -902,7 +902,9 @@ static void ppc_powernv_init(MachineStat { ram_addr_t ram_size = machine->ram_size; const char *cpu_model = machine->cpu_model; +#if 0 const char *kernel_filename = machine->kernel_filename; +#endif const char *initrd_filename = machine->initrd_filename; uint32_t initrd_base = 0; long initrd_size = 0; @@ -998,19 +1000,20 @@ static void ppc_powernv_init(MachineStat bios_name = FW_FILE_NAME; } filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); - fw_size = load_image_targphys(filename, 0, FW_MAX_SIZE); + fw_size = load_image_targphys_offset(filename, 0, FW_MAX_SIZE, 0x961000); if (fw_size < 0) { hw_error("qemu: could not load OPAL '%s'\n", filename); exit(1); } +#if 0 g_free(filename); if (kernel_filename == NULL) { kernel_filename = KERNEL_FILE_NAME; } filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, kernel_filename); - fw_size = load_image_targphys(filename, 0x20000000, 0x2000000); +#endif + fw_size = load_image_targphys_offset(filename, 0x20000000, 0x2000000, 0xa61000); if (fw_size < 0) { hw_error("qemu: could not load kernel'%s'\n", filename); exit(1);