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

[Ard Biesheuvel]

On Tue, 12 Jan 2021 at 15:21, Alexander Sverdlin
<alexander.sverdlin at nokia.com> wrote:
>
> Hi Ard!
>
> On 12/01/2021 15:05, Ard Biesheuvel wrote:
> >>>>> --- 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.
>
> I can try passing TEXT_OFFSET to the make, but is this official interface
> to the Linux Makefile which will be persistent?
>

If you are going to fix the bootloader, better to let it relocate
itself to the top of DRAM as is usually done.

The boot requirements [0] state that the uncompressed image must be
placed TEXT_OFFSET - PAGE_OFFSET bytes from the start of system
memory, but does not specify that the bootloader should not overwrite
itself in the process.

What might work is adding 4 MiB (the size of the reserved region) to
the load address if TEXT_OFFSET < 0x308000 - that way, things should
work with both old and new kernels. But it would still be a hack.