OpenBIOS January 2023

openbios@openbios.org

2 participants
7 discussions

[PATCH] kernel: Fix compiler format string warnings when some debugging options are enabled
by Glenn Washburn 29 Jul '23

29 Jul '23

Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- This compile-time errors from GCC 10.1.0 when the config options CONFIG_DEBUG_BOOT, CONFIG_DEBUG_DICTIONARY, and CONFIG_DEBUG_INTERPRETER are set to true in the ppc64_config.xml. I suspect these are issues for 32-bit PPC as well, but haven't checked. Glenn --- kernel/bootstrap.c | 8 ++++---- kernel/dict.c | 4 ++-- kernel/forth.c | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/bootstrap.c b/kernel/bootstrap.c index b7658ab..6834597 100644 --- a/kernel/bootstrap.c +++ b/kernel/bootstrap.c @@ -133,9 +133,9 @@ static void relocation_table(unsigned char * dict_one, unsigned char *dict_two, } #ifdef CONFIG_DEBUG_DICTIONARY - printk("dict1 %lx dict2 %lx dict %lx\n",dict_one, dict_two, dict); + printk("dict1 %p dict2 %p dict %p\n",dict_one, dict_two, dict); for (i=0; i< relocation_length ; i++) - printk("reloc %d %lx\n",i+1, reloc_table[i]); + printk("reloc %d "FMT_ucellx"\n",i+1, reloc_table[i]); #endif relocation_address=reloc_table; } @@ -819,7 +819,7 @@ static int build_dictionary(void) dicthead = 0; #ifdef CONFIG_DEBUG_DICTIONARY - printk("building dictionary, %d primitives.\nbuilt words:", + printk("building dictionary, %lu primitives.\nbuilt words:", sizeof(wordnames) / sizeof(void *)); #endif @@ -1248,7 +1248,7 @@ int main(int argc, char *argv[]) printf("dict1: %p\n",bootstrapdict[0]); printf("dict2: %p\n",bootstrapdict[1]); printf("trampoline: %p\n",trampoline); - printf("size=%d, trampoline_size=%d\n",MEMORY_SIZE + (2 * + printf("size=%ld, trampoline_size=%ld\n",MEMORY_SIZE + (2 * DICTIONARY_SIZE) + TRAMPOLINE_SIZE, TRAMPOLINE_SIZE); #endif diff --git a/kernel/dict.c b/kernel/dict.c index 0986cb1..e449c5b 100644 --- a/kernel/dict.c +++ b/kernel/dict.c @@ -293,8 +293,8 @@ ucell load_dictionary(const char *data, ucell len) reloc_table=(ucell *)(data+dicthead); #ifdef CONFIG_DEBUG_DICTIONARY - printk("\nmoving dictionary (%x bytes) to %x\n", - (ucell)dicthead, (ucell)dict); + printk("\nmoving dictionary (%x bytes) to "FMT_ucellx"\n", + (ucell)dicthead, pointer2cell(dict)); printk("\ndynamic relocation..."); #endif diff --git a/kernel/forth.c b/kernel/forth.c index 61dd70d..ca3fda3 100644 --- a/kernel/forth.c +++ b/kernel/forth.c @@ -111,7 +111,7 @@ static void docol(void) PUSHR(PC); PC = read_ucell(cell2pointer(PC)); - dbg_interp_printk("docol: %s\n", cell2pointer( lfa2nfa(PC - sizeof(cell)) )); + dbg_interp_printk("docol: %s\n", (char *)cell2pointer( lfa2nfa(PC - sizeof(cell)) )); } static void semis(void) @@ -719,7 +719,7 @@ static void docol_dbg(void) debug_xt_item = debug_xt_item->next; } - dbg_interp_printk("docol_dbg: %s\n", cell2pointer(lfa2nfa(PC - sizeof(cell)))); + dbg_interp_printk("docol_dbg: %s\n", (char *)cell2pointer(lfa2nfa(PC - sizeof(cell)))); } static void semis_dbg(void) -- 2.30.2

2 4

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

07 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 0/3] Add parse hex words for compatibility
by BALATON Zoltan 01 Feb '23

01 Feb '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 29 Jan '23

29 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 28 Jan '23

28 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 27 Jan '23

27 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