From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 15:49:09 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 A40B716A402 for ; Tue, 3 Apr 2007 15:49:09 +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 209D013C469 for ; Tue, 3 Apr 2007 15:49:08 +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 l33Fn7mN004772 for ; Tue, 3 Apr 2007 17:49:07 +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 l33Fmx57053633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 17:48:59 +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 l33Fmwh8002144; Tue, 3 Apr 2007 17:48:58 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l33FmwAD002143; Tue, 3 Apr 2007 17:48:58 +0200 (CEST) (envelope-from ticso) Date: Tue, 3 Apr 2007 17:48:58 +0200 From: Bernd Walter To: freebsd-arm@freebsd.org Message-ID: <20070403154858.GR80382@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Bernd Walter Subject: 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 15:49:09 -0000 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. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de 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 From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 16:26:37 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 0B3B616A409 for ; Tue, 3 Apr 2007 16:26:37 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF5813C4BE for ; Tue, 3 Apr 2007 16:26:35 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l33Gke2n015745; Tue, 3 Apr 2007 18:46:40 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l33Gkdup015744; Tue, 3 Apr 2007 18:46:39 +0200 (CEST) (envelope-from mlfbsd) Date: Tue, 3 Apr 2007 18:46:39 +0200 From: Olivier Houchard To: ticso@cicely.de Message-ID: <20070403164639.GA15510@ci0.org> References: <20070403154858.GR80382@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070403154858.GR80382@cicely12.cicely.de> User-Agent: Mutt/1.4.1i 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: Tue, 03 Apr 2007 16:26:37 -0000 Hi, On Tue, Apr 03, 2007 at 05:48:58PM +0200, 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 think you'll want to use hints. > - I would like to use a 14,7456MHz xtal > How can I tell uart(4) the frequency? > You can play with the struct uart_devinfo.bas.rclk field. > - How can I configure NCS2 range as being uncacheable? > I asume this has to be done somehow in the kernel. > pmap_mapdev() maps the physical range passed uncached, so you can use it. Cheers, Olivier 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 From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 19:16:58 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 B0ABD16A405 for ; Tue, 3 Apr 2007 19:16:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.172]) by mx1.freebsd.org (Postfix) with ESMTP id 825B213C458 for ; Tue, 3 Apr 2007 19:16:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout02/MantshX 4.0) with ESMTP id l33J62vo013486; Tue, 3 Apr 2007 12:06:04 -0700 (PDT) Received: from [172.24.104.104] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l33J5wtX019828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Apr 2007 12:06:00 -0700 (PDT) In-Reply-To: <20070403.100732.74697496.imp@bsdimp.com> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <19589D66-9DF0-428B-80BD-2ECDC992A1EE@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 3 Apr 2007 12:05:12 -0700 To: Warner Losh X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes 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 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 19:16:58 -0000 On Apr 3, 2007, at 9:07 AM, Warner Losh wrote: >> I plan to add up to 48 16550 UART to an RM9200 system. *snip* >> - 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. Seconded. It's really easy to map all 48 uart(4) with a small configuration record in puc(4). This includes the ability to specify the RCLK. The only thing you need to do is have puc(4) attach to some bus so that it will end up using the configuration record. This, as has been suggested in another email, can be done with hints. > 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. In -CURRENT, puc(4) uses the serdev I/F to ask each uart(4) device about pending interrupt status and then handle them in priority order. This may be good enough when serial I/O is sufficiently low-speed. Of course, if you have something like an ILR (interrupt latch register), then you can use that with the serdev I/F as well. In that case puc(4) will only ask those uart(4) devices that have a bit set in the ILR. Given the number of ports, this may be worthwhile and it's easy enough to teach puc(4) about your particular implementation of an ILR anyway... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 19:57:24 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 F30C816A402 for ; Tue, 3 Apr 2007 19:57:23 +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 AB15A13C458 for ; Tue, 3 Apr 2007 19:57:23 +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 l33JsKlL055166; Tue, 3 Apr 2007 13:54:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 03 Apr 2007 13:54:19 -0600 (MDT) Message-Id: <20070403.135419.74695322.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: Warner Losh In-Reply-To: <20070403185553.GS80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> <20070403185553.GS80382@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 13:54:20 -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 19:57:24 -0000 > 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. Have you considered just using a GPIO pin for this and routing the interrupt that way? There's code there now to cope with the change of level in the GPIO pins. That way you'd only have to read one register and mask out the pins you want. The only mild gotcha here is that the interrupt is for signal change, not for a level, iirc. Surely you haven't used up all the I/O lines. > Is pmap_mapdev useable as Olivier wrote and this comment is outdated? No. that's fine. > Or is there still a problem with AT91? It is OK. > All in all this is just a single page to be mapped, which won't hurt, > so pmap_mapdev sounds good. OK. The other way maps it always, but maybe it would be better the simpler way. The above table maps to calls to pmap_mapdev anyway. > > 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... heh... Warner P.S. You never answered my question about giving me one :-) that's OK, it was a joke anyway. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 22:19:05 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 0174B16A403 for ; Tue, 3 Apr 2007 22:19:05 +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 9ED9E13C480 for ; Tue, 3 Apr 2007 22:19:04 +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 l33MJ0bP010892; Wed, 4 Apr 2007 00:19:00 +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 l33MIlaH056351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 00:18:47 +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 l33MIkSE003002; Wed, 4 Apr 2007 00:18:46 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l33MIkcV003001; Wed, 4 Apr 2007 00:18:46 +0200 (CEST) (envelope-from ticso) Date: Wed, 4 Apr 2007 00:18:46 +0200 From: Bernd Walter To: Warner Losh Message-ID: <20070403221846.GU80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> <20070403185553.GS80382@cicely12.cicely.de> <20070403.135419.74695322.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070403.135419.74695322.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 22:19:05 -0000 On Tue, Apr 03, 2007 at 01:54:19PM -0600, Warner Losh wrote: > > 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. > > Have you considered just using a GPIO pin for this and routing the > interrupt that way? There's code there now to cope with the change of > level in the GPIO pins. That way you'd only have to read one register > and mask out the pins you want. The only mild gotcha here is that the > interrupt is for signal change, not for a level, iirc. Surely you > haven't used up all the I/O lines. No - hadn't thought about it, but I've learned on 6502 and I love level based interrupts. You are right - only change interrupts are possible with PIO. Would have been a good idea, but 48 PIO lines for interrupt might be ok if I would do a complete board design, but I start with the existing board and handwire the new lines, so 48 lines are not an option. I'm happy that most needed lines are available on the low desity SDRAM chips, but the PIO are not... 6 PIO based interrupt lines with an ILR for each board is a problem as well as the UART can't easily share edged interrupts and I don't want to play tricks as done in the famous AST 4 port. I'll likely stay with 2 level interrupts shared over 3 boards each with an 8-source ILR. Asking the ILR is slower than PIO, but servicing the interrupt will do many more access than those 3 for the ILR group. The access time will be something around 70-100ns, which is not very fast, but match the worst case requirement between different UART vendors. > P.S. You never answered my question about giving me one :-) that's > OK, it was a joke anyway. I know :) But I don't build a 48 port device right from the start. Likely I will do a single extension board doing the SMC buffering plus 2 8-port boards to start with. There is nothing to give away at the beginning :( -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 22:24:48 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 B5BD616A401 for ; Tue, 3 Apr 2007 22:24:48 +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 4744C13C45D for ; Tue, 3 Apr 2007 22:24:48 +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 l33MOi3J010968; Wed, 4 Apr 2007 00:24:44 +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 l33MOTCw056387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 00:24:30 +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 l33MOT49003025; Wed, 4 Apr 2007 00:24:29 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l33MOSA1003024; Wed, 4 Apr 2007 00:24:28 +0200 (CEST) (envelope-from ticso) Date: Wed, 4 Apr 2007 00:24:28 +0200 From: Bernd Walter To: Marcel Moolenaar Message-ID: <20070403222428.GV80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> <19589D66-9DF0-428B-80BD-2ECDC992A1EE@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19589D66-9DF0-428B-80BD-2ECDC992A1EE@mac.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 22:24:48 -0000 On Tue, Apr 03, 2007 at 12:05:12PM -0700, Marcel Moolenaar wrote: > > On Apr 3, 2007, at 9:07 AM, Warner Losh wrote: > > >>I plan to add up to 48 16550 UART to an RM9200 system. > *snip* > >>- 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. > > Seconded. It's really easy to map all 48 uart(4) with a > small configuration record in puc(4). This includes the > ability to specify the RCLK. The only thing you need to > do is have puc(4) attach to some bus so that it will > end up using the configuration record. This, as has been > suggested in another email, can be done with hints. Yes absolutely - puc is perfect for this. Just needs a bit of glue code added. > >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. > > In -CURRENT, puc(4) uses the serdev I/F to ask each uart(4) device > about pending interrupt status and then handle them in priority > order. This may be good enough when serial I/O is sufficiently > low-speed. > > Of course, if you have something like an ILR (interrupt latch > register), then you can use that with the serdev I/F as well. In > that case puc(4) will only ask those uart(4) devices that have a > bit set in the ILR. Given the number of ports, this may be > worthwhile and it's easy enough to teach puc(4) about your > particular implementation of an ILR anyway... I already saw the related code and was very pleased with it. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de 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" > > From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 08:16:35 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 74A3016A402 for ; Wed, 4 Apr 2007 08:16:35 +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 3197913C45A for ; Wed, 4 Apr 2007 08:16:35 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 86BC4352DF; Wed, 4 Apr 2007 11:16:33 +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 93467-10; Wed, 4 Apr 2007 11:16:30 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 70B1235310; Wed, 4 Apr 2007 11:16:30 +0300 (EEST) Message-ID: <46135EDC.30700@bulinfo.net> Date: Wed, 04 Apr 2007 11:16:28 +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> In-Reply-To: <20070403154858.GR80382@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 08:16:35 -0000 You may look at this: http://www.nxp.com/news/content/file_1194.html 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. > > -- Krassimir Slavchev Bulinfo Ltd. krassi@bulinfo.net (+359 2) 969-9160 http://www.bulinfo.net (+359 2) 969-9166 From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 09:37:17 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 2B47616A403 for ; Wed, 4 Apr 2007 09:37:17 +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 CA45713C44B for ; Wed, 4 Apr 2007 09:37:16 +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 l349b81k019697; Wed, 4 Apr 2007 11:37: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 l349arm4060563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 11:36:53 +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 l349aqfL004778; Wed, 4 Apr 2007 11:36:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l349aqFt004777; Wed, 4 Apr 2007 11:36:52 +0200 (CEST) (envelope-from ticso) Date: Wed, 4 Apr 2007 11:36:52 +0200 From: Bernd Walter To: Krassimir Slavchev Message-ID: <20070404093651.GY80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <46135EDC.30700@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46135EDC.30700@bulinfo.net> 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: Bernd Walter , 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: Wed, 04 Apr 2007 09:37:17 -0000 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. 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. > 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. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de 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. >>> > > - From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 14:01: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 CD59016A40A for ; Wed, 4 Apr 2007 14:01: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 5881813C46A for ; Wed, 4 Apr 2007 14:01:12 +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 l34E1939024417; Wed, 4 Apr 2007 16:01:09 +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 l34E0rVB062317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 16:00:53 +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 l34E0rc6005586; Wed, 4 Apr 2007 16:00:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l34E0qBT005585; Wed, 4 Apr 2007 16:00:52 +0200 (CEST) (envelope-from ticso) Date: Wed, 4 Apr 2007 16:00:52 +0200 From: Bernd Walter To: Krassimir Slavchev Message-ID: <20070404140052.GD80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <46135EDC.30700@bulinfo.net> <20070404093651.GY80382@cicely12.cicely.de> <46139CE3.6090806@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46139CE3.6090806@bulinfo.net> 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: Bernd Walter , 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: Wed, 04 Apr 2007 14:01:14 -0000 On Wed, Apr 04, 2007 at 03:41:07PM +0300, Krassimir Slavchev wrote: > Bernd Walter wrote: > >On Wed, Apr 04, 2007 at 11:16:28AM +0300, Krassimir Slavchev wrote: > >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. The main point is to get larger buffers to reduce interrupt load no matter how it is done. I get the ILR with external hardware as well and I can still get 64 byte FiFo with the same PCB layout by using ST16C654 chips if absolutely required. I know that 48 UART is much, but I still expect that it will work for todays use. Dial-up pools with UART are quite uncommon use for UART these days. People keep old equipment running, but unlikely install new one. It is more typical to have sensor networks, console concentrators and so on. The whole used bandwidth with 48 UART should be much lower than with your 34 UART dial-up scenario. Most UART will run at 9600bps, some may use all 48 with 115200, but to get peak performance not to have sustained 115200 traffic on all ports. The interrupt overhead on ARM should be much lower than on i386. Unlikely on i386 we can even reorder the priority compared to other interrupt sources. Possible that I loose that benefit with the interrupt sharing over multiple ILR though. The ithread overhead compared to 2.x and 3.x should be solved as well. Not shure about the sio(4) vs. uart(4) performance difference. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 16:36: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 1287F16A404 for ; Wed, 4 Apr 2007 16:36:50 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.186]) by mx1.freebsd.org (Postfix) with ESMTP id EF5D913C459 for ; Wed, 4 Apr 2007 16:36:49 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/smtpout16/MantshX 4.0) with ESMTP id l34GabYA020598; Wed, 4 Apr 2007 09:36:37 -0700 (PDT) Received: from [192.168.1.3] (c-24-6-177-228.hsd1.ca.comcast.net [24.6.177.228]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l34GaYkS006974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2007 09:36:35 -0700 (PDT) In-Reply-To: <20070404140052.GD80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <46135EDC.30700@bulinfo.net> <20070404093651.GY80382@cicely12.cicely.de> <46139CE3.6090806@bulinfo.net> <20070404140052.GD80382@cicely12.cicely.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 4 Apr 2007 09:35:46 -0700 To: ticso@cicely.de X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes 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 16:36:50 -0000 On Apr 4, 2007, at 7:00 AM, Bernd Walter wrote: > Not shure about the sio(4) vs. uart(4) performance difference. I ran some tests (up to 230400bps) and if there's a difference in performance at all I found it to be in favor of uart(4). I don't want to claim having done extensive testing and given how marginal differences are, I also don't want to claim that uart(4) is better performing. All I say is that claims that sio(4) performs better than uart(4) are based on ... euh... who knows :-) In short: I didn't find performance to be a concern. I still have the following puc(4) & uart(4) results on a sticky note (for hysterical raisins :-) TEST 1: puc(4) performance testing after I rewrote puc(4): o compares performance between uart0 & uart1 (determines favoritism) o compares performance between transmit (DTE) & receive (DCE) CVS HEAD: DTE0: 6.15 real 0.05 user 4.98 sys 6.14 real 0.05 user 4.96 sys 6.16 real 0.04 user 5.01 sys DTE1: 6.14 real 0.02 user 4.99 sys 6.15 real 0.07 user 4.88 sys 6.14 real 0.04 user 4.87 sys DCE0: 6.15 real 0.06 user 5.02 sys 6.15 real 0.05 user 5.00 sys 6.14 real 0.10 user 4.96 sys DCE1: 6.16 real 0.08 user 5.00 sys 6.15 real 0.07 user 5.05 sys 6.14 real 0.07 user 4.96 sys Perforce uart branch (puc(4) rewrite): DTE0: 6.03 real 0.18 user 3.25 sys 6.09 real 0.22 user 4.95 sys 6.17 real 0.24 user 4.74 sys DTE1: 6.02 real 0.16 user 3.33 sys 6.05 real 0.28 user 4.81 sys 6.07 real 0.29 user 4.75 sys DCE0: 6.14 real 0.31 user 4.55 sys 6.22 real 0.36 user 4.62 sys 6.19 real 0.31 user 4.56 sys DCE1: 6.10 real 0.40 user 4.41 sys 6.11 real 0.29 user 4.59 sys 6.14 real 0.33 user 4.52 sys TEST2: uart(4) performance testing including sio(4) -- I think it's the serdev I/F ... o I can't recall what A and B means, but A was bad :-) o HEAD represents CVS current at some time o UART represents the Perforce uart branch KERMIT: HEAD: cuau0=receive, cuau1=transmit: A 00:02:42 - 11016 CPS B 00:02:37 - 11361 CPS B 00:02:37 - 11360 CPS (sio) cuau0=transmit, cuau1=receive: A 00:02:42 - 11020 CPS B 00:02:37 - 11362 CPS B 00:02:37 - 11362 CPS (sio) UART: cuau0=receive, cuau1=transmit: A 00:02:43 - 10963 CPS B 00:02:37 - 11363 CPS cuau0=transmit, cuau1=receive: A 00:02:42 - 11016 CPS B 00:02:37 - 11364 CPS CPS between sio(4) and uart(4) are on par with a small win for uart(4) after my changes (those are in HEAD now). I think uart(4) has a slightly bigger interrupt overhead, so for higher speeds (>230400 or even >460800) this may kick in. In your case: uart(4) will do just fine :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 21:54:09 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 5E6AA16A402 for ; Wed, 4 Apr 2007 21:54:09 +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 F03A913C448 for ; Wed, 4 Apr 2007 21:54:08 +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 l34LpbPX071847; Wed, 4 Apr 2007 15:51:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 04 Apr 2007 15:51:37 -0600 (MDT) Message-Id: <20070404.155137.48476499.imp@bsdimp.com> To: krassi@bulinfo.net From: Warner Losh In-Reply-To: <46135C78.70009@bulinfo.net> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> <46135C78.70009@bulinfo.net> 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]); Wed, 04 Apr 2007 15:51:38 -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: Wed, 04 Apr 2007 21:54:09 -0000 > I have enabled usb code in at91.c but no luck. > > How to get this working? The code in perforce is working. I'll have to merge that to head soon. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Apr 5 07:28:22 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 97DBC16A402 for ; Thu, 5 Apr 2007 07:28:22 +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 42D7D13C480 for ; Thu, 5 Apr 2007 07:28:21 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id BC726383C6; Thu, 5 Apr 2007 10:28:19 +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 87702-03; Thu, 5 Apr 2007 10:28:18 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id B351E383C3; Thu, 5 Apr 2007 10:28:18 +0300 (EEST) Message-ID: <4614A512.7040503@bulinfo.net> Date: Thu, 05 Apr 2007 10:28:18 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Subject: tcpdump crash on arm? 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: Thu, 05 Apr 2007 07:28:22 -0000 Hi, This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. # ./tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes Bus error (core dumped) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-marcel-freebsd"... Core was generated by `tcpdump'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libpcap.so.4...done. Loaded symbols for /lib/libpcap.so.4 Reading symbols from /lib/libcrypto.so.5...done. Loaded symbols for /lib/libcrypto.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000203a4 in ether_print () (gdb) bt #0 0x000203a4 in ether_print () #1 0x00020730 in ether_if_print () #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, sp=0x2040901a "") at /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 #5 0x0005c3b0 in $a () at /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 #6 0x0005c3b0 in $a () at /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 (gdb) From owner-freebsd-arm@FreeBSD.ORG Thu Apr 5 10:42:41 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 29E6416A401 for ; Thu, 5 Apr 2007 10:42:41 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 606A413C480 for ; Thu, 5 Apr 2007 10:42:39 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l35B39dE035757; Thu, 5 Apr 2007 13:03:09 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l35B35Ns035756; Thu, 5 Apr 2007 13:03:05 +0200 (CEST) (envelope-from mlfbsd) Date: Thu, 5 Apr 2007 13:03:05 +0200 From: Olivier Houchard To: Krassimir Slavchev Message-ID: <20070405110305.GA35723@ci0.org> References: <4614A512.7040503@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4614A512.7040503@bulinfo.net> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, Warner Losh Subject: Re: tcpdump crash on arm? 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: Thu, 05 Apr 2007 10:42:41 -0000 On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > Hi, > > This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. > > # ./tcpdump > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes > Bus error (core dumped) > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "arm-marcel-freebsd"... > Core was generated by `tcpdump'. > Program terminated with signal 10, Bus error. > Reading symbols from /lib/libpcap.so.4...done. > Loaded symbols for /lib/libpcap.so.4 > Reading symbols from /lib/libcrypto.so.5...done. > Loaded symbols for /lib/libcrypto.so.5 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x000203a4 in ether_print () > (gdb) bt > #0 0x000203a4 in ether_print () > #1 0x00020730 in ether_if_print () > #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, > sp=0x2040901a "") > at > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 > #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 > #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 > #5 0x0005c3b0 in $a () > at > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > #6 0x0005c3b0 in $a () > at > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > (gdb) > I remember seeing this, but I thought make worlding fixed it. Warner, do you remember what the issue was, and how/if we fixed it ? I think it had to do with the change in alignment somewhere. Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Apr 5 11:13:43 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 B277D16A403; Thu, 5 Apr 2007 11:13:43 +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 69EA013C45B; Thu, 5 Apr 2007 11:13:43 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 5C4CB388BE; Thu, 5 Apr 2007 14:13:41 +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 09039-04; Thu, 5 Apr 2007 14:13:38 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 50C3F388B7; Thu, 5 Apr 2007 14:13:38 +0300 (EEST) Message-ID: <4614D9E1.5080603@bulinfo.net> Date: Thu, 05 Apr 2007 14:13:37 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Olivier Houchard References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> In-Reply-To: <20070405110305.GA35723@ci0.org> 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, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? 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: Thu, 05 Apr 2007 11:13:43 -0000 Olivier Houchard wrote: > On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > >> Hi, >> >> This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. >> >> # ./tcpdump >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >> listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes >> Bus error (core dumped) >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "arm-marcel-freebsd"... >> Core was generated by `tcpdump'. >> Program terminated with signal 10, Bus error. >> Reading symbols from /lib/libpcap.so.4...done. >> Loaded symbols for /lib/libpcap.so.4 >> Reading symbols from /lib/libcrypto.so.5...done. >> Loaded symbols for /lib/libcrypto.so.5 >> Reading symbols from /lib/libc.so.7...done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x000203a4 in ether_print () >> (gdb) bt >> #0 0x000203a4 in ether_print () >> #1 0x00020730 in ether_if_print () >> #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, >> sp=0x2040901a "") >> at >> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 >> #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 >> #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 >> #5 0x0005c3b0 in $a () >> at >> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >> #6 0x0005c3b0 in $a () >> at >> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >> (gdb) >> >> > > I remember seeing this, but I thought make worlding fixed it. > Warner, do you remember what the issue was, and how/if we fixed it ? > I think it had to do with the change in alignment somewhere. > > Olivier > > I am not sure whether it is related or not but I receive this message when logging on console: ld-elf.so.1: assert failed: /usr/src-arm/src/libexec/rtld-elf/arm/reloc.c:289 The world and the kernel are in sync (cvsup on 30.3) From owner-freebsd-arm@FreeBSD.ORG Thu Apr 5 11:45:30 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 063AF16A402; Thu, 5 Apr 2007 11:45:30 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 354ED13C43E; Thu, 5 Apr 2007 11:45:28 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l35C62DQ036296; Thu, 5 Apr 2007 14:06:03 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l35C6270036295; Thu, 5 Apr 2007 14:06:02 +0200 (CEST) (envelope-from mlfbsd) Date: Thu, 5 Apr 2007 14:06:02 +0200 From: Olivier Houchard To: Krassimir Slavchev Message-ID: <20070405120602.GA36086@ci0.org> References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> <4614D9E1.5080603@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4614D9E1.5080603@bulinfo.net> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? 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: Thu, 05 Apr 2007 11:45:30 -0000 On Thu, Apr 05, 2007 at 02:13:37PM +0300, Krassimir Slavchev wrote: > Olivier Houchard wrote: > >On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > > > >>Hi, > >> > >>This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. > >> > >># ./tcpdump > >>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > >>listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes > >>Bus error (core dumped) > >> > >>GNU gdb 6.1.1 [FreeBSD] > >>Copyright 2004 Free Software Foundation, Inc. > >>GDB is free software, covered by the GNU General Public License, and you > >>are > >>welcome to change it and/or distribute copies of it under certain > >>conditions. > >>Type "show copying" to see the conditions. > >>There is absolutely no warranty for GDB. Type "show warranty" for > >>details. > >>This GDB was configured as "arm-marcel-freebsd"... > >>Core was generated by `tcpdump'. > >>Program terminated with signal 10, Bus error. > >>Reading symbols from /lib/libpcap.so.4...done. > >>Loaded symbols for /lib/libpcap.so.4 > >>Reading symbols from /lib/libcrypto.so.5...done. > >>Loaded symbols for /lib/libcrypto.so.5 > >>Reading symbols from /lib/libc.so.7...done. > >>Loaded symbols for /lib/libc.so.7 > >>Reading symbols from /libexec/ld-elf.so.1...done. > >>Loaded symbols for /libexec/ld-elf.so.1 > >>#0 0x000203a4 in ether_print () > >>(gdb) bt > >>#0 0x000203a4 in ether_print () > >>#1 0x00020730 in ether_if_print () > >>#2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", > >>h=0xbfffeb98, > >> sp=0x2040901a "") > >> at > >>/usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 > >>#3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 > >>#4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 > >>#5 0x0005c3b0 in $a () > >> at > >>/usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > >>#6 0x0005c3b0 in $a () > >> at > >>/usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > >>(gdb) > >> > >> > > > >I remember seeing this, but I thought make worlding fixed it. > >Warner, do you remember what the issue was, and how/if we fixed it ? > >I think it had to do with the change in alignment somewhere. > > > >Olivier > > > > > I am not sure whether it is related or not but I receive this message > when logging on console: > > ld-elf.so.1: assert failed: > /usr/src-arm/src/libexec/rtld-elf/arm/reloc.c:289 > > The world and the kernel are in sync (cvsup on 30.3) Huh interesting. I think it's unrelated, I think this is an assert triggered at start time, but I'd really like to be able to reproduce it. Does that happen every time you run tcpdump ? Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Apr 5 12:05:40 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 DFD3F16A404; Thu, 5 Apr 2007 12:05:40 +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 6163F13C44B; Thu, 5 Apr 2007 12:05:39 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 66311389EA; Thu, 5 Apr 2007 15:05:37 +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 13560-02; Thu, 5 Apr 2007 15:05:36 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 48EDF389E4; Thu, 5 Apr 2007 15:05:34 +0300 (EEST) Message-ID: <4614E60D.6010100@bulinfo.net> Date: Thu, 05 Apr 2007 15:05:33 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Olivier Houchard References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> <4614D9E1.5080603@bulinfo.net> <20070405120602.GA36086@ci0.org> In-Reply-To: <20070405120602.GA36086@ci0.org> 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, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? 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: Thu, 05 Apr 2007 12:05:41 -0000 Olivier Houchard wrote: > On Thu, Apr 05, 2007 at 02:13:37PM +0300, Krassimir Slavchev wrote: > >> Olivier Houchard wrote: >> >>> On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: >>> >>> >>>> Hi, >>>> >>>> This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. >>>> >>>> # ./tcpdump >>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >>>> listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes >>>> Bus error (core dumped) >>>> >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and you >>>> are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" for >>>> details. >>>> This GDB was configured as "arm-marcel-freebsd"... >>>> Core was generated by `tcpdump'. >>>> Program terminated with signal 10, Bus error. >>>> Reading symbols from /lib/libpcap.so.4...done. >>>> Loaded symbols for /lib/libpcap.so.4 >>>> Reading symbols from /lib/libcrypto.so.5...done. >>>> Loaded symbols for /lib/libcrypto.so.5 >>>> Reading symbols from /lib/libc.so.7...done. >>>> Loaded symbols for /lib/libc.so.7 >>>> Reading symbols from /libexec/ld-elf.so.1...done. >>>> Loaded symbols for /libexec/ld-elf.so.1 >>>> #0 0x000203a4 in ether_print () >>>> (gdb) bt >>>> #0 0x000203a4 in ether_print () >>>> #1 0x00020730 in ether_if_print () >>>> #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", >>>> h=0xbfffeb98, >>>> sp=0x2040901a "") >>>> at >>>> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 >>>> #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 >>>> #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 >>>> #5 0x0005c3b0 in $a () >>>> at >>>> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >>>> #6 0x0005c3b0 in $a () >>>> at >>>> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >>>> (gdb) >>>> >>>> >>>> >>> I remember seeing this, but I thought make worlding fixed it. >>> Warner, do you remember what the issue was, and how/if we fixed it ? >>> I think it had to do with the change in alignment somewhere. >>> >>> Olivier >>> >>> >>> >> I am not sure whether it is related or not but I receive this message >> when logging on console: >> >> ld-elf.so.1: assert failed: >> /usr/src-arm/src/libexec/rtld-elf/arm/reloc.c:289 >> >> The world and the kernel are in sync (cvsup on 30.3) >> > > Huh interesting. > I think it's unrelated, I think this is an assert triggered at start time, > Yes, it happens after login. > but I'd really like to be able to reproduce it. > > Does that happen every time you run tcpdump ? > > No. Only when login on console. > Olivier > > From owner-freebsd-arm@FreeBSD.ORG Thu Apr 5 16:39:34 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 58D9D16A402; Thu, 5 Apr 2007 16:39:34 +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 E77CC13C4BB; Thu, 5 Apr 2007 16:39:33 +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 l35Gb86r084483; Thu, 5 Apr 2007 10:37:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 10:37:08 -0600 (MDT) Message-Id: <20070405.103708.71171924.imp@bsdimp.com> To: mlfbsd@ci0.org From: Warner Losh In-Reply-To: <20070405110305.GA35723@ci0.org> References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> 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]); Thu, 05 Apr 2007 10:37:10 -0600 (MDT) Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? 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: Thu, 05 Apr 2007 16:39:34 -0000 From: Olivier Houchard Subject: Re: tcpdump crash on arm? Date: Thu, 5 Apr 2007 13:03:05 +0200 > On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > > Hi, > > > > This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. > > > > # ./tcpdump > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes > > Bus error (core dumped) > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "arm-marcel-freebsd"... > > Core was generated by `tcpdump'. > > Program terminated with signal 10, Bus error. > > Reading symbols from /lib/libpcap.so.4...done. > > Loaded symbols for /lib/libpcap.so.4 > > Reading symbols from /lib/libcrypto.so.5...done. > > Loaded symbols for /lib/libcrypto.so.5 > > Reading symbols from /lib/libc.so.7...done. > > Loaded symbols for /lib/libc.so.7 > > Reading symbols from /libexec/ld-elf.so.1...done. > > Loaded symbols for /libexec/ld-elf.so.1 > > #0 0x000203a4 in ether_print () > > (gdb) bt > > #0 0x000203a4 in ether_print () > > #1 0x00020730 in ether_if_print () > > #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, > > sp=0x2040901a "") > > at > > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 > > #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 > > #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 > > #5 0x0005c3b0 in $a () > > at > > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > > #6 0x0005c3b0 in $a () > > at > > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > > (gdb) > > > > I remember seeing this, but I thought make worlding fixed it. > Warner, do you remember what the issue was, and how/if we fixed it ? > I think it had to do with the change in alignment somewhere. I thought things were working. I'll have to check again. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Apr 5 22:37:31 2007 Return-Path: X-Original-To: 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 1889E16A402; Thu, 5 Apr 2007 22:37:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9C55D13C465; Thu, 5 Apr 2007 22:37:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l35MbTrU045241; Thu, 5 Apr 2007 18:37:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l35MbTeR012538; Thu, 5 Apr 2007 18:37:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8509073039; Thu, 5 Apr 2007 18:37:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070405223729.8509073039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 18:37:29 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 22:37:31 -0000 TB --- 2007-04-05 21:35:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-05 21:35:00 - starting HEAD tinderbox run for arm/arm TB --- 2007-04-05 21:35:00 - cleaning the object tree TB --- 2007-04-05 21:35:35 - checking out the source tree TB --- 2007-04-05 21:35:35 - cd /tinderbox/HEAD/arm/arm TB --- 2007-04-05 21:35:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-05 21:45:38 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-05 21:45:38 - cd /src TB --- 2007-04-05 21:45:38 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 5 21:45:39 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c /src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c ioctl.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c kdump_subr.c kdump_subr.c: In function `whencename': kdump_subr.c:611: error: `SEEK_DATA' undeclared (first use in this function) kdump_subr.c:611: error: (Each undeclared identifier is reported only once kdump_subr.c:611: error: for each function it appears in.) kdump_subr.c:614: error: `SEEK_HOLE' undeclared (first use in this function) *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-05 22:37:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-05 22:37:29 - ERROR: failed to build world TB --- 2007-04-05 22:37:29 - tinderbox aborted TB --- 0.48 user 1.69 system 3749.19 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Apr 6 03:53:42 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 EFA9916A405 for ; Fri, 6 Apr 2007 03:53:42 +0000 (UTC) (envelope-from bbvs.gupta@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8868A13C4B8 for ; Fri, 6 Apr 2007 03:53:42 +0000 (UTC) (envelope-from bbvs.gupta@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1158043ugh for ; Thu, 05 Apr 2007 20:53:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=pGjdVonCPUeJq/+B5UCA+waxM1rE2qoA4irpc/CqRITlOnpSL0ovCM5C2ZC8L8ox9fNPcYgQ0stnYTjlTno/bbU5Jle4XC6QROIxcbuFJA+RGfx5GgANyzNSTFp6cj+o9L8gVACZPmv64yjN/HbPzBK2qWQuCdiYj/j1koueRTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=AWSabzK3X/4V9SE4tYclxLhZ9Suilamlozcnmu0EdIow7NaCzKMXo0f+CZCPH1gyUAAmc+s0qZ6r4GVg8ImOuH0IAaquBSSGzQ7RVGtBod+BKVXNd6JLoMhnu8QWcA39CtjCoe4T3tjMFOPkyIrmhxPRE81ME2mOSe+8ZQJi2gQ= Received: by 10.67.13.19 with SMTP id q19mr2659958ugi.1175830111110; Thu, 05 Apr 2007 20:28:31 -0700 (PDT) Received: by 10.67.27.14 with HTTP; Thu, 5 Apr 2007 20:28:31 -0700 (PDT) Message-ID: <2245656f0704052028r6129ac1fx37d8055f167b6bdd@mail.gmail.com> Date: Fri, 6 Apr 2007 08:58:31 +0530 From: "Shreeranganath Gupta B B V" To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Netsilicon's NS7520 port 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: Fri, 06 Apr 2007 03:53:43 -0000 Hi , I'm very new to this Freebsd and i would like to know is there any source code which is ported to Netsilicon (Now called 'Digi') ARM7 controller NS7520. If it is already ported, please let me know where i can get the source code and tool chain. If there is no port for this controller, please let me know which version of the freebsd source code and toolchaing that i may need to take start my work. If any body can give some initial steps to be followed for starting this porting activity will be of great help. Thanks in advance. Regards Gupta From owner-freebsd-arm@FreeBSD.ORG Fri Apr 6 04:03:08 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 4F51516A403 for ; Fri, 6 Apr 2007 04:03:08 +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 09E0F13C43E for ; Fri, 6 Apr 2007 04:03:07 +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 l3641o7e089896; Thu, 5 Apr 2007 22:01:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 22:01:57 -0600 (MDT) Message-Id: <20070405.220157.-345495586.imp@bsdimp.com> To: bbvs.gupta@gmail.com From: "M. Warner Losh" In-Reply-To: <2245656f0704052028r6129ac1fx37d8055f167b6bdd@mail.gmail.com> References: <2245656f0704052028r6129ac1fx37d8055f167b6bdd@mail.gmail.com> X-Mailer: Mew version 4.2 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]); Thu, 05 Apr 2007 22:01:51 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: Netsilicon's NS7520 port 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: Fri, 06 Apr 2007 04:03:08 -0000 In message: <2245656f0704052028r6129ac1fx37d8055f167b6bdd@mail.gmail.com> "Shreeranganath Gupta B B V" writes: : I'm very new to this Freebsd and i would like to know is there any : source code which is ported to Netsilicon (Now called 'Digi') ARM7 : controller NS7520. If it is already ported, please let me know where i can : get the source code and tool chain. : If there is no port for this controller, please let me know which : version of the freebsd source code and toolchaing that i may need to take : start my work. If any body can give some initial steps to be followed for : starting this porting activity will be of great help. There's no port, and there's no port planned. The NS7520 has no MMU, so a port would be challanging... Warner From owner-freebsd-arm@FreeBSD.ORG Fri Apr 6 11:40:56 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 B7F2A16A402 for ; Fri, 6 Apr 2007 11:40:56 +0000 (UTC) (envelope-from bbvs.gupta@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 4CAA413C44B for ; Fri, 6 Apr 2007 11:40:56 +0000 (UTC) (envelope-from bbvs.gupta@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1203873ugh for ; Fri, 06 Apr 2007 04:40:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LsA1qhBG+s7qyBz4zwNuxajpC/PQXr6ZTID0aBkm+R8P6DcmMsl6R+xorWIuRrCCkndJxLUFZJCqo7pjxbLIpoGAApSkEmIkjHU8dOXO98GmIgbf6VvcDdGXQUjga4wtSxd9CY3JV7PZ0mF9bSFg9oCAG4dBWgHIJ/uekAZU1A4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=N9g4T/onTJd4rDmg1W6hL5EpLCka6SWyUQ7863x+so85tEI3jKfMExLFRaGpx60peiPf9PHcVNsq19W/eo9ysu/8HiRtrWSa1jRRcoe+XQ0EtxQ+lrwZN02f/5sYt40hZ1h/mpla1VNgNBctimdehiTK4zNj6u8vXPEuDXZR+Bo= Received: by 10.67.19.20 with SMTP id w20mr2924501ugi.1175859655109; Fri, 06 Apr 2007 04:40:55 -0700 (PDT) Received: by 10.67.27.14 with HTTP; Fri, 6 Apr 2007 04:40:55 -0700 (PDT) Message-ID: <2245656f0704060440oee5bbabt256453b47e032f94@mail.gmail.com> Date: Fri, 6 Apr 2007 17:10:55 +0530 From: "Shreeranganath Gupta B B V" To: "M. Warner Losh" In-Reply-To: <20070405.220157.-345495586.imp@bsdimp.com> MIME-Version: 1.0 References: <2245656f0704052028r6129ac1fx37d8055f167b6bdd@mail.gmail.com> <20070405.220157.-345495586.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org Subject: Re: Netsilicon's NS7520 port 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: Fri, 06 Apr 2007 11:40:56 -0000 Thanks for the information. Regards Gupta On 4/6/07, M. Warner Losh wrote: > > In message: <2245656f0704052028r6129ac1fx37d8055f167b6bdd@mail.gmail.com> > "Shreeranganath Gupta B B V" writes: > : I'm very new to this Freebsd and i would like to know is there any > : source code which is ported to Netsilicon (Now called 'Digi') ARM7 > : controller NS7520. If it is already ported, please let me know where i > can > : get the source code and tool chain. > : If there is no port for this controller, please let me know which > : version of the freebsd source code and toolchaing that i may need to > take > : start my work. If any body can give some initial steps to be followed > for > : starting this porting activity will be of great help. > > There's no port, and there's no port planned. The NS7520 has no MMU, > so a port would be challanging... > > Warner >