Just for entertainment value; with this applied, 8.5 will successfully get all the way to beyond quiesce(). I didn't think about whether this actually makes any sense at all (presumably not), beware. --- arch/ppc/qemu/init.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 2b5b8e1..667eb6a 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -912,6 +912,20 @@ arch_of_init(void) size *= 2; set_property(ph, "rtas-size", (char*)&size, sizeof(size)); set_int_property(ph, "rtas-version", is_apple() ? 0x41 : 1); + set_int_property(ph, "restart-rtas", 0xabcdef01); + set_int_property(ph, "nvram-fetch", 0xabcdef02); + set_int_property(ph, "nvram-store", 0xabcdef03); + set_int_property(ph, "get-time-of-day", 0xabcdef04); + set_int_property(ph, "set-time-of-day", 0xabcdef05); + set_int_property(ph, "set-time-for-power-on", 0xabcdef06); + set_int_property(ph, "event-scan", 0xabcdef07); + set_int_property(ph, "check-exception", 0xabcdef08); + set_int_property(ph, "read-pci-config", 0xabcdef09); + set_int_property(ph, "write-pci-config", 0xabcdef0a); + set_int_property(ph, "set-indicator", 0xabcdef0c); + set_int_property(ph, "power-off", 0xabcdef12); + set_int_property(ph, "system-reboot", 0xabcdef15); + set_int_property(ph, "get-time-for-power-on", 0xabcdef1e); } break; }
On 03/02/16 22:06, Alyssa Milburn wrote:
Just for entertainment value; with this applied, 8.5 will successfully get all the way to beyond quiesce(). I didn't think about whether this actually makes any sense at all (presumably not), beware.
arch/ppc/qemu/init.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 2b5b8e1..667eb6a 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -912,6 +912,20 @@ arch_of_init(void) size *= 2; set_property(ph, "rtas-size", (char*)&size, sizeof(size)); set_int_property(ph, "rtas-version", is_apple() ? 0x41 : 1);
set_int_property(ph, "restart-rtas", 0xabcdef01);set_int_property(ph, "nvram-fetch", 0xabcdef02);set_int_property(ph, "nvram-store", 0xabcdef03);set_int_property(ph, "get-time-of-day", 0xabcdef04);set_int_property(ph, "set-time-of-day", 0xabcdef05);set_int_property(ph, "set-time-for-power-on", 0xabcdef06);set_int_property(ph, "event-scan", 0xabcdef07);set_int_property(ph, "check-exception", 0xabcdef08);set_int_property(ph, "read-pci-config", 0xabcdef09);set_int_property(ph, "write-pci-config", 0xabcdef0a);set_int_property(ph, "set-indicator", 0xabcdef0c);set_int_property(ph, "power-off", 0xabcdef12);set_int_property(ph, "system-reboot", 0xabcdef15);set_int_property(ph, "get-time-for-power-on", 0xabcdef1e); } break;
Ha cool - this is based on MOL's device tree, right? :) There is actually some RTAS code in OpenBIOS but it is disabled by default - check out config/examples/ppc_config.xml and CONFIG_RTAS. I've no idea if it was ever finished or is any good though.
Note that as this is a CONFIG option in order to test you'll need to blow away your build tree, i.e.
rm -rf obj-ppc/ ... (enable CONFIG_RTAS in ppc_config.xml) ... ./config/scripts/switch-arch ppc make
ATB,
Mark.
On Wed, Feb 03, 2016 at 10:23:19PM +0000, Mark Cave-Ayland wrote:
Ha cool - this is based on MOL's device tree, right? :) There is
I actually copied it from real hardware, but now that you mention it, I wonder if it's useful to go through the MOL tree and check for differences (the escc-legacy properties seem correct in mol, for example)..
actually some RTAS code in OpenBIOS but it is disabled by default - check out config/examples/ppc_config.xml and CONFIG_RTAS. I've no idea if it was ever finished or is any good though.
Note that as this is a CONFIG option in order to test you'll need to blow away your build tree, i.e.
rm -rf obj-ppc/ ... (enable CONFIG_RTAS in ppc_config.xml) ... ./config/scripts/switch-arch ppc make
Right, the above patch assumes you already did that. (You also have to run Adler32 before booting because you need the copyright word, as discussed in the emaculation thread.)
If I grep for spapr_rtas_register calls in qemu, then it seems to add most of these properties to the OF tree as it initialises the hardware, so I guess the correct patch would be to do something similar on the qemu side? (The IBM rtas code seems very overcomplicated compared to qemu's trivial implementaton, so I guess trying to reuse it would be more trouble than it's worth.)
- Alyssa
On 03/02/16 22:56, Alyssa Milburn wrote:
On Wed, Feb 03, 2016 at 10:23:19PM +0000, Mark Cave-Ayland wrote:
Ha cool - this is based on MOL's device tree, right? :) There is
I actually copied it from real hardware, but now that you mention it, I wonder if it's useful to go through the MOL tree and check for differences (the escc-legacy properties seem correct in mol, for example)..
actually some RTAS code in OpenBIOS but it is disabled by default - check out config/examples/ppc_config.xml and CONFIG_RTAS. I've no idea if it was ever finished or is any good though.
Note that as this is a CONFIG option in order to test you'll need to blow away your build tree, i.e.
rm -rf obj-ppc/ ... (enable CONFIG_RTAS in ppc_config.xml) ... ./config/scripts/switch-arch ppc make
Right, the above patch assumes you already did that. (You also have to run Adler32 before booting because you need the copyright word, as discussed in the emaculation thread.)
Okay no worries. I just wanted to double-check as I didn't see any reference to CONIFG_RTAS when I was looking at the patch.
If I grep for spapr_rtas_register calls in qemu, then it seems to add most of these properties to the OF tree as it initialises the hardware, so I guess the correct patch would be to do something similar on the qemu side? (The IBM rtas code seems very overcomplicated compared to qemu's trivial implementaton, so I guess trying to reuse it would be more trouble than it's worth.)
Would calls to words in /rtas be given over the the client interface? If so try enabling DEBUG_CIF in libopenbios/client.c which will dump all of the CIF requests out to the serial port which could help here.
ATB,
Mark.
On 03/02/16 22:56, Alyssa Milburn wrote:
On Wed, Feb 03, 2016 at 10:23:19PM +0000, Mark Cave-Ayland wrote:
Ha cool - this is based on MOL's device tree, right? :) There is
I actually copied it from real hardware, but now that you mention it, I wonder if it's useful to go through the MOL tree and check for differences (the escc-legacy properties seem correct in mol, for example)..
I forgot to add here: we used MOL as the reference for GSoC since it is known to be able to boot OS 9.2, and of course having the source means it is possible to add logging at certain points to compare the behaviour with QEMU.
ATB,
Mark.
-
Alyssa Milburn -
Mark Cave-Ayland