Re: AR7 runtime identification [was:- Re: [PATCH -v1] MIPS: add support for gzip/bzip2/lzma compressed kernel images]

[Florian Fainelli <florian@openwrt.org>]

Le Monday 10 August 2009 23:42:27 Florian Fainelli, vous avez écrit :
> Hi Alexander,
>
> Le Monday 10 August 2009 12:12:05 Alexander Clouter, vous avez écrit :
> > * Florian Fainelli <florian@openwrt.org> [2009-08-10 12:06:07+0200]:
> > > Hi Alexander,
> > >
> > > Le Monday 10 August 2009 11:03:15 Alexander Clouter, vous avez écrit :
> > > > I notice in arch/mips/ar7/prom.c the while loop hangs on
> > > > "(serial_in(UART_LSR) & UART_LSR_TEMT)" instead, is this because of
> > > > the buggy UART's seen in some revisions of the AR7?  As it stands
> > > > Wu's putc() implementation works fine for me but I'm guessing it is
> > > > because the UART has not much opportunity for over/underruns as not
> > > > much is being sent.
> > >
> > > Even with the silicon bug, this should not be a problem as long as you
> > > keep polling the LSR_TEMT bit in the LSR register. The problem appears
> > > when running the UART with interrupts.
> >
> > Ahhhh, that makes sense.  I'll leave Wu's code alone :)
> >
> > > > The UART on my board is buggy (missing/repeated characters like many
> > > > others seem to get) to, but I remember seeing somewhere (in a chat
> > > > you had years ago with Alan Cox if I remember correctly) the UART is
> > > > not buggy on *all* AR7 based boards?  Is is possible to detect a
> > > > buggy UART at runtime (maybe via a AR7 revision match test)?
> > >
> > > Alan Cox suggested to perform some tests which I did not carry out yet.
> > > By using two different hardware revisions in two different routers I
> > > noticed that the silicon bug is present in TNETD7300GDU revision 4,
> > > while revision 5 does not have it.
> > >
> > > The revision id can certainly help differentiating between the silicon
> > > version, later tonight when I have access to the hardware I will
> > > compare between a WAG54G and a C54APRx. I remember being them different
> > > for theTNETD7300GDU rev 4 and the rev 5.
> >
> > Well, I was offering that I could add an extra datapoint if need be.
> > There must be a way to fix up the UART without adding a 'new' UART type,
> > in a clean way.  I'll have a look into it tonight, but I imagine you
> > have looked at this in far more detail than I could...but hey, it gives
> > me something to do tonight[1]. :)
>
> For your information, the TNETD7300GDU is detected like this:
> TI AR7 (TNETD7300), ID: 0x0005, Revision: 0x02
>
> and the TNETD7300EZDW (ADSL 2+) is detected like this:
> TI AR7 (TNETD7200), ID: 0x002b, Revision: 0x10 which also has the UART bug
> and is wrongly detected as a TNETD7200.
>
> I have left the WAG54G at work and will get my hands back on it tomorow.

The bad news is that my WAG54G v2 which is also a TNEDT7300GDU has this HW bug 
too rendering the runtime detection of the bug more difficult.
-- 
Best regards, Florian Fainelli
Email: florian@openwrt.org
Web: http://openwrt.org
IRC: [florian] on irc.freenode.net
-------------------------------