Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

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.