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
