Re: [OpenBIOS] next-property

[Olivier Danet]

On 03/01/2014 17:09, Artyom Tarasenko wrote:
> On Thu, Jan 2, 2014 at 2:43 AM, Olivier Danet  wrote:
> > 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)"
> > (arch/sparc32/romvec.c)
> >    calls the "next-property" forth code, then pops the result.
> > According to the standard, next-property should return 0 if the property
> > selected
> >    is the last _OR_ if the property does not exist.
> > The current code in forth/admin/devices.fs returns nothing when the property
> > does
> >    not exit.
> >
> > For example (SPARC 32) :
> >
> > cd screen
> > " 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.
>
> Actually this matches pretty much with what OBP does:
>
> ok showstack
> ok " model" current-device next-property
> fffe61e8 4 ffffffffffffffff ok drop type
> name
> ok " bozo" current-device next-property
> ok
>
> Artyom
> > Here is a patch, I am not quite sure about it (debuting Forth)
> >    but it helps the target OS :
> > Index: forth/device/property.fs
> >
> > --- forth/device/property.fs    (révision 1246)
> > +++ 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
> >
> > ===================================================================
> >
> > 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
> >    difference.
> >
> > Olivier
> > (Btw, the OS is NetBSD :-)

You are right.
I tried on an Ultra 10 with OpenBoot 3.12.

next-property returns nothing when the property is unknown and also when 
the property is the last one.
This contradicts Sun own documentation "Writing FCode 3.x Programs".

Puzzled, I tried then on a Apple iBook G3 :
dev screen
" <something>" active-package next-property

This laptop returns :
  - true and a forth string when the property is not the last one
  - true and "0 0" when the property is the last one
  - false when the property does not exist.

Anyway, whatever method is chosen (return nothing, return zero...), 
OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to 
avoid page faults.

Olivier

next-property

[Mark Cave-Ayland]

On 03/01/14 19:16, Olivier Danet wrote:

Hi Olivier,
> You are right.
> I tried on an Ultra 10 with OpenBoot 3.12.
>
> next-property returns nothing when the property is unknown and also when
> the property is the last one.
> This contradicts Sun own documentation "Writing FCode 3.x Programs".

Hmmmm. Is there anything in the IEEE1275 errata about this?
> Puzzled, I tried then on a Apple iBook G3 :
> dev screen
> " <something>" active-package next-property
>
> This laptop returns :
> true and a forth string when the property is not the last one
> true and "0 0" when the property is the last one
> false when the property does not exist.
>
> Anyway, whatever method is chosen (return nothing, return zero...),
> OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to
> avoid page faults.

Yes indeed. The OpenBIOS Forth string to C string implementation returns 
NULL if the length is 0 which has caught me out a few times. The trick 
I've done, particularly in the filesystem drivers, is to do something 
like the following where required:

if (str == NULL) {
     return "";
}

BTW you never answered about which version of NetBSD you were trying to 
boot?

ATB,

Mark.

next-property

[Olivier Danet]

On 03/01/2014 21:01, Mark Cave-Ayland wrote:
> On 03/01/14 19:16, Olivier Danet wrote:
>
> Hi Olivier,
> > You are right.
> > I tried on an Ultra 10 with OpenBoot 3.12.
> >
> > next-property returns nothing when the property is unknown and also when
> > the property is the last one.
> > This contradicts Sun own documentation "Writing FCode 3.x Programs".
>
> Hmmmm. Is there anything in the IEEE1275 errata about this?
> > Puzzled, I tried then on a Apple iBook G3 :
> > dev screen
> > " <something>" active-package next-property
> >
> > This laptop returns :
> > true and a forth string when the property is not the last one
> > true and "0 0" when the property is the last one
> > false when the property does not exist.
> >
> > Anyway, whatever method is chosen (return nothing, return zero...),
> > OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to
> > avoid page faults.
>
> Yes indeed. The OpenBIOS Forth string to C string implementation 
> returns NULL if the length is 0 which has caught me out a few times. 
> The trick I've done, particularly in the filesystem drivers, is to do 
> something like the following where required:
>
> if (str == NULL) {
>     return "";
> }
>
> BTW you never answered about which version of NetBSD you were trying 
> to boot?
>
> ATB,
>
> Mark.

