public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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 13:46:28 +0200	[thread overview]
Message-ID: <4CA9BE94.6000401@emk-elektronik.de> (raw)
In-Reply-To: <4CA9B3EF.7000704@st.com>

Dear Vipin Kumar,
>>>> 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 ?

Do you imply that the code is really different when the pointer gets
its value by assigning it NOT to a packed entity? Hard to believe.

My assumptions:
1. it has to do NOTHING with packed attributes, once the pointer is in a
new variable, that "packed" information should be lost. Just try
int *ptr = (int *) 0x10000;
a)   *ptr = 5;
b)   writel (5, ptr);

do a) and b) produce different code?

2. the culprit on ARM is that unaligned accesses do not raise any signal
but silently IGNORE the "unused" adress lines which leads to very
undesirable effects that are hard to find.

*((int *)0x10000) = 5 is the same as *((int *)0x10003) = 5 !
Both write 5 to the word at adress 0x10000 !

So, MAYBE, in newer toolchains it was decided to circumvent that problem
by always assuming unaligned pointers unless clearly instructed otherwise.

> 
>> 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


Nope. It does not have to do with packed. It would have to do with the fact
that I/O registers cannot be safely written byte-wise.

Reinhard

  reply	other threads:[~2010-10-04 11:46 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
2010-10-04 11:01         ` Vipin Kumar
2010-10-04 11:46           ` Reinhard Meyer [this message]
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=4CA9BE94.6000401@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