Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

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.