I am using the latest, 6.1.2, installed from the full ISO image.
They changed quite a bit the video part in NetBSD 6, overhauled
the console and seem to have forked the TCX X11 driver to add hardware
acceleration.

I managed yesterday to boot NetBSD and run X in 256 colours mode !

Changes so far :

OpenBIOS :
- The "next-property" stuff. Called when starting the X server.
- "keyboard" property detail. Else keyboard input does not work.
- TCX properties modifications. For TCX/Dumb framebuffer selection.

QEMU :
- Old bug "!TC on DATA XFER" in esp.c driver
- TCX hardware acceleration stuff in tcx.c and sun4m.c (for memory regions):
   blitter, stippler, hardware cursor.

Olivier

next-property

[Mark Cave-Ayland]

On 03/01/14 20:33, Olivier Danet wrote:
> On 03/01/2014 21:01, Mark Cave-Ayland wrote:
> > On 03/01/14 19:16, Olivier Danet wrote:
> >
> > Hi Olivier,
> > > You are right.
> > > I tried on an Ultra 10 with OpenBoot 3.12.
> > >
> > > next-property returns nothing when the property is unknown and also when
> > > the property is the last one.
> > > This contradicts Sun own documentation "Writing FCode 3.x Programs".
> >
> > Hmmmm. Is there anything in the IEEE1275 errata about this?
> > > Puzzled, I tried then on a Apple iBook G3 :
> > > dev screen
> > > " <something>" active-package next-property
> > >
> > > This laptop returns :
> > > true and a forth string when the property is not the last one
> > > true and "0 0" when the property is the last one
> > > false when the property does not exist.
> > >
> > > Anyway, whatever method is chosen (return nothing, return zero...),
> > > OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to
> > > avoid page faults.
> >
> > Yes indeed. The OpenBIOS Forth string to C string implementation
> > returns NULL if the length is 0 which has caught me out a few times.
> > The trick I've done, particularly in the filesystem drivers, is to do
> > something like the following where required:
> >
> > if (str == NULL) {
> > return "";
> > }
> >
> > BTW you never answered about which version of NetBSD you were trying
> > to boot?
> >
> > ATB,
> >
> > Mark.
>
> I am using the latest, 6.1.2, installed from the full ISO image.
> They changed quite a bit the video part in NetBSD 6, overhauled
> the console and seem to have forked the TCX X11 driver to add hardware
> acceleration.

Oh that's interesting. Is there anything here that could be shared with 
a potential CG6 driver of any sort?

FWIW for testing you could also try my CG3 patchset here: 
https://github.com/mcayland/qemu/tree/cg3-final but you'll probably want 
to replace the QEMU,cgthree.bin ROM in QEMU with the one from OpenBIOS 
SVN trunk.
> I managed yesterday to boot NetBSD and run X in 256 colours mode !

Fantastic!
> Changes so far :
>
> OpenBIOS :
> The "next-property" stuff. Called when starting the X server.
> "keyboard" property detail. Else keyboard input does not work.
> TCX properties modifications. For TCX/Dumb framebuffer selection.

The latter is interesting; is it possible for the OS to detect the 
framebuffer as a CG3/CG6 at all?
> QEMU :
> Old bug "!TC on DATA XFER" in esp.c driver

I seem to remember Blue posted a potential patch for this, but I wasn't 
able to find it again?
> TCX hardware acceleration stuff in tcx.c and sun4m.c (for memory
>
> regions):
> blitter, stippler, hardware cursor.

Fascinating.

