From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vipin Kumar <vipin.kumar@st.com>
Date: Mon, 4 Oct 2010 16:31:03 +0530
Subject: [U-Boot] packed attribute problem
In-Reply-To: <4CA9B2DA.6030407@emk-elektronik.de>
References: <4CA9A095.9000900@st.com>	<20101004101714.A19931539A0@gemini.denx.de>	<4CA9ACAA.2020001@st.com>
	<20101004104443.09AE41539A0@gemini.denx.de>
	<4CA9B2DA.6030407@emk-elektronik.de>
Message-ID: <4CA9B3EF.7000704@st.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

On 10/4/2010 4:26 PM, Reinhard Meyer wrote:
> Dear Wolfgang Denk, Vipin Kumar,
>>
>> In message <4CA9ACAA.2020001@st.com> you wrote:
>>>>> This writel results in writing byte by byte on the address pointed to by status_reg.
>>>>> This problem is visible with both gcc version 4.4.1 as well as 4.5.0
>>>> I bet this is on some ARM system?
>>> Yes, it is on an ARM system (CortexA9). But I still feel that since I am creating 
>>> a new u32 * status_reg, the code should not use any intelligence and use the pointer 
>>> only to produce an str instruction in the form
>>> 	str r0, [r1]
>>>
>>> But it retains the packed property of the structure even with a new u32 ponter 
>>> typecasted to u32 *
>>> 	u32 * status_reg = (u32 *)xyz->x;
>>>
>>> A writel to status_reg results in byte by byte writing
> 
> How do you know that? Disassembly? Bus snooping?
> 

Disassembly

>>
>> I agree with you. I always considered such behaviour of the ARM C
>> compiler a bug, and still do.  However, people with better knowledge
>> of the ARm architecture than me might be able to explain why the
>> responsible PTB consider this to be a good and necessary "feature" of
>> th compiler.
> 
> Maybe because writel(v,a) is ultimately defined as
> 
> (*(volatile unsigned int *)(a) = (v))
> 
> and the compiler has to assume the worst, i.e. that (a) is not word
> aligned? Maybe there is a new compiler switch to turn that
> "pessimisation" off?
> 

I agree with you on this. But if I create a new u32 pointer and point to 
an element with in the packed structure, then what should be the behavior ?

> On the other hand, if what you say were true, all code for AT91 that
> uses writel() to access 32 bit only peripheral registers would not
> work with those newer toolchains (still 4.2.4 here).
> 

Yes, if the at91 code is using packed attribute for device structures

Regards
Vipin