[U-Boot] Strange / Unreadable console output

[U-Boot] Strange / Unreadable console output

[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
| ...

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

[U-Boot] Strange / Unreadable console output

[Jerry Van Baren]

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

[U-Boot] Strange / Unreadable console output

[Markus Hubig]

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

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

> 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

[U-Boot] Strange / Unreadable console output

[Jerry Van Baren]

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]

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

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

[U-Boot] Strange / Unreadable console output

[Andreas Bießmann]

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

[U-Boot] Strange / Unreadable console output

[Markus Hubig]

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

[U-Boot] Strange / Unreadable console output

[Markus Hubig]

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] Strange / Unreadable console output

[Andreas Bießmann]

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

[U-Boot] Strange / Unreadable console output

[Markus Hubig]

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

[U-Boot] Strange / Unreadable console output

[Andreas Bießmann]

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!

[U-Boot] Strange / Unreadable console output

[Andreas Bießmann]

Hi Markus,

On 16.08.2012 17:07, Markus Hubig wrote:
> Dear Andreas,
> 
> On Wed, Aug 15, 2012 at 12:55 PM, Andreas Bie?mann wrote:
>> 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:
> 
> <snip>
> 
>>> | 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.
> 
> 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();
> 
> 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!

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

>>>> 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().
> 
> 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 in board_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!

> 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 the at91_set_gpio_output()
> command working in board_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?

>> 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()?
> 
> Yes but this dosn't work either ...

damn ...

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

[U-Boot] [SOLVED] Strange / Unreadable console output

[Markus Hubig]

Hi Andreas,

On Thu, Aug 16, 2012 at 05:33:26PM +0200, Andreas Bie?mann wrote:
> On 16.08.2012 17:07, Markus Hubig wrote:

<snip>

> > 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 in board_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!

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! ;-)  

> 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

-- 
Human beings were created by water to transport it uphill.

[U-Boot] [SOLVED] Strange / Unreadable console output

[Andreas Bießmann]

On 16.08.2012 18:51, Markus Hubig wrote:
> Hi Andreas,
> 
> On Thu, Aug 16, 2012 at 05:33:26PM +0200, Andreas Bie?mann wrote:
>> On 16.08.2012 17:07, Markus Hubig wrote:
> 
> <snip>
> 
>>> 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 in board_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!
> 
> 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! ;-)  

great!

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

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