As always, I'm happy to apply any OpenBIOS patches and to help get the 
others into QEMU as required.

ATB,

Mark.

next-property

[Olivier Danet]

On 03/01/2014 22:14, Mark Cave-Ayland wrote:
> On 03/01/14 20:33, Olivier Danet wrote:
> > On 03/01/2014 21:01, Mark Cave-Ayland wrote:
> > > On 03/01/14 19:16, Olivier Danet wrote:
> > >
> > > Hi Olivier,
> > > > You are right.
> > > > I tried on an Ultra 10 with OpenBoot 3.12.
> > > >
> > > > next-property returns nothing when the property is unknown and also 
> > > > when
> > > > the property is the last one.
> > > > This contradicts Sun own documentation "Writing FCode 3.x Programs".
> > >
> > > Hmmmm. Is there anything in the IEEE1275 errata about this?
> > > > Puzzled, I tried then on a Apple iBook G3 :
> > > > dev screen
> > > > " <something>" active-package next-property
> > > >
> > > > This laptop returns :
> > > > true and a forth string when the property is not the last one
> > > > true and "0 0" when the property is the last one
> > > > false when the property does not exist.
> > > >
> > > > Anyway, whatever method is chosen (return nothing, return zero...),
> > > > OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to
> > > > avoid page faults.
> > >
> > > Yes indeed. The OpenBIOS Forth string to C string implementation
> > > returns NULL if the length is 0 which has caught me out a few times.
> > > The trick I've done, particularly in the filesystem drivers, is to do
> > > something like the following where required:
> > >
> > > if (str == NULL) {
> > > return "";
> > > }
> > >
> > > BTW you never answered about which version of NetBSD you were trying
> > > to boot?
> > >
> > > ATB,
> > >
> > > Mark.
> >
> > I am using the latest, 6.1.2, installed from the full ISO image.
> > They changed quite a bit the video part in NetBSD 6, overhauled
> > the console and seem to have forked the TCX X11 driver to add hardware
> > acceleration.
>
> Oh that's interesting. Is there anything here that could be shared 
> with a potential CG6 driver of any sort?
>
> FWIW for testing you could also try my CG3 patchset here: 
> https://github.com/mcayland/qemu/tree/cg3-final but you'll probably 
> want to replace the QEMU,cgthree.bin ROM in QEMU with the one from 
> OpenBIOS SVN trunk.

I will try !
> > I managed yesterday to boot NetBSD and run X in 256 colours mode !
>
> Fantastic!
> > Changes so far :
> >
> > OpenBIOS :
> > The "next-property" stuff. Called when starting the X server.
> > "keyboard" property detail. Else keyboard input does not work.
> > TCX properties modifications. For TCX/Dumb framebuffer selection.
>
> The latter is interesting; is it possible for the OS to detect the 
> framebuffer as a CG3/CG6 at all?

The modifications were necessary to prevent the dumb framebuffer from 
taking control of the console during
boot. It is almost a bug in NetBSD.
The 'name' property is used for identifying the device type : 
"SUNW,tcx", or "cgsix"...
I have never met a real CG3 !
> > QEMU :
> > Old bug "!TC on DATA XFER" in esp.c driver
>
> I seem to remember Blue posted a potential patch for this, but I 
> wasn't able to find it again?
> > TCX hardware acceleration stuff in tcx.c and sun4m.c (for memory
> >
> > regions):
> > blitter, stippler, hardware cursor.
>
> Fascinating.
>
> As always, I'm happy to apply any OpenBIOS patches and to help get the 
> others into QEMU as required.
>
> ATB,
>
> Mark.

I will try the truecolor mode and check for regressions and post the 
diffs soon.

The acceleration parts of TCX used by NetBSD are really very simple, the 
actual hardware
is probably quite limited, much simpler than CG6.
The hardware cursor part is probably quite similar, as is the palette.

