Date: Wed, 22 Nov 2006 15:57:57 +0100 From: Olivier Houchard <mlfbsd@ci0.org> To: "Daan Vreeken [PA4DAN]" <Danovitsch@vitsch.net> Cc: freebsd-arm@freebsd.org Subject: Re: At91rm9200 how to start with FreeBSD Message-ID: <20061122145757.GA97202@ci0.org> In-Reply-To: <200611221526.24471.Danovitsch@vitsch.net> References: <7380637.post@talk.nabble.com> <200611202312.58007.Danovitsch@vitsch.net> <20061121112926.GA87021@ci0.org> <200611221526.24471.Danovitsch@vitsch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 22, 2006 at 03:26:24PM +0100, Daan Vreeken [PA4DAN] wrote: > 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 <zaitsevbros@mail.ru> 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). > > I have been debugging the usb problems some more. Your were right in your > assumption (thanks for the pointer) about lack of calls to bus_dmamap_sync(). > In usbdi.c bus_dmamap_sync() does get used for transfers that move data from > PC to USB and it is used for transfers that move data from USB to PC. But > someone forgot that control transfers consist of possibly two data chunks : > the request itself and optionally a buffer of data that should be transfered > to or from the USB device. > On requests to the control endpoint without additional data bus_dmamap_sync() > didn't get called. For some reason my first tests with umass worked (due to > enough cache poisening I guess). > The attached patch adds a call to bus_dmamap_sync() to usbdi.c and now all > devices I have tried work out of the box. > I have successfully transfered large files using the if_axe driver and I have > mounted several different umass devices. > That's great to hear ! Hopefully I'll be able to look at this tonight. Thanks a lot ! > And once again: > This work was sponsored by Vitsch Electronics. > It's noted. Olivier > -- > Daan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061122145757.GA97202>