Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

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:
>>> On Sat, Oct 19, 2019 at 11:09:34AM -0500, Marty E. Plummer wrote:
>>>> On Sat, Oct 19, 2019 at 05:53:12PM +0200, Cédric Le Goater wrote:
>>>>> On 19/10/2019 17:31, Marty E. Plummer wrote:
>>>>>> On Sat, Oct 19, 2019 at 03:46:59PM +0200, Cédric Le Goater wrote:
>>>>>>> On 18/10/2019 19:28, Marty E. Plummer wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> First off, thank you for the work you've done on the ppc64 support, it
>>>>>>>> has been very useful. I'm currently working on a coreboot port for the
>>>>>>>> talos ii line of systems (which means more ppc64 support, support
>>>>>>>> specifically for the power9 sforza chip, and specific mainboard 
>>>>>>>> support.
>>>>>>>> My plate is very full lol) and have been using qemu to debug the
>>>>>>>> bootblock.
>>>>>>>>
>>>>>>>> It has been very useful for that, but I'm now at the point where I need
>>>>>>>> to jump to romstage, and that's where it gets tricky. qemu parses the 
>>>>>>>> rom
>>>>>>>> image and looks for a ffs header, locates skiboot on it, and jumps 
>>>>>>>> straight
>>>>>>>> to that. Not exactly ideal for debugging something not produced from 
>>>>>>>> op-build.
>>>>>>>
>>>>>>> yes. I suppose you are using my branch powernv-4.2 which adds PNOR 
>>>>>>> support
>>>>>>> and a way to boot directly from PNOR. In that case, QEMU parses the PNOR
>>>>>>> file to extract the PAYLOAD partition (skiboot). skiboot also detects 
>>>>>>> the
>>>>>>> flash and extract the kernel and initramfs from the PNOR.
>>>>>>>
>>>>>>> However, you can bypass all this internal boot process by simply passing
>>>>>>> a -bios option and not passing a MTD device.
>>>>>>>
>>>>>> Doing so gives me the following error:
>>>>>> qemu-system-ppc64: Could not load OPAL firmware 'build/coreboot.rom'
>>>>>> (this is after I patched the 4mb size limit up)
>>>>>
>>>>> Could you make that rom available ? 
>>>>>
>>>> Sure, I think. Not sure about how sending files works in my current mail
>>>> client but will see. Its more or less a 'stock' (as stock as can be for
>>>> a new coreboot target) coreboot.rom file, but I've added some logic into
>>>> the build to fake a pnor ffs header at the end in order to trick hostboot
>>>> bootloader into loading it.
>>>
>>> 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.
>>
>> 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. 

I will sense the patches I have on the topic.

C. 


>> I have applied this small hack to load larger -bios files :
>>  
>> --- qemu-powernv-4.2.git.orig/hw/ppc/pnv.c
>> +++ qemu-powernv-4.2.git/hw/ppc/pnv.c
>> @@ -58,7 +58,7 @@
>>  
>>  #define FW_FILE_NAME            "skiboot.lid"
>>  #define FW_LOAD_ADDR            0x0
>> -#define FW_MAX_SIZE             (4 * MiB)
>> +#define FW_MAX_SIZE             (64 * MiB)
>>  
>>  #define KERNEL_LOAD_ADDR        0x20000000
>>  #define KERNEL_MAX_SIZE         (256 * MiB)
>>
>> and coreboot.rom loads and boots and loops.
>>
>>
>> You can use -d exec,in_asm to check what's going on.
>>
>>
>> C.
>>
>