[U-Boot] Strange / Unreadable console output

[Jerry Van Baren]

On 08/13/2012 07:17 AM, Markus Hubig wrote:
> On Sat, Aug 11, 2012 at 08:15:43AM -0400, Jerry Van Baren wrote:
>> On 07/27/2012 05:16 AM, Markus Hubig wrote:
>>> 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
>>> | ...

[snip]

>> 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???
> 
> Hmm the only reverence I found related to caches in the at91bootstrap
> code I use (https://bitbucket.org/imko/at91bootstrap) is in crt0_gnu.S.
> 
> There are some lines disabling the cache but only if I enable Thump
> support, which I don't ... but I'll try this.

Good test, although it likely will change the system timing.  The really
worst case is that the problem is still lurking, but changing the boot
timing hides it. :-/

>> 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).
> 
> OK. But is enabling the caches in context of u-boot/bootstrap generally
> a good thing to do?

Enabling caches is a very good thing to do for speed, especially if you
are copying a flash image to RAM, but you pay a price in complexity.
Enabling code cache is generally safe (the only time you get into
problems is self-modifying code - probably why "thump" support disables
the cache).  Enabling data caches is good for memory operations, but
will bite you if you inadvertently cache hardware registers.

A fairly common technique is to enable data caches during heavy memory
read/write operations (copies, checksum/hash verifications, etc.) and
then disable it.

>> 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.
> 
> OK good to know, I'm running a bit out of time at the moment course of
> my thesis, but I'll definitely will have a look at this in detail when
> I'm finished.

Making sure cache is disabled when exiting the bootstrap loader to
u-boot should be reasonably easy to do (make sure you flush the data
cache before disabling it).  That and a few reboots should give you a
good indication if that is indeed your problem.

> Cheers, Markus

Good luck on the thesis,
gvb