Hi Alexey,
On 10/22/26 2:46 PM, Alexey Charkov wrote:
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:
[...]
+ 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.
Well, yes but this is assuming that code compiled without -mstrict-align
will *always* be unaligned, which I don't know is true. For some
additional context, we've had a number of issues with the Device Tree
blob not being 8B aligned for example, and it wouldn't always be the
case which made things "fun" to debug :)
I think there's value in reliably crashing the board if we are in a
scenario we expect possible failures. Debugging a random unaligned issue
may prove difficult as adding debug may move code around and have it
align again.
Cheers,
Quentin
