[U-Boot] Strange / Unreadable console output
Hi @all,
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 ideea how to fix this? Or what's the cause of it? Is it even related to u-boot or is it something at91bootstrap is doing wrong?
Cheers, Markus
Hi Markus,
On 07/27/2012 05:16 AM, Markus Hubig wrote:
Hi @all,
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. :-)
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: 1) 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.
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???
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).
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.
Cheers, Markus
Good luck, and let us know what you learn, gvb
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
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]
- 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
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
Dear Markus Hubig,
On 27.07.12 11:16, Markus Hubig wrote:
Hi @all,
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 ideea how to fix this? Or what's the cause of it? Is it even related to u-boot or is it something at91bootstrap is doing wrong?
can you please check http://patchwork.ozlabs.org/patch/107896/
It seems this patch was set to 'Accepted' but never applied to the master repository. Unfortunately this got lost in nirvana end of last year. I will apply it in any case but can you please check if it fixes your problem?
Best regards
Andreas Bießmann
On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
On 27.07.12 11:16, 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 | ...
<snipp>
Has anyone an ideea how to fix this? Or what's the cause of it? Is it even related to u-boot or is it something at91bootstrap is doing wrong?
can you please check http://patchwork.ozlabs.org/patch/107896/
It seems this patch was set to 'Accepted' but never applied to the master repository. Unfortunately this got lost in nirvana end of last year. I will apply it in any case but can you please check if it fixes your problem?
Unfortunately not ... but it dosen't do any harm.
Cheers, Markus
Dear Markus Hubig,
On 14.08.2012 11:08, Markus Hubig wrote:
On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
On 27.07.12 11:16, 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 | ...
<snipp>
Has anyone an ideea how to fix this? Or what's the cause of it? Is it even related to u-boot or is it something at91bootstrap is doing wrong?
can you please check http://patchwork.ozlabs.org/patch/107896/
It seems this patch was set to 'Accepted' but never applied to the master repository. Unfortunately this got lost in nirvana end of last year. I will apply it in any case but can you please check if it fixes your problem?
Unfortunately not ... but it dosen't do any harm.
How sad!
I wonder if this has something to do with the ominous PC9. It is possible that this PC9 switches some vital element e.g. power supply, 'output enable' of UART level shifter or something else which needs some settling. Have you tried adding some delay in between setting this pin and activating the serial port output pins? Did you investigate the PCB? Which device is directly behind the DB9 connector? Can you find a datasheet for that device and check if it has some power saving features? Can you check if these power saving features switched with the PC9? Did taskit respond to your request for detailed information?
Another possible reason can be the fact that you enable the output pins after serial port is enabled (serial_init runs way before board_init). Therefore your output is put into the TX register but I don't know what happens then. Eventually the output is delayed until the output pins are enabled in conjunction with the 'SYS' clock. Maybe the TX logic is happily shifting the bits into nirvana until you switch on the output pins. In conjunction with the PC9 thing this could be your problem.
best regards
Andreas Bießmann
On Tue, Aug 14, 2012 at 02:03:55PM +0200, Andreas Bießmann wrote:
On 14.08.2012 11:08, Markus Hubig wrote:
On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
On 27.07.12 11:16, Markus Hubig wrote:
<snipp>
Has anyone an ideea how to fix this? Or what's the cause of it? Is it even related to u-boot or is it something at91bootstrap is doing wrong?
can you please check http://patchwork.ozlabs.org/patch/107896/
It seems this patch was set to 'Accepted' but never applied to the master repository. Unfortunately this got lost in nirvana end of last year. I will apply it in any case but can you please check if it fixes your problem?
Unfortunately not ... but it dosen't do any harm.
How sad!
I wonder if this has something to do with the ominous PC9. It is possible that this PC9 switches some vital element e.g. power supply, 'output enable' of UART level shifter or something else which needs some settling. Have you tried adding some delay in between setting this pin and activating the serial port output pins?
Hmm no, good idea. I tryed this in board_early_init_f(), but again with no console output at all ...
| int board_early_init_f(void) | { | struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC; | | /* Enable clocks for all PIOs */ | writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) | | (1 << ATMEL_ID_PIOC), &pmc->pcer); | | /* Enable the serial interface */ | at91_set_gpio_output(AT91_PIN_PC9, 1); | mdelay(1000); | at91_seriald_hw_init(); | | return 0; | }
Did you investigate the PCB? Which device is directly behind the DB9 connector? Can you find a datasheet for that device and check if it has some power saving features? Can you check if these power saving features switched with the PC9? Did taskit respond to your request for detailed information?
Problem is, I don't have the circuit diagrams and taskit didn't respond yet ...
Another possible reason can be the fact that you enable the output pins after serial port is enabled (serial_init runs way before board_init).
This is what I think too! But board_early_init_f() is called befor serial_init() so this would be the place to put this, but I don't unterstand why the
| at91_set_gpio_output(AT91_PIN_PC9, 1);
command is not working in board_early_init_f() ...
I even put this into serial_init() but again with no luck ...
Therefore your output is put into the TX register but I don't know what happens then. Eventually the output is delayed until the output pins are enabled in conjunction with the 'SYS' clock. Maybe the TX logic is happily shifting the bits into nirvana until you switch on the output pins. In conjunction with the PC9 thing this could be your problem.
I'll wait what taskit says, maybe this will shine some light on this issue.
Cheers, Markus
Dear Markus Hubig,
On 14.08.2012 17:11, Markus Hubig wrote:
On Tue, Aug 14, 2012 at 02:03:55PM +0200, Andreas Bießmann wrote:
On 14.08.2012 11:08, Markus Hubig wrote:
On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
On 27.07.12 11:16, Markus Hubig wrote:
<snipp>
Has anyone an ideea how to fix this? Or what's the cause of it? Is it even related to u-boot or is it something at91bootstrap is doing wrong?
can you please check http://patchwork.ozlabs.org/patch/107896/
It seems this patch was set to 'Accepted' but never applied to the master repository. Unfortunately this got lost in nirvana end of last year. I will apply it in any case but can you please check if it fixes your problem?
Unfortunately not ... but it dosen't do any harm.
How sad!
I wonder if this has something to do with the ominous PC9. It is possible that this PC9 switches some vital element e.g. power supply, 'output enable' of UART level shifter or something else which needs some settling. Have you tried adding some delay in between setting this pin and activating the serial port output pins?
Hmm no, good idea. I tryed this in board_early_init_f(), but again with no console output at all ...
| int board_early_init_f(void) | { | struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC; | | /* Enable clocks for all PIOs */ | writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) | | (1 << ATMEL_ID_PIOC), &pmc->pcer); | | /* Enable the serial interface */ | at91_set_gpio_output(AT91_PIN_PC9, 1); | mdelay(1000); | at91_seriald_hw_init(); | | return 0; | }
Can you just test the delay in board_init()? I think it should remove the wired characters.
Did you investigate the PCB? Which device is directly behind the DB9 connector? Can you find a datasheet for that device and check if it has some power saving features? Can you check if these power saving features switched with the PC9? Did taskit respond to your request for detailed information?
Problem is, I don't have the circuit diagrams and taskit didn't respond yet ...
Another possible reason can be the fact that you enable the output pins after serial port is enabled (serial_init runs way before board_init).
This is what I think too! But board_early_init_f() is called befor serial_init() so this would be the place to put this, but I don't unterstand why the
| at91_set_gpio_output(AT91_PIN_PC9, 1);
command is not working in board_early_init_f() ...
This works for me: ---8<--- --- a/board/atmel/at91sam9263ek/at91sam9263ek.c +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c @@ -254,6 +254,14 @@ int board_early_init_f(void) (1 << ATMEL_ID_PIOCDE), &pmc->pcer);
+ at91_set_gpio_output(AT91_PIN_PB28, 0); + mdelay(10); + at91_set_gpio_output(AT91_PIN_PB28, 1); + mdelay(10); + at91_set_gpio_output(AT91_PIN_PB28, 0); + mdelay(10); + at91_set_gpio_output(AT91_PIN_PB28, 1); + at91_seriald_hw_init(); return 0; } --->8---
I can see pin toggling, unfortunately not the correct timing (~38 us instead of 10 ms; have to have a look for that). However the PB28 stays high after leaving board_early_init_f().
Another possibility: Your switching of PC9 in board_early_init_f works correctly but needs some settling. Due to the defective mdelay() in board_early_init_f() you will just see nothing cause it was toggled out after your level shifter was ready. Have you tried pressing <Return> after boot in your terminal when you tested the at91_seriald_hw_init() in board_early_init_f()?
I even put this into serial_init() but again with no luck ...
Therefore your output is put into the TX register but I don't know what happens then. Eventually the output is delayed until the output pins are enabled in conjunction with the 'SYS' clock. Maybe the TX logic is happily shifting the bits into nirvana until you switch on the output pins. In conjunction with the PC9 thing this could be your problem.
I'll wait what taskit says, maybe this will shine some light on this issue.
BTW: have you seen this patch http://patchwork.ozlabs.org/patch/71772/ before?
Best regards
Andreas Bießmann
PS: mdelay relies on __udelay() which needs the timer running, but the timer is started after board_early_init_f!
participants (3)
-
Andreas Bießmann -
Jerry Van Baren -
Markus Hubig