__BROKEN_CONFIG_UNIT_USAGE ?
David Young
mysterious #define, which affects which code in subr_autoconf.c is
compiled, implies that sun3 is somehow "broken"? Will somebody fix it?
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 278-3933
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Manuel Bouyer
> Only NetBSD/sun3 uses __BROKEN_CONFIG_UNIT_USAGE. The name of this
> mysterious #define, which affects which code in subr_autoconf.c is
> compiled, implies that sun3 is somehow "broken"? Will somebody fix it?
So you know what is broken exactly ?
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
David Young
> On Mon, Nov 30, 2009 at 01:54:13PM -0600, David Young wrote:
> > mysterious #define, which affects which code in subr_autoconf.c is
> > compiled, implies that sun3 is somehow "broken"? Will somebody fix it?
>
No, I do not. I'm hoping that some NetBSD/sun3 developer knows.
Jason Thorpe
On Dec 1, 2009, at 12:46 PM, David Young wrote:
> On Tue, Dec 01, 2009 at 09:44:29PM +0100, Manuel Bouyer wrote:
>> On Mon, Nov 30, 2009 at 01:54:13PM -0600, David Young wrote:
>>> Only NetBSD/sun3 uses __BROKEN_CONFIG_UNIT_USAGE. The name of this
>>> mysterious #define, which affects which code in subr_autoconf.c is
>>> compiled, implies that sun3 is somehow "broken"? Will somebody fix it?
>>
>> So you know what is broken exactly ?
>
> No, I do not. I'm hoping that some NetBSD/sun3 developer knows.
The code makes assumptions about the behavior / relationships of devices at fixed unit numbers. See sun3/sun3/vme.c:vme_match(), and to a lesser extent, sun3/dev/xd.c:xdmatch() and sun3/dev/xy.c:xymatch().
In general, any use of cfdata_t::cf_unit outside of printing it is wrong (or, at least, discouraged).
It would be good if the sun3 port was switched to the MI VME and Xylogics SMD drivers.
-- thorpej
Izumi Tsutsui
> the MI VME and Xylogics SMD drivers.
Well, I implemented bus_dma(9) and bus_space(9) for it,
but the rest annoying part is framebuffer support which
has too many quirks to use MI drivers...
(and I don't have such machines)
---
Izumi Tsutsui
David Young
>
> On Dec 1, 2009, at 12:46 PM, David Young wrote:
>
> >> On Mon, Nov 30, 2009 at 01:54:13PM -0600, David Young wrote:
> >>> Only NetBSD/sun3 uses __BROKEN_CONFIG_UNIT_USAGE. The name of this
> >>> mysterious #define, which affects which code in subr_autoconf.c is
> >>> compiled, implies that sun3 is somehow "broken"? Will somebody fix it?
> >>
> >> So you know what is broken exactly ?
> >
> > No, I do not. I'm hoping that some NetBSD/sun3 developer knows.
>
> devices at fixed unit numbers. See sun3/sun3/vme.c:vme_match(),
Can this magic in vme_match()
#define VME_UNITS 6
unit = cf->cf_unit;
if (unit >= VME_UNITS)
return 0;
if (ca->ca_bustype != vme_info[unit].bustype)
return 0;
be avoided by creating a new locator, "bustype", and
rewriting the kernel configuration
vme0 at mainbus? # A16/D16
vme1 at mainbus? # A16/D32
vme2 at mainbus? # A24/D16
vme3 at mainbus? # A24/D32
vme4 at mainbus? # A32/D16
vme5 at mainbus? # A32/D32
as follows?
vme0 at mainbus? bustype 0 # A16/D16
vme1 at mainbus? bustype 1 # A16/D32
vme2 at mainbus? bustype 2 # A24/D16
vme3 at mainbus? bustype 3 # A24/D32
vme4 at mainbus? bustype 4 # A32/D16
vme5 at mainbus? bustype 5 # A32/D32
> and to a lesser extent, sun3/dev/xd.c:xdmatch() and
> sun3/dev/xy.c:xymatch().
Wow, what are *those* doing? Any reason that cannot be expressed in the
kernel configuration, too?
Jason Thorpe
On Dec 1, 2009, at 2:45 PM, Izumi Tsutsui wrote:
>> It would be good if the sun3 port was switched to
>> the MI VME and Xylogics SMD drivers.
>
> Well, I implemented bus_dma(9) and bus_space(9) for it,
> but the rest annoying part is framebuffer support which
> has too many quirks to use MI drivers...
Well, there is bus_space_mmap() and bus_space_vaddr()...
> (and I don't have such machines)
Write emulators of those devices for TME? :-)
> ---
> Izumi Tsutsui
-- thorpej
Jason Thorpe
On Dec 1, 2009, at 2:45 PM, Izumi Tsutsui wrote:
>> It would be good if the sun3 port was switched to
>> the MI VME and Xylogics SMD drivers.
>
> Well, I implemented bus_dma(9) and bus_space(9) for it,
> but the rest annoying part is framebuffer support which
> has too many quirks to use MI drivers...
Of course, the MI VME drivers don't seem to use much of bus_space anyway... take a look at the xy and xd drivers!
> (and I don't have such machines)
> ---
> Izumi Tsutsui
-- thorpej
Izumi Tsutsui
> > but the rest annoying part is framebuffer support which
> > has too many quirks to use MI drivers...
>
> Well, there is bus_space_mmap() and bus_space_vaddr()...
Most quirks are in attach code. See sys/arch/sun3/conf/cg4.sun3:
---
# Each cg4 config line applies to only one machine type,
# and the low 4 bits of the flags (if set) are matched
# against the same bits of the machine type ID code.
# Also, flag 0x10 signifies Type A (AMD RAMDACs),
# and the flag 0x20 indicates a missing P4 reg.
cgfour0 at obmem0 addr 0xFE400000 flags 0x34 # 3/110
cgfour0 at obmem0 addr 0xFF300000 flags 7 # 3/60 (P4)
# These two appear to have no P4 register.
cgfour0 at obmem0 addr 0xFF300000 flags 0x27 # 3/60 (old)
cgfour0 at obmem0 addr 0xFF300000 flags 0x28 # 3/E
---
cgfour on 3/60 is most major ones, I guess (and I looked for).
> > (and I don't have such machines)
> Write emulators of those devices for TME? :-)
I'm not sure if it's worth to implement such variants
to confirm them... (quirks are not so much fun but just annoying)
> Of course, the MI VME drivers don't seem to use much of
> bus_space anyway... take a look at the xy and xd drivers!
sun2 already uses MI vme and xy(4) on it. It's not so hard.
There are also MD ie(4), si(4), cgtwo(4), bwtwo(4) etc. on sun3 vme.
MI bwtwo(4) requires MI sun kbd drivers. Maybe we also need wscons.
And more something else? :-)
ie(4) and si(4) might be trivial (there are MI vme attachments),
but sebuf(4) on 3/E is also annoying..
---
Izumi Tsutsui
David Young
> On Tue, Dec 01, 2009 at 01:48:44PM -0800, Jason Thorpe wrote:
> >
> > On Dec 1, 2009, at 12:46 PM, David Young wrote:
> >
> > >> On Mon, Nov 30, 2009 at 01:54:13PM -0600, David Young wrote:
> > >>> Only NetBSD/sun3 uses __BROKEN_CONFIG_UNIT_USAGE. The name of this
> > >>> mysterious #define, which affects which code in subr_autoconf.c is
> > >>> compiled, implies that sun3 is somehow "broken"? Will somebody fix it?
> > >>
> > >> So you know what is broken exactly ?
> > >
> > > No, I do not. I'm hoping that some NetBSD/sun3 developer knows.
> >
It looks to me like the relationships can be expressed in the
kernel configuration file. I am going to delete all of the #ifdef
__BROKEN_CONFIG_UNIT_USAGE code from sys/kern/subr_autoconf.c in a week.
I will send an untested patch to try to ease sun3's transition.
David Young
> It looks to me like the relationships can be expressed in the
> kernel configuration file. I am going to delete all of the #ifdef
> __BROKEN_CONFIG_UNIT_USAGE code from sys/kern/subr_autoconf.c in a week.
> I will send an untested patch to try to ease sun3's transition.
I think that something like the attached will do.