Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

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.