From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 08:06:23 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 AAF4B16A405 for ; Wed, 4 Apr 2007 08:06:23 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4786D13C45B for ; Wed, 4 Apr 2007 08:06:23 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 05EB2352E7 for ; Wed, 4 Apr 2007 11:06:21 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93004-05 for ; Wed, 4 Apr 2007 11:06:19 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 37D87352DF for ; Wed, 4 Apr 2007 11:06:19 +0300 (EEST) Message-ID: <46135C78.70009@bulinfo.net> Date: Wed, 04 Apr 2007 11:06:16 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> In-Reply-To: <20070403.100732.74697496.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Wed, 04 Apr 2007 08:06:23 -0000 Warner Losh wrote: > 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 still have problems with ohci mapping. ohci0: 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" > >