Date: Wed, 22 Nov 2006 15:26:24 +0100 From: "Daan Vreeken [PA4DAN]" <Danovitsch@vitsch.net> To: Olivier Houchard <mlfbsd@ci0.org> Cc: freebsd-arm@freebsd.org Subject: Re: At91rm9200 how to start with FreeBSD Message-ID: <200611221526.24471.Danovitsch@vitsch.net> In-Reply-To: <20061121112926.GA87021@ci0.org> References: <7380637.post@talk.nabble.com> <200611202312.58007.Danovitsch@vitsch.net> <20061121112926.GA87021@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-00=_Q4FZFhGJxDJPQNe
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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.
And once again:
This work was sponsored by Vitsch Electronics.
--
Daan
--Boundary-00=_Q4FZFhGJxDJPQNe
Content-Type: text/x-diff; charset="iso-8859-1"; name="daan_usbdi_patch.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="daan_usbdi_patch.diff"
--- usbdi.c.org Wed Nov 22 11:40:46 2006
+++ usbdi.c Wed Nov 22 15:16:37 2006
@@ -377,6 +377,13 @@
xfer->buffer != xfer->allocbuf)
memcpy(xfer->allocbuf, xfer->buffer, xfer->length);
bus_dmamap_sync(tag, dmap->map, BUS_DMASYNC_PREWRITE);
+ } else {
+ /*
+ * Even if we have no data portion we still need to sync the
+ * dmamap for the request data in the SETUP packet
+ */
+ if (xfer->rqflags & URQ_REQUEST)
+ bus_dmamap_sync(tag, dmap->map, BUS_DMASYNC_PREWRITE);
}
err = pipe->methods->transfer(xfer);
if (err != USBD_IN_PROGRESS && err) {
--Boundary-00=_Q4FZFhGJxDJPQNe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611221526.24471.Danovitsch>