From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 18:56:13 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 AD52F16A402 for ; Tue, 3 Apr 2007 18:56:13 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5744613C4C2 for ; Tue, 3 Apr 2007 18:56:13 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l33Iu86x007562; Tue, 3 Apr 2007 20:56:08 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l33Itsru054904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 20:55:55 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l33ItsxL002555; Tue, 3 Apr 2007 20:55:54 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l33Itsbo002554; Tue, 3 Apr 2007 20:55:54 +0200 (CEST) (envelope-from ticso) Date: Tue, 3 Apr 2007 20:55:54 +0200 From: Bernd Walter To: Warner Losh Message-ID: <20070403185553.GS80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070403.100732.74697496.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: ticso@cicely12.cicely.de, freebsd-arm@FreeBSD.org, ticso@cicely.de Subject: Re: adding 16550 UART to RM9200 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de 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 18:56:13 -0000 On Tue, Apr 03, 2007 at 10:07:32AM -0600, Warner Losh wrote: > From: Bernd Walter > Subject: adding 16550 UART to RM9200 > Date: Tue, 3 Apr 2007 17:48:58 +0200 > 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. puc looks like a good idea - it has almost everything I need. The hardware is more complex than the simplification I described. The board will get a SMC buffer with 5V translation plus subaddress decoding added. Up to 6 daughter boards can be added via short ribbon cable containing 8 ports each. Having a puc attachment per daugther board sounds most reasonable. I thought about an interrupt location register, but the distributed system makes it a bit difficult. The easiest thing seem to be adding a register per daughter board, which holds the bits of the 8 ports. This still requires polling up to 6 registers per interrupt though, but it is much better than polling 48. I might consider running only 3 boards on IRQ0 and the other 3 on IRQ3. Although the RM9200 has 7 external interrupts (not counting FIQ), the remaining IRQ* all collide :( - IRQ0 unshared - IRQ1 TWCK needed for my external RTC - IRQ2 TWD same as above - IRQ3 TXD2 I can easily accept loosing this UART with the new ones - IRQ4 SPCK needed for dataflash booting and I don't want to switch to iic-eeprom for booting - IRQ5 NPCS0 same as above - IRQ6 Ethernet MDIO I could free 2 IRQ if I either run without IIC or SPI, but this still wouldn't give me the ideal of 6 lines. > > - 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. > */ Is pmap_mapdev useable as Olivier wrote and this comment is outdated? Or is there still a problem with AT91? All in all this is just a single page to be mapped, which won't hurt, so pmap_mapdev sounds good. > 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 :-) Consider, that the daughter boards all get generic bus access and don't really have to be UART ones... -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de