From mboxrd@z Thu Jan  1 00:00:00 1970
From: Remco Poelstra <remco.poelstra@duran-audio.com>
Date: Wed, 18 Feb 2009 09:19:08 +0100
Subject: [U-Boot] Strange data behaviour
In-Reply-To: <20090217191211.5C469832E893@gemini.denx.de>
References: <499AA5B8.7030805@duran-audio.com>
	<20090217191211.5C469832E893@gemini.denx.de>
Message-ID: <499BC47C.6060601@duran-audio.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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