Jason Thorpe stands accused of saying:
>  > 
>  > >     80A0	TIMER
>  > 
>  > Interesting!  Timers are always nice.
> 
> Hmmm ... the hp300 (as does the 400-series; it's what NetBSD uses) has a
> 6840 at 0x5F8000... 

Still, more timers are always nice, especially if this one runs fast, it
could (perhaps) be used to improve microtime(), like the highres TC clock
in some pmaxen.

>  > >     80C0	UTIL_PIO
>  > >     80C0	MMU_ISR (?? NOT SURE ??)
>  > >     80E0	UTIL_PIC 
>  > > 
>  > > So, there is a timer, a PIO (who knows what for ?) and the interrupt
>      control
>  > > register.
> 
> Actually, that PIC is _probably_ the ISA PIC.  

It may also control interrupts from the ISA port, but the high 4 bits
in the byte at 0xe0 are definitely the interrupt enable bits for the
Frodo onboard UARTs.  It wouldn't actually surprise me all that much
if all of the IRQ lines on the ISA slot were tied together, so you'd
only need one interrupt input somewhere.

> PIO ... not sure ..
> I don't think it's the parallel port ... the parallel port on my
> 380, at least, is:
> 
> device id = 0x6 secid = 0x0 at dio0 scode 23 not configured

Hmm, on the 425 it's at scode 12; still, that implies that it's in
"real" dio space, and should behave like a normal DIO device.  Any
docco for that?

>  > This is the approach I've taken with my 'apci' driver.  I was planning to 
>  > add some extra 8250-aware probing once I knew how to generate and check 
>  > for interrupts.
> 
> ...err, I would really prefer that you not probe based on interrupts.
> In fact, for various reasons, I _really_ want to turn all interrupts
> off during autoconfiguration.

Sorry, I should have been more explicit - check for _masked_
interrupts, ie. a basic 8250-family functionality check.  If you're
going for an MI 16x50 driver it's going to have to do those sort of
checks just to work usefully with the range of 16x50-clone UARTs
around.

There are some other issues here that may seriously affect the
performance of such a driver though; the indirection necessary to
handle both I/O mapped and memory mapped registers, as well as the
different spacing (the dca in the 300's is spaced on alternate bytes,
in the 700 they're packed, and the apci ports appear to be spaced one
byte per longword) will be expensive, which may be significant on
slower systems.

> I'd take an approach like this:
> 
> utilchipmatch:
> 
> 	/* Can't tell between a 380 and 425. */

That bugs me 8)  It _must_ be possible, somehow, although I suspect you'd
have to grub in the EEPROM for it.

> 	if (machineid == HP_380 || machineid == HP_433) {
> 		/*
> 		 * Try to read a "safe" address where the Frodo lives.
> 		 * Return 0 if we bus err.
> 		 */
> 	}

Ok; badaddr() on some register is what I'm doing just now.

> I have some info on the ISA slot space somewhere.  I just managed to
> get a 425 today (complete with Apollo ring interface :-) and Domain
> keyboard.  It' has a frotzed LANCE, I think, tho... grumble.  I
> could poke around there as well, once I get the thing bootstrapped.

That'd be fun.  Having a copy of at least the salient parts of your
documentation would be nice, or do I have to find someone to come over
and steal all your docco?  8)

> ...what _really_ needs to happen is for the dca to be split up
> into a 16x50 core and a dca front-end (we can do all the neat
> new config stuff now :-).
> 
> For this, I suggest we wait a spell; 

That's well and good; I want something happening now 8) 8) 8)

> In the kernel, what we need is to attach the HIL like a normal device
> instead of the way it's done now, and attach hilkbd instances to the
> hil parent.  The tree would look something like this:
> 
> 	utilchip0 at intio0
> 		apci0 at intio0
> 			dnkbd0 at acpi0
> 				dnms0 at dnkbd0

I wouldn't bother with the mouse as a seperate device; the data from the
mouse is part of the keyboard data stream; use the same major and a
different minor to select between the two.

> 		acpi1 at intio0

You'll only get that one on 425e's, where it will want to be the console.

> 		apci2 at intio0
 		apci3 at intio0

> The ITE driver will then pick one ... on systems with both, I'd say
> default to HIL unless specified otherwise in the kernel config file.

That's not unreasonable; it's already required that the system be in
HP/UX mode to boot.

> (BTW, any locals want to help me replace the LANCE on this 425?  Dave?
> I'll buy the first round... :-)

Hmm, if you were local I'd say bring it on over and do it here, but
until/unless someone headhunts me that's going to be tough. 8(

> Jason R. Thorpe                                       thorpej@nas.nasa.gov

-- 
]] Mike Smith, Software Engineer        msmith@gsoft.com.au             [[
]] Genesis Software                     genesis@gsoft.com.au            [[
]] High-speed data acquisition and      (GSM mobile)     0411-222-496   [[
]] realtime instrument control.         (ph)          +61-8-8267-3493   [[
]] Unix hardware collector.             "Where are your PEZ?" The Tick  [[