* Re: qemu/powernv: coreboot support?
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-19 18:51 ` Marty E. Plummer
2019-10-19 19:23 ` Marty E. Plummer
2 siblings, 1 reply; 24+ messages in thread
From: Marty E. Plummer @ 2019-10-19 16:09 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Joel Stanley, qemu-ppc, qemu-devel, David Gibson
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-19 16:09 ` Marty E. Plummer
@ 2019-10-20 6:28 ` David Gibson
2019-10-20 6:51 ` Cédric Le Goater
0 siblings, 1 reply; 24+ messages in thread
From: David Gibson @ 2019-10-20 6:28 UTC (permalink / raw)
To: Marty E. Plummer
Cc: Joel Stanley, qemu-ppc, Cédric Le Goater, qemu-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
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
0 siblings, 2 replies; 24+ messages in thread
From: Cédric Le Goater @ 2019-10-20 6:51 UTC (permalink / raw)
To: David Gibson, Marty E. Plummer; +Cc: qemu-ppc, qemu-devel, Joel Stanley
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-20 6:51 ` Cédric Le Goater
@ 2019-10-20 16:32 ` Marty E. Plummer
2019-10-21 5:34 ` David Gibson
1 sibling, 0 replies; 24+ messages in thread
From: Marty E. Plummer @ 2019-10-20 16:32 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Joel Stanley, qemu-ppc, qemu-devel, 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:
> > 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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-20 6:51 ` Cédric Le Goater
2019-10-20 16:32 ` Marty E. Plummer
@ 2019-10-21 5:34 ` David Gibson
2019-10-21 12:46 ` Cédric Le Goater
1 sibling, 1 reply; 24+ messages in thread
From: David Gibson @ 2019-10-21 5:34 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Marty E. Plummer, qemu-ppc, qemu-devel, Joel Stanley
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-21 5:34 ` David Gibson
@ 2019-10-21 12:46 ` Cédric Le Goater
2019-10-22 0:32 ` Marty E. Plummer
0 siblings, 1 reply; 24+ messages in thread
From: Cédric Le Goater @ 2019-10-21 12:46 UTC (permalink / raw)
To: David Gibson; +Cc: Marty E. Plummer, qemu-ppc, qemu-devel, Joel Stanley
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.
>>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
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 7:58 ` Cédric Le Goater
0 siblings, 2 replies; 24+ messages in thread
From: Marty E. Plummer @ 2019-10-22 0:32 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Joel Stanley, qemu-ppc, qemu-devel, David Gibson
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
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:58 ` Cédric Le Goater
1 sibling, 1 reply; 24+ messages in thread
From: David Gibson @ 2019-10-22 1:40 UTC (permalink / raw)
To: Marty E. Plummer
Cc: Joel Stanley, qemu-ppc, Cédric Le Goater, qemu-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-22 1:40 ` David Gibson
@ 2019-10-22 2:17 ` Marty E. Plummer
2019-10-22 7:55 ` David Gibson
0 siblings, 1 reply; 24+ messages in thread
From: Marty E. Plummer @ 2019-10-22 2:17 UTC (permalink / raw)
To: David Gibson; +Cc: Joel Stanley, qemu-ppc, Cédric Le Goater, qemu-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-22 2:17 ` Marty E. Plummer
@ 2019-10-22 7:55 ` David Gibson
0 siblings, 0 replies; 24+ messages in thread
From: David Gibson @ 2019-10-22 7:55 UTC (permalink / raw)
To: Marty E. Plummer
Cc: Joel Stanley, qemu-ppc, Cédric Le Goater, qemu-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-22 0:32 ` Marty E. Plummer
2019-10-22 1:40 ` David Gibson
@ 2019-10-22 7:58 ` Cédric Le Goater
2019-10-23 21:41 ` Marty E. Plummer
1 sibling, 1 reply; 24+ messages in thread
From: Cédric Le Goater @ 2019-10-22 7:58 UTC (permalink / raw)
To: Marty E. Plummer; +Cc: Joel Stanley, qemu-ppc, qemu-devel, David Gibson
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-22 7:58 ` Cédric Le Goater
@ 2019-10-23 21:41 ` Marty E. Plummer
0 siblings, 0 replies; 24+ messages in thread
From: Marty E. Plummer @ 2019-10-23 21:41 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Joel Stanley, qemu-ppc, qemu-devel, David Gibson
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-19 15:53 ` Cédric Le Goater
2019-10-19 16:09 ` Marty E. Plummer
@ 2019-10-19 18:51 ` Marty E. Plummer
2019-10-19 19:23 ` Marty E. Plummer
2 siblings, 0 replies; 24+ messages in thread
From: Marty E. Plummer @ 2019-10-19 18:51 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Joel Stanley, qemu-ppc, qemu-devel, David Gibson
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-19 15:53 ` Cédric Le Goater
2019-10-19 16:09 ` 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
2 siblings, 1 reply; 24+ messages in thread
From: Marty E. Plummer @ 2019-10-19 19:23 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Joel Stanley, qemu-ppc, qemu-devel, David Gibson
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-19 19:23 ` Marty E. Plummer
@ 2019-10-20 19:48 ` Peter Maydell
2019-10-21 9:51 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 24+ messages in thread
From: Peter Maydell @ 2019-10-20 19:48 UTC (permalink / raw)
To: Marty E. Plummer
Cc: QEMU Developers, Joel Stanley, qemu-ppc, Cédric Le Goater,
Philippe Mathieu-Daudé,
David Gibson
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: qemu/powernv: coreboot support?
2019-10-20 19:48 ` Peter Maydell
@ 2019-10-21 9:51 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 24+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-10-21 9:51 UTC (permalink / raw)
To: Peter Maydell, Marty E. Plummer
Cc: QEMU Developers, David Gibson, qemu-ppc, Cédric Le Goater,
Joel Stanley
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.
^ permalink raw reply [flat|nested] 24+ messages in thread