> Most 
> notably, I have a mostly-working (albeit slowly) `si' driver, much 
> better than it was before OBIO bwtwo support, a change to the ddb to make 
> it talk to the Sun 4 on-board console properly, some changes to MI scsi 
> to make it talk to the Emulex MD21 better, dynamic mapping of sd targets 
> based on prom info where appropriate (yeah! no more CRAZYMAP()!), and a 
> nasty kludge to make dk_establish() at least _try_ to work on machines 
> without an esp...
> 
> I am stuck in a few spots, though.  For one, the whole 
> dk_establish()/bootpath mechanism is sort of broken; it makes some really 
> nasty assumptions the whole way though (and is pretty much commented as 
> such).  I have some ideas on how to make it work, but so far none of them 
> have really `panned out'...

i have a solution for this that works for sd disks on the esp, and
should work very easily for the si as well. it no longer makes an esp
assumption, works on floppy drives and ethernet, and should work
trivially for xy and xd. i also see no reason why it shouldn't work
fine for multiple controllers (except for one prom bug that i attempt
to work around).

> Also, and I'm not sure exactly the cause of this, the bwtwo driver seems 
> to work ok...I get console and size info from the eeprom (I guess I've 
> verified that that driver works, anyhow :-), but I panic with `bad 
> instruction' if I let it call rcons_init()...I've not really had time to 
> look at that in detail, and I haven't really gotten a chance to `test' 
> the framebuffer yet (by running Xsun, for example).

i think that i have a working sun4 bwtwo driver. rcons needs changes
for the sun4. i'm not sure if the eeprom can always be trusted to be
correct about the sun4 bwtwo -- there's a few strange issues in there.

> Along these lines, I did get a couple of suggestions about adding the lun 
> to the scsi command.  I added that glue in the MI scsi code, but it 
> doesn't seem to make any difference.

this should be done in the driver. last i looked, there was at least one
other driver in the kernel tree that had the same failing...

all in all, very cool Jason.