Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Nov 2006 18:17:23 +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:  <200611211817.23949.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
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 <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).

The device does attach, here is the dmesg snippet :
axe0: <vendor 0x0b95 product 0x1720, class 2/0, rev 2.00/0.01, addr 2> 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<BROADCAST,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 1500
        ether 00:50:fc:bd:17:ac
# ifconfig axe0
axe0: flags=108802<BROADCAST,SIMPLEX,MULTICAST,NEEDSGIANT> 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: <vendor 0x0b95 product 0x1720, class 2/0, rev 2.00/0.01, addr 2> on
   uhub0
axe0: vendor 0x0b95 product 0x1720, rev 2.00/0.01, addr 2
miibus1: <MII bus> on axe0
ukphy1: <Generic IEEE 802.3u media interface> 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: <vendor 0x0b95 product 0x1720, class 2/0, rev 2.00/0.01, addr 2> 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: <vendor 0x0b95 product 0x1720, class 2/0, rev 2.00/0.01, addr 2> on
   uhub0
axe0: vendor 0x0b95 product 0x1720, rev 2.00/0.01, addr 2
miibus1: <MII bus> on axe0
ukphy1: <Generic IEEE 802.3u media interface> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611211817.23949.Danovitsch>