This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu --- arch/amd64/init.fs | 2 +- arch/ia64/init.fs | 2 +- arch/ppc/briq/briq.fs | 2 +- arch/ppc/mol/mol.fs | 2 +- arch/ppc/mol/tree.fs | 2 +- arch/ppc/pearpc/pearpc.fs | 2 +- arch/ppc/qemu/tree.fs | 2 +- arch/sparc64/tree.fs | 4 ++-- arch/unix/tree.fs | 4 ++-- arch/x86/init.fs | 2 +- drivers/esp.fs | 4 ++-- drivers/ide.c | 2 +- drivers/lsi.c | 2 +- drivers/pci.c | 4 ++++ drivers/sbus.fs | 4 ++-- forth/admin/nvram.fs | 4 ++-- forth/device/pathres.fs | 2 +- forth/device/tree.fs | 2 +- forth/lib/string.fs | 2 +- 19 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/arch/amd64/init.fs b/arch/amd64/init.fs index fda3acd..0a06383 100644 --- a/arch/amd64/init.fs +++ b/arch/amd64/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ;
finish-device
diff --git a/arch/ia64/init.fs b/arch/ia64/init.fs index 5b65dd1..c7c83f6 100644 --- a/arch/ia64/init.fs +++ b/arch/ia64/init.fs @@ -24,7 +24,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ;
finish-device
diff --git a/arch/ppc/briq/briq.fs b/arch/ppc/briq/briq.fs index 78d7797..c8e0502 100644 --- a/arch/ppc/briq/briq.fs +++ b/arch/ppc/briq/briq.fs @@ -58,7 +58,7 @@
over active-package! case - 1 of ['] parse-hex " decode-unit" is-xt-func endof + 1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nip diff --git a/arch/ppc/mol/mol.fs b/arch/ppc/mol/mol.fs index 10c99bd..2e1be19 100644 --- a/arch/ppc/mol/mol.fs +++ b/arch/ppc/mol/mol.fs @@ -51,7 +51,7 @@
over active-package! case - 1 of ['] parse-hex " decode-unit" is-xt-func endof + 1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nip diff --git a/arch/ppc/mol/tree.fs b/arch/ppc/mol/tree.fs index 228163f..434033b 100644 --- a/arch/ppc/mol/tree.fs +++ b/arch/ppc/mol/tree.fs @@ -64,7 +64,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ;
finish-device
diff --git a/arch/ppc/pearpc/pearpc.fs b/arch/ppc/pearpc/pearpc.fs index 0d018b1..8201f17 100644 --- a/arch/ppc/pearpc/pearpc.fs +++ b/arch/ppc/pearpc/pearpc.fs @@ -59,7 +59,7 @@
over active-package! case - 1 of ['] parse-hex " decode-unit" is-xt-func endof + 1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nip diff --git a/arch/ppc/qemu/tree.fs b/arch/ppc/qemu/tree.fs index 06583ab..dc6f501 100644 --- a/arch/ppc/qemu/tree.fs +++ b/arch/ppc/qemu/tree.fs @@ -64,7 +64,7 @@ new-device ;
: decode-unit ( str len -- unit ) - parse-hex + parse-1hex ;
finish-device diff --git a/arch/sparc64/tree.fs b/arch/sparc64/tree.fs index af8948d..a1f2fc0 100644 --- a/arch/sparc64/tree.fs +++ b/arch/sparc64/tree.fs @@ -7,8 +7,8 @@ include config.fs : decode-unit-upa ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L ) - parse-hex - -rot parse-hex + parse-1hex + -rot parse-1hex swap ;
diff --git a/arch/unix/tree.fs b/arch/unix/tree.fs index a7529b0..3326b9b 100644 --- a/arch/unix/tree.fs +++ b/arch/unix/tree.fs @@ -22,7 +22,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ;
finish-device
@@ -95,7 +95,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ;
\ testnode \ new-device diff --git a/arch/x86/init.fs b/arch/x86/init.fs index eef72e9..220bec0 100644 --- a/arch/x86/init.fs +++ b/arch/x86/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ;
finish-device
diff --git a/drivers/esp.fs b/drivers/esp.fs index 9e37c0a..6f78ee4 100644 --- a/drivers/esp.fs +++ b/drivers/esp.fs @@ -5,8 +5,8 @@ : decode-unit-scsi ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L ) - parse-hex - -rot parse-hex + parse-1hex + -rot parse-1hex swap ;
diff --git a/drivers/ide.c b/drivers/ide.c index 4cc572c..79ea8dd 100644 --- a/drivers/ide.c +++ b/drivers/ide.c @@ -1284,7 +1284,7 @@ NODE_METHODS(ob_ide) = { static void ob_ide_ctrl_decodeunit(int *idx) { - fword("parse-hex"); + fword("parse-1hex"); }
static void diff --git a/drivers/lsi.c b/drivers/lsi.c index 51a541c..e5b09b3 100644 --- a/drivers/lsi.c +++ b/drivers/lsi.c @@ -590,7 +590,7 @@ static void ob_lsi_decodeunit(__attribute__((unused)) lsi_private_t **lsi_p) { /* ( str len -- id ) */ - fword("parse-hex"); + fword("parse-1hex"); }
static void diff --git a/drivers/pci.c b/drivers/pci.c index 787fa93..1691e6d 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1072,11 +1072,13 @@ int vga_config_cb (const pci_config_t *config) uint32_t rom_size, size, bar; phandle_t ph; #endif + PCI_DPRINTF("%s 0x%x\n", __func__, config->assigned[0]); if (config->assigned[0] != 0x00000000) { setup_video();
#ifdef CONFIG_PPC if (config->assigned[6]) { + PCI_DPRINTF("%s Checking ROM\n", __func__); rom = pci_bus_addr_to_host_addr(MEMORY_SPACE_32, config->assigned[6] & ~0x0000000F); rom_size = config->sizes[6]; @@ -1092,10 +1094,12 @@ int vga_config_cb (const pci_config_t *config) p = (const char *)rom; if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') { size = *(uint32_t*)(p + 4); + PCI_DPRINTF("%s Found NDRV, size=%u\n", __func__, size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p + 8, size); } else if (p[0] == 'J' && p[1] == 'o' && p[2] == 'y' && p[3] == '!') { + PCI_DPRINTF("%s Found PEF, size=%u\n", __func__, rom_size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p, rom_size); } diff --git a/drivers/sbus.fs b/drivers/sbus.fs index b84a3ac..cea2f14 100644 --- a/drivers/sbus.fs +++ b/drivers/sbus.fs @@ -5,8 +5,8 @@ : decode-unit-sbus ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L ) - parse-hex - -rot parse-hex + parse-1hex + -rot parse-1hex swap ;
diff --git a/forth/admin/nvram.fs b/forth/admin/nvram.fs index 3fbd935..d543a5e 100644 --- a/forth/admin/nvram.fs +++ b/forth/admin/nvram.fs @@ -104,7 +104,7 @@ constant config-info.size
: exec-int-conf ( str len -- value ) \ fixme - parse-hex + parse-1hex ; : check-int-conf ( str len -- str len valid? ) true @@ -145,7 +145,7 @@ constant config-info.size 2dup s" false" strcmp 0= if 2drop false exit then 2dup s" TRUE" strcmp 0= if 2drop false exit then 2dup s" FALSE" strcmp 0= if 2drop false exit then - parse-hex 0<> + parse-1hex 0<> ;
: check-bool-conf ( name len -- str len valid? ) diff --git a/forth/device/pathres.fs b/forth/device/pathres.fs index a185b95..7976d78 100644 --- a/forth/device/pathres.fs +++ b/forth/device/pathres.fs @@ -179,7 +179,7 @@ constant sinfo.size
\ used if package lacks a decode-unit method : def-decode-unit ( str len -- unitaddr ... ) - parse-hex + parse-1hex ;
: get-decode-unit-xt ( phandle -- xt ) diff --git a/forth/device/tree.fs b/forth/device/tree.fs index 6a4cb35..34c01e7 100644 --- a/forth/device/tree.fs +++ b/forth/device/tree.fs @@ -15,7 +15,7 @@ new-device 1 encode-int " #address-cells" property : open true ; : close ; - : decode-unit parse-hex ; + : decode-unit parse-1hex ; : encode-unit ( addr -- str len ) pocket tohexstr ; diff --git a/forth/lib/string.fs b/forth/lib/string.fs index f97db23..55b24fc 100644 --- a/forth/lib/string.fs +++ b/forth/lib/string.fs @@ -122,7 +122,7 @@ \ string to number conversion \ -----------------------------------------------------
-: parse-hex ( str len -- value ) +: parse-1hex ( str len -- value ) base @ hex -rot $number if 0 then swap base ! ;
On Sat, 10 Sep 2022, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
arch/amd64/init.fs | 2 +- arch/ia64/init.fs | 2 +- arch/ppc/briq/briq.fs | 2 +- arch/ppc/mol/mol.fs | 2 +- arch/ppc/mol/tree.fs | 2 +- arch/ppc/pearpc/pearpc.fs | 2 +- arch/ppc/qemu/tree.fs | 2 +- arch/sparc64/tree.fs | 4 ++-- arch/unix/tree.fs | 4 ++-- arch/x86/init.fs | 2 +- drivers/esp.fs | 4 ++-- drivers/ide.c | 2 +- drivers/lsi.c | 2 +- drivers/pci.c | 4 ++++ drivers/sbus.fs | 4 ++-- forth/admin/nvram.fs | 4 ++-- forth/device/pathres.fs | 2 +- forth/device/tree.fs | 2 +- forth/lib/string.fs | 2 +- 19 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/arch/amd64/init.fs b/arch/amd64/init.fs index fda3acd..0a06383 100644 --- a/arch/amd64/init.fs +++ b/arch/amd64/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ;
finish-device
diff --git a/arch/ia64/init.fs b/arch/ia64/init.fs index 5b65dd1..c7c83f6 100644 --- a/arch/ia64/init.fs +++ b/arch/ia64/init.fs @@ -24,7 +24,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ;
finish-device
diff --git a/arch/ppc/briq/briq.fs b/arch/ppc/briq/briq.fs index 78d7797..c8e0502 100644 --- a/arch/ppc/briq/briq.fs +++ b/arch/ppc/briq/briq.fs @@ -58,7 +58,7 @@
over active-package! case
1 of ['] parse-hex " decode-unit" is-xt-func endof
1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nipdiff --git a/arch/ppc/mol/mol.fs b/arch/ppc/mol/mol.fs index 10c99bd..2e1be19 100644 --- a/arch/ppc/mol/mol.fs +++ b/arch/ppc/mol/mol.fs @@ -51,7 +51,7 @@
over active-package! case
1 of ['] parse-hex " decode-unit" is-xt-func endof
1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nipdiff --git a/arch/ppc/mol/tree.fs b/arch/ppc/mol/tree.fs index 228163f..434033b 100644 --- a/arch/ppc/mol/tree.fs +++ b/arch/ppc/mol/tree.fs @@ -64,7 +64,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ;
finish-device
diff --git a/arch/ppc/pearpc/pearpc.fs b/arch/ppc/pearpc/pearpc.fs index 0d018b1..8201f17 100644 --- a/arch/ppc/pearpc/pearpc.fs +++ b/arch/ppc/pearpc/pearpc.fs @@ -59,7 +59,7 @@
over active-package! case
1 of ['] parse-hex " decode-unit" is-xt-func endof
1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nipdiff --git a/arch/ppc/qemu/tree.fs b/arch/ppc/qemu/tree.fs index 06583ab..dc6f501 100644 --- a/arch/ppc/qemu/tree.fs +++ b/arch/ppc/qemu/tree.fs @@ -64,7 +64,7 @@ new-device ;
: decode-unit ( str len -- unit )
parse-hex
parse-1hexfinish-device diff --git a/arch/sparc64/tree.fs b/arch/sparc64/tree.fs index af8948d..a1f2fc0 100644 --- a/arch/sparc64/tree.fs +++ b/arch/sparc64/tree.fs @@ -7,8 +7,8 @@ include config.fs : decode-unit-upa ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L )
- parse-hex
- -rot parse-hex
- parse-1hex
- -rot parse-1hex swap
;
diff --git a/arch/unix/tree.fs b/arch/unix/tree.fs index a7529b0..3326b9b 100644 --- a/arch/unix/tree.fs +++ b/arch/unix/tree.fs @@ -22,7 +22,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ;
finish-device
@@ -95,7 +95,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ;
\ testnode \ new-device diff --git a/arch/x86/init.fs b/arch/x86/init.fs index eef72e9..220bec0 100644 --- a/arch/x86/init.fs +++ b/arch/x86/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ;
finish-device
diff --git a/drivers/esp.fs b/drivers/esp.fs index 9e37c0a..6f78ee4 100644 --- a/drivers/esp.fs +++ b/drivers/esp.fs @@ -5,8 +5,8 @@ : decode-unit-scsi ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L )
- parse-hex
- -rot parse-hex
- parse-1hex
- -rot parse-1hex swap
;
diff --git a/drivers/ide.c b/drivers/ide.c index 4cc572c..79ea8dd 100644 --- a/drivers/ide.c +++ b/drivers/ide.c @@ -1284,7 +1284,7 @@ NODE_METHODS(ob_ide) = { static void ob_ide_ctrl_decodeunit(int *idx) {
- fword("parse-hex");
- fword("parse-1hex");
}
static void diff --git a/drivers/lsi.c b/drivers/lsi.c index 51a541c..e5b09b3 100644 --- a/drivers/lsi.c +++ b/drivers/lsi.c @@ -590,7 +590,7 @@ static void ob_lsi_decodeunit(__attribute__((unused)) lsi_private_t **lsi_p) { /* ( str len -- id ) */
- fword("parse-hex");
- fword("parse-1hex");
}
static void diff --git a/drivers/pci.c b/drivers/pci.c index 787fa93..1691e6d 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1072,11 +1072,13 @@ int vga_config_cb (const pci_config_t *config) uint32_t rom_size, size, bar; phandle_t ph; #endif
PCI_DPRINTF("%s 0x%x\n", __func__, config->assigned[0]); if (config->assigned[0] != 0x00000000) { setup_video();#ifdef CONFIG_PPC if (config->assigned[6]) {
PCI_DPRINTF("%s Checking ROM\n", __func__); rom = pci_bus_addr_to_host_addr(MEMORY_SPACE_32, config->assigned[6] & ~0x0000000F); rom_size = config->sizes[6];@@ -1092,10 +1094,12 @@ int vga_config_cb (const pci_config_t *config) p = (const char *)rom; if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') { size = *(uint32_t*)(p + 4);
PCI_DPRINTF("%s Found NDRV, size=%u\n", __func__, size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p + 8, size); } else if (p[0] == 'J' && p[1] == 'o' && p[2] == 'y' && p[3] == '!') {PCI_DPRINTF("%s Found PEF, size=%u\n", __func__, rom_size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p, rom_size); }
These changes to pci.c is actually left over debug included here in error so regard only the rest. I can send a v2 without it if that helps. (Or you can consider this one separately to add more debug to VGA ROM detection.)
Regards, BALATON Zoltan
diff --git a/drivers/sbus.fs b/drivers/sbus.fs index b84a3ac..cea2f14 100644 --- a/drivers/sbus.fs +++ b/drivers/sbus.fs @@ -5,8 +5,8 @@ : decode-unit-sbus ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L )
- parse-hex
- -rot parse-hex
- parse-1hex
- -rot parse-1hex swap
;
diff --git a/forth/admin/nvram.fs b/forth/admin/nvram.fs index 3fbd935..d543a5e 100644 --- a/forth/admin/nvram.fs +++ b/forth/admin/nvram.fs @@ -104,7 +104,7 @@ constant config-info.size
: exec-int-conf ( str len -- value ) \ fixme
- parse-hex
- parse-1hex
; : check-int-conf ( str len -- str len valid? ) true @@ -145,7 +145,7 @@ constant config-info.size 2dup s" false" strcmp 0= if 2drop false exit then 2dup s" TRUE" strcmp 0= if 2drop false exit then 2dup s" FALSE" strcmp 0= if 2drop false exit then
- parse-hex 0<>
- parse-1hex 0<>
;
: check-bool-conf ( name len -- str len valid? ) diff --git a/forth/device/pathres.fs b/forth/device/pathres.fs index a185b95..7976d78 100644 --- a/forth/device/pathres.fs +++ b/forth/device/pathres.fs @@ -179,7 +179,7 @@ constant sinfo.size
\ used if package lacks a decode-unit method : def-decode-unit ( str len -- unitaddr ... )
- parse-hex
- parse-1hex
;
: get-decode-unit-xt ( phandle -- xt ) diff --git a/forth/device/tree.fs b/forth/device/tree.fs index 6a4cb35..34c01e7 100644 --- a/forth/device/tree.fs +++ b/forth/device/tree.fs @@ -15,7 +15,7 @@ new-device 1 encode-int " #address-cells" property : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ; : encode-unit ( addr -- str len ) pocket tohexstr ;
diff --git a/forth/lib/string.fs b/forth/lib/string.fs index f97db23..55b24fc 100644 --- a/forth/lib/string.fs +++ b/forth/lib/string.fs @@ -122,7 +122,7 @@ \ string to number conversion \ -----------------------------------------------------
-: parse-hex ( str len -- value ) +: parse-1hex ( str len -- value ) base @ hex -rot $number if 0 then swap base ! ;
On 10/09/2022 12:58, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
arch/amd64/init.fs | 2 +- arch/ia64/init.fs | 2 +- arch/ppc/briq/briq.fs | 2 +- arch/ppc/mol/mol.fs | 2 +- arch/ppc/mol/tree.fs | 2 +- arch/ppc/pearpc/pearpc.fs | 2 +- arch/ppc/qemu/tree.fs | 2 +- arch/sparc64/tree.fs | 4 ++-- arch/unix/tree.fs | 4 ++-- arch/x86/init.fs | 2 +- drivers/esp.fs | 4 ++-- drivers/ide.c | 2 +- drivers/lsi.c | 2 +- drivers/pci.c | 4 ++++ drivers/sbus.fs | 4 ++-- forth/admin/nvram.fs | 4 ++-- forth/device/pathres.fs | 2 +- forth/device/tree.fs | 2 +- forth/lib/string.fs | 2 +- 19 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/arch/amd64/init.fs b/arch/amd64/init.fs index fda3acd..0a06383 100644 --- a/arch/amd64/init.fs +++ b/arch/amd64/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
: decode-unit parse-1hex ;
finish-device
diff --git a/arch/ia64/init.fs b/arch/ia64/init.fs index 5b65dd1..c7c83f6 100644 --- a/arch/ia64/init.fs +++ b/arch/ia64/init.fs @@ -24,7 +24,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
: decode-unit parse-1hex ;
finish-device
diff --git a/arch/ppc/briq/briq.fs b/arch/ppc/briq/briq.fs index 78d7797..c8e0502 100644 --- a/arch/ppc/briq/briq.fs +++ b/arch/ppc/briq/briq.fs @@ -58,7 +58,7 @@
over active-package! case
1 of ['] parse-hex " decode-unit" is-xt-func endof
1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nipdiff --git a/arch/ppc/mol/mol.fs b/arch/ppc/mol/mol.fs index 10c99bd..2e1be19 100644 --- a/arch/ppc/mol/mol.fs +++ b/arch/ppc/mol/mol.fs @@ -51,7 +51,7 @@
over active-package! case
1 of ['] parse-hex " decode-unit" is-xt-func endof
1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nipdiff --git a/arch/ppc/mol/tree.fs b/arch/ppc/mol/tree.fs index 228163f..434033b 100644 --- a/arch/ppc/mol/tree.fs +++ b/arch/ppc/mol/tree.fs @@ -64,7 +64,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
: decode-unit parse-1hex ;
finish-device
diff --git a/arch/ppc/pearpc/pearpc.fs b/arch/ppc/pearpc/pearpc.fs index 0d018b1..8201f17 100644 --- a/arch/ppc/pearpc/pearpc.fs +++ b/arch/ppc/pearpc/pearpc.fs @@ -59,7 +59,7 @@
over active-package! case
1 of ['] parse-hex " decode-unit" is-xt-func endof
1 of ['] parse-1hex " decode-unit" is-xt-func endof 3 of " bus-range" active-package get-package-property 0= if decode-int nip nipdiff --git a/arch/ppc/qemu/tree.fs b/arch/ppc/qemu/tree.fs index 06583ab..dc6f501 100644 --- a/arch/ppc/qemu/tree.fs +++ b/arch/ppc/qemu/tree.fs @@ -64,7 +64,7 @@ new-device ;
: decode-unit ( str len -- unit )
parse-hex
parse-1hex;
finish-device
diff --git a/arch/sparc64/tree.fs b/arch/sparc64/tree.fs index af8948d..a1f2fc0 100644 --- a/arch/sparc64/tree.fs +++ b/arch/sparc64/tree.fs @@ -7,8 +7,8 @@ include config.fs : decode-unit-upa ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L )
- parse-hex
- -rot parse-hex
- parse-1hex
- -rot parse-1hex swap ;
diff --git a/arch/unix/tree.fs b/arch/unix/tree.fs index a7529b0..3326b9b 100644 --- a/arch/unix/tree.fs +++ b/arch/unix/tree.fs @@ -22,7 +22,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
: decode-unit parse-1hex ;
finish-device
@@ -95,7 +95,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
: decode-unit parse-1hex ;
\ testnode \ new-device
diff --git a/arch/x86/init.fs b/arch/x86/init.fs index eef72e9..220bec0 100644 --- a/arch/x86/init.fs +++ b/arch/x86/init.fs @@ -26,7 +26,7 @@ new-device external : open true ; : close ;
- : decode-unit parse-hex ;
: decode-unit parse-1hex ;
finish-device
diff --git a/drivers/esp.fs b/drivers/esp.fs index 9e37c0a..6f78ee4 100644 --- a/drivers/esp.fs +++ b/drivers/esp.fs @@ -5,8 +5,8 @@ : decode-unit-scsi ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L )
- parse-hex
- -rot parse-hex
- parse-1hex
- -rot parse-1hex swap ;
diff --git a/drivers/ide.c b/drivers/ide.c index 4cc572c..79ea8dd 100644 --- a/drivers/ide.c +++ b/drivers/ide.c @@ -1284,7 +1284,7 @@ NODE_METHODS(ob_ide) = { static void ob_ide_ctrl_decodeunit(int *idx) {
- fword("parse-hex");
fword("parse-1hex"); }
static void
diff --git a/drivers/lsi.c b/drivers/lsi.c index 51a541c..e5b09b3 100644 --- a/drivers/lsi.c +++ b/drivers/lsi.c @@ -590,7 +590,7 @@ static void ob_lsi_decodeunit(__attribute__((unused)) lsi_private_t **lsi_p) { /* ( str len -- id ) */
- fword("parse-hex");
fword("parse-1hex"); }
static void
diff --git a/drivers/pci.c b/drivers/pci.c index 787fa93..1691e6d 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1072,11 +1072,13 @@ int vga_config_cb (const pci_config_t *config) uint32_t rom_size, size, bar; phandle_t ph; #endif
PCI_DPRINTF("%s 0x%x\n", __func__, config->assigned[0]); if (config->assigned[0] != 0x00000000) { setup_video();#ifdef CONFIG_PPC if (config->assigned[6]) {
PCI_DPRINTF("%s Checking ROM\n", __func__); rom = pci_bus_addr_to_host_addr(MEMORY_SPACE_32, config->assigned[6] & ~0x0000000F); rom_size = config->sizes[6];@@ -1092,10 +1094,12 @@ int vga_config_cb (const pci_config_t *config) p = (const char *)rom; if (p[0] == 'N' && p[1] == 'D' && p[2] == 'R' && p[3] == 'V') { size = *(uint32_t*)(p + 4);
PCI_DPRINTF("%s Found NDRV, size=%u\n", __func__, size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p + 8, size); } else if (p[0] == 'J' && p[1] == 'o' && p[2] == 'y' && p[3] == '!') {PCI_DPRINTF("%s Found PEF, size=%u\n", __func__, rom_size); set_property(ph, "driver,AAPL,MacOS,PowerPC", p, rom_size); }diff --git a/drivers/sbus.fs b/drivers/sbus.fs index b84a3ac..cea2f14 100644 --- a/drivers/sbus.fs +++ b/drivers/sbus.fs @@ -5,8 +5,8 @@ : decode-unit-sbus ( str len -- id lun ) ascii , left-split ( addr-R len-R addr-L len-L )
- parse-hex
- -rot parse-hex
- parse-1hex
- -rot parse-1hex swap ;
diff --git a/forth/admin/nvram.fs b/forth/admin/nvram.fs index 3fbd935..d543a5e 100644 --- a/forth/admin/nvram.fs +++ b/forth/admin/nvram.fs @@ -104,7 +104,7 @@ constant config-info.size
: exec-int-conf ( str len -- value ) \ fixme
- parse-hex
- parse-1hex ; : check-int-conf ( str len -- str len valid? ) true
@@ -145,7 +145,7 @@ constant config-info.size 2dup s" false" strcmp 0= if 2drop false exit then 2dup s" TRUE" strcmp 0= if 2drop false exit then 2dup s" FALSE" strcmp 0= if 2drop false exit then
- parse-hex 0<>
parse-1hex 0<> ;
: check-bool-conf ( name len -- str len valid? )
diff --git a/forth/device/pathres.fs b/forth/device/pathres.fs index a185b95..7976d78 100644 --- a/forth/device/pathres.fs +++ b/forth/device/pathres.fs @@ -179,7 +179,7 @@ constant sinfo.size
\ used if package lacks a decode-unit method : def-decode-unit ( str len -- unitaddr ... )
- parse-hex
parse-1hex ;
: get-decode-unit-xt ( phandle -- xt )
diff --git a/forth/device/tree.fs b/forth/device/tree.fs index 6a4cb35..34c01e7 100644 --- a/forth/device/tree.fs +++ b/forth/device/tree.fs @@ -15,7 +15,7 @@ new-device 1 encode-int " #address-cells" property : open true ; : close ;
- : decode-unit parse-hex ;
- : decode-unit parse-1hex ; : encode-unit ( addr -- str len ) pocket tohexstr ;
diff --git a/forth/lib/string.fs b/forth/lib/string.fs index f97db23..55b24fc 100644 --- a/forth/lib/string.fs +++ b/forth/lib/string.fs @@ -122,7 +122,7 @@ \ string to number conversion \ -----------------------------------------------------
-: parse-hex ( str len -- value ) +: parse-1hex ( str len -- value ) base @ hex -rot $number if 0 then swap base ! ;
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
ATB,
Mark.
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote:
On 10/09/2022 12:58, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
parse-1hex is a word in every Apple Open Firmware for parsing one hex string into a number.
It looks like this:
: parse-ints ( str len count - numbers... ) { local_0 local_1 local_2 ; ... } local_2 0 do local_1 if local_0 local_1 2c left-parse-string \ 2c = ',' it's a comma! 2swap -> local_1 -> local_0 $number if 0 then else 0 then >r loop local_2 0 do r> loop ;
: parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> base ! ; \ save base, set base to hex, parse-ints, restore base : parse-1hex ( str len -- val ) 1 parse-nhex ; : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / Convert a “hi,lo” string into a pair of values.
I don't think OpenBIOS supports the Apple Open Firmware { locals from stack... ; locals... } syntax so you will have to make changes to parse-ints using normal forth stack manipulation words.
parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Regards, BALATON Zoltan
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote:
On 10/09/2022 12:58, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
parse-1hex is a word in every Apple Open Firmware for parsing one hex string into a number.
It looks like this:
: parse-ints ( str len count - numbers... ) { local_0 local_1 local_2 ; ... } local_2 0 do local_1 if local_0 local_1 2c left-parse-string \ 2c = ',' it's a comma! 2swap -> local_1 -> local_0 $number if 0 then else 0 then >r loop local_2 0 do r> loop ;
: parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> base ! ; \ save base, set base to hex, parse-ints, restore base : parse-1hex ( str len -- val ) 1 parse-nhex ; : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / Convert a “hi,lo” string into a pair of values.
I don't think OpenBIOS supports the Apple Open Firmware { locals from stack... ; locals... } syntax so you will have to make changes to parse-ints using normal forth stack manipulation words.
parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
ATB,
Mark.
On Sun, 18 Sep 2022, Mark Cave-Ayland wrote:
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote:
On 10/09/2022 12:58, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
parse-1hex is a word in every Apple Open Firmware for parsing one hex string into a number.
It looks like this:
: parse-ints ( str len count - numbers... ) { local_0 local_1 local_2 ; ... } local_2 0 do local_1 if local_0 local_1 2c left-parse-string \ 2c = ',' it's a comma! 2swap -> local_1 -> local_0 $number if 0 then else 0 then >r loop local_2 0 do r> loop ;
: parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> base ! ; \ save base, set base to hex, parse-ints, restore base : parse-1hex ( str len -- val ) 1 parse-nhex ; : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / Convert a “hi,lo” string into a pair of values.
I don't think OpenBIOS supports the Apple Open Firmware { locals from stack... ; locals... } syntax so you will have to make changes to parse-ints using normal forth stack manipulation words.
parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
How did you come to that conclusion from the above? The definition from SLOF does not work as it's based on some hex-decode-unit word which is also non-standard and unique to SLOF. I've actually ported that to OpenBIOS before as part of the fdt parsing code, look it up in the mail archive somwhere, but that's probably too much stuff for just parse-1hex. I still think renaming parse-hex to parse-1hex is the minimal change that's least likely to cause any problems here. Are you aware of anything that could break by it? If you don't like this patch then please do what you like and implement parse-1hex the way you think is better but some FCode ROMs will need this word.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
No, only parse-1hex for now but you'll need the other missing words I've posted almost 3 years ago. I've just sent a v2 that adds config-[wl] variants too as some other ROMs were needing those.
Apart from those we've found (again) "us" wotd is missing: https://mail.coreboot.org/pipermail/openbios/2017-December/010085.html
With the config-*, r*, map-* fixes, parse-1hex and substituting us with 1 ms for now we could run the FCode ROM of some ATI and NVidia cards.
Regards, BALATON Zoltan
On Sun, 18 Sep 2022, BALATON Zoltan wrote:
On Sun, 18 Sep 2022, Mark Cave-Ayland wrote:
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote:
On 10/09/2022 12:58, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
parse-1hex is a word in every Apple Open Firmware for parsing one hex string into a number.
It looks like this:
: parse-ints ( str len count - numbers... ) { local_0 local_1 local_2 ; ... } local_2 0 do local_1 if local_0 local_1 2c left-parse-string \ 2c = ',' it's a comma! 2swap -> local_1 -> local_0 $number if 0 then else 0 then >r loop local_2 0 do r> loop ;
: parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> base ! ; \ save base, set base to hex, parse-ints, restore base : parse-1hex ( str len -- val ) 1 parse-nhex ; : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / Convert a “hi,lo” string into a pair of values.
I don't think OpenBIOS supports the Apple Open Firmware { locals from stack... ; locals... } syntax so you will have to make changes to parse-ints using normal forth stack manipulation words.
parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
How did you come to that conclusion from the above? The definition from SLOF does not work as it's based on some hex-decode-unit word which is also non-standard and unique to SLOF. I've actually ported that to OpenBIOS before as part of the fdt parsing code, look it up in the mail archive somwhere, but that's probably too much stuff for just parse-1hex. I still think renaming parse-hex to parse-1hex is the minimal change that's least likely to cause any problems here. Are you aware of anything that could break by it? If you don't like this patch then please do what you like and implement parse-1hex the way you think is better but some FCode ROMs will need this word.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
No, only parse-1hex for now but you'll need the other missing words I've posted almost 3 years ago. I've just sent a v2 that adds config-[wl] variants too as some other ROMs were needing those.
Apart from those we've found (again) "us" wotd is missing: https://mail.coreboot.org/pipermail/openbios/2017-December/010085.html
There's some more info on the missing "us" word here: https://forums.macrumors.com/threads/question-how-powerful-of-a-graphics-car...
That thread also shows people wanted to use OpenBIOS to test gfx card ROMs but then went to DinfusPPC instead which by now can emulate a Mac better than QEMU and run OpenFirmware ROMs already.
With the config-*, r*, map-* fixes, parse-1hex and substituting us with 1 ms for now we could run the FCode ROM of some ATI and NVidia cards.
Regards, BALATON Zoltan
On 18/09/2022 22:14, BALATON Zoltan wrote:
On Sun, 18 Sep 2022, Mark Cave-Ayland wrote:
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote:
On 10/09/2022 12:58, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
parse-1hex is a word in every Apple Open Firmware for parsing one hex string into a number.
It looks like this:
: parse-ints ( str len count - numbers... ) { local_0 local_1 local_2 ; ... } local_2 0 do local_1 if local_0 local_1 2c left-parse-string \ 2c = ',' it's a comma! 2swap -> local_1 -> local_0 $number if 0 then else 0 then >r loop local_2 0 do r> loop ;
: parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> base ! ; \ save base, set base to hex, parse-ints, restore base : parse-1hex ( str len -- val ) 1 parse-nhex ; : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / Convert a “hi,lo” string into a pair of values.
I don't think OpenBIOS supports the Apple Open Firmware { locals from stack... ; locals... } syntax so you will have to make changes to parse-ints using normal forth stack manipulation words.
parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
How did you come to that conclusion from the above? The definition from SLOF does not work as it's based on some hex-decode-unit word which is also non-standard and unique to SLOF. I've actually ported that to OpenBIOS before as part of the fdt parsing code, look it up in the mail archive somwhere, but that's probably too much stuff for just parse-1hex. I still think renaming parse-hex to parse-1hex is the minimal change that's least likely to cause any problems here. Are you aware of anything that could break by it? If you don't like this patch then please do what you like and implement parse-1hex the way you think is better but some FCode ROMs will need this word.
Replacing one non-standard word with another non-standard word is just going to create code churn, with no discernible benefit. So let's go with just adding a PPC-specific alias for now.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
No, only parse-1hex for now but you'll need the other missing words I've posted almost 3 years ago. I've just sent a v2 that adds config-[wl] variants too as some other ROMs were needing those.
Apart from those we've found (again) "us" wotd is missing: https://mail.coreboot.org/pipermail/openbios/2017-December/010085.html
It should be fairly trivial to implement us by reading the timebase in a similar manner to ciface_milliseconds()/
With the config-*, r*, map-* fixes, parse-1hex and substituting us with 1 ms for now we could run the FCode ROM of some ATI and NVidia cards.
That's good progress :)
ATB,
Mark.
On Sun, 25 Sep 2022, Mark Cave-Ayland wrote:
On 18/09/2022 22:14, BALATON Zoltan wrote:
On Sun, 18 Sep 2022, Mark Cave-Ayland wrote:
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote:
On 10/09/2022 12:58, BALATON Zoltan wrote:
This word does not appear in OpenFirmware nor OpenBoot but Apple OF has a word called parse-1hex which is used by code running on that OF implementation. Rename parse-hex accordingly for compatibility.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
parse-1hex is a word in every Apple Open Firmware for parsing one hex string into a number.
It looks like this:
: parse-ints ( str len count - numbers... ) { local_0 local_1 local_2 ; ... } local_2 0 do local_1 if local_0 local_1 2c left-parse-string \ 2c = ',' it's a comma! 2swap -> local_1 -> local_0 $number if 0 then else 0 then >r loop local_2 0 do r> loop ;
: parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> base ! ; \ save base, set base to hex, parse-ints, restore base : parse-1hex ( str len -- val ) 1 parse-nhex ; : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / Convert a “hi,lo” string into a pair of values.
I don't think OpenBIOS supports the Apple Open Firmware { locals from stack... ; locals... } syntax so you will have to make changes to parse-ints using normal forth stack manipulation words.
parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
How did you come to that conclusion from the above? The definition from SLOF does not work as it's based on some hex-decode-unit word which is also non-standard and unique to SLOF. I've actually ported that to OpenBIOS before as part of the fdt parsing code, look it up in the mail archive somwhere, but that's probably too much stuff for just parse-1hex. I still think renaming parse-hex to parse-1hex is the minimal change that's least likely to cause any problems here. Are you aware of anything that could break by it? If you don't like this patch then please do what you like and implement parse-1hex the way you think is better but some FCode ROMs will need this word.
Replacing one non-standard word with another non-standard word is just going to create code churn, with no discernible benefit. So let's go with just adding a PPC-specific alias for now.
I think just one word which at least exists in some implementations is better than two words but it would also work with aliasing it in ppc so I'll try to do that then.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
No, only parse-1hex for now but you'll need the other missing words I've posted almost 3 years ago. I've just sent a v2 that adds config-[wl] variants too as some other ROMs were needing those.
Apart from those we've found (again) "us" wotd is missing: https://mail.coreboot.org/pipermail/openbios/2017-December/010085.html
It should be fairly trivial to implement us by reading the timebase in a similar manner to ciface_milliseconds()/
Looks like despite it's being trivial you could not get to do it in 3 years so we'll keep on waiting. I have no intention to do it as I don't need it.
With the config-*, r*, map-* fixes, parse-1hex and substituting us with 1 ms for now we could run the FCode ROM of some ATI and NVidia cards.
That's good progress :)
The ATI ROMs ran 3 years ago so no real progress there it's still the same. I did not try NVidia ROMs but we've found most don't run due to a different problem with colom defs within if. I have some info on this that I'll forward here in case it helps but basically old world Apple OF also has the same problem so people in the forum thread I've forwarded now patching these ROMs so that would also avoid the problem on OpenBIOS. Other than that NVidis ROMs only needed the config-[wl] words that was really trivial to add analogously to config-b and the "us" which could be defined as : us drop 1 ms ; (this could be mare complex but no need to as all delays were below 1 ms).
Regards, BALATON Zoltan
On 25/09/2022 14:29, BALATON Zoltan wrote:
On Sun, 25 Sep 2022, Mark Cave-Ayland wrote:
On 18/09/2022 22:14, BALATON Zoltan wrote:
On Sun, 18 Sep 2022, Mark Cave-Ayland wrote:
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote:
On 10/09/2022 12:58, BALATON Zoltan wrote:
> This word does not appear in OpenFirmware nor OpenBoot but Apple OF > has a word called parse-1hex which is used by code running on that > OF implementation. Rename parse-hex accordingly for compatibility. > > Signed-off-by: BALATON Zoltan balaton@eik.bme.hu > ---
I'd be wary of using Apple's Open Firmware as the baseline standard since it has a number of bugs and incompatibilities with the OF specification. Is there any significance to the digit 1 in parse-1hex? If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
parse-1hex is a word in every Apple Open Firmware for parsing one hex string into a number.
It looks like this:
: parse-ints ( str len count - numbers... ) { local_0 local_1 local_2 ; ... } local_2 0 do local_1 if local_0 local_1 2c left-parse-string \ 2c = ',' it's a comma! 2swap -> local_1 -> local_0 $number if 0 then else 0 then >r loop local_2 0 do r> loop ;
: parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> base ! ; \ save base, set base to hex, parse-ints, restore base : parse-1hex ( str len -- val ) 1 parse-nhex ; : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / Convert a “hi,lo” string into a pair of values.
I don't think OpenBIOS supports the Apple Open Firmware { locals from stack... ; locals... } syntax so you will have to make changes to parse-ints using normal forth stack manipulation words.
parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
How did you come to that conclusion from the above? The definition from SLOF does not work as it's based on some hex-decode-unit word which is also non-standard and unique to SLOF. I've actually ported that to OpenBIOS before as part of the fdt parsing code, look it up in the mail archive somwhere, but that's probably too much stuff for just parse-1hex. I still think renaming parse-hex to parse-1hex is the minimal change that's least likely to cause any problems here. Are you aware of anything that could break by it? If you don't like this patch then please do what you like and implement parse-1hex the way you think is better but some FCode ROMs will need this word.
Replacing one non-standard word with another non-standard word is just going to create code churn, with no discernible benefit. So let's go with just adding a PPC-specific alias for now.
I think just one word which at least exists in some implementations is better than two words but it would also work with aliasing it in ppc so I'll try to do that then.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
No, only parse-1hex for now but you'll need the other missing words I've posted almost 3 years ago. I've just sent a v2 that adds config-[wl] variants too as some other ROMs were needing those.
Apart from those we've found (again) "us" wotd is missing: https://mail.coreboot.org/pipermail/openbios/2017-December/010085.html
It should be fairly trivial to implement us by reading the timebase in a similar manner to ciface_milliseconds()/
Looks like despite it's being trivial you could not get to do it in 3 years so we'll keep on waiting. I have no intention to do it as I don't need it.
That comment was about fixing up the existing timers for non-SPARC architectures generally, not implementing the us word. If someone wants to implement the us word for PPC separately similar to ciface_milliseconds() then I'm happy to take a patch for it, however it is not on my immediate TODO list.
I'd also like to point out that making snarky comments is not appropriate behaviour for this mailing list: no one on this list is sponsored to maintain the project, so maintainership is done as time and interest allows. The quickest way to get a patch merged is to work with the list members and maintainers in a cooperative manner: trying to blame people for not doing what you think they should be doing is not helpful.
With the config-*, r*, map-* fixes, parse-1hex and substituting us with 1 ms for now we could run the FCode ROM of some ATI and NVidia cards.
That's good progress :)
The ATI ROMs ran 3 years ago so no real progress there it's still the same. I did not try NVidia ROMs but we've found most don't run due to a different problem with colom defs within if. I have some info on this that I'll forward here in case it helps but basically old world Apple OF also has the same problem so people in the forum thread I've forwarded now patching these ROMs so that would also avoid the problem on OpenBIOS. Other than that NVidis ROMs only needed the config-[wl] words that was really trivial to add analogously to config-b and the "us" which could be defined as : us drop 1 ms ; (this could be mare complex but no need to as all delays were below 1 ms).
Are there any other people who are interested in working on this? Even if you don't have the time/interest yourself, then I'm happy for discussions about features and patches to be discussed on this mailing list.
ATB,
Mark.
On Sun, 25 Sep 2022, Mark Cave-Ayland wrote:
On 25/09/2022 14:29, BALATON Zoltan wrote:
On Sun, 25 Sep 2022, Mark Cave-Ayland wrote:
On 18/09/2022 22:14, BALATON Zoltan wrote:
On Sun, 18 Sep 2022, Mark Cave-Ayland wrote:
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote: > On 10/09/2022 12:58, BALATON Zoltan wrote: > >> This word does not appear in OpenFirmware nor OpenBoot but Apple OF >> has a word called parse-1hex which is used by code running on that >> OF implementation. Rename parse-hex accordingly for compatibility. >> >> Signed-off-by: BALATON Zoltan balaton@eik.bme.hu >> --- > > I'd be wary of using Apple's Open Firmware as the baseline standard > since it has a number of bugs and incompatibilities with the OF > specification. Is there any significance to the digit 1 in parse-1hex? > If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" > somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
> parse-1hex is a word in every Apple Open Firmware for parsing one hex > string into a number. > > It looks like this: > > > : parse-ints ( str len count - numbers... ) > { local_0 local_1 local_2 ; ... } > local_2 0 do > local_1 if > local_0 local_1 2c left-parse-string \ 2c = ',' it's a > comma! > 2swap > -> local_1 > -> local_0 > $number > if > 0 > then > else > 0 > then > >r > loop > local_2 > 0 > do > r> > loop > ; > > : parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> > base ! ; \ save base, set base to hex, parse-ints, restore base > : parse-1hex ( str len -- val ) 1 parse-nhex ; > : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; > : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; > : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / > Convert a “hi,lo” string into a pair of values. > > > I don't think OpenBIOS supports the Apple Open Firmware { locals from > stack... ; locals... } syntax so you will have to make changes to > parse-ints using normal forth stack manipulation words. > > parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. > Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
How did you come to that conclusion from the above? The definition from SLOF does not work as it's based on some hex-decode-unit word which is also non-standard and unique to SLOF. I've actually ported that to OpenBIOS before as part of the fdt parsing code, look it up in the mail archive somwhere, but that's probably too much stuff for just parse-1hex. I still think renaming parse-hex to parse-1hex is the minimal change that's least likely to cause any problems here. Are you aware of anything that could break by it? If you don't like this patch then please do what you like and implement parse-1hex the way you think is better but some FCode ROMs will need this word.
Replacing one non-standard word with another non-standard word is just going to create code churn, with no discernible benefit. So let's go with just adding a PPC-specific alias for now.
I think just one word which at least exists in some implementations is better than two words but it would also work with aliasing it in ppc so I'll try to do that then.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
No, only parse-1hex for now but you'll need the other missing words I've posted almost 3 years ago. I've just sent a v2 that adds config-[wl] variants too as some other ROMs were needing those.
Apart from those we've found (again) "us" wotd is missing: https://mail.coreboot.org/pipermail/openbios/2017-December/010085.html
It should be fairly trivial to implement us by reading the timebase in a similar manner to ciface_milliseconds()/
Looks like despite it's being trivial you could not get to do it in 3 years so we'll keep on waiting. I have no intention to do it as I don't need it.
That comment was about fixing up the existing timers for non-SPARC architectures generally, not implementing the us word. If someone wants to implement the us word for PPC separately similar to ciface_milliseconds() then I'm happy to take a patch for it, however it is not on my immediate TODO list.
Well, apparently nobody wanted to do it for quite some time and I don't expect many people come forward to do it now either.
I'd also like to point out that making snarky comments is not appropriate behaviour for this mailing list: no one on this list is sponsored to maintain the project, so maintainership is done as time and interest allows. The
I'm sorry. Let's not start this again and try to leave it behind. We just spent some hours to find this out again only to realise all this was debugged and found 3 years ago already so we've lost some time (more than a few us ;-) ) on this again.
quickest way to get a patch merged is to work with the list members and maintainers in a cooperative manner: trying to blame people for not doing what you think they should be doing is not helpful.
I wasn't trying to blame you, just trying to say that what you think is trivial might not be for others because they first need to understand what you already know so instead of telling others to do it you could just do it if it's so simple. It might take much less time for you if you already see what to do than for sombody who first has to learn a lot about OpenBIOS and open firmware in general. From past experience you're also quick to dismiss any patches that aren't to your liking which discourages any potential contributor to spend time with it if the hours put in are dismissed then. That leaves you the only one at the end who can fix stuff in OpenBIOS.
With the config-*, r*, map-* fixes, parse-1hex and substituting us with 1 ms for now we could run the FCode ROM of some ATI and NVidia cards.
That's good progress :)
The ATI ROMs ran 3 years ago so no real progress there it's still the same. I did not try NVidia ROMs but we've found most don't run due to a different problem with colom defs within if. I have some info on this that I'll forward here in case it helps but basically old world Apple OF also has the same problem so people in the forum thread I've forwarded now patching these ROMs so that would also avoid the problem on OpenBIOS. Other than that NVidis ROMs only needed the config-[wl] words that was really trivial to add analogously to config-b and the "us" which could be defined as : us drop 1 ms ; (this could be mare complex but no need to as all delays were below 1 ms).
Are there any other people who are interested in working on this? Even if you don't have the time/interest yourself, then I'm happy for discussions about features and patches to be discussed on this mailing list.
So this came up again when somebody wanted to try passing through a real video card to MacOS for which we need to run the card's ROM to init both the card and the device tree for MacOS. With emulated cards this could be patched up sonehow but for a real card using the genuine Mac FCode ROM is the best way and the best way to do this cleanly. This was also the reason this came up 3 years ago from JD Lyons' experiments with some NVidia card and I only got involved because I wanted to test my ati-vga emulation with MacOS and real card ROMs to identify missing parts and fix the emulation that way. Back then I managed to get the ATI ROM run and MacOS boot and find some bugs in ati-vga that way. I've posted the bugs and proposed solutions to this list that I've identified during this but that's all I could do. Now we came together again because somebody still wanted to try this real card pass through and had to gather the pieces and rediscover some stuff. After spending a week with it people ran out of free time so it stalled again but I'm trying to get at least the parts upstreamed we already have so others don't have to go through all this again and again.
I think most people who wanted to use this won't come here, they are just try it and find it's not working and abandon it or maybe post on forums but very few people get to find this list and even less get to send patches here. For now this effort has stalled again, I'll try to forward at least the info we found, most of these are in these patches and there's one more in the forum thread about NVidia ROMs vs old world Apple OF which may also be a problem with OpenBIOS. I'll gather the discussion on that to forward here later just to have it documented somewhere.
Regards, BALATON Zoltan
-
BALATON Zoltan -
Mark Cave-Ayland