qemu-ppc
[Top][All Lists]
Advanced

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

Re: qemu/powernv: coreboot support?


From: Marty E. Plummer
Subject: Re: qemu/powernv: coreboot support?
Date: Sun, 20 Oct 2019 11:32:55 -0500

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.
> 
Yeah, but its useful enough to see that my rough understanding of ppc64
assembly is more/less correct (using the hostboot/skiboot sources as a
reference [both are elfv1] to write coreboot [I'm using elfv2] is a bit
fun)
> 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.
> 
Yeah, it would be useful to be able to use a non-pnor mtd device but
still get the hiomap behavior, because that's what I'll be dealing with
on real hardware.
> 
> 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)
>  
Yeah, I did a similar hack after I realized I only did this hack to
version 4.1.0 and not the powernv-4.2 git version.
>  #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.
> 
Ended up using -s -S and gdb'ing it. It loops because of endian issues
in the coreboot fmap implmentation. That needs to be fixed upstream.
> 
> C.



reply via email to

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