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@xxxxxxxxxxx> [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@xxxxxxxxxxx Web: http://openwrt.org IRC: [florian] on irc.freenode.net -------------------------------