http://sourceware.mirrors.tds.net/pub/NetBSD/NetBSD-release-6/xsrc/external/...
http://sourceware.mirrors.tds.net/pub/NetBSD/NetBSD-release-6/xsrc/external/...
The Xsun sources which were published a while ago included the CG6 
driver, iirc.

Having a reasonably complete TCX driver is probably doable and 
interesting for Solaris (6/7/8/9 ???).

Olivier

next-property

[Mark Cave-Ayland]

On 03/01/14 22:32, Olivier Danet wrote:
> > > I am using the latest, 6.1.2, installed from the full ISO image.
> > > They changed quite a bit the video part in NetBSD 6, overhauled
> > > the console and seem to have forked the TCX X11 driver to add hardware
> > > acceleration.
> >
> > Oh that's interesting. Is there anything here that could be shared
> > with a potential CG6 driver of any sort?
> >
> > FWIW for testing you could also try my CG3 patchset here:
> > https://github.com/mcayland/qemu/tree/cg3-final but you'll probably
> > want to replace the QEMU,cgthree.bin ROM in QEMU with the one from
> > OpenBIOS SVN trunk.
>
> I will try !

Great let me know how you get on :)
> > > I managed yesterday to boot NetBSD and run X in 256 colours mode !
> >
> > Fantastic!
> > > Changes so far :
> > >
> > > OpenBIOS :
> > > The "next-property" stuff. Called when starting the X server.
> > > "keyboard" property detail. Else keyboard input does not work.
> > > TCX properties modifications. For TCX/Dumb framebuffer selection.
> >
> > The latter is interesting; is it possible for the OS to detect the
> > framebuffer as a CG3/CG6 at all?
>
> The modifications were necessary to prevent the dumb framebuffer from
> taking control of the console during
> boot. It is almost a bug in NetBSD.
> The 'name' property is used for identifying the device type :
> "SUNW,tcx", or "cgsix"...
> I have never met a real CG3 !
> > > QEMU :
> > > Old bug "!TC on DATA XFER" in esp.c driver
> >
> > I seem to remember Blue posted a potential patch for this, but I
> > wasn't able to find it again?
> > > TCX hardware acceleration stuff in tcx.c and sun4m.c (for memory
> > >
> > > regions):
> > > blitter, stippler, hardware cursor.
> >
> > Fascinating.
> >
> > As always, I'm happy to apply any OpenBIOS patches and to help get the
> > others into QEMU as required.
> >
> > ATB,
> >
> > Mark.
>
> I will try the truecolor mode and check for regressions and post the
> diffs soon.
>
> The acceleration parts of TCX used by NetBSD are really very simple, the
> actual hardware
> is probably quite limited, much simpler than CG6.
> The hardware cursor part is probably quite similar, as is the palette.
>
> http://sourceware.mirrors.tds.net/pub/NetBSD/NetBSD-release-6/xsrc/external/...
>
> http://sourceware.mirrors.tds.net/pub/NetBSD/NetBSD-release-6/xsrc/external/...
>
> The Xsun sources which were published a while ago included the CG6
> driver, iirc.
>
> Having a reasonably complete TCX driver is probably doable and
> interesting for Solaris (6/7/8/9 ???).

Well the CG3 framebuffer code above will boot my Solaris 7 ISO in 
1024x768 graphics mode, and current SVN trunk FCode ROMs for TCX and CG3 
work with both OBP and OpenBIOS :)  Unless someone wants to sponsor 
development of course ;)

ATB,

Mark.

next-property

[Olivier Danet]

On 03/01/2014 23:41, Mark Cave-Ayland wrote:
> On 03/01/14 22:32, Olivier Danet wrote:
> > > > I am using the latest, 6.1.2, installed from the full ISO image.
> > > > They changed quite a bit the video part in NetBSD 6, overhauled
> > > > the console and seem to have forked the TCX X11 driver to add hardware
> > > > acceleration.
> > >
> > > Oh that's interesting. Is there anything here that could be shared
> > > with a potential CG6 driver of any sort?
> > >
> > > FWIW for testing you could also try my CG3 patchset here:
> > > https://github.com/mcayland/qemu/tree/cg3-final but you'll probably
> > > want to replace the QEMU,cgthree.bin ROM in QEMU with the one from
> > > OpenBIOS SVN trunk.
> >
> > I will try !
>
> Great let me know how you get on :)

