Robert Swindells <swindellsr@genrad.co.uk> writes:
> I have been doing a bit of work on adding support for other StrongARM
> CPUs and have got to the stage where I need to decide how to structure
> the device drivers for the built in serial ports etc...

yay.  "finally."  8-)


> Looking at the hpcmips port, they define a device for Vr41x1
> integrated peripherals, called 'vrip', connected to mainbus then hang
> drivers for the individual devices off this parent. For the Toshiba
> tx39 CPU they just hang everything off mainbus.
>
> Is there an 'official' way to do this ?

No. more on this, and other issues, below.


> I am putting any new files into 'arch/arm32/sa11x0'.

Cool.


> I would expect 'fb' to live in 'arch/arm32/dev/fb.c' since it should
> be used by both SA11x0 and Cirrus Logic ports.

uh, what's 'fb'?

In general, you should have a device-specific driver, which then
attaches the MI wscons frame buffer code, if you have a frame buffer.


> It would be nice to move the 'es' driver to arch/arm32/dev as well
> since it is neeeded for the Neponset board.

actually, if you're talking about the one named in if_es.c in the
rc7500 dir, i note that it says:

 * Modified from Amiga's es driver for SMC 91C9x ethernet controller.
 * SMC 91C90 Single-Chip Ethernet Controller

which says to me that it should probably be in dev/ic, as a generic
driver with appropriate MD hooks, rather than anyplace else.



So, really, the arm32 port needs to be put into a chipper shredder,
and have the pieces spread around a bit.

The arm32 port should be driven in one of two ways.  It should:

	* be able to have a single GENERIC kernel that can boot on
	  all of the machines that are supported by it (e.g. like
	  alpha), or

	* be split into multiple MACHINEs, leaving MACHINE_ARCH as
	  arm32 and having common arm32 code shared, but otherwise
	  be separate per type/family of machine that is supported.

The hpcmips port does things the former way (as far as I know), which
kind of makes sense: the booter, etc., will be common for all of those
kernels, so it's _possible_ to have a single set of software that does
the right thing.

I'd say that the ARM should do the latter, like mips, m68k, powerpc,
and sh3 have done.

Re: how to do mainbus, etc.: first of all, 'mainbus' is just a
convention.  You should feel free to define a different name, if
that's truly appropriate.  however, there may be some things which
aren't easily placeable within the context of a generic cpu bus.

some thoughts:

* provide general facilities that are common when you can, but provide
  specific facilities are are chip-specific.  One interesting/bad
  thing about that arm32 port is that there are _no_
  armv4/SA-optimized routines like copyin/copyout.  There's
  time and cycles wasted on doing the copies the Old way,
  unless i misread the code in question.

* don't try to provide a magic bullet for autoconfig.

	* let MACHINE rather than MACHINE_ARCH configure e.g. the
	  main bus.  almost certainly you'll want to configure
	  a standard system bus underneath -- with MACHINE input --
	  but who knows.  (you'll note that the arm32 port already
	  has somewhat of a separation like this... which should
	  be a sign... 8-)

	* for systems based around SOCs, e.g. the sa1100, let
	  different MACHINEs provide input to the
	  configuration process (e.g. gpio mappings,
	  which ports actually make sense for the particular
	  board), but provide generic, paramerizable drivers
	  for those features.

	* when there are generic, common core logic chipsets,
	  e.g. the '285 for the sa110, provide a MACHINE-indepdent
	  driver similar to the ones for SOC devices, but again
	  it needs to be parameterizable.

To take the particular case of sa11x0-based systems, and, more
particularly, the sa1100-based system that I've spent the last N
months playing with in various capacities (ranging from "whacking the
schematics a bit," to "sitting with a tla704", to "making firmware, an
OS, and apps run on it"), a proper netbsd device tree should probably
look something like:

	mainbus0 at root
	sa11x0sb0 at mainbus0
		sa11x0sl0 at sa11x0sb0 addr <addr of port 3>
		sa11x0sl1 at sa11x0sb0 addr <addr of port 1>
		sa11x0clk0 at sa11x0sb0 addr <the first clock>
		sa11x0clk1 at sa11x0sb0 addr <the second clock>
		sa11x0clk2 at sa11x0sb0 addr <the third clock>
		# alternately, just another clock for the next one,
		# based on kernel config
		sa11x0wdog0 at sa11x0sb0 addr <the fourth clock>
		pcmcia0 at sa11x0sb addr <the first pcmcia slot>
			... whatever at pcmcia0
		dcisa0 at sa11x0sb addr <the second pcmcia slot>
			cs0 at dcisa0 addr 0x300 irq <i forget>
			cs1 at dcisa0 addr 0x310 irq <i forget>

there are also two flash ROMs, which could easily go at either mainbus
or sa11x0sb.

there are also two LEDs, which should probably go at mainbus rather
than sa1100sb (since they're entirely driven by GPIOs, and would be
hard to express as generic devices to go on system-bus bus.

looking at our schematics, I think that's everything.  8-)

note, of course, that there's a lot _not_ shown there:

	* that should all be direct configuration (even the ISA:
	  that's why i said 'dcisa' rather than just 'isa' -- that's
	  something that doesn't exist yet), hard-wired in the
	  MACHINE code in tables as appropriate, and then put into
	  the 'config' file at a user's whim.  (on this device, we
	  have nothing hooked up to the frame buffer or other serial
	  ports, so there wouldn't be any point in even providing
	  configuration hooks for them.)

	* there need to be channels in the attach-args and
	  perhaps MD callbacks in various places, to communicate
	  various information, e.g.:

		* for the serial ports, which GPIOs to use as RS-232
		  signals (if any), and how to use them (i.e. active
		  high, active low, etc.)

		* for the pcmcia: what the PCMCIA interrupt line
		  attaches to.

(also, things like the current ISA notion that IRQ is 0-15 need to be
Fixed, i'd say that you should just use the GPIO value in a situation
like this and be done with it.)



I would suggest that rather than just dumping your code into
arch/arm32 like everybody else has done (and i'm partially guilty here
too 8-), you dump your board/system/family-specific code into some
_other_ appropriately-named directory of 'arch', then put what you
think should be 'common' code into appropriate places under
arch/arm32.



question for you: right now, IIRC, all of the existing ARM code
expects things to be running w/ virtual memory turned on when you
start.  Does your new code continue that?



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.