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 | ...
Has anyone an idea how to fix this?
No. :-)
Damn! :-)
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:
- 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.
No. I get the CRC Warning only after I completly delete the NAND. After a 'saveenv' this warning is gone but my output is garbled.
- 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.
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?
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.
Cheers, Markus