From owner-freebsd-arm@FreeBSD.ORG Tue Nov 21 17:23:02 2006 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 CBE5616D5FA for ; Tue, 21 Nov 2006 17:21:31 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from amsfep14-int.chello.nl (amsfep17-int.chello.nl [213.46.243.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F0B143E7B for ; Tue, 21 Nov 2006 17:17:10 +0000 (GMT) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([62.195.87.223]) by amsfep14-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20061121171728.JIBD7165.amsfep14-int.chello.nl@Tuinhuisje.Vitsch.net>; Tue, 21 Nov 2006 18:17:28 +0100 Received: from self (f23025.upc-f.chello.nl [80.56.23.25]) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id kALHHHq6064165; Tue, 21 Nov 2006 18:17:22 +0100 (CET) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: Olivier Houchard Date: Tue, 21 Nov 2006 18:17:23 +0100 User-Agent: KMail/1.9.1 References: <7380637.post@talk.nabble.com> <200611202312.58007.Danovitsch@vitsch.net> <20061121112926.GA87021@ci0.org> In-Reply-To: <20061121112926.GA87021@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611211817.23949.Danovitsch@vitsch.net> Cc: freebsd-arm@freebsd.org Subject: Re: At91rm9200 how to start with FreeBSD 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, 21 Nov 2006 17:23:02 -0000 Hi Olivier, On Tuesday 21 November 2006 12:29, you wrote: > Hi Daan, > > On Mon, Nov 20, 2006 at 11:12:57PM +0100, Daan Vreeken [PA4DAN] wrote: > > On Monday 20 November 2006 23:03, Daan Vreeken [PA4DAN] wrote: > > > Hi Warner (and the list), > > > > > > On Thursday 16 November 2006 17:36, M. Warner Losh wrote: > > > > In message: <7380637.post@talk.nabble.com> > > > > > > > > Zuy writes: > > > > : How I'm soldering board based on AT91RM9200 with 16mb SDRAM and > > > > : othe standartpPeripherals(USB, SD, UART ...). I'm going to run > > > > : FreeBSD on this board, but unfortunately I do not know how to > > > > : start. > > > > : I havn't found any files connected with AT91RM9200 in FreeBSD6.0 > > > > : Stable source files directory. > > > > : I found from this board that freebsd works on at91rm9200. > > > > > > > > Yes. It does. FreeBSD-current has the most up to date tested code > > > > for this platform. FreeBSD 6.2 will contain the tools you need to > > > > build it, as well as a slightly less advanced version (the freeze > > > > date for 6.2 was a while ago). 6.3 is likely to have even more > > > > advanced support. > > > > > > ... > > > > > > > Here's the broad outlines. > > > > > > ... followed by a very nice ARM-introduction :) ... > > > > > > > Feel free to ask questions. the more people that ask, the bigger my > > > > collection of email on the topic gets, and the easier it will be for > > > > me to synthesize a tutorial. Also, if there are areas that I've been > > > > vague, please don't hesitate to let me know. > > > > > > This email got me to dust-off the KB9202B board my company bought a > > > while back for a project that hasn't started (yet). With your email it > > > was quite easy to get the board to work. I now use the original > > > Kwikbyte boot loader to load the kernel with tftp. After that the > > > kernel mounts root over NFS and everything works like a charm. > > > If I am going to use this board in the project it was intended for, we > > > will need USB support, so I took a shot at getting USB working... > > > > Stupid me, I pressed [ctrl+enter] while typing this email instead of > > [enter], so a piece of the intended story didn't make it into the first > > email :-s > > > > The conclusion : I've got USB to work. > > !! > That's great news ! > Thanks a lot for doing this. > > > What I changed : > > > o updated hints.at91rm9200 (ohci controller is on ASB) > > > > o I've added a mapping for the OHCI controller in kb920x_machdep.c that > > maps the controller to 0xdfe00000 (just below where the IO region is > > mapped) > > > > After enabling the ohci controller it crashed in usbd_transfer() because > > of > > > > missing device->bus->buffer_dmatag so I added : > > > o allocate dma tags in ohci_atmelarm_attach() > > > (inspired by ohci_pci.c) > > > o destroy dma tags in ohc_atmelarm_detach() > > > > With these changes USB is now working on the board I have here. I have > > succesfully read the entire content of a memory stick inside a digital > > camera with it. There are some problems though (not sure yet where they > > come from). I have a if_axe device here that doesn't want to work. (Will > > investigate further). > > Not working as in failed to probe/attach, or fail to transfer ? If it is > fail to transfer, a common issue on arm is the lack of proper use of > bus_dmamap_sync(), because arm is the only arch which really needs those (I > don't know the USB code enough to tell if it's the problem here, but it's > an usual suspect). The device does attach, here is the dmesg snippet : axe0: on uhub0 axe0: vendor 0x0b95 product 0x1720, rev 2.00/0.01, addr 2 axe0: Ethernet address: 00:50:fc:bd:17:ac axe0: if_start running deferred for Giant The reported mac address is the same as when I plug the device into an i386 machine, so it looks as if byte-ordering is also done where needed upto here. I have added some printf's to the rxeof and txeof functions but they don't get printed. Playing around with ifconfig gives the following : # ifconfig axe0 axe0: flags=108802 mtu 1500 ether 00:50:fc:bd:17:ac # ifconfig axe0 axe0: flags=108802 mtu 1500 ether 00:50:fc:bd:17:ac (at least it's consistent :) # ifconfig axe0 up axe0: getting interface handle failed # ifconfig axe0 doon axe_rxeof() called axe0: getting interface handle failed # ifconfig axe0 up axe0: getting interface handle failed # ifconfig axe0 down axe_rxeof() called axe0: getting interface handle failed # ifconfig axe0 up axe0: getting interface handle failed # axe0: at uhub0 port 1 (addr 2) disconnected axe_rxeof() called And unplugging the device after this crashes the board. While typing this email I've been testing some more. Just now and then ukphy also attaches when I plug in the device : axe0: on uhub0 axe0: vendor 0x0b95 product 0x1720, rev 2.00/0.01, addr 2 miibus1: on axe0 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto axe0: Ethernet address: 00:50:fc:bd:17:ac axe0: if_start running deferred for Giant After that, assigning an ip address to the interface seems to work and the link LED even lights up. Starting a "ping" even shows txeof() being called. (Still no rxeof() though). Unplugging the device in this state works as it should. Another couple of plug & unplug's show : axe0: on uhu0 axe0: vendor 0x0b95 product 0x1720, rev 2.00/0.01, addr 2 axe0: MII without any PHY! device_attach: axe0 attach returned 6 axe0: at uhub0 port 1 (addr 2) disconnected axe0: on uhub0 axe0: vendor 0x0b95 product 0x1720, rev 2.00/0.01, addr 2 miibus1: on axe0 ukphy1: on miibus1 ukphy1: ifmedia_set: no match for 0x0/0xfffffff panic: ifmedia_set KDB: enter: panic [thread pid 22 tid 100025 ] Stopped at kdb_enter+0x3c: ldrb r15, [r15, r15, ror r15]! db> So it seems that if_axe itself at least attaches without a problem, but the interaction with mii seems to be purely random. Apart from that I have another problem with this KB9202B board. I use the original boot loader that was provided by Kwikbyte and load the kernel using TFTP. I would really like to keep using TFTP for it's speed, but for some reason not all kernels I have created are bootable... I suspect this to be a problem in the boot loader. When I change the configuration of my kernel (add a device, or remove one) all of a sudden the kernel won't boot. The boot loader doesn't complain during the TFTP-transfer, but after typing "e 0x20000000" to execute, the board hangs without a single letter being output on the serial console. Has anyone else seen this problem? Is there a way to fix the TFTP problems I am seeing? (Or did I really mess up with compiling?) > > Also, I'm not sure if I need to tell the kernel more about the VA/PA > > mapping I have added and wheter or not there is a better way/place to do > > the mapping. Any comments are appreciated. > > Given the static nature of the OHCI controller, I think it's OK to do as > you did, that's KVA we won't use anyway. Ok. Great. > > If time permits I'll try to implement a driver for the USB Device Port as > > it could also come in handy when we're going to use these boards. > > That would be great. > > > btw: This work is sponsored by Vitsch Electronics. > > We'll make sure it appears in the commit log. Thanks a lot ! > > Olivier -- Daan