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. > 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 :) > > + 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. Best regards, Alexey
