[U-Boot] Strange / Unreadable console output

[Jerry Van Baren]

Hi Markus,

On 07/27/2012 05:16 AM, Markus Hubig wrote:
> Hi @all,
> 
> one minor Problem I often read about in this list is some crappy / unreadable
> console output at beginning of the U-Boot start procedure. Now I have the same
> "visual" Problem.
> 
> | H�NAND:  128 MiB
> | *** Warning - bad CRC, using default environment
> | 
> | In:    serial
> | Out:   serial
> | Err:   serial
> | Net:   macb0
> | macb0: Starting autonegotiation...
> | macb0: Autonegotiation timed out (status=0x7849)
> | macb0: link down (status: 0x7849)
> | Hit any key to stop autoboot:  0 
> | ...
> 
> Sometimes I get a good readable output, which looks like so:
> 
> | U-Boot 2012.04.01-00003-gab465ef-dirty (Jul 23 2012 - 14:44:29)
> | 
> | U-Boot code: 23F00000 -> 23F30464  BSS: -> 23F72128
> | CPU: AT91SAM9G20
> | Crystal frequency:   18.432 MHz
> | CPU clock        :  396.288 MHz
> | Master clock     :  132.096 MHz
> | RAM Configuration:
> | Bank #0: 20000000 64 MiB
> | WARNING: Caches not enabled
> | NAND:  128 MiB
> | ...
> 
> Has anyone an idea how to fix this?

No. :-)

>  Or what's the cause of it?

The UART is being mishandled, either directly or indirectly, e.g. due to
caching issues or maybe the UART block isn't configured properly.

> Is it even related to u-boot or is it something at91bootstrap is
> doing wrong?

Yes. :-)

Questions / observations:
1) When the output is garbled, is it always associated with the line
"*** Warning - bad CRC, using default environment" and not garbled if
the environment is OK?  That would indicate it is a configuration issue
with the default environment.  It could also indicate a caching problem
(see next), where your environment is obscured by an enabled cache.

2) The line before the garbled output becomes readable is "WARNING:
Caches not enabled".  Does (your) at91bootstrap enable caches?  If so,
does it disable them before jumping to u-boot?  When the output is
garbled, does it say "WARNING: Caches not enabled" or is that line
missing???

A classic way for UARTs to be garbled is to inadvertently cache their
registers.  This shows up on start up because typically caching is "all
or nothing" until the MMU is fully configured (MMU configuration is
complex).

When your program reads the "TxReady" flag, in this scenario it gets a
cached value of the status register that a always says "ready" even
though the hardware isn't ready at all.  The result is all bytes get
immediately crammed into the Tx register, overwriting the previous byte
and garbling it.

If you get lucky and the UART status register isn't cached (or is cached
"not ready" but the Tx routine has a timeout so it writes the byte to
the Tx register anyway), the UART works properly and the output isn't
garbled.

> Cheers, Markus

Good luck, and let us know what you learn,
gvb