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,
Quoted 34 lines · Markus Hubig
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 | ...
Quoted 1 line
Has anyone an idea how to fix this?
No. :-)
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 1 line
Cheers, Markus
Good luck, and let us know what you learn,
gvb
Quoted 33 lines · Jerry Van Baren
Quoted 32 lines · Markus Hubig
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 | ...
Quoted 3 lines
Quoted 1 line
Has anyone an idea how to fix this?
No. :-)
Damn! :-)
Quoted 8 lines
Quoted 1 line
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.
Quoted 2 lines
Is it even related to u-boot or is it something at91bootstrap is doing wrong?
Quoted 8 lines
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.
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.
Quoted 5 lines
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.
Quoted 4 lines
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?
Quoted 10 lines
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
Quoted 33 lines · Markus Hubig
Quoted 32 lines · Jerry Van Baren
Quoted 31 lines · Markus Hubig
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]
Quoted 11 lines
Quoted 5 lines
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. :-/
Quoted 7 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 1 line
Cheers, Markus
Good luck on the thesis,
gvb
Quoted 13 lines · Jerry Van Baren
Quoted 12 lines · Markus Hubig
Quoted 7 lines · Jerry Van Baren
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 30 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 11 lines
Quoted 10 lines
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.
Quoted 8 lines
Quoted 3 lines
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,
Quoted 34 lines · Markus Hubig
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 | ...
Quoted 2 lines
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
Quoted 5 lines · Andreas Bie?mann
Quoted 4 lines · Markus Hubig
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.
Quoted 12 lines
Quoted 4 lines
| H?NAND: 128 MiB | *** Warning - bad CRC, using default environment | | In: serialQuoted 8 lines
| 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>
Quoted 10 lines
Quoted 3 lines
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,
Quoted 25 lines · Markus Hubig
Quoted 5 lines · Andreas Bie?mann
Quoted 4 lines · Markus Hubig
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.
Quoted 12 lines
Quoted 4 lines
| H?NAND: 128 MiB | *** Warning - bad CRC, using default environment | | In: serialQuoted 8 lines
| 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>
Quoted 4 lines
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
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
Quoted 3 lines · Andreas Bie?mann
Quoted 2 lines · Markus Hubig
Quoted 1 line · Andreas Bie?mann
On 27.07.12 11:16, Markus Hubig wrote:
<snipp>
Quoted 12 lines
Quoted 11 lines
Quoted 9 lines
Quoted 2 lines
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.
Quoted 7 lines
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;
| }Quoted 5 lines
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 ...
Quoted 2 lines
Another possible reason can be the fact that you enable the output pins after serial port is enabled (
serial_initruns way beforeboard_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 ...
Quoted 5 lines
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,
Quoted 30 lines · Markus Hubig
Quoted 3 lines · Andreas Bie?mann
Quoted 2 lines · Markus Hubig
Quoted 1 line · Andreas Bie?mann
On 27.07.12 11:16, Markus Hubig wrote:
<snipp>
Quoted 12 lines
Quoted 11 lines
Quoted 9 lines
Quoted 2 lines
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.
Quoted 7 lines
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 ...
Quoted 15 lines
| 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.
Quoted 12 lines
Quoted 5 lines
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 ...
Quoted 2 lines
Another possible reason can be the fact that you enable the output pins after serial port is enabled (
serial_initruns way beforeboard_init).
Quoted 7 lines
This is what I think too! But
board_early_init_f()is called beforserial_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<---
board/atmel/at91sam9263ek/at91sam9263ek.c +8 -0
@@ -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()?
Quoted 9 lines
I even put this into
serial_init()but again with no luck ...Quoted 5 lines
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!
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Markus,
Quoted 43 lines · Markus Hubig
Dear Andreas,
Quoted 5 lines · Andreas Bie?mann
Quoted 4 lines · Markus Hubig
Quoted 3 lines · Andreas Bie?mann
Quoted 2 lines · Markus Hubig
Quoted 1 line · Andreas Bie?mann
On 27.07.12 11:16, Markus Hubig wrote:
<snip>
Quoted 16 lines
Quoted 7 lines
| 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);Quoted 8 lines
| | /* Enable the serial interface */ | at91_set_gpio_output(AT91_PIN_PC9, 1); | mdelay(1000); | at91_seriald_hw_init(); | | return 0; | }Quoted 2 lines
Can you just test the delay in
board_init()? I think it should remove the wired characters.Yes, the strange chars are gone with a small delay after enabling PC9!
| --- a/board/taskit/stamp9g20/stamp9g20.c | +++ b/board/taskit/stamp9g20/stamp9g20.c | @@ -166,6 +166,7 @@ int board_init(void) | | /* Enable the serial interface */ | at91_set_gpio_output(AT91_PIN_PC9, 1); | + mdelay(1); | at91_seriald_hw_init(); | | stamp9G20_nand_hw_init();
Quoted 3 lines
And now the output correctly shows "NAND: ..." as the first message course
stamp9G20_nand_hw_init()is the first funktion that writes something to the serial line after it is enabled.
great!
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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?
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Problem is, I don't have the circuit diagrams and taskit didn't respond yet ...
OK now I got an responce from taskit. PC9 enables the level converter of the RS232 interface. The level converter is a TI MAX3243I. And PC9 is connected to ~FORCEOFF. So in order to get the serial line working PC9 has to be high.
Ok, as I thought ...
Quoted 32 lines
Quoted 32 lines
Quoted 10 lines
Quoted 2 lines
Another possible reason can be the fact that you enable the output pins after serial port is enabled (
serial_initruns way beforeboard_init).This is what I think too! But
board_early_init_f()is called beforserial_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<---board/atmel/at91sam9263ek/at91sam9263ek.c +8
-1@@ -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---
Quoted 7 lines
Quoted 3 lines
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().But it definitly dosn't work here. I checked with an oscilator, if I toggle the pin in
board_init()I can nicely see it going high and low but if I toggle it inboard_early_init_f()*nothing* happens!
Well as mentioned in my mail the mdelay() can not work in board_eraly_init_f() cause the timers are not setup at this stage. You need to provide some nop-loop based delay here to have proper delay! As mentioned before my at91sam9263 (running at about 200 MHz produce 38 us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz produces here). A simple test could be to move the timer init in a/a/lib/board.c before board_early_init_f in the init_sequence. Then the mdelay() will work as expected!
Quoted 4 lines
This seems to be the real problem ... for some reason a can *not* toggle gpio pins in
board_early_init_f()! I also double checked this with a LED pin. I bet there is something I need to enable earlier to get theat91_set_gpio_output()command working inboard_early_init_f()...
Have you tried pulling the pin low in board_early_init_f and pull it high later on in e.g. board_init?
Quoted 8 lines
Quoted 6 lines
Another possibility: Your switching of PC9 in
board_early_init_fworks correctly but needs some settling. Due to the defectivemdelay()inboard_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 theat91_seriald_hw_init()inboard_early_init_f()?Yes but this dosn't work either ...
damn ...
Quoted 11 lines
Quoted 7 lines
Quoted 7 lines
I even put this into
serial_init()but again with no luck ...Quoted 5 lines
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 have a look how stuff is done in
board_early_init_f()in other boards, maybe I find a hint what to do to enable the use ob PIO pins there ...
Quoted 6 lines
Quoted 2 lines
BTW: have you seen this patch http://patchwork.ozlabs.org/patch/71772/
before?Not exactly this one, when I first started to work on the patch I got an old (~2 years) one from taskit ... Damn! Here the PC5 and PC9 pins are nicly named ;(
send a patch (including working serial console output ;)
Best regards
Andreas Bie?mann
Hi Andreas,
Quoted 1 line · Andreas Bie?mann
On 16.08.2012 17:07, Markus Hubig wrote:
<snip>
Quoted 4 lines
Quoted 3 lines
But it definitly dosn't work here. I checked with an oscilator, if I toggle the pin in
board_init()I can nicely see it going high and low but if I toggle it inboard_early_init_f()*nothing* happens!
Quoted 8 lines
Well as mentioned in my mail the
mdelay()can not work inboard_eraly_init_f()cause the timers are not setup at this stage. You need to provide some nop-loop based delay here to have proper delay! As mentioned before my at91sam9263 (running at about 200 MHz produce 38 us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz produces here). A simple test could be to move the timer init ina/a/lib/board.cbeforeboard_early_init_fin theinit_sequence. Then themdelay()will work as expected!
You were right! The problem was the missing delay after setting the pin! Just moving the timer_init() before board_early_init_f() in the init_sequence didn't work because we need the clocks from board_early_init_f() first. But I found the
| board_postclk_init()
function and the corresponding
| CONFIG_BOARD_POSTCLK_INIT
switch, so I put everything there and now it all works fine! ;-)
Quoted 1 line
send a patch (including working serial console output ;)
Unfortunately the board_postclk_init() function was not in the init_sequence at arch/arm/lib/board.c so I added it there. I will provide two patches, one for the board stuff and one for the stamp stuff, if this is OK with you ...
Cheers, Markus
Signature · 1 line
Human beings were created by water to transport it uphill.
Quoted 25 lines · Markus Hubig
Hi Andreas,
Quoted 1 line · Andreas Bie?mann
On 16.08.2012 17:07, Markus Hubig wrote:
<snip>
Quoted 4 lines
Quoted 3 lines
But it definitly dosn't work here. I checked with an oscilator, if I toggle the pin in
board_init()I can nicely see it going high and low but if I toggle it inboard_early_init_f()*nothing* happens!Quoted 8 lines
Well as mentioned in my mail the
mdelay()can not work inboard_eraly_init_f()cause the timers are not setup at this stage. You need to provide some nop-loop based delay here to have proper delay! As mentioned before my at91sam9263 (running at about 200 MHz produce 38 us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz produces here). A simple test could be to move the timer init ina/a/lib/board.cbeforeboard_early_init_fin theinit_sequence. Then themdelay()will work as expected!You were right! The problem was the missing delay after setting the pin! Just moving the
timer_init()beforeboard_early_init_f()in theinit_sequencedidn't work because we need the clocks fromboard_early_init_f()first. But I found the
Quoted 7 lines
|
board_postclk_init()function and the corresponding
|
CONFIG_BOARD_POSTCLK_INITswitch, so I put everything there and now it all works fine! ;-)
great!
Quoted 5 lines
Quoted 1 line
send a patch (including working serial console output ;)
Unfortunately the
board_postclk_init()function was not in theinit_sequenceatarch/arm/lib/board.cso I added it there. I will provide two patches, one for the board stuff and one for the stamp stuff, if this is OK with you ...
I think adding the postclock stuff to arm is ok. Albert is responsible for that so if he is willing to accept that the stamp9g20 stuff is no problem.
Best regards
Andreas Bie?mann