[PATCH] arm64: head: set TEXT_OFFSET to the historical value

Ard Biesheuvel ardb at kernel.org
Thu Oct 9 14:45:14 PDT 2025


On Wed, 8 Oct 2025 at 12:51, Dmitry Baryshkov
<dmitry.baryshkov at oss.qualcomm.com> wrote:
>
> On Tue, Oct 07, 2025 at 01:46:08AM +0200, Ard Biesheuvel wrote:
...
> >
> > Just setting the header field and not updating the base address also
> > means that the boot breaks without CONFIG_RELOCATABLE, and you will
> > get a warning in the kernel log about the load address not being
> > aligned to 2 MiB.
> >
> > So I don't think this is the right solution.
>
> Since most of the people build the kernel with CONFIG_RELOCATABLE, would
> it be better to set it to 0x80000 for relocatable kernels and to 0
> otherwise?
>

When CONFIG_RELOCATABLE is set, any multiple of 64k is acceptable in
practice, but given that this violates the documented boot protocol
for arm64, we only permit this when booting via the EFI stub.

When we set this field to 0x80000, we are basically instructing
bootloaders to violate the boot protocol, which is not ideal, and we
should definitely not issue the pr_warn() we have today in
arch/arm64/kernel/setup.c.

> >
> > If this is really something that needs to be fixed upstream, we should
> > just bring back TEXT_OFFSET in its entirety, but I'm not convinced
> > that this is really justified here. As a workaround, you could just
> > add 2 MiB - 0x80000 bytes of padding at the start of the image, and
> > add your own header (as Will alludes to as well)
>
> Does it mean building a device specific kernel? Or just packing
> everything while building the Android boot image?
>

No idea. What does the Android boot image contain? Is the first thing
that gets loaded the kernel image? In that case, you would wrap the
kernel image before sticking it into the Android boot image, yes.



More information about the linux-arm-kernel mailing list