I have tried your CG3 branch.

NetBSD 6 can start and the console driver successfully detects a CG3.
(The next-property, keyboard and esp.c patches are still necessary...)

The 'small' problem is that there is no X CG3 driver installed ! Available
drivers are CG14, LEO, CG6, FFB (creator 3D) and TCX.
Both CG3 and TCX were removed from latest Xorg distribution (7.7), I guess
TCX is still in NetBSD because they forked it themselves.

The CG3 driver works with NetBSD 5.1 though.

Olivier

next-property

[Mark Cave-Ayland]

On 04/01/14 20:31, Olivier Danet wrote:
> I have tried your CG3 branch.
>
> NetBSD 6 can start and the console driver successfully detects a CG3.
> (The next-property, keyboard and esp.c patches are still necessary...)
>
> The 'small' problem is that there is no X CG3 driver installed ! Available
> drivers are CG14, LEO, CG6, FFB (creator 3D) and TCX.
> Both CG3 and TCX were removed from latest Xorg distribution (7.7), I guess
> TCX is still in NetBSD because they forked it themselves.
>
> The CG3 driver works with NetBSD 5.1 though.

Hmmmm okay. Out of all Sun framebuffers, the CG6 seems to be the most 
supported but getting documentation appears to be impossible (and from 
memory it was marked as "missing" on Sun's documentation site before it 
disappeared from Oracle). Hence the choice of CG3 which is a plain 
framebuffer with no hardware acceleration.

It seems like someone has a copy though: 
http://my.opera.com/Macallan/blog/2013/02/07/better-late-than-never. I 
wonder if they'd be willing to share at all?

ATB,

Mark.

next-property

[Tarl Neustaedter]

On 2014-Jan-3, 17:32 , Olivier Danet wrote:
> [...] The 'name' property is used for identifying the device type : 
> "SUNW,tcx", or "cgsix"...

Hmm. That's wrong - it should be using the "compatible" property, not 
the "name" property. That's worth fixing if at all possible.

next-property

[Mark Cave-Ayland]

On 03/01/14 19:16, Olivier Danet wrote:
> On 03/01/2014 17:09, Artyom Tarasenko wrote:
> > On Thu, Jan 2, 2014 at 2:43 AM, Olivier Danet 
> > wrote:
> > > 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)"
> > > (arch/sparc32/romvec.c)
> > > calls the "next-property" forth code, then pops the result.
> > > According to the standard, next-property should return 0 if the property
> > > selected
> > > is the last _OR_ if the property does not exist.
> > > The current code in forth/admin/devices.fs returns nothing when the
> > > property
> > > does
> > > not exit.
> > >
> > > For example (SPARC 32) :
> > >
> > > cd screen
> > > " 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.
> >
> > Actually this matches pretty much with what OBP does:
> >
> > ok showstack
> > ok " model" current-device next-property
> > fffe61e8 4 ffffffffffffffff ok drop type
> > name
> > ok " bozo" current-device next-property
> > ok
> >
> > Artyom
> > > Here is a patch, I am not quite sure about it (debuting Forth)
> > > but it helps the target OS :
> > > Index: forth/device/property.fs
> > >
> > > --- forth/device/property.fs (révision 1246)
> > > +++ 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
> > >
> > > 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
> > > difference.
> > >
> > > Olivier
> > > (Btw, the OS is NetBSD :-)
>
> You are right.
> I tried on an Ultra 10 with OpenBoot 3.12.
>
> next-property returns nothing when the property is unknown and also when
> the property is the last one.
> This contradicts Sun own documentation "Writing FCode 3.x Programs".
>
> Puzzled, I tried then on a Apple iBook G3 :
> dev screen
> " <something>" active-package next-property
>
> This laptop returns :
> true and a forth string when the property is not the last one
> true and "0 0" when the property is the last one
> false when the property does not exist.
>
> Anyway, whatever method is chosen (return nothing, return zero...),
> OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to
> avoid page faults.

