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? Dave -- -- David Young OJC Technologies dyoung <at> ojctech.com Urbana, IL * (217) 278-3933
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 ? -- -- Manuel Bouyer <bouyer <at> antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
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. Dave -- -- David Young OJC Technologies dyoung <at> ojctech.com Urbana, IL * (217) 278-3933
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
> 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... (and I don't have such machines) --- Izumi Tsutsui
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
> > 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()... 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?(Continue reading)
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
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 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(),
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
(Continue reading)
On Tue, Dec 01, 2009 at 05:52:44PM -0600, David Young wrote: > 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 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(), > > 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(Continue reading)
On Sun, Dec 06, 2009 at 02:27:36PM -0600, David Young wrote: > 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. Dave -- David Young OJC Technologies dyoung <at> ojctech.com Urbana, IL * (217) 278-3933
Index: conf/GENERIC =================================================================== RCS file: /cvsroot/src/sys/arch/sun3/conf/GENERIC,v retrieving revision 1.148 diff -p -u -u -p -r1.148 GENERIC --- conf/GENERIC 17 Jan 2009 07:31:57 -0000 1.148 +++ conf/GENERIC 6 Dec 2009 21:01:56 -0000 <at> <at> -205,12 +205,20 <at> <at> si1 at vme2 addr 0x204000 ipl 2 vect 0x4 # Xylogics 450/451 controllers (VME A16/D16) xyc0 at vme0 addr 0xee40 ipl 2 vect 0x48 xyc1 at vme0 addr 0xee48 ipl 2 vect 0x49 -xy* at xyc? drive ? +xy0 at xyc0 drive 0 +xy1 at xyc0 drive 1 +xy2 at xyc1 drive 0(Continue reading)
RSS Feed