Re: qemu/powernv: coreboot support?
On Tue, Oct 22, 2019 at 09:58:10AM +0200, Cédric Le Goater wrote: > On 22/10/2019 02:32, Marty E. Plummer wrote: > > On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote: > >> On 21/10/2019 07:34, David Gibson wrote: > >>> On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote: > On 20/10/2019 08:28, David Gibson wrote: > > > > Ok. Note that the qemu emulated machine doesn't model the hardware > > right down to the level of hostboot. That's wy we're just loading > > skiboot and jumping straight into it usually. I guess clg's stuff to > > load pnor images gets us a little closer to the hardware behaviour, > > but I think it's still only a rough approximation. > > > On that note, is qemu-ppc64 currently capable of running LE firmware? My > > coreboot port has currently reached a hitch in that part of the firmware > > headers mapping stuff out is saved in LE mode while the cpu (real or emu) > > is running in BE mode (FMAP headers are saved LE but CBFS headers are > > saved BE) > It's really tied to the OpenPOWER firmwares using the HIOMAP protocol > to discuss with the BMC and load the flash. We could loosen how QEMU > interprets the MTD device and use a property to inform QEMU that this > is an OpenPOWER PNOR file and that skiboot and can be loaded from it. > Something to discuss. > >>> > >>> Right. I'm guessing one significant issue here is that to fully model > >>> the BMC, with *its* firmware and comms channels with the main host > >>> would be quite a lot of work, hence cheating a bit to bypass that. > >> > >> In fact, we are not cheating that much. We use the IPMI BT interface of > >> QEMU to handle the HIOMAP communication with the BMC and this model is > >> quite precise. > >> > >> The mapping of the PNOR is simply mapped on the LPC FW address space. > >> The underlying access are simplified because we don't have a LPC model > >> but we could generate all the SPI transaction using the Aspeed models. > >> I had experiments in that sense for P8. > >> > > Honestly getting the coreboot.rom into the lpc fw addr space in the same > > way you do pnor images would be a useful sim, as that's more or less how > > its going to be done on existing hardware. > > That is covered by patch 'ppc/pnv: Add HIOMAP commands' in the series > I sent. > Unless I'm mistaken I have that patch in my build (I assume you pulled that right from your git branch powernv-4.2, which is what I built from) and that it would still parse and look for the skiboot partition, and run it. I need something akin to 'hey, shove this at the addr space and start executing $bios (where bios is either the bottom of the flash in that addr space or a provided -bios file on the command line). The final intent after the first 'conversion' flash is that the coreboot bootblock will reside in the seeprom, akin to current hostboot bootloader, and then pull romstage from the flash over lpc into cache, then after romstage initializes memory pull ramstage into from the flash over lpc into ram and start executing that. > C.
Re: qemu/powernv: coreboot support?
On 22/10/2019 02:32, Marty E. Plummer wrote: > On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote: >> On 21/10/2019 07:34, David Gibson wrote: >>> On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote: On 20/10/2019 08:28, David Gibson wrote: > > Ok. Note that the qemu emulated machine doesn't model the hardware > right down to the level of hostboot. That's wy we're just loading > skiboot and jumping straight into it usually. I guess clg's stuff to > load pnor images gets us a little closer to the hardware behaviour, > but I think it's still only a rough approximation. > On that note, is qemu-ppc64 currently capable of running LE firmware? My > coreboot port has currently reached a hitch in that part of the firmware > headers mapping stuff out is saved in LE mode while the cpu (real or emu) > is running in BE mode (FMAP headers are saved LE but CBFS headers are > saved BE) It's really tied to the OpenPOWER firmwares using the HIOMAP protocol to discuss with the BMC and load the flash. We could loosen how QEMU interprets the MTD device and use a property to inform QEMU that this is an OpenPOWER PNOR file and that skiboot and can be loaded from it. Something to discuss. >>> >>> Right. I'm guessing one significant issue here is that to fully model >>> the BMC, with *its* firmware and comms channels with the main host >>> would be quite a lot of work, hence cheating a bit to bypass that. >> >> In fact, we are not cheating that much. We use the IPMI BT interface of >> QEMU to handle the HIOMAP communication with the BMC and this model is >> quite precise. >> >> The mapping of the PNOR is simply mapped on the LPC FW address space. >> The underlying access are simplified because we don't have a LPC model >> but we could generate all the SPI transaction using the Aspeed models. >> I had experiments in that sense for P8. >> > Honestly getting the coreboot.rom into the lpc fw addr space in the same > way you do pnor images would be a useful sim, as that's more or less how > its going to be done on existing hardware. That is covered by patch 'ppc/pnv: Add HIOMAP commands' in the series I sent. C.
Re: qemu/powernv: coreboot support?
On Mon, Oct 21, 2019 at 09:17:55PM -0500, Marty E. Plummer wrote: > On Tue, Oct 22, 2019 at 12:40:32PM +1100, David Gibson wrote: > > On Mon, Oct 21, 2019 at 07:32:09PM -0500, Marty E. Plummer wrote: > > > On that note, is qemu-ppc64 currently capable of running LE > > > firmware? > > > > Well.. "qemu-ppc64" as such isn't capable of running either LE or > > firmware, since that's the Linux userspace emulator. > > qemu-system-ppc64 *is* capable of running both LE and BE firmwares though. > > > Ah. yeah, that's what I meant. Good to know. Paul Mackerras came up with some magic code that can get you from an unknown endian state to a known state. > > Your firmware will, however, need a tiny BE shim to switch the cpu > > into LE mode. > > > Yeah, I figured as much, and was planning to have a shim available for > 'real' hardware in the event a user wants to run coreboot in LE mode > after both work properly (though somewhere in the OpenPOWER spec it is > stated firmware must be BE). TBH, it makes no sense to specify the endianness of the firmware - it's an internal detail. The endianness of the firmware *interfaces* needs to be fixed of course, but not the endianness of the implementation. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: qemu/powernv: coreboot support?
On Tue, Oct 22, 2019 at 12:40:32PM +1100, David Gibson wrote: > On Mon, Oct 21, 2019 at 07:32:09PM -0500, Marty E. Plummer wrote: > > On that note, is qemu-ppc64 currently capable of running LE > > firmware? > > Well.. "qemu-ppc64" as such isn't capable of running either LE or > firmware, since that's the Linux userspace emulator. > qemu-system-ppc64 *is* capable of running both LE and BE firmwares though. > Ah. yeah, that's what I meant. Good to know. > Your firmware will, however, need a tiny BE shim to switch the cpu > into LE mode. > Yeah, I figured as much, and was planning to have a shim available for 'real' hardware in the event a user wants to run coreboot in LE mode after both work properly (though somewhere in the OpenPOWER spec it is stated firmware must be BE). > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au| minimalist, thank you. NOT _the_ > _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson
Re: qemu/powernv: coreboot support?
On Mon, Oct 21, 2019 at 07:32:09PM -0500, Marty E. Plummer wrote: > On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote: > > On 21/10/2019 07:34, David Gibson wrote: > > > On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote: > > >> On 20/10/2019 08:28, David Gibson wrote: > > >>> > > >>> Ok. Note that the qemu emulated machine doesn't model the hardware > > >>> right down to the level of hostboot. That's wy we're just loading > > >>> skiboot and jumping straight into it usually. I guess clg's stuff to > > >>> load pnor images gets us a little closer to the hardware behaviour, > > >>> but I think it's still only a rough approximation. > > >> > On that note, is qemu-ppc64 currently capable of running LE > firmware? Well.. "qemu-ppc64" as such isn't capable of running either LE or firmware, since that's the Linux userspace emulator. qemu-system-ppc64 *is* capable of running both LE and BE firmwares though. Your firmware will, however, need a tiny BE shim to switch the cpu into LE mode. > My > coreboot port has currently reached a hitch in that part of the firmware > headers mapping stuff out is saved in LE mode while the cpu (real or emu) > is running in BE mode (FMAP headers are saved LE but CBFS headers are > saved BE) > > >> It's really tied to the OpenPOWER firmwares using the HIOMAP protocol > > >> to discuss with the BMC and load the flash. We could loosen how QEMU > > >> interprets the MTD device and use a property to inform QEMU that this > > >> is an OpenPOWER PNOR file and that skiboot and can be loaded from it. > > >> Something to discuss. > > > > > > Right. I'm guessing one significant issue here is that to fully model > > > the BMC, with *its* firmware and comms channels with the main host > > > would be quite a lot of work, hence cheating a bit to bypass that. > > > > In fact, we are not cheating that much. We use the IPMI BT interface of > > QEMU to handle the HIOMAP communication with the BMC and this model is > > quite precise. > > > > The mapping of the PNOR is simply mapped on the LPC FW address space. > > The underlying access are simplified because we don't have a LPC model > > but we could generate all the SPI transaction using the Aspeed models. > > I had experiments in that sense for P8. > > > Honestly getting the coreboot.rom into the lpc fw addr space in the same > way you do pnor images would be a useful sim, as that's more or less how > its going to be done on existing hardware. > > I will sense the patches I have on the topic. > > > > C. > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: qemu/powernv: coreboot support?
On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote: > On 21/10/2019 07:34, David Gibson wrote: > > On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote: > >> On 20/10/2019 08:28, David Gibson wrote: > >>> > >>> Ok. Note that the qemu emulated machine doesn't model the hardware > >>> right down to the level of hostboot. That's wy we're just loading > >>> skiboot and jumping straight into it usually. I guess clg's stuff to > >>> load pnor images gets us a little closer to the hardware behaviour, > >>> but I think it's still only a rough approximation. > >> On that note, is qemu-ppc64 currently capable of running LE firmware? My coreboot port has currently reached a hitch in that part of the firmware headers mapping stuff out is saved in LE mode while the cpu (real or emu) is running in BE mode (FMAP headers are saved LE but CBFS headers are saved BE) > >> It's really tied to the OpenPOWER firmwares using the HIOMAP protocol > >> to discuss with the BMC and load the flash. We could loosen how QEMU > >> interprets the MTD device and use a property to inform QEMU that this > >> is an OpenPOWER PNOR file and that skiboot and can be loaded from it. > >> Something to discuss. > > > > Right. I'm guessing one significant issue here is that to fully model > > the BMC, with *its* firmware and comms channels with the main host > > would be quite a lot of work, hence cheating a bit to bypass that. > > In fact, we are not cheating that much. We use the IPMI BT interface of > QEMU to handle the HIOMAP communication with the BMC and this model is > quite precise. > > The mapping of the PNOR is simply mapped on the LPC FW address space. > The underlying access are simplified because we don't have a LPC model > but we could generate all the SPI transaction using the Aspeed models. > I had experiments in that sense for P8. > Honestly getting the coreboot.rom into the lpc fw addr space in the same way you do pnor images would be a useful sim, as that's more or less how its going to be done on existing hardware. > I will sense the patches I have on the topic. > > C.
Re: qemu/powernv: coreboot support?
On 21/10/2019 07:34, David Gibson wrote: > On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote: >> On 20/10/2019 08:28, David Gibson wrote: >>> On Sat, Oct 19, 2019 at 11:09:34AM -0500, Marty E. Plummer wrote: On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote: > On 19/10/2019 17:31, Marty E. Plummer wrote: >> On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: >>> On 18/10/2019 19:28, Marty E. Plummer wrote: Hello, First off, thank you for the work you've done on the ppc64 support, it has been very useful. I'm currently working on a coreboot port for the talos ii line of systems (which means more ppc64 support, support specifically for the power9 sforza chip, and specific mainboard support. My plate is very full lol) and have been using qemu to debug the bootblock. It has been very useful for that, but I'm now at the point where I need to jump to romstage, and that's where it gets tricky. qemu parses the rom image and looks for a ffs header, locates skiboot on it, and jumps straight to that. Not exactly ideal for debugging something not produced from op-build. >>> >>> yes. I suppose you are using my branch powernv-4.2 which adds PNOR >>> support >>> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR >>> file to extract the PAYLOAD partition (skiboot). skiboot also detects >>> the >>> flash and extract the kernel and initramfs from the PNOR. >>> >>> However, you can bypass all this internal boot process by simply passing >>> a -bios option and not passing a MTD device. >>> >> Doing so gives me the following error: >> qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' >> (this is after I patched the 4mb size limit up) > > Could you make that rom available ? > Sure, I think. Not sure about how sending files works in my current mail client but will see. Its more or less a 'stock' (as stock as can be for a new coreboot target) coreboot.rom file, but I've added some logic into the build to fake a pnor ffs header at the end in order to trick hostboot bootloader into loading it. >>> >>> Ok. Note that the qemu emulated machine doesn't model the hardware >>> right down to the level of hostboot. That's wy we're just loading >>> skiboot and jumping straight into it usually. I guess clg's stuff to >>> load pnor images gets us a little closer to the hardware behaviour, >>> but I think it's still only a rough approximation. >> >> It's really tied to the OpenPOWER firmwares using the HIOMAP protocol >> to discuss with the BMC and load the flash. We could loosen how QEMU >> interprets the MTD device and use a property to inform QEMU that this >> is an OpenPOWER PNOR file and that skiboot and can be loaded from it. >> Something to discuss. > > Right. I'm guessing one significant issue here is that to fully model > the BMC, with *its* firmware and comms channels with the main host > would be quite a lot of work, hence cheating a bit to bypass that. In fact, we are not cheating that much. We use the IPMI BT interface of QEMU to handle the HIOMAP communication with the BMC and this model is quite precise. The mapping of the PNOR is simply mapped on the LPC FW address space. The underlying access are simplified because we don't have a LPC model but we could generate all the SPI transaction using the Aspeed models. I had experiments in that sense for P8. I will sense the patches I have on the topic. C. >> I have applied this small hack to load larger -bios files : >> >> --- qemu-powernv-4.2.git.orig/hw/ppc/pnv.c >> +++ qemu-powernv-4.2.git/hw/ppc/pnv.c >> @@ -58,7 +58,7 @@ >> >> #define FW_FILE_NAME"skiboot.lid" >> #define FW_LOAD_ADDR0x0 >> -#define FW_MAX_SIZE (4 * MiB) >> +#define FW_MAX_SIZE (64 * MiB) >> >> #define KERNEL_LOAD_ADDR0x2000 >> #define KERNEL_MAX_SIZE (256 * MiB) >> >> and coreboot.rom loads and boots and loops. >> >> >> You can use -d exec,in_asm to check what's going on. >> >> >> C. >> >
Re: qemu/powernv: coreboot support?
On 10/20/19 9:48 PM, Peter Maydell wrote: On Sat, 19 Oct 2019 at 20:24, Marty E. Plummer wrote: Turns out the 'not text' warning came from lists.sr.ht, I wonder why that mailed me. It's just an individual subscribed address that complains, not the qemu mailing list itself. Philippe, did you say it was you that had subscribed a lists.sr.ht address ? Could you configure it not to complain to individual list senders? Failing that, would it be too annoying to unsubscribe it? At the moment it mostly seems to confuse people. Unfortunately it is not very configurable, so I simply unsubscribed it (no problem, it was just an experiment with sr.ht which provide fancy features such a similar patchwork system and repository, but we use patchew). The other alternative here is I could turn back on the qemu-devel list facility that turns HTML emails into plain text. I sort of didn't want to do that, though, as editing emails means we end up with from-header mangling if the sender has a strict dmarc/dkim setup... Agreed, no need to go back to this. Sorry for the noise with this experiment. Regards, Phil.
Re: qemu/powernv: coreboot support?
On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote: > On 20/10/2019 08:28, David Gibson wrote: > > On Sat, Oct 19, 2019 at 11:09:34AM -0500, Marty E. Plummer wrote: > >> On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote: > >>> On 19/10/2019 17:31, Marty E. Plummer wrote: > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > > On 18/10/2019 19:28, Marty E. Plummer wrote: > >> Hello, > >> > >> First off, thank you for the work you've done on the ppc64 support, it > >> has been very useful. I'm currently working on a coreboot port for the > >> talos ii line of systems (which means more ppc64 support, support > >> specifically for the power9 sforza chip, and specific mainboard > >> support. > >> My plate is very full lol) and have been using qemu to debug the > >> bootblock. > >> > >> It has been very useful for that, but I'm now at the point where I need > >> to jump to romstage, and that's where it gets tricky. qemu parses the > >> rom > >> image and looks for a ffs header, locates skiboot on it, and jumps > >> straight > >> to that. Not exactly ideal for debugging something not produced from > >> op-build. > > > > yes. I suppose you are using my branch powernv-4.2 which adds PNOR > > support > > and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > > file to extract the PAYLOAD partition (skiboot). skiboot also detects > > the > > flash and extract the kernel and initramfs from the PNOR. > > > > However, you can bypass all this internal boot process by simply passing > > a -bios option and not passing a MTD device. > > > Doing so gives me the following error: > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' > (this is after I patched the 4mb size limit up) > >>> > >>> Could you make that rom available ? > >>> > >> Sure, I think. Not sure about how sending files works in my current mail > >> client but will see. Its more or less a 'stock' (as stock as can be for > >> a new coreboot target) coreboot.rom file, but I've added some logic into > >> the build to fake a pnor ffs header at the end in order to trick hostboot > >> bootloader into loading it. > > > > Ok. Note that the qemu emulated machine doesn't model the hardware > > right down to the level of hostboot. That's wy we're just loading > > skiboot and jumping straight into it usually. I guess clg's stuff to > > load pnor images gets us a little closer to the hardware behaviour, > > but I think it's still only a rough approximation. > > It's really tied to the OpenPOWER firmwares using the HIOMAP protocol > to discuss with the BMC and load the flash. We could loosen how QEMU > interprets the MTD device and use a property to inform QEMU that this > is an OpenPOWER PNOR file and that skiboot and can be loaded from it. > Something to discuss. Right. I'm guessing one significant issue here is that to fully model the BMC, with *its* firmware and comms channels with the main host would be quite a lot of work, hence cheating a bit to bypass that. > I have applied this small hack to load larger -bios files : > > --- qemu-powernv-4.2.git.orig/hw/ppc/pnv.c > +++ qemu-powernv-4.2.git/hw/ppc/pnv.c > @@ -58,7 +58,7 @@ > > #define FW_FILE_NAME"skiboot.lid" > #define FW_LOAD_ADDR0x0 > -#define FW_MAX_SIZE (4 * MiB) > +#define FW_MAX_SIZE (64 * MiB) > > #define KERNEL_LOAD_ADDR0x2000 > #define KERNEL_MAX_SIZE (256 * MiB) > > and coreboot.rom loads and boots and loops. > > > You can use -d exec,in_asm to check what's going on. > > > C. > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: qemu/powernv: coreboot support?
On Sat, 19 Oct 2019 at 20:24, Marty E. Plummer wrote: > Turns out the 'not text' warning came from lists.sr.ht, I wonder why > that mailed me. It's just an individual subscribed address that complains, not the qemu mailing list itself. Philippe, did you say it was you that had subscribed a lists.sr.ht address ? Could you configure it not to complain to individual list senders? Failing that, would it be too annoying to unsubscribe it? At the moment it mostly seems to confuse people. The other alternative here is I could turn back on the qemu-devel list facility that turns HTML emails into plain text. I sort of didn't want to do that, though, as editing emails means we end up with from-header mangling if the sender has a strict dmarc/dkim setup... thanks -- PMM
Re: qemu/powernv: coreboot support?
On Sun, Oct 20, 2019 at 08:51:47AM +0200, Cédric Le Goater wrote: > On 20/10/2019 08:28, David Gibson wrote: > > Ok. Note that the qemu emulated machine doesn't model the hardware > > right down to the level of hostboot. That's wy we're just loading > > skiboot and jumping straight into it usually. I guess clg's stuff to > > load pnor images gets us a little closer to the hardware behaviour, > > but I think it's still only a rough approximation. > Yeah, but its useful enough to see that my rough understanding of ppc64 assembly is more/less correct (using the hostboot/skiboot sources as a reference [both are elfv1] to write coreboot [I'm using elfv2] is a bit fun) > It's really tied to the OpenPOWER firmwares using the HIOMAP protocol > to discuss with the BMC and load the flash. We could loosen how QEMU > interprets the MTD device and use a property to inform QEMU that this > is an OpenPOWER PNOR file and that skiboot and can be loaded from it. > Something to discuss. > Yeah, it would be useful to be able to use a non-pnor mtd device but still get the hiomap behavior, because that's what I'll be dealing with on real hardware. > > I have applied this small hack to load larger -bios files : > > --- qemu-powernv-4.2.git.orig/hw/ppc/pnv.c > +++ qemu-powernv-4.2.git/hw/ppc/pnv.c > @@ -58,7 +58,7 @@ > > #define FW_FILE_NAME"skiboot.lid" > #define FW_LOAD_ADDR0x0 > -#define FW_MAX_SIZE (4 * MiB) > +#define FW_MAX_SIZE (64 * MiB) > Yeah, I did a similar hack after I realized I only did this hack to version 4.1.0 and not the powernv-4.2 git version. > #define KERNEL_LOAD_ADDR0x2000 > #define KERNEL_MAX_SIZE (256 * MiB) > > and coreboot.rom loads and boots and loops. > > > You can use -d exec,in_asm to check what's going on. > Ended up using -s -S and gdb'ing it. It loops because of endian issues in the coreboot fmap implmentation. That needs to be fixed upstream. > > C.
Re: qemu/powernv: coreboot support?
On 20/10/2019 08:28, David Gibson wrote: > On Sat, Oct 19, 2019 at 11:09:34AM -0500, Marty E. Plummer wrote: >> On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote: >>> On 19/10/2019 17:31, Marty E. Plummer wrote: On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > On 18/10/2019 19:28, Marty E. Plummer wrote: >> Hello, >> >> First off, thank you for the work you've done on the ppc64 support, it >> has been very useful. I'm currently working on a coreboot port for the >> talos ii line of systems (which means more ppc64 support, support >> specifically for the power9 sforza chip, and specific mainboard support. >> My plate is very full lol) and have been using qemu to debug the >> bootblock. >> >> It has been very useful for that, but I'm now at the point where I need >> to jump to romstage, and that's where it gets tricky. qemu parses the rom >> image and looks for a ffs header, locates skiboot on it, and jumps >> straight >> to that. Not exactly ideal for debugging something not produced from >> op-build. > > yes. I suppose you are using my branch powernv-4.2 which adds PNOR support > and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > file to extract the PAYLOAD partition (skiboot). skiboot also detects the > flash and extract the kernel and initramfs from the PNOR. > > However, you can bypass all this internal boot process by simply passing > a -bios option and not passing a MTD device. > Doing so gives me the following error: qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' (this is after I patched the 4mb size limit up) >>> >>> Could you make that rom available ? >>> >> Sure, I think. Not sure about how sending files works in my current mail >> client but will see. Its more or less a 'stock' (as stock as can be for >> a new coreboot target) coreboot.rom file, but I've added some logic into >> the build to fake a pnor ffs header at the end in order to trick hostboot >> bootloader into loading it. > > Ok. Note that the qemu emulated machine doesn't model the hardware > right down to the level of hostboot. That's wy we're just loading > skiboot and jumping straight into it usually. I guess clg's stuff to > load pnor images gets us a little closer to the hardware behaviour, > but I think it's still only a rough approximation. It's really tied to the OpenPOWER firmwares using the HIOMAP protocol to discuss with the BMC and load the flash. We could loosen how QEMU interprets the MTD device and use a property to inform QEMU that this is an OpenPOWER PNOR file and that skiboot and can be loaded from it. Something to discuss. I have applied this small hack to load larger -bios files : --- qemu-powernv-4.2.git.orig/hw/ppc/pnv.c +++ qemu-powernv-4.2.git/hw/ppc/pnv.c @@ -58,7 +58,7 @@ #define FW_FILE_NAME"skiboot.lid" #define FW_LOAD_ADDR0x0 -#define FW_MAX_SIZE (4 * MiB) +#define FW_MAX_SIZE (64 * MiB) #define KERNEL_LOAD_ADDR0x2000 #define KERNEL_MAX_SIZE (256 * MiB) and coreboot.rom loads and boots and loops. You can use -d exec,in_asm to check what's going on. C.
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 10:31:09AM -0500, Marty E. Plummer wrote: > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > > On 18/10/2019 19:28, Marty E. Plummer wrote: > > > Hello, > > > > > > First off, thank you for the work you've done on the ppc64 support, it > > > has been very useful. I'm currently working on a coreboot port for the > > > talos ii line of systems (which means more ppc64 support, support > > > specifically for the power9 sforza chip, and specific mainboard support. > > > My plate is very full lol) and have been using qemu to debug the > > > bootblock. > > > > > > It has been very useful for that, but I'm now at the point where I need > > > to jump to romstage, and that's where it gets tricky. qemu parses the rom > > > image and looks for a ffs header, locates skiboot on it, and jumps > > > straight > > > to that. Not exactly ideal for debugging something not produced from > > > op-build. > > > > yes. I suppose you are using my branch powernv-4.2 which adds PNOR support > > and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > > file to extract the PAYLOAD partition (skiboot). skiboot also detects the > > flash and extract the kernel and initramfs from the PNOR. > > > > However, you can bypass all this internal boot process by simply passing > > a -bios option and not passing a MTD device. > > > Doing so gives me the following error: > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' > (this is after I patched the 4mb size limit up) Hm curious. We'd have to delve into load_image_targphys() and see why it's failing. Have you checked for simple causes: incorrect path, or bad permissions to your coreboot image. > > I haven't published the PNOR support and the boot from PNOR yet. Lack > > of time and because sPAPR is the priority. > > > > > Do you think it would be within your wheelhouse to provide a generic, > > > non-ffs > > > pnor interface for loading arbitary rom images? > > > > I should probably send the PNOR patchset now so that we can discuss on > > a better way to satisfy all needs. > > > > > It would be of great help if > > > you could. (This would still hopefully have the bmc support code as > > > well, as I'm still needing to support a system using one). > > > > We have support for Aspeed machines AST2400, AST2500 and AST2600. It > > is possible to interconnect them through the BT device. Or you can use > > the IPMI BT simulator of QEMU on the PowerNV machine > > > > Thanks, > > > > C. > > > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 11:09:34AM -0500, Marty E. Plummer wrote: > On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote: > > On 19/10/2019 17:31, Marty E. Plummer wrote: > > > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > > >> On 18/10/2019 19:28, Marty E. Plummer wrote: > > >>> Hello, > > >>> > > >>> First off, thank you for the work you've done on the ppc64 support, it > > >>> has been very useful. I'm currently working on a coreboot port for the > > >>> talos ii line of systems (which means more ppc64 support, support > > >>> specifically for the power9 sforza chip, and specific mainboard support. > > >>> My plate is very full lol) and have been using qemu to debug the > > >>> bootblock. > > >>> > > >>> It has been very useful for that, but I'm now at the point where I need > > >>> to jump to romstage, and that's where it gets tricky. qemu parses the > > >>> rom > > >>> image and looks for a ffs header, locates skiboot on it, and jumps > > >>> straight > > >>> to that. Not exactly ideal for debugging something not produced from > > >>> op-build. > > >> > > >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR > > >> support > > >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > > >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the > > >> flash and extract the kernel and initramfs from the PNOR. > > >> > > >> However, you can bypass all this internal boot process by simply passing > > >> a -bios option and not passing a MTD device. > > >> > > > Doing so gives me the following error: > > > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' > > > (this is after I patched the 4mb size limit up) > > > > Could you make that rom available ? > > > Sure, I think. Not sure about how sending files works in my current mail > client but will see. Its more or less a 'stock' (as stock as can be for > a new coreboot target) coreboot.rom file, but I've added some logic into > the build to fake a pnor ffs header at the end in order to trick hostboot > bootloader into loading it. Ok. Note that the qemu emulated machine doesn't model the hardware right down to the level of hostboot. That's wy we're just loading skiboot and jumping straight into it usually. I guess clg's stuff to load pnor images gets us a little closer to the hardware behaviour, but I think it's still only a rough approximation. > > Thanks, > > > > C. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > On 18/10/2019 19:28, Marty E. Plummer wrote: > > Hello, > > > > First off, thank you for the work you've done on the ppc64 support, it > > has been very useful. I'm currently working on a coreboot port for the > > talos ii line of systems (which means more ppc64 support, support > > specifically for the power9 sforza chip, and specific mainboard support. > > My plate is very full lol) and have been using qemu to debug the > > bootblock. > > > > It has been very useful for that, but I'm now at the point where I need > > to jump to romstage, and that's where it gets tricky. qemu parses the rom > > image and looks for a ffs header, locates skiboot on it, and jumps straight > > to that. Not exactly ideal for debugging something not produced from > > op-build. > > yes. I suppose you are using my branch powernv-4.2 which adds PNOR support > and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > file to extract the PAYLOAD partition (skiboot). skiboot also detects the > flash and extract the kernel and initramfs from the PNOR. Ah! Now I understand. I hadn't looked at that branch, so I had no idea what all this pnor stuff was about. In mainline we just load skiboot as a normal firmware file and jump into it. > However, you can bypass all this internal boot process by simply passing > a -bios option and not passing a MTD device. Right. > I haven't published the PNOR support and the boot from PNOR yet. Lack > of time and because sPAPR is the priority. > > > Do you think it would be within your wheelhouse to provide a generic, > > non-ffs > > pnor interface for loading arbitary rom images? > > I should probably send the PNOR patchset now so that we can discuss on > a better way to satisfy all needs. > > > It would be of great help if > > you could. (This would still hopefully have the bmc support code as > > well, as I'm still needing to support a system using one). > > We have support for Aspeed machines AST2400, AST2500 and AST2600. It > is possible to interconnect them through the BT device. Or you can use > the IPMI BT simulator of QEMU on the PowerNV machine > > Thanks, > > C. > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote: > On 19/10/2019 17:31, Marty E. Plummer wrote: > > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > >> On 18/10/2019 19:28, Marty E. Plummer wrote: > >>> Hello, > >>> > >>> First off, thank you for the work you've done on the ppc64 support, it > >>> has been very useful. I'm currently working on a coreboot port for the > >>> talos ii line of systems (which means more ppc64 support, support > >>> specifically for the power9 sforza chip, and specific mainboard support. > >>> My plate is very full lol) and have been using qemu to debug the > >>> bootblock. > >>> > >>> It has been very useful for that, but I'm now at the point where I need > >>> to jump to romstage, and that's where it gets tricky. qemu parses the rom > >>> image and looks for a ffs header, locates skiboot on it, and jumps > >>> straight > >>> to that. Not exactly ideal for debugging something not produced from > >>> op-build. > >> > >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support > >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the > >> flash and extract the kernel and initramfs from the PNOR. > >> > >> However, you can bypass all this internal boot process by simply passing > >> a -bios option and not passing a MTD device. > >> > > Doing so gives me the following error: > > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' > > (this is after I patched the 4mb size limit up) > Oof. My bad, I had only patched the 4.1.0 package, not the live sources from your tree. > Could you make that rom available ? > Turns out the 'not text' warning came from lists.sr.ht, I wonder why that mailed me. > Thanks, > > C.
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote: > On 19/10/2019 17:31, Marty E. Plummer wrote: > > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > >> On 18/10/2019 19:28, Marty E. Plummer wrote: > >>> Hello, > >>> > >>> First off, thank you for the work you've done on the ppc64 support, it > >>> has been very useful. I'm currently working on a coreboot port for the > >>> talos ii line of systems (which means more ppc64 support, support > >>> specifically for the power9 sforza chip, and specific mainboard support. > >>> My plate is very full lol) and have been using qemu to debug the > >>> bootblock. > >>> > >>> It has been very useful for that, but I'm now at the point where I need > >>> to jump to romstage, and that's where it gets tricky. qemu parses the rom > >>> image and looks for a ffs header, locates skiboot on it, and jumps > >>> straight > >>> to that. Not exactly ideal for debugging something not produced from > >>> op-build. > >> > >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support > >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the > >> flash and extract the kernel and initramfs from the PNOR. > >> > >> However, you can bypass all this internal boot process by simply passing > >> a -bios option and not passing a MTD device. > >> > > Doing so gives me the following error: > > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' > > (this is after I patched the 4mb size limit up) > > Could you make that rom available ? > Sent it, but the ml kicked back a 'hey, that's not a normal text file' error, could you confirm if you personally got it? > Thanks, > > C.
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote: > On 19/10/2019 17:31, Marty E. Plummer wrote: > > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > >> On 18/10/2019 19:28, Marty E. Plummer wrote: > >>> Hello, > >>> > >>> First off, thank you for the work you've done on the ppc64 support, it > >>> has been very useful. I'm currently working on a coreboot port for the > >>> talos ii line of systems (which means more ppc64 support, support > >>> specifically for the power9 sforza chip, and specific mainboard support. > >>> My plate is very full lol) and have been using qemu to debug the > >>> bootblock. > >>> > >>> It has been very useful for that, but I'm now at the point where I need > >>> to jump to romstage, and that's where it gets tricky. qemu parses the rom > >>> image and looks for a ffs header, locates skiboot on it, and jumps > >>> straight > >>> to that. Not exactly ideal for debugging something not produced from > >>> op-build. > >> > >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support > >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the > >> flash and extract the kernel and initramfs from the PNOR. > >> > >> However, you can bypass all this internal boot process by simply passing > >> a -bios option and not passing a MTD device. > >> > > Doing so gives me the following error: > > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' > > (this is after I patched the 4mb size limit up) > > Could you make that rom available ? > Sure, I think. Not sure about how sending files works in my current mail client but will see. Its more or less a 'stock' (as stock as can be for a new coreboot target) coreboot.rom file, but I've added some logic into the build to fake a pnor ffs header at the end in order to trick hostboot bootloader into loading it. > Thanks, > > C. coreboot.rom.gz Description: Binary data
Re: qemu/powernv: coreboot support?
On 19/10/2019 17:31, Marty E. Plummer wrote: > On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: >> On 18/10/2019 19:28, Marty E. Plummer wrote: >>> Hello, >>> >>> First off, thank you for the work you've done on the ppc64 support, it >>> has been very useful. I'm currently working on a coreboot port for the >>> talos ii line of systems (which means more ppc64 support, support >>> specifically for the power9 sforza chip, and specific mainboard support. >>> My plate is very full lol) and have been using qemu to debug the >>> bootblock. >>> >>> It has been very useful for that, but I'm now at the point where I need >>> to jump to romstage, and that's where it gets tricky. qemu parses the rom >>> image and looks for a ffs header, locates skiboot on it, and jumps straight >>> to that. Not exactly ideal for debugging something not produced from >>> op-build. >> >> yes. I suppose you are using my branch powernv-4.2 which adds PNOR support >> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR >> file to extract the PAYLOAD partition (skiboot). skiboot also detects the >> flash and extract the kernel and initramfs from the PNOR. >> >> However, you can bypass all this internal boot process by simply passing >> a -bios option and not passing a MTD device. >> > Doing so gives me the following error: > qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' > (this is after I patched the 4mb size limit up) Could you make that rom available ? Thanks, C.
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote: > On 18/10/2019 19:28, Marty E. Plummer wrote: > > Hello, > > > > First off, thank you for the work you've done on the ppc64 support, it > > has been very useful. I'm currently working on a coreboot port for the > > talos ii line of systems (which means more ppc64 support, support > > specifically for the power9 sforza chip, and specific mainboard support. > > My plate is very full lol) and have been using qemu to debug the > > bootblock. > > > > It has been very useful for that, but I'm now at the point where I need > > to jump to romstage, and that's where it gets tricky. qemu parses the rom > > image and looks for a ffs header, locates skiboot on it, and jumps straight > > to that. Not exactly ideal for debugging something not produced from > > op-build. > > yes. I suppose you are using my branch powernv-4.2 which adds PNOR support > and a way to boot directly from PNOR. In that case, QEMU parses the PNOR > file to extract the PAYLOAD partition (skiboot). skiboot also detects the > flash and extract the kernel and initramfs from the PNOR. > > However, you can bypass all this internal boot process by simply passing > a -bios option and not passing a MTD device. > Doing so gives me the following error: qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom' (this is after I patched the 4mb size limit up) > I haven't published the PNOR support and the boot from PNOR yet. Lack > of time and because sPAPR is the priority. > > > Do you think it would be within your wheelhouse to provide a generic, > > non-ffs > > pnor interface for loading arbitary rom images? > > I should probably send the PNOR patchset now so that we can discuss on > a better way to satisfy all needs. > > > It would be of great help if > > you could. (This would still hopefully have the bmc support code as > > well, as I'm still needing to support a system using one). > > We have support for Aspeed machines AST2400, AST2500 and AST2600. It > is possible to interconnect them through the BT device. Or you can use > the IPMI BT simulator of QEMU on the PowerNV machine > > Thanks, > > C. >
Re: qemu/powernv: coreboot support?
On 18/10/2019 19:28, Marty E. Plummer wrote: > Hello, > > First off, thank you for the work you've done on the ppc64 support, it > has been very useful. I'm currently working on a coreboot port for the > talos ii line of systems (which means more ppc64 support, support > specifically for the power9 sforza chip, and specific mainboard support. > My plate is very full lol) and have been using qemu to debug the > bootblock. > > It has been very useful for that, but I'm now at the point where I need > to jump to romstage, and that's where it gets tricky. qemu parses the rom > image and looks for a ffs header, locates skiboot on it, and jumps straight > to that. Not exactly ideal for debugging something not produced from op-build. yes. I suppose you are using my branch powernv-4.2 which adds PNOR support and a way to boot directly from PNOR. In that case, QEMU parses the PNOR file to extract the PAYLOAD partition (skiboot). skiboot also detects the flash and extract the kernel and initramfs from the PNOR. However, you can bypass all this internal boot process by simply passing a -bios option and not passing a MTD device. I haven't published the PNOR support and the boot from PNOR yet. Lack of time and because sPAPR is the priority. > Do you think it would be within your wheelhouse to provide a generic, non-ffs > pnor interface for loading arbitary rom images? I should probably send the PNOR patchset now so that we can discuss on a better way to satisfy all needs. > It would be of great help if > you could. (This would still hopefully have the bmc support code as > well, as I'm still needing to support a system using one). We have support for Aspeed machines AST2400, AST2500 and AST2600. It is possible to interconnect them through the BT device. Or you can use the IPMI BT simulator of QEMU on the PowerNV machine Thanks, C.
Re: qemu/powernv: coreboot support?
On Sat, Oct 19, 2019 at 10:15:19PM +1100, David Gibson wrote: > On Fri, Oct 18, 2019 at 12:28:29PM -0500, Marty E. Plummer wrote: > > Hello, > > > > First off, thank you for the work you've done on the ppc64 support, it > > has been very useful. I'm currently working on a coreboot port for the > > talos ii line of systems (which means more ppc64 support, support > > specifically for the power9 sforza chip, and specific mainboard support. > > My plate is very full lol) and have been using qemu to debug the > > bootblock. > > Ok. I'm assuming that's with the powernv machine type? > Assuming you mean the hardware, yes, the kernel for it is configured with the powernv_defconfig. Assuming that you mean how I call qemu, yes, also powernv: my full command is: qemu-system-ppc64 -cpu power9 -M powernv -m 4G -s -S \ -chardev socket,id=qemu-monitor,host=localhost,port=,server,nowait,telnet \ -mon qemu-monitor,mode=readline -nographic -bios build/cbfs/fallback/bootblock.bin > > It has been very useful for that, but I'm now at the point where I need > > to jump to romstage, and that's where it gets tricky. qemu parses the rom > > image and looks for a ffs header, locates skiboot on it, and jumps straight > > to that. Not exactly ideal for debugging something not produced from > > op-build. > > Um.. I'm not sure what code you're talking about. AFAICT the pnv code > just starts the cpus at address 0x10. > If I pass it the full coreboot.rom file via `-drive file=./build/coreboot.rom,format=raw,if=mtd` it returns this error: 'qemu-system-ppc64: Initialization of device pnv-pnor failed: bad header' which arises in hw/ppc/pnv_pnor.c:136-140 using legoater's powernv-4.2 branch. Ah, so I wasn't going crazy and it was skipping the first four instructions, how odd. Any particular reason the first four instruction are skipped? On hostboot that's setting up the msr; on skiboot that seems to be the fdt_entry branch to boot_entry. > > Do you think it would be within your wheelhouse to provide a generic, > > non-ffs > > pnor interface for loading arbitary rom images? It would be of great help if > > you could. (This would still hopefully have the bmc support code as > > well, as I'm still needing to support a system using one). > > Uh.. and I'm not really sure what you're asking for here. > Basically not have to have a pnor-style image for mtd devices, and not immidiatly jump to skiboot. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au| minimalist, thank you. NOT _the_ > _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson
Re: qemu/powernv: coreboot support?
On Fri, Oct 18, 2019 at 12:28:29PM -0500, Marty E. Plummer wrote: > Hello, > > First off, thank you for the work you've done on the ppc64 support, it > has been very useful. I'm currently working on a coreboot port for the > talos ii line of systems (which means more ppc64 support, support > specifically for the power9 sforza chip, and specific mainboard support. > My plate is very full lol) and have been using qemu to debug the > bootblock. Ok. I'm assuming that's with the powernv machine type? > It has been very useful for that, but I'm now at the point where I need > to jump to romstage, and that's where it gets tricky. qemu parses the rom > image and looks for a ffs header, locates skiboot on it, and jumps straight > to that. Not exactly ideal for debugging something not produced from > op-build. Um.. I'm not sure what code you're talking about. AFAICT the pnv code just starts the cpus at address 0x10. > Do you think it would be within your wheelhouse to provide a generic, non-ffs > pnor interface for loading arbitary rom images? It would be of great help if > you could. (This would still hopefully have the bmc support code as > well, as I'm still needing to support a system using one). Uh.. and I'm not really sure what you're asking for here. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
qemu/powernv: coreboot support?
Hello, First off, thank you for the work you've done on the ppc64 support, it has been very useful. I'm currently working on a coreboot port for the talos ii line of systems (which means more ppc64 support, support specifically for the power9 sforza chip, and specific mainboard support. My plate is very full lol) and have been using qemu to debug the bootblock. It has been very useful for that, but I'm now at the point where I need to jump to romstage, and that's where it gets tricky. qemu parses the rom image and looks for a ffs header, locates skiboot on it, and jumps straight to that. Not exactly ideal for debugging something not produced from op-build. Do you think it would be within your wheelhouse to provide a generic, non-ffs pnor interface for loading arbitary rom images? It would be of great help if you could. (This would still hopefully have the bmc support code as well, as I'm still needing to support a system using one). Regards, Marty
