[U-Boot-Users] PXA270 board startup: printf does not work

[U-Boot-Users] PXA270 board startup: printf does not work

[JP]

Starting up a new board with a PXA270, the console output from
printf calls in board.c contains garbage, whereas puts works fine.
It appears the vsprintf call in printf works correctly, but printf's
local char buffer has a few alternate correct characters at its
very beginning followed by junk.

Everything else seems to work correctly: this SDRAM area can be written 
to with a debugger.   But test functions (similar to printf) that copy a
string parameter to a local buffer and then call puts also produce garbage.

Buffers initialized (i.e., char t [12] = "Testing...";) in these 
functions will print (with puts) ONLY if their size is <= 32.  Their 
contents become garbage when other data are copied to them, regardless 
of size.

I haven't yet tried to start a ramdisk or image; without correct output
from printf or the debug () macro it would be futile.

Thanks for any ideas.

JP

[U-Boot-Users] PXA270 board startup: printf does not work

[Jerry Van Baren]

JP wrote:
> Starting up a new board with a PXA270, the console output from
> printf calls in board.c contains garbage, whereas puts works fine.
> It appears the vsprintf call in printf works correctly, but printf's
> local char buffer has a few alternate correct characters at its
> very beginning followed by junk.
> 
> Everything else seems to work correctly: this SDRAM area can be written 
> to with a debugger.   But test functions (similar to printf) that copy a
> string parameter to a local buffer and then call puts also produce garbage.
> 
> Buffers initialized (i.e., char t [12] = "Testing...";) in these 
> functions will print (with puts) ONLY if their size is <= 32.  Their 
> contents become garbage when other data are copied to them, regardless 
> of size.
> 
> I haven't yet tried to start a ramdisk or image; without correct output
> from printf or the debug () macro it would be futile.
> 
> Thanks for any ideas.
> 
> JP

Hi JP,

Your talk about having a corrupted local char buffer confused me.  If it 
were not for that detail, I would have been positive that you have a 
problem with handling your UART's Tx busy flag.

Your symptoms are typical of not waiting for the UART to complete 
transmitting a character before stuffing the next one in once the UART 
FIFO is full.  The result is that, if the string has fewer than /n/ 
characters (/n/ being the depth of the UART's Tx FIFO, possibly a few 
more), it works OK.  If the string is longer than /n/, it gets corrupted 
by your s/w overwriting characters in the UART.  Depending on the UART 
implementation, this could include the one currently being shifted out, 
resulting in garbage characters.

What in your processor is 32 bytes long?  UART FIFO?  Cache line? 
Hmmmm, could you be having cache consistency problems?  Cache problems 
would be consistent with garbage in memory.

BIG WARNING NOTE: Writing memory with a debugger is typically very 
benign (s.l.o.w.) compared to writing with the processor.  Writing 
single memory locations with the processor is typically benign compared 
to a cache line burst read/write.  SDRAM (including DDR/DDR2) 
initialization problems typically do *not* show up until cache is 
enabled because it is the burst read/write that violates the "S" in 
SDRAM (you end up out of sync "synchronous").
FAQ: <http://www.denx.de/wiki/DULG/SDRAM>

Good luck,
gvb

[U-Boot-Users] PXA270 board startup: printf does not work

[JP]

Jerry Van Baren wrote:
> 
> Your talk about having a corrupted local char buffer confused me.  If it 
> were not for that detail, I would have been positive that you have a 
> problem with handling your UART's Tx busy flag.
> 
> Your symptoms are typical of not waiting for the UART to complete 
> transmitting a character before stuffing the next one in once the UART 
> FIFO is full.  The result is that, if the string has fewer than /n/ 
> characters (/n/ being the depth of the UART's Tx FIFO, possibly a few 
> more), it works OK.  If the string is longer than /n/, it gets corrupted 
> by your s/w overwriting characters in the UART.  Depending on the UART 
> implementation, this could include the one currently being shifted out, 
> resulting in garbage characters.

A very long (already initialized) string prints correctly with puts, so 
I suspect the FIFO implementation is OK.   We're using the FFUART.
> 
> What in your processor is 32 bytes long?  UART FIFO?  Cache line? Hmmmm, 
> could you be having cache consistency problems?  Cache problems would be 
> consistent with garbage in memory.
> 
> BIG WARNING NOTE: Writing memory with a debugger is typically very 
> benign (s.l.o.w.) compared to writing with the processor.  Writing 
> single memory locations with the processor is typically benign compared 
> to a cache line burst read/write.  SDRAM (including DDR/DDR2) 
> initialization problems typically do *not* show up until cache is 
> enabled because it is the burst read/write that violates the "S" in 
> SDRAM (you end up out of sync "synchronous").
> FAQ: <http://www.denx.de/wiki/DULG/SDRAM>

Thanks for those ideas.  We haven't found many examples to compare our 
configuration to, but we did have trouble initially getting the SDRAM 
startup sequence working.  Your description and the wiki entry describe 
what could be happening.

JP

[U-Boot-Users] PXA270 board startup: printf does not work

[JP]

JP wrote:
> Jerry Van Baren wrote:
>> Your talk about having a corrupted local char buffer confused me.  If it 
>> were not for that detail, I would have been positive that you have a 
>> problem with handling your UART's Tx busy flag.
>>
>> Your symptoms are typical of not waiting for the UART to complete 
>> transmitting a character before stuffing the next one in once the UART 
>> FIFO is full.  The result is that, if the string has fewer than /n/ 
>> characters (/n/ being the depth of the UART's Tx FIFO, possibly a few 
>> more), it works OK.  If the string is longer than /n/, it gets corrupted 
>> by your s/w overwriting characters in the UART.  Depending on the UART 
>> implementation, this could include the one currently being shifted out, 
>> resulting in garbage characters.
> 
> A very long (already initialized) string prints correctly with puts, so 
> I suspect the FIFO implementation is OK.   We're using the FFUART.
>> What in your processor is 32 bytes long?  UART FIFO?  Cache line? Hmmmm, 
>> could you be having cache consistency problems?  Cache problems would be 
>> consistent with garbage in memory.
>>
>> BIG WARNING NOTE: Writing memory with a debugger is typically very 
>> benign (s.l.o.w.) compared to writing with the processor.  Writing 
>> single memory locations with the processor is typically benign compared 
>> to a cache line burst read/write.  SDRAM (including DDR/DDR2) 
>> initialization problems typically do *not* show up until cache is 
>> enabled because it is the burst read/write that violates the "S" in 
>> SDRAM (you end up out of sync "synchronous").
>> FAQ: <http://www.denx.de/wiki/DULG/SDRAM>
> 
> Thanks for those ideas.  We haven't found many examples to compare our 
> configuration to, but we did have trouble initially getting the SDRAM 
> startup sequence working.  Your description and the wiki entry describe 
> what could be happening.
> 
> JP
This turned out to be a hardware problem: the DQM 0/1 lines that select 
8 bits of a 32 bit location were reversed.

[U-Boot-Users] PXA270 board startup: printf does not work

[Jerry Van Baren]

JP wrote:

[snip]

>> JP
> This turned out to be a hardware problem: the DQM 0/1 lines that select 
> 8 bits of a 32 bit location were reversed.

Hi JP,

Thanks for letting the list know what the problem and resolution was. 
It is very important to close the loop.  Too many people never post the 
final answer to what their problem is.  This is unfortunate because it 
lets us guessers guess better next time and it gives others the ability 
to look over *real* answers when they google for their similar problems.

Thanks again,
gvb