Subject: Re: Debugging / SPL-levels / AT91RM9200 success
To: None <>
From: M. Warner Losh <>
List: port-arm
Date: 03/06/2007 14:03:48
In message: <>
            Sami Kantoluoto <> writes:
: On Wed, Mar 07, 2007 at 01:58:14AM +0900, Toru Nishimura wrote:
: > Sami Kantoluoto wrote;
: > 
: > > When dd hangs (reading normal device), it's waiting "biowait".
: > 
: > "lost interrupt" which notify xfer has done.  Upper half device driver
: > waits for notification to proceed and is waiting forever.
: Shouldn't there be that "lost interrupt" notify at console if that's the
: case? I saw those before I fixed the driver to check that the IRQ request
: line is in correct state (need to check because of the pin _change_ 
: interrupt) but not anymore.
: I'll take a look of FreeBSD's port.

FreeBSD's port doesn't do CF cards right now.  It does a lot of other
things.  Also, since FreeBSD doesn't have spl anymore, I'm not sure
how helpful it would be.  That part of the systems have been diverging
for a while now...

: PS. When the port is somehow working, we would like to see it in NetBSD's
: repository. Currently we've three arch-directories, arch/arm/at91,
: arch/arm/at91rm9200 and arch/evbarm/mpcsa. I've separated at91 and at91rm9200
: because the idea is to write AT91SAM926x support too someday. They (AT91RM9200
: and AT91SAM926x) have quite a lot common but e.g. AT91SAM926x does not have
: a system timer like AT91RM9200, ethernet controllers are different and so
: on.

Be careful here.  Many of the drivers are also applicable to the AVR32
family as well.  The MCI controller is near enough to being the same
that it could be shared between the two, but thankfully the
AT91SAM926x processors don't share the byte order erratum with the
AT91RM9200, so streaming performance isn't limited by how quickly you
can byte swap...

I'm also not convinced you need separate directories for each of the
SOCs.  In FreeBSD all the files live in sys/arm/at91, so far quite
happily.  I'm in the midst of bringing up an AT91SAM9260 eval board on
FreeBSD, and so far it hasn't been too bad.  A lot easier than trying
to bring up the AVR32 board I have...