Date: Wed, 04 Apr 2007 11:06:16 +0300 From: Krassimir Slavchev <krassi@bulinfo.net> Cc: freebsd-arm@FreeBSD.org Subject: Re: adding 16550 UART to RM9200 Message-ID: <46135C78.70009@bulinfo.net> In-Reply-To: <20070403.100732.74697496.imp@bsdimp.com> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: > From: Bernd Walter <ticso@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46135C78.70009>