From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 12:41:11 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 D5C2516A404 for ; Wed, 4 Apr 2007 12:41:11 +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 61B4913C44B for ; Wed, 4 Apr 2007 12:41:11 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 2D682356AD; Wed, 4 Apr 2007 15:41:09 +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 16768-05; Wed, 4 Apr 2007 15:41:08 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id E960D356AF; Wed, 4 Apr 2007 15:41:07 +0300 (EEST) Message-ID: <46139CE3.6090806@bulinfo.net> Date: Wed, 04 Apr 2007 15:41:07 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: ticso@cicely.de References: <20070403154858.GR80382@cicely12.cicely.de> <46135EDC.30700@bulinfo.net> <20070404093651.GY80382@cicely12.cicely.de> In-Reply-To: <20070404093651.GY80382@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Bernd Walter , 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 12:41:11 -0000 Bernd Walter wrote: > On Wed, Apr 04, 2007 at 11:16:28AM +0300, Krassimir Slavchev wrote: > >> You may look at this: >> http://www.nxp.com/news/content/file_1194.html >> > > Exar has something similar with the XR20M117x/XR20V117x > > The problem with IIC is that it is way to slow (max 400kbps) and is to > be shared with 48 UARTS, which even invalidates the full data rate. > You can't even run a single UART at 230kbps. > Yes, you are right, it was just an idea. > Plus IIC is quite expensive in respect of CPU time on the RM9200. > IIC is what I do right now - an USB master electronic for ubser(4) > plus multiple IIC connected ATMEGA8 controller doing a few software > UART at 9600bps each. > > SPI may be fast enough but requires a select line per UART, which of > course can be done via 6 to 64 decoder. > SPI works good for bulk transfers on the RM9200, but since we are > likely doing small transfers it is not very efficient. > > And it requires a complete new set of drivers. > > Additionally the 16C554 is available from multiple vendors and much > easier to source in small volume than the IIC/SPI chips. > If that wouldn't be a reason I would have selected the Exar XR16L788, > which is a 8 channel 16550 compatible UART with 64 Byte buffers and > an integraded ILR. > > This chip seems to be good choice. I dont now what is your application but 48 uarts are too much. I have dial-up servers with 34 (32+2) uarts on P1 166 Mhz (FreeBSD 2.2.8 and 3.5.1) which work perfect for years at 38400 bps but I still get "silo overflow" messages. It is not a bad idea to use multiplexers where you can. >> Bernd Walter wrote: >> >>> 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. >>> >>> However some question points are still left: >>> >>> - 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? >>> >>> - How can I configure NCS2 range as being uncacheable? >>> I asume this has to be done somehow in the kernel. >>> > > -