Re: qemu/powernv: coreboot support?

[David Gibson]

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.

> 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.
> 

-- 
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