adding 16550 UART to RM9200

[Warner Losh]

From: Bernd Walter <ticso at cicely12.cicely.de>
Subject: adding 16550 UART to RM9200
Date: Tue, 3 Apr 2007 17:48:58 +0200

> I plan to add up to 48 16550 UART to an RM9200 system.
> It should be done with 16C554 chips - so I only have 16 byte FiFo.
> I would like to avoid using 64 byte FiFo chips, but those are pin
> compatible, so things are changeable in case.
> Likely most of the ports are doing low volume and I hope this will
> be Ok.
> They will be addressed via NCS2 space.
> Most of the external interrupts are not available because of
> unfortunate multiplexing with other required signals, so I have to
> attach them all to IRQ0.
> The interrupt will be level configured by firmware.
> And the NCS2 waitstates and buswidth will be configured by firmware
> as well.

I'll help you out, but you gotta send me one of these devices :-)

> - How can I attach our uart(4) driver to the chips?
> It will likely addressed with:
> UART0	0x30000000 - 0x30000007 IRQ0
> UART1	0x30000008 - 0x3000000f IRQ0
> UART2	0x30000010 - 0x30000017 IRQ0
> UART3	0x30000018 - 0x3000001f IRQ0
> UART4	0x30000020 - 0x30000027 IRQ0
> UART5	0x30000028 - 0x3000002f IRQ0
> [...]
> UART47	0x30000170 - 0x30000177 IRQ0
> UART48	0x30000178 - 0x3000017f IRQ0
> - I would like to use a 14,7456MHz xtal
> How can I tell uart(4) the frequency?

I'd consider creating a puc device that attaches to the atmelarm bus.
This device would need to manage the resources for the sub devices in
a minimal way (take a look at pccard_puc for a simple example).  The
advantage to doing this is that you also get the clock frequency as a
parameter for free.  You'll likely need to have a custom ISR routine,
depending on the details of the interrupt structure.  If there's no
external way to know quickly which of the parts interrupted, you may
be OK with the default one.

> - How can I configure NCS2 range as being uncacheable?
> I asume this has to be done somehow in the kernel.

Others will have to answer this question, since all the pmap_* and
vm_* routines make my head spin...  I'm guessing it will be similar to
how we map the ohci device in kb920x_machdep.c:

	/*
	 * We can't just map the OHCI registers VA == PA, because
	 * AT91RM92_OHCI_BASE belongs to the userland address space.
	 * We could just choose a different virtual address, but a better
	 * solution would probably be to just use pmap_mapdev() to allocate
	 * KVA, as we don't need the OHCI controller before the vm
	 * initialization is done. However, the AT91 resource allocation
	 * system doesn't know how to use pmap_mapdev() yet.
	 */
#if 1
	{
		/*
		 * Add the ohci controller, and anything else that might be
		 * on this chip select for a VA/PA mapping.
		 */
		AT91RM92_OHCI_BASE,
		AT91RM92_OHCI_PA_BASE,
		AT91RM92_OHCI_SIZE,
		VM_PROT_READ|VM_PROT_WRITE,                             
		PTE_NOCACHE,
	},
#endif

where

#define AT91RM92_OHCI_BASE	0xdfe00000
#define AT91RM92_OHCI_PA_BASE	0x00300000
#define AT91RM92_OHCI_SIZE	0x00100000

I'm starting to think that we may be getting to the point where we
need to do better board support in this subport.  You are making too
many of them too quickly and it is straining the infrastructure :-)

Warner