OpenBIOS March 2014

openbios@openbios.org

7 participants
30 discussions

[PATCH 3/4] Changes for MorphOS
by BALATON Zoltan 06 Mar '14

06 Mar '14

arch/ppc/qemu: Change model name to one which is similar but supported by MorphOS and better matches the emulated CPU. This should be safe to change as the two models are very close and unlikely to cause problems with other OSs but more testing is welcome. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Index: openbios-devel/arch/ppc/qemu/init.c =================================================================== --- openbios-devel/arch/ppc/qemu/init.c (revision 1272) +++ openbios-devel/arch/ppc/qemu/init.c (working copy) @@ -745,12 +745,12 @@ /* model */ - push_str("PowerMac2,1"); + push_str("PowerMac3,1"); fword("model"); /* compatible */ - push_str("PowerMac2,1"); + push_str("PowerMac3,1"); fword("encode-string"); push_str("MacRISC"); fword("encode-string");

1 0

[PATCH 2/4] Changes for MorphOS
by BALATON Zoltan 06 Mar '14

06 Mar '14

Update URL to documentation which is not where it used to be Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Index: openbios-devel/arch/ppc/qemu/ofmem.c =================================================================== --- openbios-devel/arch/ppc/qemu/ofmem.c (revision 1272) +++ openbios-devel/arch/ppc/qemu/ofmem.c (working copy) @@ -179,7 +179,7 @@ /* Generate translation property entry for PPC. * According to the platform bindings for PPC - * (http://playground.sun.com/1275/bindings/ppc/release/ppc-2_1.html#REF34579) + * (http://www.openfirmware.org/1275/bindings/ppc/release/ppc-2_1.html#REF34579) * a translation property entry has the following layout: * * virtual address

1 0

[PATCH 1/4] Changes for MorphOS
by BALATON Zoltan 06 Mar '14

06 Mar '14

arch/ppc/qemu: Fix cache parameter property names to match the standard. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Index: openbios-devel/arch/ppc/qemu/init.c =================================================================== --- openbios-devel/arch/ppc/qemu/init.c (revision 1272) +++ openbios-devel/arch/ppc/qemu/init.c (working copy) @@ -241,32 +241,32 @@ PUSH(cpu->dcache_size); fword("encode-int"); - push_str("dcache-size"); + push_str("d-cache-size"); fword("property"); PUSH(cpu->icache_size); fword("encode-int"); - push_str("icache-size"); + push_str("i-cache-size"); fword("property"); PUSH(cpu->dcache_sets); fword("encode-int"); - push_str("dcache-sets"); + push_str("d-cache-sets"); fword("property"); PUSH(cpu->icache_sets); fword("encode-int"); - push_str("icache-sets"); + push_str("i-cache-sets"); fword("property"); PUSH(cpu->dcache_block_size); fword("encode-int"); - push_str("dcache-block-size"); + push_str("d-cache-block-size"); fword("property"); PUSH(cpu->icache_block_size); fword("encode-int"); - push_str("icache-block-size"); + push_str("i-cache-block-size"); fword("property"); PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));

1 0

"next-property" reloaded !
by Olivier Danet 05 Mar '14

05 Mar '14

Hello ! I have tried to recreate the 3 known variants of next-property: Standard : a) true "string" b) false c) false Sun Ultra10 : a) -1 "string" b) nothing c) nothing PowerPC iBook : a) -1 "string" b) -1 0 0 c) 0 Here is a tentative patch : Index: forth/admin/devices.fs =================================================================== --- forth/admin/devices.fs (révision 1269) +++ forth/admin/devices.fs (copie de travail) @@ -451,7 +451,7 @@ ?active-package dup >r if 0 0 begin - r@ next-property + r@ next-property-std while cr 2dup dup -rot type begin ." " 1+ dup d# 26 >= until drop Index: forth/device/property.fs =================================================================== --- forth/device/property.fs (révision 1269) +++ forth/device/property.fs (copie de travail) @@ -63,14 +63,14 @@ ; \ From package (5.3.4.1) -: next-property +: next-property-std ( previous-str previous-len phandle -- false | name-str name-len true ) >r 2dup 0= swap 0= or if 2drop r> >dn.properties @ else r> find-property dup if @ then - ?dup if >prop.next @ then + dup if >prop.next @ then then ?dup if @@ -81,7 +81,57 @@ then ; +: next-property-ppc +( previous-str previous-len phandle -- false | name-str name-len true | 0 0 true ) + >r + 2dup 0= swap 0= or if + 2drop r> >dn.properties @ true + else + r> find-property dup if @ then + dup if >prop.next @ true then + then + if + dup if + >prop.name @ dup cstrlen + ( phandle name-str name-len ) + else + 0 + ( 0 0 ) + then + true + else + false + then +; + +: next-property-std-bis + next-property-ppc + dup + if over 0= + if + 2drop + then + then +; + +: next-property-s64 + next-property-std + ?dup drop +; + +: next-property + [IFDEF] CONFIG_PPC + next-property-ppc + [ELSE] + [IFDEF] CONFIG_SPARC64 + next-property-s64 + [ELSE] + next-property-std + [THEN] + [THEN] +; + \ \ 5.3.5.4 Property value access \ Index: forth/system/ciface.fs =================================================================== --- forth/system/ciface.fs (révision 1269) +++ forth/system/ciface.fs (copie de travail) @@ -121,7 +121,7 @@ ( buf prev prev_len ) - r> next-property if + r> next-property-std if ( buf name name_len ) dup 1+ -rot ci-strcpy drop 1 else =================================================================== there are : next-property-std = standard, used by Sparc32 "romvec" C code and by forth code, like ".properties" next-property-s64 = Sparc64 version, built from next-property-std next-property-ppc = PowerPC version next-property-std-bis = Alternate standard version, built from the PPC one (e.g. when compiling for PPC target) Tests : showstack cd screen \ Sparc32 " " ?active-package next-property-std cr . type cr " name" ?active-package next-property-std cr . type cr " interrupts" ?active-package next-property-std cr . cr " ttttt" ?active-package next-property-std cr . cr \ PowerPC " " ?active-package next-property-ppc cr . type cr " name" ?active-package next-property-ppc cr . type cr " interrupts" ?active-package next-property-ppc cr . . . cr " ttttt" ?active-package next-property-ppc cr . cr \ Sparc64 " " ?active-package next-property-s64 cr . type cr " name" ?active-package next-property-s64 cr . type cr " interrupts" ?active-package next-property-s64 cr " ttttt" ?active-package next-property-s64 cr " " ?active-package next-property-std-bis cr . type cr " name" ?active-package next-property-std-bis cr . type cr " interrupts" ?active-package next-property-std-bis cr . cr " ttttt" ?active-package next-property-std-bis cr . cr Currently all variants are available simultaneously. Additional [IFDEF] can be used to hide some variants according to compilation options, generate the -std from the -ppc,.. One more oddity: NetBSD is not the only one to do strange things with properties. In OpenBSD, one can find : arch/sparc/dev/sbus.c:int sbus_testdma(sc, ca) ... getpropint(0, "slave-only", 0) ... arch/sparc/dev/sbus.c:int sbus_print(args, sbus) ... getpropint(0, sl, 0) ... Here, 0 should select the 'root' node. It really looks like a bug in OpenBSD. It does not prevent the OS from running though. Olivier

2 4

Re: [OpenBIOS] [Qemu-ppc] MorphOS 4.x on QEMU
by BALATON Zoltan 05 Mar '14

05 Mar '14

On Fri, 28 Feb 2014, BALATON Zoltan wrote: > On Thu, 27 Feb 2014, Mark Cave-Ayland wrote: >> FWIW there is a known issue with PPC's next-property iterator being >> implemented differently to the standard (see Olivier's tentative patch at >> http://www.openfirmware.info/pipermail/openbios/2014-February/008141.html). >> It's likely that a broken device tree iteration could be the cause of the >> MorphOS bootloader not being able to locate a suitable console mode which >> could be related to your issue. > > I think I did not hit this one yet at least the console problem is surely not > caused by this but by MorphOS only supporting some specific Radeon GPUs that > are found in the PPC Macs it is supporting. It is looking for them by their > vendor-id:device-id and fails if not found, but tries to continue anyway. While the next property iterator is not the cause of the console failed message it may very well be related to the hang in CPU detection later that I'm currently facing. I see the following openbios debug output with DEBUG_CIF enabled in libopenbios/client.c while MorphOS tries to detect the CPU: >> finddevice("/cpus") = 0xfff4bbec >> child(0xfff4bbec) = 0xfff5194c >> nextprop(0xfff5194c, "", 0x07de7e30) = 1 >> 0x07de7e30 6e __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ n >> getprop(0xfff5194c, "name", 0x07de7df0, 64) = 11 >> 0x07de7df0 50 6f 77 65 72 50 43 2c 47 34 00 __ __ __ __ __ PowerPC,G4. >> nextprop(0xfff5194c, "name", 0x07de7e30) = -1 >> child(0xfff5194c) = 0x00000000 and here it gives up and freezes. This is with Olivier's patch applied, which does not change anything in the above, I'm seeing this with or without this patch. It seems to be a case of nextprop failing which the patch does not correct. Any hints how to debug it further? I don't know how to test or trace forth so I'd need some help with this. By the way, if it didn't fail to explore the properties of the CPU it seems to be looking for these on the CPU node: altivec bus-frequency clock-frequency cpu-version data-streams d-cache-block-size d-cache-line-size d-cache-sets d-cache-size i-cache-block-size i-cache-line-size i-cache-sets i-cache-size performance-monitor reservation-granule-size timebase-frequency tlb-size tlb-sets then it tries to go down the tree and explore l2-cache and l3-cache nodes (this is the last child call returning NULL in the above). I don't know which of these are optional and which are critical but looking at what QEMU provides now: name "PowerPC,G4" device_type "cpu" cpu-version c0209 dcache-size 8000 icache-size 8000 dcache-sets 80 icache-sets 80 dcache-block-size 20 icache-block-size 20 timebase-frequency 3b9aca00 clock-frequency 0 state "running" reg 00000000 available 00004000 07c54000 07e10000 f80f0000 00000000 ffffffff translations 00001000 00003000 00001000 00000000 07c58000 001b8000 07c58000 00000000 fff00000 00100000 07f00000 00000000 I expect some problems with these too once we manage to make nextprop work. For a start frequency entries are missing or seem to be wrong. Regards, BALATON Zoltan

5 22

[patch] fix "partition-zero"/%BOOT booting for PowerPC targets.
by Andrei E. Warkentin 05 Mar '14

05 Mar '14

Hi, This is a patch against r1272 which implements fully bootcode booting via Apple boot partition descriptors. The current implementation in libopenbios/bootcode_load.c hardcoded values for QUIK (the old OldWorld bootloader), which is useless if you try to boot anything else. In particular, I implemented this to simplify my development and test cycle on iQUIK (https://github.com/andreiw/quik), but I also tested this with the NetBSD floppy. The later now boots to stage 2 as well, although it tries using some functionality unavailable in the OpenBIOS implementation when compared to Apple's. I did this in the simplest way possible. Btw, I see that the optimization bugs are still present. I had to compile with -O0, otherwise the resulting image doesn't boot (GCC 4.8 here). -- A

1 0

[commit] r1272 - trunk/openbios-devel/forth/device
by repository service 05 Mar '14

05 Mar '14

Author: mcayland Date: Wed Mar 5 01:04:32 2014 New Revision: 1272 URL: http://tracker.coreboot.org/trac/openbios/changeset/1272 Log: property.fs: fix next-property return when requesting non-existent property obp_nextprop(node,name) calls the Forth word "next-property" then pops the result. "next-property" should therefore always return something: * A string when the property provided is not the last one of the node. * Zero when the property provided is the last one of the node. * Zero when the property provided does not exist in the current node. Previously, next-property returned nothing when the property didn't exist. "next-property" behavior with last and nonexistant properties differs between implementations of OF. This problem was found with NetBSD on Sparc32. It ennumerates peripherals when starting X11 and asks for the "name" and "device_type" property of many nodes, including some which have neither "name" nor "device_type" properties. Signed-off-by: Olivier Danet <odanet(a)caramail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/property.fs Modified: trunk/openbios-devel/forth/device/property.fs ============================================================================== --- trunk/openbios-devel/forth/device/property.fs Mon Mar 3 18:00:20 2014 (r1271) +++ trunk/openbios-devel/forth/device/property.fs Wed Mar 5 01:04:32 2014 (r1272) @@ -70,7 +70,7 @@ 2drop r> >dn.properties @ else r> find-property dup if @ then - ?dup if >prop.next @ then + dup if >prop.next @ then then ?dup if

1 0

[commit] r1271 - trunk/openbios-devel/forth/system
by repository service 03 Mar '14

03 Mar '14

Author: mcayland Date: Mon Mar 3 18:00:20 2014 New Revision: 1271 URL: http://tracker.coreboot.org/trac/openbios/changeset/1271 Log: ciface.fs: alter nextprop to preserve output buffer unless an error occurs Previously nextprop would always write a 0 length string to the output buffer before calling the underlying property words, with the assumption that this would be the default return value in the case of an error. MorphOS breaks this assumption by specifying buf == prev when calling nextprop which caused the prev value to be overwritten before it could be used, and so nextprop would always return an (error) exit code of -1. Fix nextprop so that the 0 length string is only written into the output buffer when an error exit code of -1 or 0 is returned, as per the IEEE1275 specification. As reported by BALATON Zoltan <balaton(a)eik.bme.hu>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/system/ciface.fs Modified: trunk/openbios-devel/forth/system/ciface.fs ============================================================================== --- trunk/openbios-devel/forth/system/ciface.fs Mon Mar 3 00:18:34 2014 (r1270) +++ trunk/openbios-devel/forth/system/ciface.fs Mon Mar 3 18:00:20 2014 (r1271) @@ -108,12 +108,13 @@ dup 0= if 0 else dup cstrlen then ( buf prev prev_len ) - 0 3 pick c! \ verify that prev exists (overkill...) dup if 2dup r@ get-package-property if - r> 2drop 2drop -1 exit + r> 2drop drop + 0 swap c! + -1 exit else 2drop then @@ -126,7 +127,8 @@ dup 1+ -rot ci-strcpy drop 1 else ( buf ) - drop 0 + 0 swap c! + 0 then ;

1 0

[commit] r1270 - trunk/openbios-devel/drivers
by repository service 03 Mar '14

03 Mar '14

Author: mcayland Date: Mon Mar 3 00:18:34 2014 New Revision: 1270 URL: http://tracker.coreboot.org/trac/openbios/changeset/1270 Log: pci: Add the prog interface field to class-code property The class-code property of PCI devices should also include the prog interface field. This patch adds this. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/pci.c Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Sun Feb 16 17:26:46 2014 (r1269) +++ trunk/openbios-devel/drivers/pci.c Mon Mar 3 00:18:34 2014 (r1270) @@ -893,11 +893,13 @@ int status,id; uint16_t vendor_id, device_id; uint8_t rev; + uint8_t class_prog; uint32_t class_code; vendor_id = pci_config_read16(addr, PCI_VENDOR_ID); device_id = pci_config_read16(addr, PCI_DEVICE_ID); rev = pci_config_read8(addr, PCI_REVISION_ID); + class_prog = pci_config_read8(addr, PCI_CLASS_PROG); class_code = pci_config_read16(addr, PCI_CLASS_DEVICE); if (pci_dev) { @@ -925,7 +927,7 @@ set_int_property(dev, "vendor-id", vendor_id); set_int_property(dev, "device-id", device_id); set_int_property(dev, "revision-id", rev); - set_int_property(dev, "class-code", class_code << 8); + set_int_property(dev, "class-code", class_code << 8 | class_prog); if (config->irq_pin) { OLDWORLD(set_int_property(dev, "AAPL,interrupts",

1 0

[PATCH] Add the prog interface field to class-code property
by BALATON Zoltan 03 Mar '14

03 Mar '14

The class-code property of PCI devices should also include the prog interface field. This patch adds this. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> =================================================================== --- drivers/pci.c (revision 1269) +++ drivers/pci.c (working copy) @@ -893,11 +893,13 @@ int status,id; uint16_t vendor_id, device_id; uint8_t rev; + uint8_t class_prog; uint32_t class_code; vendor_id = pci_config_read16(addr, PCI_VENDOR_ID); device_id = pci_config_read16(addr, PCI_DEVICE_ID); rev = pci_config_read8(addr, PCI_REVISION_ID); + class_prog = pci_config_read8(addr, PCI_CLASS_PROG); class_code = pci_config_read16(addr, PCI_CLASS_DEVICE); if (pci_dev) { @@ -925,7 +927,7 @@ set_int_property(dev, "vendor-id", vendor_id); set_int_property(dev, "device-id", device_id); set_int_property(dev, "revision-id", rev); - set_int_property(dev, "class-code", class_code << 8); + set_int_property(dev, "class-code", class_code << 8 | class_prog); if (config->irq_pin) { OLDWORLD(set_int_property(dev, "AAPL,interrupts", ===============================================================

2 3