From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 16:09:50 2007 Return-Path: X-Original-To: freebsd-arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9AB316A403 for ; Tue, 3 Apr 2007 16:09:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5645313C48A for ; Tue, 3 Apr 2007 16:09:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l33G7WGB052409; Tue, 3 Apr 2007 10:07:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 03 Apr 2007 10:07:32 -0600 (MDT) Message-Id: <20070403.100732.74697496.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: Warner Losh In-Reply-To: <20070403154858.GR80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 03 Apr 2007 10:07:32 -0600 (MDT) Cc: freebsd-arm@FreeBSD.org Subject: Re: adding 16550 UART to RM9200 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 16:09:50 -0000 From: Bernd Walter 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