I may have found a bug in OpenBIOS.
An OS uses the "nextprop" iterator to scan device properties, and eventually
asks about nonexistant properties.
"const char *obp_nextprop(int node, const char *name)"
calls the "next-property" forth code, then pops the result.
According to the standard, next-property should return 0 if the property
is the last _OR_ if the property does not exist.
The current code in forth/admin/devices.fs returns nothing when the
For example (SPARC 32) :
" name" ?active-package next-property drop cr type
--> returns "device_type"
" interrupts" ?active-package next-property
--> returns 0, this is the last property.
" bozo" ?active-package next-property
--> returns nothing. Which, imho, is wrong.
Here is a patch, I am not quite sure about it (debuting Forth)
but it helps the target OS :
--- forth/device/property.fs (révision 1246)
+++ forth/device/property.fs (copie de travail)
@@ -70,7 +70,7 @@
2drop r> >dn.properties @
r> find-property dup if @ then
- ?dup if >prop.next @ then
+ dup if >prop.next @ then
The standard asks for a pointer to a zero lenght string instead of zero,
the C code obp_nextprop() expects a zero. I don't know if it makes a
(Btw, the OS is NetBSD :-)
On 03/01/14 13:03, Artyom Tarasenko wrote:
>> Oh that's interesting. As part of my test suite, I regularly boot SPARC32
>> NetBSD into graphics mode so I would expect this to already work.
> Have you tried the following image?
Not that particular image, however I boot both sparccd-5.0.2.iso and
sparccd-4.0.iso for my tests. Does NetBSD 6 do something different that
the others don't?