From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] packed attribute problem
Date: Mon, 04 Oct 2010 12:56:26 +0200 [thread overview]
Message-ID: <4CA9B2DA.6030407@emk-elektronik.de> (raw)
In-Reply-To: <20101004104443.09AE41539A0@gemini.denx.de>
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?
>
> 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?
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).
Best Regards,
Reinhard
next prev parent reply other threads:[~2010-10-04 10:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 9:38 [U-Boot] packed attribute problem Vipin Kumar
2010-10-04 10:17 ` Wolfgang Denk
2010-10-04 10:30 ` Vipin Kumar
2010-10-04 10:44 ` Wolfgang Denk
2010-10-04 10:56 ` Reinhard Meyer [this message]
2010-10-04 11:01 ` Vipin Kumar
2010-10-04 11:46 ` Reinhard Meyer
2010-10-04 12:29 ` Wolfgang Denk
2010-10-04 12:43 ` Reinhard Meyer
2010-10-04 12:50 ` Balau
2010-10-04 12:58 ` Wolfgang Denk
2010-10-04 13:02 ` [U-Boot] DDR SPD table sywang
2010-10-04 15:56 ` Mike Frysinger
2010-10-04 12:56 ` [U-Boot] packed attribute problem Wolfgang Denk
2010-10-05 3:45 ` Vipin Kumar
2010-10-05 11:43 ` Detlev Zundel
2010-10-05 18:03 ` Scott Wood
2010-10-07 9:59 ` Detlev Zundel
2010-10-07 16:46 ` Scott Wood
2010-10-07 17:57 ` Wolfgang Denk
2010-10-07 18:52 ` Scott Wood
2010-10-07 19:31 ` Wolfgang Denk
2010-10-07 20:15 ` Scott Wood
2010-10-11 11:32 ` Detlev Zundel
2010-10-11 13:22 ` Balau
2010-10-04 10:57 ` Vipin Kumar
2010-10-04 12:04 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CA9B2DA.6030407@emk-elektronik.de \
--to=u-boot@emk-elektronik.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox