qemu/powernv: coreboot support?

qemu/powernv: coreboot support?

[Marty E. Plummer]

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.

Do you think it would be within your wheelhouse to provide a generic, non-ffs
pnor interface for loading arbitary rom images? It would be of great help if
you could. (This would still hopefully have the bmc support code as
well, as I'm still needing to support a system using one).

Regards,
Marty

Re: qemu/powernv: coreboot support?

[David Gibson]

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

On Fri, Oct 18, 2019 at 12:28:29PM -0500, 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.

Ok.  I'm assuming that's with the powernv machine type?

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

Um.. I'm not sure what code you're talking about.  AFAICT the pnv code
just starts the cpus at address 0x10.

> Do you think it would be within your wheelhouse to provide a generic, non-ffs
> pnor interface for loading arbitary rom images? It would be of great help if
> you could. (This would still hopefully have the bmc support code as
> well, as I'm still needing to support a system using one).

Uh.. and I'm not really sure what you're asking for here.

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

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Sat, Oct 19, 2019 at 10:15:19PM +1100, David Gibson wrote:
> On Fri, Oct 18, 2019 at 12:28:29PM -0500, 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.
> 
> Ok.  I'm assuming that's with the powernv machine type?
> 
Assuming you mean the hardware, yes, the kernel for it is configured
with the powernv_defconfig.

Assuming that you mean how I call qemu, yes, also powernv: my full
command is:

qemu-system-ppc64 -cpu power9 -M powernv -m 4G -s -S \
-chardev socket,id=qemu-monitor,host=localhost,port=7777,server,nowait,telnet \
-mon qemu-monitor,mode=readline -nographic -bios build/cbfs/fallback/bootblock.bin
> > 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.
> 
> Um.. I'm not sure what code you're talking about.  AFAICT the pnv code
> just starts the cpus at address 0x10.
> 
If I pass it the full coreboot.rom file via
`-drive file=./build/coreboot.rom,format=raw,if=mtd` it returns this error:
'qemu-system-ppc64: Initialization of device pnv-pnor failed: bad header'
which arises in hw/ppc/pnv_pnor.c:136-140 using legoater's powernv-4.2
branch.

Ah, so I wasn't going crazy and it was skipping the first four instructions,
how odd. Any particular reason the first four instruction are skipped?
On hostboot that's setting up the msr; on skiboot that seems to be the
fdt_entry branch to boot_entry.
> > Do you think it would be within your wheelhouse to provide a generic, non-ffs
> > pnor interface for loading arbitary rom images? It would be of great help if
> > you could. (This would still hopefully have the bmc support code as
> > well, as I'm still needing to support a system using one).
> 
> Uh.. and I'm not really sure what you're asking for here.
> 
Basically not have to have a pnor-style image for mtd devices, and not
immidiatly jump to skiboot.
> -- 
> 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

Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

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.

I haven't published the PNOR support and the boot from PNOR yet. Lack
of time and because sPAPR is the priority.

> Do you think it would be within your wheelhouse to provide a generic, non-ffs
> pnor interface for loading arbitary rom images? 

I should probably send the PNOR patchset now so that we can discuss on 
a better way to satisfy all needs.  

> It would be of great help if
> you could. (This would still hopefully have the bmc support code as
> well, as I'm still needing to support a system using one).

We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
is possible to interconnect them through the BT device. Or you can use
the IPMI BT simulator of QEMU on the PowerNV machine

Thanks,

C. 

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

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)
> I haven't published the PNOR support and the boot from PNOR yet. Lack
> of time and because sPAPR is the priority.
> 
> > Do you think it would be within your wheelhouse to provide a generic, non-ffs
> > pnor interface for loading arbitary rom images? 
> 
> I should probably send the PNOR patchset now so that we can discuss on 
> a better way to satisfy all needs.  
> 
> > It would be of great help if
> > you could. (This would still hopefully have the bmc support code as
> > well, as I'm still needing to support a system using one).
> 
> We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
> is possible to interconnect them through the BT device. Or you can use
> the IPMI BT simulator of QEMU on the PowerNV machine
> 
> Thanks,
> 
> C. 
> 

Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

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 ? 

Thanks,

C. 

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

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

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.
> Thanks,
> 
> C. 

[-- Attachment #2: coreboot.rom.gz --]
[-- Type: application/octet-stream, Size: 102985 bytes --]

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

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 ? 
> 
Sent it, but the ml kicked back a 'hey, that's not a normal text file'
error, could you confirm if you personally got it?
> Thanks,
> 
> C. 

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

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)
> 
Oof. My bad, I had only patched the 4.1.0 package, not the live sources
from your tree.
> Could you make that rom available ? 
> 
Turns out the 'not text' warning came from lists.sr.ht, I wonder why
that mailed me.
> Thanks,
> 
> C. 

Re: qemu/powernv: coreboot support?

[David Gibson]

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

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.

Ah!  Now I understand.  I hadn't looked at that branch, so I had no
idea what all this pnor stuff was about.  In mainline we just load
skiboot as a normal firmware file and jump into it.

> However, you can bypass all this internal boot process by simply passing
> a -bios option and not passing a MTD device.

Right.

> I haven't published the PNOR support and the boot from PNOR yet. Lack
> of time and because sPAPR is the priority.
> 
> > Do you think it would be within your wheelhouse to provide a generic, non-ffs
> > pnor interface for loading arbitary rom images? 
> 
> I should probably send the PNOR patchset now so that we can discuss on 
> a better way to satisfy all needs.  
> 
> > It would be of great help if
> > you could. (This would still hopefully have the bmc support code as
> > well, as I'm still needing to support a system using one).
> 
> We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
> is possible to interconnect them through the BT device. Or you can use
> the IPMI BT simulator of QEMU on the PowerNV machine
> 
> Thanks,
> 
> 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 --]

Re: qemu/powernv: coreboot support?

[David Gibson]

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

On Sat, Oct 19, 2019 at 10:31:09AM -0500, 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)

Hm curious.  We'd have to delve into load_image_targphys() and see why
it's failing.  Have you checked for simple causes: incorrect path, or
bad permissions to your coreboot image.

> > I haven't published the PNOR support and the boot from PNOR yet. Lack
> > of time and because sPAPR is the priority.
> > 
> > > Do you think it would be within your wheelhouse to provide a generic, non-ffs
> > > pnor interface for loading arbitary rom images? 
> > 
> > I should probably send the PNOR patchset now so that we can discuss on 
> > a better way to satisfy all needs.  
> > 
> > > It would be of great help if
> > > you could. (This would still hopefully have the bmc support code as
> > > well, as I'm still needing to support a system using one).
> > 
> > We have support for Aspeed machines AST2400, AST2500 and AST2600. It 
> > is possible to interconnect them through the BT device. Or you can use
> > the IPMI BT simulator of QEMU on the PowerNV machine
> > 
> > Thanks,
> > 
> > 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 --]

Re: qemu/powernv: coreboot support?

[David Gibson]

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

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.

> > Thanks,
> > 
> > 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 --]

Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

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.

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

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.

Re: qemu/powernv: coreboot support?

[Peter Maydell]

On Sat, 19 Oct 2019 at 20:24, Marty E. Plummer <hanetzer@startmail.com> wrote:
> Turns out the 'not text' warning came from lists.sr.ht, I wonder why
> that mailed me.

It's just an individual subscribed address that complains,
not the qemu mailing list itself.

Philippe, did you say it was you that had subscribed
a lists.sr.ht address ? Could you configure it not
to complain to individual list senders? Failing that,
would it be too annoying to unsubscribe it? At the moment
it mostly seems to confuse people.

The other alternative here is I could turn back on the
qemu-devel list facility that turns HTML emails into plain
text. I sort of didn't want to do that, though, as editing
emails means we end up with from-header mangling if the
sender has a strict dmarc/dkim setup...

thanks
-- PMM

Re: qemu/powernv: coreboot support?

[David Gibson]

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

Re: qemu/powernv: coreboot support?

[Philippe Mathieu-Daudé]

On 10/20/19 9:48 PM, Peter Maydell wrote:
> On Sat, 19 Oct 2019 at 20:24, Marty E. Plummer <hanetzer@startmail.com> wrote:
>> Turns out the 'not text' warning came from lists.sr.ht, I wonder why
>> that mailed me.
> 
> It's just an individual subscribed address that complains,
> not the qemu mailing list itself.
> 
> Philippe, did you say it was you that had subscribed
> a lists.sr.ht address ? Could you configure it not
> to complain to individual list senders? Failing that,
> would it be too annoying to unsubscribe it? At the moment
> it mostly seems to confuse people.

Unfortunately it is not very configurable, so I simply unsubscribed it
(no problem, it was just an experiment with sr.ht which provide fancy
features such a similar patchwork system and repository, but we use
patchew).

> The other alternative here is I could turn back on the
> qemu-devel list facility that turns HTML emails into plain
> text. I sort of didn't want to do that, though, as editing
> emails means we end up with from-header mangling if the
> sender has a strict dmarc/dkim setup...

Agreed, no need to go back to this.

Sorry for the noise with this experiment.

Regards,

Phil.

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

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote:
> 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:
> >>>
> >>> 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.
> >>
On that note, is qemu-ppc64 currently capable of running LE firmware? My
coreboot port has currently reached a hitch in that part of the firmware
headers mapping stuff out is saved in LE mode while the cpu (real or emu)
is running in BE mode (FMAP headers are saved LE but CBFS headers are
saved BE)
> >> 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. 
> 
Honestly getting the coreboot.rom into the lpc fw addr space in the same
way you do pnor images would be a useful sim, as that's more or less how
its going to be done on existing hardware.
> I will sense the patches I have on the topic.
> 
> C. 

Re: qemu/powernv: coreboot support?

[David Gibson]

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

On Mon, Oct 21, 2019 at 07:32:09PM -0500, Marty E. Plummer wrote:
> On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote:
> > 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:
> > >>>
> > >>> 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.
> > >>
> On that note, is qemu-ppc64 currently capable of running LE
> firmware?

Well.. "qemu-ppc64" as such isn't capable of running either LE or
firmware, since that's the Linux userspace emulator.
qemu-system-ppc64 *is* capable of running both LE and BE firmwares though.

Your firmware will, however, need a tiny BE shim to switch the cpu
into LE mode.

> My
> coreboot port has currently reached a hitch in that part of the firmware
> headers mapping stuff out is saved in LE mode while the cpu (real or emu)
> is running in BE mode (FMAP headers are saved LE but CBFS headers are
> saved BE)
> > >> 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. 
> > 
> Honestly getting the coreboot.rom into the lpc fw addr space in the same
> way you do pnor images would be a useful sim, as that's more or less how
> its going to be done on existing hardware.
> > I will sense the patches I have on the topic.
> > 
> > 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 --]

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Tue, Oct 22, 2019 at 12:40:32PM +1100, David Gibson wrote:
> On Mon, Oct 21, 2019 at 07:32:09PM -0500, Marty E. Plummer wrote:
> > On that note, is qemu-ppc64 currently capable of running LE
> > firmware?
> 
> Well.. "qemu-ppc64" as such isn't capable of running either LE or
> firmware, since that's the Linux userspace emulator.
> qemu-system-ppc64 *is* capable of running both LE and BE firmwares though.
> 
Ah. yeah, that's what I meant. Good to know.
> Your firmware will, however, need a tiny BE shim to switch the cpu
> into LE mode.
> 
Yeah, I figured as much, and was planning to have a shim available for
'real' hardware in the event a user wants to run coreboot in LE mode
after both work properly (though somewhere in the OpenPOWER spec it is
stated firmware must be BE).
> -- 
> 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

Re: qemu/powernv: coreboot support?

[David Gibson]

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

On Mon, Oct 21, 2019 at 09:17:55PM -0500, Marty E. Plummer wrote:
> On Tue, Oct 22, 2019 at 12:40:32PM +1100, David Gibson wrote:
> > On Mon, Oct 21, 2019 at 07:32:09PM -0500, Marty E. Plummer wrote:
> > > On that note, is qemu-ppc64 currently capable of running LE
> > > firmware?
> > 
> > Well.. "qemu-ppc64" as such isn't capable of running either LE or
> > firmware, since that's the Linux userspace emulator.
> > qemu-system-ppc64 *is* capable of running both LE and BE firmwares though.
> > 
> Ah. yeah, that's what I meant. Good to know.

Paul Mackerras came up with some magic code that can get you from an
unknown endian state to a known state.

> > Your firmware will, however, need a tiny BE shim to switch the cpu
> > into LE mode.
> > 
> Yeah, I figured as much, and was planning to have a shim available for
> 'real' hardware in the event a user wants to run coreboot in LE mode
> after both work properly (though somewhere in the OpenPOWER spec it is
> stated firmware must be BE).

TBH, it makes no sense to specify the endianness of the firmware -
it's an internal detail.  The endianness of the firmware *interfaces*
needs to be fixed of course, but not the endianness of the
implementation.

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

Re: qemu/powernv: coreboot support?

[Cédric Le Goater]

On 22/10/2019 02:32, Marty E. Plummer wrote:
> On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote:
>> 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:
>>>>>
>>>>> 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.
>>>>
> On that note, is qemu-ppc64 currently capable of running LE firmware? My
> coreboot port has currently reached a hitch in that part of the firmware
> headers mapping stuff out is saved in LE mode while the cpu (real or emu)
> is running in BE mode (FMAP headers are saved LE but CBFS headers are
> saved BE)
>>>> 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. 
>>
> Honestly getting the coreboot.rom into the lpc fw addr space in the same
> way you do pnor images would be a useful sim, as that's more or less how
> its going to be done on existing hardware.

That is covered by patch 'ppc/pnv: Add HIOMAP commands' in the series
I sent.

C. 

Re: qemu/powernv: coreboot support?

[Marty E. Plummer]

On Tue, Oct 22, 2019 at 09:58:10AM +0200, Cédric Le Goater wrote:
> On 22/10/2019 02:32, Marty E. Plummer wrote:
> > On Mon, Oct 21, 2019 at 02:46:59PM +0200, Cédric Le Goater wrote:
> >> 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:
> >>>>>
> >>>>> 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.
> >>>>
> > On that note, is qemu-ppc64 currently capable of running LE firmware? My
> > coreboot port has currently reached a hitch in that part of the firmware
> > headers mapping stuff out is saved in LE mode while the cpu (real or emu)
> > is running in BE mode (FMAP headers are saved LE but CBFS headers are
> > saved BE)
> >>>> 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. 
> >>
> > Honestly getting the coreboot.rom into the lpc fw addr space in the same
> > way you do pnor images would be a useful sim, as that's more or less how
> > its going to be done on existing hardware.
> 
> That is covered by patch 'ppc/pnv: Add HIOMAP commands' in the series
> I sent.
> 
Unless I'm mistaken I have that patch in my build (I assume you pulled
that right from your git branch powernv-4.2, which is what I built from)
and that it would still parse and look for the skiboot partition, and
run it. I need something akin to 'hey, shove this at the addr space and
start executing $bios (where bios is either the bottom of the flash in
that addr space or a provided -bios file on the command line).

The final intent after the first 'conversion' flash is that the coreboot
bootblock will reside in the seeprom, akin to current hostboot bootloader,
and then pull romstage from the flash over lpc into cache, then after
romstage initializes memory pull ramstage into from the flash over lpc
into ram and start executing that.
> C.