On Fri, 21 Mar 1997 10:39:46 +1030 (CST) 
 Michael Smith <msmith@atrad.adelaide.edu.au> wrote:

 > > 7FBA8000	UTILITY_CHIP
 > >     8000	SIO_0
 > >     8020	SIO_1
 > >     8040	SIO_2
 > >     8060	SIO_3
 > 
 > All OK so far.
 > 
 > >     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... 

 > >     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.  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

 > They didn't bother emulating the 2681, why go with the 6840?  More
 > interestingly, perhaps, can the timer generate interrupts?

...see above... the 425 _has_ a 6840 :-)

 > > The port cannot identify itself just as other HP cards (or better pseuso
 > > cards), as the do not have the special space in the first 16 bytes of their
 > > address space, as the dca, SCSI and lance devices have (though they are
 > > builtin). Perhaps just testing for a writable address somewhere might be
 > > enough? 
 > 
 > 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.

Internal I/O space (the BSD nomenclature for this area before the select
codes) is in indirect bus... even worse, you sort of have to take it
on faith that something's there (do you _really_ want to go poking around
for the DMA engine or clock chip?  :-)

I'd take an approach like this:

utilchipmatch:

	/* Can't tell between a 380 and 425. */
	if (machineid == HP_380 || machineid == HP_433) {
		/*
		 * Try to read a "safe" address where the Frodo lives.
		 * Return 0 if we bus err.
		 */
	}

utilchipattach:

	/*
	 * We know there are 4 "UART"s here.  Use direct configuration
	 * to attach 0, 2, and 3.
	 */

 > Slow is fine; my primary goal is just to get the Apollo keyboard talking.
 > Finding the ISA slot would be a winner too (anything in the apollo info
 > that you have there?)

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.

 > > Driver ideas: As I said, Domain/OS seems to address the Frodo ports just as
 > > 16550. So, nothing seems to prohibit us to reuse all the dca code.
 > 
 > I looked fairly hard at this, but unfortunately there are quite a few
 > assumptions about the dca embedded in the driver (specifically, its
 > dio-ness).

...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; Charles Hannum should be committing
the new ISA com driver RSN ... these are basically the same driver,
and the new com driver will be MI (well, for the most part... but mostly
there is better than nothing).  Eventually, I want the DCA driver
to be a front-end to the MI 16x50 core.  This requires that the hp300
get a bus.h implementation, but his isn't too hard to do, given that
Scott Reynolds has written an m68k bus.h for the mac68k port :-)

 > Checking the monitor PROM is almost certainly the right way to go.

...in the boot program, yes.

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:

	hil0 at intio0
		hilkbd0 at hil0
			hilms0 at hilkbd0
	utilchip0 at intio0
		apci0 at intio0
			dnkbd0 at acpi0
				dnms0 at dnkbd0
		acpi1 at intio0
		apci2 at intio0

(I _think_ the mice are logically associated with the keyboard.. that's
certainly how they seem to be.. anyone with more info here?)

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.

Eventually, I'm going to scrap the entire grf/ite, and migrate to
the forthcoming Alpha console code (when it's ready).  At that point,
handling keyboard and mouse events will be quite a lot like doing
so under SunOS (event queues that are generated inside the kernel,
hiding the differences between the devices)

I'm really happy to see progress here!  Keep up the good work, guys!

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

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