OpenBIOS

openbios@openbios.org

2 participants
4278 discussions

[PATCH 0/3] Simplify pci.c by moving some parts to forth
by BALATON Zoltan 11 May '23

11 May '23

This is untested and probably should be marked RFC as it's mainly to show what I was suggesting as an alternative fix for the decode-unit problem discovered by Mark. This could be taken further to adopt the decode-unit and encode-unit words from openfirmware to reduce clutter in pci.c even more which I may attempt if this direction is accepted. My config words patch will also need to be rebased but let this part settle fitst and I can submit the rest as a follow up or a v2 for this series later. Regards, BALATON Zoltan (3): pci: Use forth to add trivial open/close methods pci: Add is-pci-bus word to install some methods from forth pci: Fix calling decode-unit without active-package drivers/pci.c | 78 +++++--------------------------------------------- drivers/pci.fs | 10 +++++++ 2 files changed, 17 insertions(+), 71 deletions(-) -- 2.30.8

3 16

[PATCH 0/6] Fixes for Forth PCI config access words and implementation
by Mark Cave-Ayland 14 Mar '23

14 Mar '23

This series provides a set of fixes required to allow Forth PCI config access words to work correctly on both 32-bit and 64-bit platforms, along with Zoltan's original v4 patch. There are 2 main fixes included: - Implement and convert PCI encode-unit/decode-unit to static methods - Fix my-address and my-unit on 64-bit platforms With this series applied it is possible to execute the Forth PCI config words as documented in various drivers as below: PPC (32-bit): 0 > showstack ok 0 > " /pci/QEMU,VGA" open-dev to my-self ok 0 > my-space " config-w@" $call-parent u. 1234 ok 0 > my-space ok 800 < 1 > my-address ok 800 0 0 < 3 > SPARC64 (64-bit, including across PCI bridge): 0 > showstack ok 0 > " /pci/pci@1,1/QEMU,VGA" open-dev to my-self ok 0 > my-space " config-w@" $call-parent u. 1234 ok 0 > my-space ok 11000 < 1 > my-address ok 11000 0 0 < 3 > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> BALATON Zoltan (1): drivers/pci: Implement config access words Mark Cave-Ayland (5): libopenbios/clib.fs: add new is-2arg-cfunc for calling into C libopenbios: introduce BIND_NODE_STATIC_METHOD and supporting functions drivers/pci.c: convert encode-unit and decode-unit words to static methods package.fs: fix my-address on 64-bit systems package.fs: fix my-unit on 64-bit systems drivers/pci.c | 115 +++++++++++++++++++++++++++++++-- forth/device/package.fs | 8 +-- include/libopenbios/bindings.h | 7 ++ libopenbios/bindings.c | 26 ++++++++ libopenbios/clib.fs | 10 +++ 5 files changed, 155 insertions(+), 11 deletions(-) -- 2.30.2

2 12

[PATCH] usbhid: Implement get-key-map method
by BALATON Zoltan 06 Mar '23

06 Mar '23

Mac OS X calls it during boot. This gets rid of an error saying "call-method slw_update_keymap failed with error ffffffdf" but otherwise does not seem to matter. It's probably used for getting the pressed keys that can change some boot actions like enable verbose mode with Cmd-V. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- drivers/usbhid.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/usbhid.c b/drivers/usbhid.c index b8e1548..d3ad4ef 100644 --- a/drivers/usbhid.c +++ b/drivers/usbhid.c @@ -52,12 +52,20 @@ keyboard_close(int *idx) { } +static void +keyboard_get_key_map(void) +{ + static char keytable[32] = { 0 }; + PUSH(pointer2cell(keytable)); +} + static void keyboard_read(void); NODE_METHODS( usb_kbd ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, }; #ifdef CONFIG_DEBUG_USB -- 2.30.6

2 5

[PATCH v4] drivers/pci: Implement config access words
by BALATON Zoltan 06 Mar '23

