[U-Boot] Strange data behaviour

[U-Boot] Strange data behaviour

[Remco Poelstra]

Hi,

I'm trying to get my LPC2468 based board to work. I've some problems 
with the external memory databus.
I would like to know the settings of internal registers to see whether 
I've initialized them correctly, so I tried making a function that 
prints the content over the serial link. I'm still in the lowlevel_init 
function, so I do not have the U-boot puts functions available.
I wrote the following function to convert a long to a HEX string:
-------------------
void print_long(unsigned long data) {
   char i;
   char 
hex_data[]={'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'};

   for(i=0; i<8; i++) {
     while((U0LSR & (1<<5)) == 0); /* Wait for empty U0THR */
//    U0THR = hex_data[(0xDEADBEEF>>i*4)&0xF];
     U0THR = hex_data[(0xDEADBEEF>>4)&0xF];
   }
}
---------------
When I run it likes this I get 8 E's. Which is what I expect. When I run 
it with the commented-out line, I get back 8 0x0's. So it seems that the 
output is only correct when it is constant.
Does anyone have a clue on why that is?

Kind regards,

Remco Poelstra

[U-Boot] Strange data behaviour

[Wolfgang Denk]

Dear Remco Poelstra,

In message <499AA5B8.7030805@duran-audio.com> you wrote:
> 
> I'm trying to get my LPC2468 based board to work. I've some problems 
> with the external memory databus.
> I would like to know the settings of internal registers to see whether 
> I've initialized them correctly, so I tried making a function that 
> prints the content over the serial link. I'm still in the lowlevel_init 
> function, so I do not have the U-boot puts functions available.
> I wrote the following function to convert a long to a HEX string:
> -------------------
> void print_long(unsigned long data) {
>    char i;
>    char 
> hex_data[]={'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'};
> 
>    for(i=0; i<8; i++) {
>      while((U0LSR & (1<<5)) == 0); /* Wait for empty U0THR */
> //    U0THR = hex_data[(0xDEADBEEF>>i*4)&0xF];

For clearity of the code I would write that as "...>>(i*4)...", but
that's not relevant here.

>      U0THR = hex_data[(0xDEADBEEF>>4)&0xF];
>    }
> }
> ---------------
> When I run it likes this I get 8 E's. Which is what I expect. When I run 
> it with the commented-out line, I get back 8 0x0's. So it seems that the 
> output is only correct when it is constant.
> Does anyone have a clue on why that is?

What exactly is U0THR ? 

The only definition I can find in the U-Boot sources is here:

include/asm-arm/arch-lpc2292/lpc2292_registers.h:#define U0THR 0xE000C000

but that is obviously not what you are using.

You probably forget the effects of compiler optimization and/or
caching here.


I bet you are using a plain  pointer  access  without  a  "volatile",
which is essential here. Maybe even some form of "sync" is needed. In
any  case,  you  should  use appropriate accessor functions to access
device registers.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never call a man a fool.  Borrow from him.

[U-Boot] Strange data behaviour

[Remco Poelstra]

Wolfgang Denk schreef:
>>      U0THR = hex_data[(0xDEADBEEF>>4)&0xF];
>>    }
>> }
>> ---------------
>> When I run it likes this I get 8 E's. Which is what I expect. When I run 
>> it with the commented-out line, I get back 8 0x0's. So it seems that the 
>> output is only correct when it is constant.
>> Does anyone have a clue on why that is?
> 
> What exactly is U0THR ? 

Hi,

Thanks for your reply.

For my processor, U0THR is defnied as:
#define U0THR          (*(volatile unsigned char *)(UART0_BASE_ADDR + 
0x00))

UART0_BASE_ADDR is equal to 0xE000C000

The register itself represents the top of the UART0 transmit FIFO.

> 
> The only definition I can find in the U-Boot sources is here:
> 
> include/asm-arm/arch-lpc2292/lpc2292_registers.h:#define U0THR 0xE000C000
> 
> but that is obviously not what you are using.
> 
> You probably forget the effects of compiler optimization and/or
> caching here.
> 
> 
> I bet you are using a plain  pointer  access  without  a  "volatile",
> which is essential here. Maybe even some form of "sync" is needed. In
> any  case,  you  should  use appropriate accessor functions to access
> device registers.

I do not know any accessor functions.
What do you mean with a "sync"?

Kind regards,

Remco Poelstra

[U-Boot] Strange data behaviour

[Kim Phillips]

On Wed, 18 Feb 2009 09:19:08 +0100
Remco Poelstra <remco.poelstra@duran-audio.com> wrote:

> Wolfgang Denk schreef:
> > I bet you are using a plain  pointer  access  without  a  "volatile",
> > which is essential here. Maybe even some form of "sync" is needed. In
> > any  case,  you  should  use appropriate accessor functions to access
> > device registers.
> 
> I do not know any accessor functions.

things like out_be32 (at least that's what it's called on ppc arch).

> What do you mean with a "sync"?

it's a processor instruction that ensures that memory and/or i/o
accesses occur exactly when you specify they occur.  For this reason, a
sync instruction is included as a part of the accessor functions.

Kim