qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu/powernv: coreboot support?


From: Cédric Le Goater
Subject: Re: qemu/powernv: coreboot support?
Date: Sun, 20 Oct 2019 08:51:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

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.


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]