OpenBIOS February 2014

openbios@openbios.org

5 participants
26 discussions

[PATCH] Dummy tick counter
by Olivier Danet 04 Feb '14

04 Feb '14

romvec.pvtime is a pointer to a millisecond rate uptime counter. NextSTEP uses this counter for timing the 10 seconds timeout during boot, when asking for boot options. For now, let's just set this to a constant, there is no timeout, but we avoid null pointer dereferencing. Signed-off-by: Olivier Danet <odanet(a)caramail.com> =================================================================== --- arch/sparc32/romvec.c (révision 1257) +++ arch/sparc32/romvec.c (copie de travail) @@ -26,7 +26,7 @@ char obp_stdin, obp_stdout; const char *obp_stdin_path, *obp_stdout_path; - +int32_t obp_ticks; struct linux_arguments_v0 obp_arg; const char *bootpath; static const struct linux_arguments_v0 * const obp_argp = &obp_arg; @@ -456,6 +456,8 @@ via their handler (see call-romvec.S) which acts as a proxy to save the globals and setup the stack correctly */ + obp_ticks = 10000; /* Dummy. Ticks should be the uptime, in milliseconds. */ + // Linux wants a R/W romvec table romvec0.pv_magic_cookie = LINUX_OPPROM_MAGIC; romvec0.pv_romvers = 3; @@ -479,6 +481,7 @@ romvec0.pv_reboot = obp_reboot_handler; romvec0.pv_printf = obp_printf_handler; romvec0.pv_abort = obp_abort_handler; + romvec0.pv_ticks = &obp_ticks; romvec0.pv_halt = obp_halt_handler; romvec0.pv_synchook = &sync_hook; romvec0.pv_v0bootargs = &obp_argp; ===================================================================

2 1

[PATCH] Replace name -> fil
by Olivier Danet 04 Feb '14

04 Feb '14

Because name does not exist ! Signed-off-by: Olivier Danet <odanet(a)caramail.com> =================================================================== --- kernel/bootstrap.c (révision 1257) +++ kernel/bootstrap.c (copie de travail) @@ -513,7 +513,7 @@ if (ret != NULL) { #ifdef CONFIG_DEBUG_INTERPRETER - printk("Including '%s'\n", name ); + printk("Including '%s'\n", fil); #endif srcfilenames[cursrc] = strdup(fil); srclines [ cursrc ] = 1; ===================================================================

2 1

[PATCH] SparcStation 10/20 mode fix
by Olivier Danet 04 Feb '14

04 Feb '14

* SS10/20 use 36bits addresses. When mapping peripherals, bits [35:32] are not always tied to 0. * The probe-set-sbus forth word expects hex numbers for slots. SS5 uses slots 0 to 5, whereas SS10/20 uses the slot 0xF, and triggers the bug. Signed-off-by: Olivier Danet <odanet(a)caramail.com> =================================================================== --- drivers/iommu.c (révision 1257) +++ drivers/iommu.c (copie de travail) @@ -158,8 +158,8 @@ ucell size, virt; size = POP(); - POP(); phys = POP(); + phys = (phys << 32) + POP(); virt = ofmem_map_io(phys, size); =================================================================== --- drivers/sbus.c (révision 1257) +++ drivers/sbus.c (copie de travail) @@ -153,7 +153,7 @@ fword("new-device"); PUSH(0); PUSH(0); - snprintf(buf, 6, "%d,0", slot); + snprintf(buf, 6, "%x,0", slot); push_str(buf); fword("set-args"); feval("['] tcx-driver-fcode 2 cells + 1 byte-load"); @@ -268,7 +268,7 @@ PUSH(0); PUSH(0); - snprintf(buf, 6, "%d,%ld", slot, offset); + snprintf(buf, 6, "%x,%lx", slot, offset); push_str(buf); fword("2dup"); fword("probe-self-sbus"); ===================================================================

2 1

[PATCH] Keyboard property
by Olivier Danet 04 Feb '14

04 Feb '14

The keyboard property should be empty. NetBSD accesses the keyboard property in 'kernel/arch/sparc/dev/zs.c' and checks this : (prom_getproplen(zsc->zsc_node, "keyboard") == 0) ...which is true only when the property exists but has no value. It matches Sun's OpenBOOT behavior. Signed-off-by: Olivier Danet <odanet(a)caramail.com> =================================================================== --- drivers/escc.c (révision 1257) +++ drivers/escc.c (copie de travail) @@ -329,13 +329,13 @@ fword("property"); if (keyboard) { - PUSH(-1); - fword("encode-int"); + PUSH(0); + PUSH(0); push_str("keyboard"); fword("property"); - PUSH(-1); - fword("encode-int"); + PUSH(0); + PUSH(0); push_str("mouse"); fword("property"); } ===================================================================

2 1

Re: [OpenBIOS] [PATCH] next-property
by Olivier Danet 03 Feb '14

03 Feb '14

On 03/02/2014 15:21, Artyom Tarasenko wrote: > On Sat, Feb 1, 2014 at 9:54 PM, Olivier Danet <odanet(a)caramail.com> wrote: >> 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. > Right. As discussed before, the current behavior matches the OBP behavior on > sun4u machines. > > It would be nice to keep the comatibility with OBP. Can the C function > obp_nextprop(node,name) be modified instead? > > Artyom > >> 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> >> =================================================================== >> --- forth/device/property.fs (révision 1257) >> +++ forth/device/property.fs (copie de travail) >> @@ -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 >> =================================================================== >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you > > OpenBIOS's current behavior does not match any other ! For "next-property" we have 3 cases : a) The property is not the last b) The property is the last c) The property does not exist Current OpenBIOS : a) -1 "string" b) 0 c) nothing 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 Previous patch : a) -1 "string" b) 0 c) 0 Here is a patch adhering to the Ultra10's behavior, maybe other Sun4u computers do differently : =================================================================== --- arch/sparc32/romvec.c (révision 1257) +++ arch/sparc32/romvec.c (copie de travail) @@ -173,8 +173,9 @@ const char *obp_nextprop(int node, const char *name) { - int found; + int stackcnt; + stackcnt = dstackcnt; if (!name || *name == '\0') { // NULL name means get first property push_str(""); @@ -184,14 +185,13 @@ } PUSH(node); fword("next-property"); - found = POP(); - if (!found) { + if (dstackcnt == stackcnt) { DPRINTF("obp_nextprop(0x%x, %s) (not found)\n", node, name); return ""; } else { char *str; - + POP(); /* true */ POP(); /* len */ str = (char *) POP(); =================================================================== --- forth/device/property.fs (révision 1257) +++ forth/device/property.fs (copie de travail) @@ -70,14 +70,12 @@ 2drop r> >dn.properties @ else r> find-property dup if @ then - ?dup if >prop.next @ then + dup if >prop.next @ then then ?dup if >prop.name @ dup cstrlen true ( phandle name-str name-len true ) - else - false then ; =================================================================== The 'standard' way makes next-property more useable as a Forth word, but, really, I don't care. Olivier

1 0

[PATCH] next-property
by Olivier Danet 03 Feb '14

03 Feb '14

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> =================================================================== --- forth/device/property.fs (révision 1257) +++ forth/device/property.fs (copie de travail) @@ -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 ===================================================================

2 1