Re: qemu/powernv: coreboot support?

[David Gibson]

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