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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot