[U-Boot] Strange / Unreadable console output

[Markus Hubig]

On Mon, Aug 13, 2012 at 08:12:51PM -0400, Jerry Van Baren wrote:
> 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:
> 
> >> 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. :-/

Hmm, enabling the thumb support dosen't change anything. But at leased it
didn't do no harm.

> >> 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.

This at91bootstrap thing is no good pice of software. I'm looking foreward
to have an U-Boot based SPL ... ;-)

Cheers, Markus