adding 16550 UART to RM9200

[Krassimir Slavchev]

Warner Losh wrote:
> 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 still have problems with ohci mapping.

ohci0: <AT91 integrated ohci controller> mem 0xdfe00000-0xdfefffff irq 
23 on atmelarm0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
Enable ohci_clk
Enable mck
Enable plla
Enable main
Turning PC 0x800 on
Done PCSR is now: 0x1fffffc!
Enable uhpck
Enable pllb
Enable main
Turning PLLB 0x102f3e05 on
Done!
Turning SC 0x10 on
Done SCSR is now: 0x15!
usb0: OHCI version 1.0
usb0 on ohci0
usb0: USB revision 1.0

vm_fault(0xc022547c, 0, 1, 0) -> 1
Fatal kernel mode data abort: 'Translation Fault (S)'
trapframe: 0xc0254514
FSR=00000005, FAR=00000030, spsr=a00000d3
r0 =c023de50, r1 =00000000, r2 =00000000, r3 =00000000
r4 =c023c9b0, r5 =00000000, r6 =c0871780, r7 =00000000
r8 =c0891b48, r9 =c0871880, r10=c021ff88, r11=c0254584
r12=00000000, ssp=c0254560, slr=00000000, pc =c0191624

[thread pid 0 tid 0 ]
Stopped at      bus_dmamap_create+0xa4: ldr     r3, [r5, #0x030]
db>

I have enabled usb code in at91.c but no luck.

How to get this working?
> 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
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>
>