qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: "Marty E. Plummer" <hanetzer@startmail.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	Joel Stanley <joel@jms.id.au>
Subject: Re: qemu/powernv: coreboot support?
Date: Mon, 21 Oct 2019 16:34:39 +1100	[thread overview]
Message-ID: <20191021053439.GA6439@umbus.fritz.box> (raw)
In-Reply-To: <0a7cbd9b-2c46-259d-4e0d-9084ee2875a3@kaod.org>

[-- Attachment #1: Type: text/plain, Size: 3978 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2019-10-21  6:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18 17:28 qemu/powernv: coreboot support? Marty E. Plummer
2019-10-19 11:15 ` David Gibson
2019-10-19 12:28   ` Marty E. Plummer
2019-10-19 13:46 ` Cédric Le Goater
2019-10-19 15:31   ` Marty E. Plummer
2019-10-19 15:53     ` Cédric Le Goater
2019-10-19 16:09       ` Marty E. Plummer
2019-10-20  6:28         ` David Gibson
2019-10-20  6:51           ` Cédric Le Goater
2019-10-20 16:32             ` Marty E. Plummer
2019-10-21  5:34             ` David Gibson [this message]
2019-10-21 12:46               ` Cédric Le Goater
2019-10-22  0:32                 ` Marty E. Plummer
2019-10-22  1:40                   ` David Gibson
2019-10-22  2:17                     ` Marty E. Plummer
2019-10-22  7:55                       ` David Gibson
2019-10-22  7:58                   ` Cédric Le Goater
2019-10-23 21:41                     ` Marty E. Plummer
2019-10-19 18:51       ` Marty E. Plummer
2019-10-19 19:23       ` Marty E. Plummer
2019-10-20 19:48         ` Peter Maydell
2019-10-21  9:51           ` Philippe Mathieu-Daudé
2019-10-20  6:26     ` David Gibson
2019-10-20  6:24   ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191021053439.GA6439@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=clg@kaod.org \
    --cc=hanetzer@startmail.com \
    --cc=joel@jms.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).