Skip site navigation (1)Skip section navigation (2)
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>