[PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack

[Ard Biesheuvel]

On Tue, 12 Jan 2021 at 14:55, Alexander Sverdlin
<alexander.sverdlin at nokia.com> wrote:
>
> Hi Ard,
>
> On 12/01/2021 11:40, Ard Biesheuvel wrote:
> >>> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> >>> ---
> >>>  arch/arm/Makefile | 1 -
> >>>  1 file changed, 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> >>> index 4aaec9599e8a..c0496983198f 100644
> >>> --- a/arch/arm/Makefile
> >>> +++ b/arch/arm/Makefile
> >>> @@ -151,7 +151,6 @@ textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
> >>>  textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> >>>  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> >>>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> >>> -textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> >>>
> >>>  # Machine directory name.  This list is sorted alphanumerically
> >>>  # by CONFIG_* macro name.
> >> What should the users of uncompressed kernel do with their legacy bootloaders?
> >> I've tested you patch and AXXIA bootloader is not able to deal with 0x8000 default
> >> load address...
> >>
> > I am not sure I understand why this makes a difference. Does the AXXIA
> > bootloader take the load address from the uncompressed image somehow?
> >
> > I would assume that the bootloader knows about the memory reservation
> > at the base of DRAM, and places the kernel image outside of it. That
> > kernel image can now run at any offset of the start of DRAM modulo 2
> > MB.
> >
> > Maybe the issue is that the old offset is 3 MiB?
>
> Some more info from the AXXIA U-Boot, include/configs/axxia.arm.h:
>
> #define CONFIG_UBOOT_REGION_SIZE        0x400000
> #define CONFIG_FEMAC_DMA_SIZE           0x40000
> #define CONFIG_FEMAC_DMA_START          (CONFIG_UBOOT_REGION_SIZE - CONFIG_FEMAC_DMA_SIZE)
>
> From what I see in same file the layout seems to be:
> Start: 0
> CodeEnd: 0x200000
> StackTop: 0x260000
> HeapTop: 0x3C0000
> FEMAC_Top: 0x400000
>
> So the previous 0x308000 worked overwriting U-Boot heap, but
> going down to 0x8000 actually overwrites U-Boot code and everything explodes...
>

It is rather disappointing that the axxia bootloader is so braindead
that it will overwrite itself if vmlinux is not built with a huge hole
at the beginning.

I guess that rules out any cleanup we might attempt to do here.

Thanks for testing,