Hi Alexey,
On 10/16/26 11:58 AM, Alexey Charkov wrote:
Hi Quentin,
On Fri, Oct 16, 2026 at 1:06 PM Quentin Schulz <[email protected]> wrote:
Hi Alexey,
On 10/2/26 12:04 PM, Alexey Charkov wrote:
ARM passes -mstrict-align (-mno-unaligned-access on ARMv7) to everything,
because when the MMU is off any unaligned access there faults. The
compiler then has to assemble every wide unaligned load out of single
bytes: one ldr becomes eight ldrb and seven orr/lsl.
This is especially painful for decompressors which refill their buffer
in 64-bit words. On a Rockchip RK3576 SPL, zstd unpacks a 30MiB Falcon
mode Linux kernel in 1947ms built this way and 596ms without the flag,
and the SPL gets 2.3KiB smaller by cutting down on the byte-wise loads and
ORs. gzip, whose inflate walks its input a byte at a time anyway, gains
6%.
Add ASSUME_UNALIGNED_ACCESS_OK for a platform to state that the MMU is on
by the time it unpacks an image, and let the decompression libraries drop
the flag when it is set. The arch exports the flag it added rather than
lib/ naming it, so this stays correct for anything else which adds one.
No functional change anywhere until the symbol is selected.
Signed-off-by: Alexey Charkov <[email protected]>
---
arch/Kconfig | 35 +++++++++++++++++++++++++++++++++++
arch/arm/cpu/armv7/config.mk | 3 +++
arch/arm/cpu/armv8/config.mk | 3 +++
lib/Makefile | 3 +++
lib/lzma/Makefile | 8 ++++++++
lib/lzo/Makefile | 8 ++++++++
lib/zlib/Makefile | 8 ++++++++
lib/zstd/Makefile | 8 ++++++++
8 files changed, 76 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 8d63afeb138e..606b9d79ecd8 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -27,6 +27,41 @@ config SUPPORT_LITTLE_ENDIAN
bool
default y if !SUPPORT_BIG_ENDIAN
+config ASSUME_UNALIGNED_ACCESS_OK
I only see changes in ARM and ARM64 config.mk, should this (and SPL)
symbol depends on ARM/ARM64 maybe? I see in the second patch you're
adding another dependency on !SPL_SYS_DCACHE_OFF, any reason for it not
to be a dependency in the main symbol in this file here?
Given that it's strictly opt-in by each platform and not
user-selectable, I don't think adding explicit dependencies in the
main symbol helps much. As for !SPL_SYS_DCACHE_OFF, that's
arch-specific. E.g. on ARM/ARM64 unaligned accesses fault by default.
The exception is when both the MMU and D-cache are up and running - in
which case they work just fine. For some other strict-alignment
architecture the set of conditions would probably be different - and I
have no idea about those, so I'd rather leave it to the respective
architecture/platform code owners to assert, not add any direct hints
which may or may not apply to their case.
I guess the point is that this is an invisible symbol and it's up to the
arch/soc maintainers to enable it via a select (so joining you on not
adding the dependencies here).
I know I'm usually against going into implementation details in Kconfig
symbol's helptext, but maybe it'd be nice to give an example for ARM64
on which functions must be called before the code that can make use of
that symbol is called? That could help other architecture maintainers to
decide whether this could be applicable to them as well?
You also missed the -mno-unaligned-access in
arch/arm/cpu/armv7m/config.mk, was this on purpose?
This is very compressor/decompressor-specific, should we rename the
symbol so it's clear only those would/should be impacted by this symbol
(hoping that its usage doesn't get extended in the future).
Compressors and decompressors are the primary beneficiaries and the
only current users enabled by this patch, but the mechanism itself
isn't strictly limited to them. I also hate overly long Kconfig symbol
names, and the current one is already stretching it a bit :)
Fair enough.
+ bool
+ help
+ Assume that an unaligned access cannot fault by the time U-Boot
+ proper unpacks an image, and build the decompression libraries
+ without the architecture's strict-alignment flag on that basis.
+
+ Architectures whose unaligned accesses fault while the MMU is off
+ pass such a flag to everything, which makes the compiler assemble
+ each wide unaligned load out of single bytes. That is both slower
+ and larger, and a decompressor refilling its bit buffer in machine
+ words can spend up to four times as long for it.
+
+ The assumption holds only once the MMU is on, which on most
+ platforms has not happened by the time an image is unpacked, and
+ nothing checks it. Select it from code which enables the MMU
Crazy idea, but should we add a flag that specifies whether the MMU (and
dcache?) has been set up, and then read that flag in places where we
have this assumption? Then we could at least clearly hard fail on this
flag not being set and tell the user something went wrong before the
system does a HW fault by itself?
Do you mean a runtime flag? I'm afraid that will add more global state
affecting all platforms, and some platforms with tight SPL size
requirements will not love it.
gd->flags with a new flag in enum gd_flags?
Cheers,
Quentin
