[U-Boot] mips board with no output from console

[Jerry Van Baren <gvb.uboot@gmail.com>]

myuboot at fastmail.fm wrote:
> I am trying to upgrade my u-boot from 2008.10 to 2009.06. So I used the
> buildroot 2009.06 to build the tool chain for my mips32 board as well as
> u-boot. I also copied the previous u-boot initialization code to
> initialze timer, serial port, ram and etc from u-boot 2008.10 to
> 2009.06. My previous version of u-boot-2008.10 was working, but after
> porting it over to u-boot 2009.06, there is no output from console at
> all. I used bdi hardware debugger to debug it, and found that u-boot is
> stuck in file drivers/serial/ns16550.c function NS16550_putc. There is a
> while loop there :
> while ((com_port>lsr & LSR_THRE) == 0);
> 
> My understanding is the line here is to wait for the hardware register
> (LSR_THRE) to acknowledge the input character was received by the
> hardware.
> 
> But I don't have any clue how to fix this issue. I think I have
> initialized the serial port the same way as I did for u-boot 2008.10.
> Can some one give me some suggestions on what to check for?
> 
> Thanks.  

Hi "myuboot",

If you look in ./include/ns16550.h you will see:
#define UART_LSR_THRE   0x20            /* Xmit holding register empty */

The code you quote is waiting for room in the transmit buffer to put the 
character in.  It is stuck in the loop because it is reading 0 == not 
empty, i.e. full.

This means the UART is not transmitting for some reason - that is why it 
is backed up.  My first suspicion would be that your UART is not being 
clocked.  I know nothing of your board or processor, but I would check 
clock configurations.  I would put a scope on the UART clock pin, 
assuming you can probe it, and *verify* that the clock is running at the 
expected rate.

If your clocking is OK, the next likely thing is that you have hardware 
handshaking and the RTS/CTS (DSR/DTR) lines are holding off the Tx. 
This could be due to actual handshaking hardware, or due to port (or 
SOC) configuration that makes the UART think that there are handshake 
lines that aren't connected or that are configured to be inactive.

I would put 98% odds on your clocking not clocking, however.

Good luck,
gvb