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