[ I missed Mike's original message, so I'm replying to this one... 
  --thorpej ]

On Mon, 18 Mar 1996 16:09:39 -0600 (CST) 
 Scott Reynolds <scottr@Plexus.COM> wrote:

 > > It's only manifesting on the hp300 because only the hp300 is using old
 > > config.
 > 
 > Yes, but the argument is that it ought not to have manifested itself 
 > _at_all_.

Exactly.

 > >  How does the hp300 handle other devices|attributes that have
 > > "needs-flag" attached to them in the new config?
 > 
 > Apparently it uses a "device-driver" attribute.

Well, it's not exactly an "attribute" in the same way that new config has 
attributes, but... :-)

 > > Why is the hp300 port still using the old config, anyway?

It's not as easy as you might think :-)  (Plus, I need to have *some* 
time leftover for the pub.. :-)

Here's an example of some of the "major" hurdles I've had to deal with 
along the way, which I've finished:

	- Completely new interrupt system.  This was because *several*
	  device drivers had interrupt service routines hard-coded
	  in locore.s  Not only that, but Hibler had a clever little
	  trick in there that made the unbuffered serial serial port
	  on the lesser hp300s usable ... I didn't want to lose
	  any functionality.  It took a while to finalize and work
	  the kinks out of the design.  Luckily, there was some sun3
	  interrupt code I was able to steal that had most of what
	  I wanted to do...

	- Console driver(s).  The way consoles were probed assumed
	  several things:

		- A function called find_devs() was called early
		  during boot.  This function (before configure())
		  would go out and find all of the devices attached
		  to the system and build a "hardware table".

		- Console probe routines had access to statically
		  allocated softcs.

	  These two assumptions are bogus in the new config world,
	  and so I had to completely re-do how the console was probed.
	  Debugging this is a trick, too, since you don't have a working
	  console to see debugging info with.

The console thing, thusfar, has been the biggest.

Now, I'm currently in the midst of re-writing the driver for the hp300 
DMA chip.  Doing the software machinery isn't hard, but given that I 
(until today) had *NO* documentation on the hp300 DMA chip, and the 
source code for the old driver is sparsely commented (and the register 
maps aren't commented *at all*), I've had to spend long (*really long*) 
hours staring at code trying to figure out just what's going on ... On 
top of it all, the old-style drivers are stuck with 
"controller/slave/unit" triples for representing anything.  This isn't a 
terribly flexible scheme, so there are many structure members which are 
overloaded with information they're just not meant to store, which makes 
reading the code (and it's maze of weird call-backs) challenging at 
best.

Luckily, Mike Hibler is a really nice guy, and has been more than willing 
to answer my (seemingly stupid, I'm sure :-) questions about the code and 
the hardware itself...

What's next?  Well, after the DMA driver, I'll probably re-write the SCSI 
driver.  It needs some help anyway, and I need something to test the DMA 
driver with :-)  I could start with hpib, I guess, but I need to write an 
"hpibbus" thing ... I'll probably mostly just steal the "scsibus" 
mechanism, and frob it for hpib ... I'll probably make it MI, too ... 
there are at leat a couple of GPIB cards for ISA out there, and PCMIA 
GPIB cards, too ... I see no reason why all platforms couldn't share the 
HP-IB stuff ... it's really just HP's CS/80 (or Amigo, for ancient 
devices) command set over IEEE488.

 > Because Jason is still untangling spaghetti.  He's made significant 
 > progress, but isn't finished yet.

Progress is currently defined as, with the exception of one minor console 
bug specific to new config, I have a hp300 new config kernel that boots 
diskless into multi-user.

basalt (thorpej) /sys/arch/hp300 117% cvs -q diff -rnetbsd | wc -l
    2265
basalt (thorpej) /sys/arch/hp300 119% wc -l dev/dio.c dev/dioreg.h \
? dev/grf_subr.c dev/intio.c hp300/mainbus.c
     696 dev/dio.c
      53 dev/dioreg.h
     124 dev/grf_subr.c
     122 dev/intio.c
     112 hp300/mainbus.c
    1107 total

The new DMA driver is included in dio.c, but is only about 1/2 done.  
dio.c also includes the autoconfiguration goo for the dio bus, but since 
the DMA chip is actually somewhat coupled to the dio bus (even though the 
chip itself lives in intio space), I decided to put it there...Only dio 
cards can use that DMA chip, anyhow...400s with an EISA/ISA bus have 
standward EISA/ISA dma hardware on them, as well.

Of course, this whole process is made more difficult by lack of hardware 
documentation ... I have *very* little ... a photocopied document from 
Fujitsu that describes the chip used on the dio SCSI cards, and a FAX 
describing the DMA hardware.  The rest of it, well, I have a list of 
books that I need to order from HP, but the last time I called them, the 
person on the other end of the phone said they were out of print :(

(Yes, I ought to call them again ... I'm not sure I believe her ... I.e., 
I don't think I got the Right Person on the phone :-)

Above all, I've wanted to make sure that the hp300 port remains somewhat 
stable during this transition period.  I know of at least a couple sites 
that track -current (or, at least, used to) on over 50 (relatively 
diverse) hp300 systems per site.  I don't really want to break the port 
in the process of improving it :-)

Anyway, that's why...

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939