Hi Quentin, On Fri, Oct 16, 2026 at 2:16 PM Quentin Schulz <[email protected]> wrote: > > 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?
I missed it because armv7m has no MMU, so I assumed it doesn't apply there. As it turns out though, it MAY apply: when it runs on memory marked as "Normal" via its MPU / default memory map, unaligned accesses should work too. I will therefore expand the help text and add a similar hook in arch/arm/cpu/armv7m/config.mk for v3. [...] > >>> + 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? I gave it some further thought, and after all I don't think adding a global flag with a separate panic adds much. If the processor runs into an unaligned load in a context where it cannot work, it will loudly fail with a synchronous abort pointing at the unaligned access exception. It won't silently skip over it, corrupt data, or do anything of that sort. So it is pretty much the same as a panic, and it will occur at exactly the offending location, so the program counter will point directly at the offending instruction for debugging, all with no extra code. Best regards, Alexey
