From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tetsuyuki Kobayashi Date: Tue, 03 Jul 2012 16:10:32 +0900 Subject: [U-Boot] [PATCH] arm: armv7: add compile option -mno-unaligned-access if available In-Reply-To: References: <1338918451-10126-1-git-send-email-dev@lynxeye.de> <4FCE52FB.3020501@wwwdotorg.org> <1338923180.1377.2.camel@tellur> <20120622111501.21e1fdcc@aari01-12> <4FEA21F5.4080803@gmail.com> <4FEADD13.2040708@kmckk.co.jp> <4FF16CF2.9090808@kmckk.co.jp> <1341242168.1392.2.camel@tellur> Message-ID: <4FF29AE8.5080103@kmckk.co.jp> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello, M?ns Thank you for summarizing. I am not against you. I'm OK either "Allow unaligned access in U-Boot setting" or "Specify compiler not to generate unaligned memory access" or other. I just want to solve hung-up by unaligned access. I follow custodian's decision. (2012/07/03 1:14), M?ns Rullg?rd wrote: > Lucas Stach writes: > >> Am Montag, den 02.07.2012, 10:53 +0100 schrieb M?ns Rullg?rd: >>> Tetsuyuki Kobayashi writes: >>> >>>> Recent compiler generates unaligned memory access in armv7 default. >>>> But current U-Boot does not allow unaligned memory access, so it causes >>>> data abort exception. >>>> This patch add compile option "-mno-unaligned-access" if it is available. >>> >>> Why not allow unaligned accesses instead? >>> >> IMHO, our recent discussion showed that both ways are wrong. >> "-mno-unaligned-access" works around misaligned data on the software >> level, while allowing unaligned access does on the hardware level. >> >> What we really want is no unaligned access in U-Boot at all. Just >> because "-mno-unaligned-access" is the default on ARMv5, we should not >> consider it a gold standard. > > It's slightly more complicated than that. Data can be misaligned for a > variety of reasons: > > 1. Errors in software. > 2. Specified by a file format or communication protocol. > 3. Deliberately misaligned by the compiler. > > Misaligned data of type 1 should of course be fixed properly, not worked > around in any way. > > Type 2 happens all the time, and has to be dealt with one way or > another. If the hardware supports unaligned accesses, this is usually > faster than reading a byte at a time. > > When targeting ARMv6 and later, recent gcc versions have started issuing > deliberate unaligned accesses where previously byte by byte accesses > would have been done. This happens with "packed" structs and sometimes > to write multiple smaller values at once, typically when > zero-initialising things. These unaligned accesses are *good*. They > make code smaller and faster. > > The real problem here is that u-boot is setting the strict alignment > checking flag, invalidating the assumption of the compiler that the > system allows unaligned accesses. For ARMv5 and earlier, setting this > flag is usually advisable since it makes finding accidental unaligned > accesses much easier. > > This was debated in the context of the kernel a while ago, ultimately > leading to strict alignment being disabled for ARMv6 and up [1]. > > [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8428e84d42179c2a00f5f6450866e70d802d1d05 >