Hi Olivier,

Do you have a revised version of this patch based upon the discussion in 
this thread?

I'm wondering whether we should simply use a [IFDEF] SPARC32 ... [ENDIF] 
block so that your change only takes effect on SPARC32?

ATB,

Mark.

next-property

[Olivier Danet]

On 25/01/2014 13:58, Mark Cave-Ayland wrote:
> On 03/01/14 19:16, Olivier Danet wrote:
> > On 03/01/2014 17:09, Artyom Tarasenko wrote:
> > > On Thu, Jan 2, 2014 at 2:43 AM, Olivier Danet 
> > > wrote:
> > > > 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)"
> > > > (arch/sparc32/romvec.c)
> > > > calls the "next-property" forth code, then pops the result.
> > > > According to the standard, next-property should return 0 if the 
> > > > property
> > > > selected
> > > > is the last _OR_ if the property does not exist.
> > > > The current code in forth/admin/devices.fs returns nothing when the
> > > > property
> > > > does
> > > > not exit.
> > > >
> > > > For example (SPARC 32) :
> > > >
> > > > cd screen
> > > > " 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.
> > >
> > > Actually this matches pretty much with what OBP does:
> > >
> > > ok showstack
> > > ok " model" current-device next-property
> > > fffe61e8 4 ffffffffffffffff ok drop type
> > > name
> > > ok " bozo" current-device next-property
> > > ok
> > >
> > > Artyom
> > > > Here is a patch, I am not quite sure about it (debuting Forth)
> > > > but it helps the target OS :
> > > > Index: forth/device/property.fs
> > > >
> > > > --- forth/device/property.fs (révision 1246)
> > > > +++ 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
> > > >
> > > > 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
> > > > difference.
> > > >
> > > > Olivier
> > > > (Btw, the OS is NetBSD :-)
> >
> > You are right.
> > I tried on an Ultra 10 with OpenBoot 3.12.
> >
> > next-property returns nothing when the property is unknown and also when
> > the property is the last one.
> > This contradicts Sun own documentation "Writing FCode 3.x Programs".
> >
> > Puzzled, I tried then on a Apple iBook G3 :
> > dev screen
> > " <something>" active-package next-property
> >
> > This laptop returns :
> > true and a forth string when the property is not the last one
> > true and "0 0" when the property is the last one
> > false when the property does not exist.
> >
> > Anyway, whatever method is chosen (return nothing, return zero...),
> > OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to
> > avoid page faults.
>
> Hi Olivier,
>
> Do you have a revised version of this patch based upon the discussion 
> in this thread?
>
> I'm wondering whether we should simply use a [IFDEF] SPARC32 ... 
> [ENDIF] block so that your change only takes effect on SPARC32?
>
> ATB,
>
> Mark.

When starting X under NetBSD 6.x, it enumerates devices and
eventually asks next-property of "name" and "device_type"
  to many nodes, including "/chosen", "/builtin"...

I did not look into NetBSD to determine whether this behaviour is sane.
I have found several 'almost bugs' in NetBSD. For example the TCX 
framebuffer
should not have an address property.

Sun's OpenBOOT does not define "next-property" on 32bits, any
behavior is acceptable on that platform.

Should we make Sparc64's behaviour (silence) the default one? Answering zero
seemed more polite and simpler for the C obp_ wrapper.

I have a dozen patches waiting for OpenBIOS and QEMU.
I hope I will be able to post them next week.

Regards
Olivier