From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Date: Mon, 14 Oct 2013 15:48:11 +0200 [thread overview]
Message-ID: <20131014154811.2852096b@lilith> (raw)
In-Reply-To: <yw1x1u3o3svq.fsf@unicorn.mansr.com>
Hi M?ns,
On Mon, 14 Oct 2013 14:05:13 +0100, M?ns Rullg?rd <mans@mansr.com>
wrote:
> Albert ARIBAUD <albert.u.boot@aribaud.net> writes:
>
> >> > Please do not advise using native unaligned accesses on code that is
> >> > not strictly used by ARMv6+ architectures: the present code, for
> >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus,
> >> > should never assume ability to perform unaligned accesses natively.
> >>
> >> I'm advising no such thing. I said two things:
> >>
> >> 1. Declaring a struct with the 'packed' attribute makes gcc
> >> automatically generate correct code for all targets. _IF_ the
> >> selected target supports unaligned ldr/str, these might get used.
> >>
> >> 2. If your target is ARMv6 or later _AND_ you enable strict alignment
> >> checking in the system control register, you _MUST_ build with the
> >> -mno-unaligned-access flag.
> >
> > Then I apologize; I had read "Note that on ARMv6 and later ldr/str
> > support unaligned addresses unless this is explicitly disabled in
> > the system control register" as a suggestion to use that capability.
>
> If building for ARMv6 or later, I do suggest allowing unaligned
> accesses. The moment you add -march=armv6 (or equivalent), you allow
> for a number of things not supported by older versions, so why not
> unaligned memory accesses?
doc/README.arm-unaligned-accesses probably has the answer to your
question, especially from line 21 onward. If not, I'll be happy to
provide further clarification.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2013-10-14 13:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 13:31 [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition Piotr Wilczek
2013-10-11 16:00 ` Albert ARIBAUD
2013-10-11 23:28 ` Måns Rullgård
2013-10-14 8:30 ` Piotr Wilczek
2013-10-14 10:50 ` Måns Rullgård
2013-10-14 11:46 ` Albert ARIBAUD
2013-10-14 12:19 ` Måns Rullgård
2013-10-14 13:00 ` Albert ARIBAUD
2013-10-14 13:05 ` Måns Rullgård
2013-10-14 13:48 ` Albert ARIBAUD [this message]
2013-10-14 14:09 ` Måns Rullgård
2013-10-14 15:18 ` Albert ARIBAUD
2013-10-14 15:59 ` Måns Rullgård
2013-10-14 17:26 ` Albert ARIBAUD
2013-10-15 15:23 ` Måns Rullgård
2013-10-15 16:21 ` Albert ARIBAUD
2013-10-15 16:29 ` Måns Rullgård
2013-10-15 17:07 ` Albert ARIBAUD
2013-10-14 13:49 ` Piotr Wilczek
2013-10-14 14:22 ` Albert ARIBAUD
2014-01-28 12:46 ` [U-Boot] [PATCH V2] " Piotr Wilczek
2014-01-29 21:48 ` Tom Rini
2014-02-19 14:56 ` Hector Palacios
2014-02-19 15:03 ` Tom Rini
2014-02-19 15:23 ` Tom Rini
2014-02-24 15:56 ` Lukasz Majewski
2014-02-24 16:23 ` Tom Rini
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=20131014154811.2852096b@lilith \
--to=albert.u.boot@aribaud.net \
--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