06 Mar '23

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- v4: Added call parent word for bridge devices drivers/pci.c | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index f30e427..084ebe9 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -424,6 +424,60 @@ ob_pci_bus_map_in(int *idx) PUSH(virt); } +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint16_t val = pci_config_read16(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write16(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint32_t val = pci_config_read32(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write32(addr, hi & 0xff, val); +} + static void ob_pci_dma_alloc(int *idx) { @@ -460,6 +514,12 @@ NODE_METHODS(ob_pci_bus_node) = { { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bus_map_in }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, + { "config-w@", ob_pci_config_read16 }, + { "config-w!", ob_pci_config_write16 }, + { "config-l@", ob_pci_config_read32 }, + { "config-l!", ob_pci_config_write32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -476,12 +536,54 @@ ob_pci_bridge_map_in(int *idx) call_parent_method("pci-map-in"); } +static void +ob_pci_bridge_cread8(void) +{ + call_parent_method("config-b@"); +} + +static void +ob_pci_bridge_cwrite8(void) +{ + call_parent_method("config-b!"); +} + +static void +ob_pci_bridge_cread16(void) +{ + call_parent_method("config-w@"); +} + +static void +ob_pci_bridge_cwrite16(void) +{ + call_parent_method("config-w!"); +} + +static void +ob_pci_bridge_cread32(void) +{ + call_parent_method("config-l@"); +} + +static void +ob_pci_bridge_cwrite32(void) +{ + call_parent_method("config-l!"); +} + NODE_METHODS(ob_pci_bridge_node) = { { "open", ob_pci_open }, { "close", ob_pci_close }, { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bridge_map_in }, + { "config-b@", ob_pci_bridge_cread8 }, + { "config-b!", ob_pci_bridge_cwrite8 }, + { "config-w@", ob_pci_bridge_cread16 }, + { "config-w!", ob_pci_bridge_cwrite16 }, + { "config-l@", ob_pci_bridge_cread32 }, + { "config-l!", ob_pci_bridge_cwrite32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, -- 2.30.6

2 3

[PATCH v5] drivers/pci: Implement config access words
by BALATON Zoltan 01 Feb '23

01 Feb '23

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- v5: Different approach to add call parent words for bridge v4: Added call parent word for bridge devices drivers/pci.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index f30e427..1d6d973 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -424,6 +424,60 @@ ob_pci_bus_map_in(int *idx) PUSH(virt); } +static void +ob_pci_config_read8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint8_t val = pci_config_read8(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write8(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write8(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint16_t val = pci_config_read16(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write16(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write16(addr, hi & 0xff, val); +} + +static void +ob_pci_config_read32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + uint32_t val = pci_config_read32(addr, hi & 0xff); + PUSH(val); +} + +static void +ob_pci_config_write32(int *idx) +{ + cell hi = POP(); + pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi)); + cell val = POP(); + pci_config_write32(addr, hi & 0xff, val); +} + static void ob_pci_dma_alloc(int *idx) { @@ -460,6 +514,12 @@ NODE_METHODS(ob_pci_bus_node) = { { "decode-unit", ob_pci_decode_unit }, { "encode-unit", ob_pci_encode_unit }, { "pci-map-in", ob_pci_bus_map_in }, + { "config-b@", ob_pci_config_read8 }, + { "config-b!", ob_pci_config_write8 }, + { "config-w@", ob_pci_config_read16 }, + { "config-w!", ob_pci_config_write16 }, + { "config-l@", ob_pci_config_read32 }, + { "config-l!", ob_pci_config_write32 }, { "dma-alloc", ob_pci_dma_alloc }, { "dma-free", ob_pci_dma_free }, { "dma-map-in", ob_pci_dma_map_in }, @@ -494,6 +554,14 @@ NODE_METHODS(ob_pci_simple_node) = { { "close", ob_pci_close }, }; +static void pci_config_call_parent_methods(void) +{ + /* As per the IEEE-1275 PCI specification, chain up to the parent */ + feval("\" config-b@\" is-call-parent \" config-b!\" is-call-parent " + "\" config-w@\" is-call-parent \" config-w!\" is-call-parent " + "\" config-l@\" is-call-parent \" config-l!\" is-call-parent "); +} + static void pci_set_bus_range(const pci_config_t *config) { phandle_t dev = find_dev(config->path); @@ -1831,6 +1899,7 @@ static phandle_t ob_configure_pci_device(const char* parent_path, case PCI_BASE_CLASS_BRIDGE: if (subclass != PCI_SUBCLASS_BRIDGE_HOST) { BIND_NODE_METHODS(phandle, ob_pci_bridge_node); + pci_config_call_parent_methods(); } else { BIND_NODE_METHODS(phandle, ob_pci_bus_node); } -- 2.30.6

1 0

[PATCH 0/3] Add parse hex words for compatibility
by BALATON Zoltan 31 Jan '23

31 Jan '23

Hello, Both Apple OF and SLOF has words to parse hex numbers from comma separated strings which is easily implemented using existing parse-ints word. Doing that removes some duplicated implementations and makes it easy to add compatibility words for Mac FCode ROMs. Originally I've also proposed to rename the existing parse-hex to patse-1hex as it does not matter what it's called as parse-hex is not standard. I still think that would be simpler but this series keeps that word and only adds another parse-1hex for ppc/qemu specifically. That patch renaming patse-hex could still be resurrected if needed. Regards, BALATON Zoltan BALATON Zoltan (3): Generalise parse-hex Use parse-nhex arch/ppc/qemu: Add parse hex words for compatibility with Apple OF arch/ppc/qemu/qemu.fs | 8 ++++++++ arch/sparc64/tree.fs | 6 +----- drivers/esp.fs | 6 +----- drivers/sbus.fs | 6 +----- forth/device/package.fs | 29 ----------------------------- forth/lib/string.fs | 36 ++++++++++++++++++++++++++++++++++-- 6 files changed, 45 insertions(+), 46 deletions(-) -- 2.30.6

2 5

[PATCH v3 0/6] Misc fixes for running FCode ROMs
by BALATON Zoltan 28 Jan '23

28 Jan '23

This starts from v3 as it contains the previous ATI ROM patch split up into smaller patches and also contains other changes that were submitted as separate patches to keep them together. After looking at this again I'm not sure about one patch defining register access words as io access which should work for io bars but I'm unsure about memory bars. Does somebody know what these words should do or what they do on other open firmware implementations? Regards, BALATON Zoltan BALATON Zoltan (6): Limit binary dump bytes in .properties output Don't add open/close words to unmanaged devices Define register access words drivers/pci: Implement config access words drivers/pci: Fix map-in and map-out words arch/ppc/qemu: Add parse-1hex word for compatibility with Apple OF arch/ppc/qemu/qemu.fs | 6 +++ drivers/pci.c | 91 ++++++++++++++++++++++++++++++++++------- drivers/pci.fs | 41 +++++++++++++++++++ drivers/vga.fs | 4 +- forth/admin/devices.fs | 7 ++-- forth/device/other.fs | 6 +++ forth/device/pathres.fs | 5 ++- 7 files changed, 140 insertions(+), 20 deletions(-) -- 2.30.4

3 14

get-key-map method for Mac OS (was Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option)
by BALATON Zoltan 27 Jan '23

27 Jan '23

On Fri, 27 Jan 2023, Howard Spoelstra wrote: > On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan <balaton(a)eik.bme.hu> wrote: >> On Fri, 27 Jan 2023, BALATON Zoltan wrote: >>> On Thu, 26 Jan 2023, Howard Spoelstra wrote: >>>> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton(a)eik.bme.hu> >> wrote: >>>>> On Thu, 26 Jan 2023, Howard Spoelstra wrote: >>>>>> Mac OS X >>>>>> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to >> adb >>>>>> mouse. No recognition as HID device. >>>>>> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that >> point >>>>> kbd >>>>>> pcap shows normal interrupt operation and recognition as HID device >>>>>> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that >> point >>>>> kbd >>>>>> pcap shows normal interrupt operation and recognition as HID device >>>>>> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to >> adb >>>>>> mouse. pcap shows no recognition as HID device. >>>>>> #10.0 in both cases apple system profiler shows 2 usb buses but no >>>>> devices. >>>>> >>>>> These are all the logs I get booting a 10.0 install iso with >>>>> mac99,via=pmu >>>>> >>>>>>> ============================================================= >>>>>>> OpenBIOS 1.1 [May 25 2022 20:04] >>>>>>> Configuration device id QEMU version 1 machine id 1 >>>>>>> CPUs: 1 >>>>>>> Memory: 256M >>>>>>> UUID: 00000000-0000-0000-0000-000000000000 >>>>>>> CPU type PowerPC,G4 >>>>> milliseconds isn't unique. >>>>>>> switching to new context: >>>>>>> call-method slw_update_keymap failed with error ffffffdf >>>>>>> call-method slw_update_keymap failed with error ffffffdf >>>>> usb_ohci_reset pci-ohci >>>>> usb_ohci_stop pci-ohci: USB Suspended >>>>> usb_ohci_set_ctl pci-ohci: new state 0x0 >>>>> usb_ohci_stop pci-ohci: USB Suspended >>>>> usb_ohci_port_detach port #0 >>>>> usb_ohci_port_attach port #0 >>>>> usb_ohci_port_detach port #1 >>>>> usb_ohci_port_attach port #1 >>>>> dbdma_unassigned_flush: use of unassigned channel 0 >>>>> dbdma_unassigned_flush: use of unassigned channel 0 >>>>> usb_ohci_mem_write_bad_offset 0x30 >>>>> usb_ohci_set_ctl pci-ohci: new state 0x80 >>>>> usb_ohci_start pci-ohci: USB Operational >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_set_ctl pci-ohci: new state 0xc0 >>>>> usb_ohci_stop pci-ohci: USB Suspended >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_hub_power_up powered up all ports >>>>> usb_ohci_port_reset port #0 >>>>> >>>>> It's probably OK until it restarts but the seems to be stopped. Anybody >>>>> wants to have a look? Maybe start with finding what the states mean. >>>>> >>>>> >>>> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS >>>> 9.0.4: >>>> >>>> usb_ohci_set_ctl pci-ohci: new state 0x80 >>>> usb_ohci_start pci-ohci: USB Operational >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_hub_power_up powered up all ports >>>> usb_ohci_port_reset port #0 >>>> usb_ohci_port_reset port #0 >>>> >>>> So both usb mouse and kbd do not work. >>>> >>>> the pcap file for the mouse stalls here: >>>> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response >>> >>> Maybe the driver gets something from the emulated HID device that it >> cannot >>> handle and stops during init? Can you reproduce the same with OS X 10.0 >> and >>> try to correlate the events you see in pcap and trace with the driver >> source >>> or find out how to enable and read the messages in the driver (unless >> these >>> are stripped from the binary in Mac OS X but maybe there's something in >> the >>> guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are >>> implemented in hw/usb/dev-hid.c but this file does not have any debuging >> or >>> traces. You might try to add some printfs for testing. >>> >>>> However, when I use the usb probe tool from the USB DDK, to probe the >> buses >>>> I see the host emit a get descriptor >>>> >>>> 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE >>>> 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE >>>> 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request >>>> etc. and this time the mouse is recognised as HID device, the host >> starts >>>> polling it and mouse and kbd start to work. >>> >>> It could be possible that the driver did not get to this point but once >>> something else get's past that it recognises the device but I have no >> idea >>> how this works and not even sure which OS you had this result with. Is >> this >>> still 9.0.4? That's hard to debug because we don't know what its driver >> is >>> doing. >>> >>> Is there a Darwin, OpenDarwin or whatever was that called during the >> years >>> iso that boots on this machine (also on the real one)? That should be >> fully >>> open source and probably have the same drivers as Mac OS X so >> reproducing >>> with that could give some more info or maybe its driver is more verbose >> about >>> errors and has debugging. So you could try to find an early Darwin >> version >>> that's about the same time as early OS X versions or look at the >> IOHIDFamily >>> and try to find what part of it is running when you see the logs (as >> this >>> driver is quite complex it may not be easy). >> >> The oldest Darwin CD I could find is 6.2 which boots and works so it's not >> old enough for us. >> >> The simplest driver is in the oldest 10.0 version so maybe we should try >> to look at that: >> >> https://github.com/apple-oss-distributions/IOHIDFamily/tree/IOHIDFamily-6 >> >> and the low level part is in the xnu kernel: >> >> >> https://github.com/apple-oss-distributions/xnu/tree/xnu-123.5/iokit/Familie… >> >> I don't quite know how it works and where it starts running but a large >> part of it looks like it handles key mapping. While booting I see an error >> from OpenBIOS saying: >> >>>> call-method slw_update_keymap failed with error ffffffdf >> >> Could this be related to the problem? What is this error about? This >> PearPC bug has some info on where it may come from: >> >> > This seem to come from here: > https://web.archive.org/web/20150922180615/http://www.opensource.apple.com/… Great. That's now here (also this is the earilest 10.0 version which should be the simplest): https://github.com/apple-oss-distributions/BootX/blob/BootX-34/bootx.tproj/… This seems to want to call get-key-map method on keyboard. Searching for that in OpenBIOS shows we have that implemented in openbios/drivers/adb_kbd.c and arch/ppc/mol/methods.c but not for usb keyboard. I'm moving this thread to the openbios mailing list as it is now more about this issue than my qemu patch. Any idea/suggestion how should we add this method to the usb keyboard in OpenBIOS? I've ported the USB driver back then but I forgot all about it. There are some methods defined in openbios/drivers/usbhid.c so I guess I could copy it from one of the above two implementations but maybe it's a good time to try to share it between these places but I'm not sure what's the best way for that. Regards, BALATON Zoltan

1 1

[PATCH v3] Limit binary dump bytes in .properties output
by BALATON Zoltan 26 Jan '23

26 Jan '23

Some device trees can contain large chunks of binary data that result in .properties output to get lost in the dump of all binary bytes. Put an upper limit of the bytes dumped. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- forth/admin/devices.fs | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 38f6ad6..879c271 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -307,15 +307,16 @@ : .p-bytes? ( data len -- 1 | data len 0 ) ." -- " dup . ." : " - swap >r 0 + swap >r dup 100 min 0 begin 2dup > while dup r@ + c@ ( len n ch ) 2 0.r space 1+ - repeat - 2drop r> drop 1 + repeat + drop > if ." ..." then + r> drop 1 ; \ this function tries to heuristically determine the data format -- 2.30.4

2 4

CHRP booting.
by Jd Lyons 03 Oct '22

03 Oct '22

I’m trying to figure how Openbios boots CHRP boot scrips like :tbxi, yet SOLF does not. Can anyone point me to the code in Openbios that enables :tbxi/CHRP booting? Also, does anyone know how exactly that works, what was done to Openbios to enable booting the Mac OS? I’d really like to try and get Apple’s BootX to load on Qemu’s pseries machines and as I understand it CHRP booting should work in SLOF, but it just errors out on BootX with "bad executable”, so there must be some magic I need to understand about :tbxi CHRP boot scripts that SLOF needs some sort of patch.

4 7

Jump to page: