* [PATCH 0/2] ARM: remove TEXT_OFFSET override for Axxia
@ 2021-01-11 10:30 Ard Biesheuvel
2021-01-11 10:30 ` [PATCH 1/2] ARM: take memreserve FDT entries into account when discovering base of RAM Ard Biesheuvel
2021-01-11 10:30 ` [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack Ard Biesheuvel
0 siblings, 2 replies; 12+ messages in thread
From: Ard Biesheuvel @ 2021-01-11 10:30 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Arnd Bergmann, Geert Uytterhoeven, Linus Walleij,
Russell King - ARM Linux, Alexander Sverdlin, Ard Biesheuvel
Now that the minimum relative alignment of physical to linear virtual
addresses has been reduced to 2 MiB (from 16 MiB), simply rounding up
the lowest usable DRAM address is no longer as wasteful as before.
Combined with Geert's DT memory discovery patch [0], we can now also
cross reference the decompressor's intended load address against DT memory
reservations, and override it if it points into a reserved area.
By doing this, we remove the need for TEXT_OFFSET hacks that override the
placement of the decompressed kernel on all platforms to accommodate a
single platform that has decided to put reserved areas at the base of DRAM.
As a first step, apply this change to mach-axxia, which is the only platform
that increments TEXT_OFFSET by 3 MiB, and defines this memory reservation as
a /memreserve/ entry.
Future followup work could be done that takes the /reserved-memory node into
account as well, which would allow us to remove another set of TEXT_OFFSET
override hacks for a collection of Qualcomm platforms.
[0] https://lore.kernel.org/linux-arm-kernel/20210104130111.1269694-1-geert+renesas@glider.be/
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Ard Biesheuvel (2):
ARM: take memreserve FDT entries into account when discovering base of
RAM
ARM: axxia: remove TEXT_OFFSET override hack
arch/arm/Makefile | 1 -
arch/arm/boot/compressed/Makefile | 2 ++
.../arm/boot/compressed/fdt_check_mem_start.c | 35 ++++++++++++++++++-
3 files changed, 36 insertions(+), 2 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 1/2] ARM: take memreserve FDT entries into account when discovering base of RAM 2021-01-11 10:30 [PATCH 0/2] ARM: remove TEXT_OFFSET override for Axxia Ard Biesheuvel @ 2021-01-11 10:30 ` Ard Biesheuvel 2021-01-11 10:30 ` [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack Ard Biesheuvel 1 sibling, 0 replies; 12+ messages in thread From: Ard Biesheuvel @ 2021-01-11 10:30 UTC (permalink / raw) To: linux-arm-kernel Cc: Arnd Bergmann, Geert Uytterhoeven, Linus Walleij, Russell King - ARM Linux, Alexander Sverdlin, Ard Biesheuvel As an enhancement to the newly added logic to cross-reference the base of DRAM calculated by rounding the decompressor load address against the memory nodes in the DT, take /memreserve/ entries into account as well. This ensures that DT platforms that currently rely on TEXT_OFFSET to be increased in order to stay clear of memory reservations no longer need this hack in the future. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm/boot/compressed/Makefile | 2 ++ arch/arm/boot/compressed/fdt_check_mem_start.c | 35 +++++++++++++++++++- 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index fd94e27ba4fa..cf8cfe3f286c 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -96,6 +96,8 @@ endif $(foreach o, $(libfdt_objs) atags_to_fdt.o fdt_check_mem_start.o, \ $(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt -fno-stack-protector)) +CFLAGS_fdt_check_mem_start.o += -DTEXT_OFFSET=$(TEXT_OFFSET) + # These were previously generated C files. When you are building the kernel # with O=, make sure to remove the stale files in the output tree. Otherwise, # the build system wrongly compiles the stale ones. diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c b/arch/arm/boot/compressed/fdt_check_mem_start.c index 62450d824c3c..f81ed6ae9776 100644 --- a/arch/arm/boot/compressed/fdt_check_mem_start.c +++ b/arch/arm/boot/compressed/fdt_check_mem_start.c @@ -4,6 +4,19 @@ #include <linux/libfdt.h> #include <linux/sizes.h> +/* + * The ARM kernel only uses part of the 32 KiB TEXT_OFFSET window at the start + * of the uncompressed image, and some platforms rely on this, and have placed + * reserved regions right before it. This means we should only consider an + * overlap to be a collision if the reserved region covers the area that we + * actually use for page tables. + */ +#ifdef CONFIG_ARM_LPAE +#define TEXT_OFFSET_FREE (TEXT_OFFSET - 0x5000) +#else +#define TEXT_OFFSET_FREE (TEXT_OFFSET - 0x4000) +#endif + static const void *get_prop(const void *fdt, const char *node_path, const char *property, int minlen) { @@ -44,6 +57,24 @@ static uint64_t get_val(const fdt32_t *cells, uint32_t ncells) return r; } +static void clip_reserved_regions(const void *fdt, uint32_t *base, uint64_t *end) +{ + int i; + + for (i = 0; i < fdt_num_mem_rsv(fdt); i++) { + uint64_t address, size; + + if (fdt_get_mem_rsv(fdt, i, &address, &size)) + return; + + if (*base >= address && *base < (address + size)) + *base = address + size; + + if (*end >= address && *end < (address + size)) + *end = address; + } +} + /* * Check the start of physical memory * @@ -107,7 +138,9 @@ uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt) base = fdt32_ld(reg + addr_cells - 1); end = base + size; - if (mem_start >= base && mem_start < end) { + clip_reserved_regions(fdt, &base, &end); + if (mem_start + TEXT_OFFSET_FREE >= base && + mem_start < end) { /* Calculated address is valid, use it */ return mem_start; } -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-11 10:30 [PATCH 0/2] ARM: remove TEXT_OFFSET override for Axxia Ard Biesheuvel 2021-01-11 10:30 ` [PATCH 1/2] ARM: take memreserve FDT entries into account when discovering base of RAM Ard Biesheuvel @ 2021-01-11 10:30 ` Ard Biesheuvel 2021-01-12 10:34 ` Alexander Sverdlin 1 sibling, 1 reply; 12+ messages in thread From: Ard Biesheuvel @ 2021-01-11 10:30 UTC (permalink / raw) To: linux-arm-kernel Cc: Arnd Bergmann, Geert Uytterhoeven, Linus Walleij, Russell King - ARM Linux, Alexander Sverdlin, Ard Biesheuvel Now that the decompressor will take memreserve entries into account when placing the uncompressed kernel in memory on DT platforms, we no longer have to override TEXT_OFFSET to stay clear of the memory reservation that exists at the base of memory on these platforms. Signed-off-by: Ard Biesheuvel <ardb@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. -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-11 10:30 ` [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack Ard Biesheuvel @ 2021-01-12 10:34 ` Alexander Sverdlin 2021-01-12 10:40 ` Ard Biesheuvel 0 siblings, 1 reply; 12+ messages in thread From: Alexander Sverdlin @ 2021-01-12 10:34 UTC (permalink / raw) To: Ard Biesheuvel, linux-arm-kernel Cc: Linus Walleij, Geert Uytterhoeven, Russell King - ARM Linux, Arnd Bergmann Hi Ard! On 11/01/2021 11:30, Ard Biesheuvel wrote: > Now that the decompressor will take memreserve entries into account when > placing the uncompressed kernel in memory on DT platforms, we no longer > have to override TEXT_OFFSET to stay clear of the memory reservation that > exists at the base of memory on these platforms. > > Signed-off-by: Ard Biesheuvel <ardb@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... -- Best regards, Alexander Sverdlin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-12 10:34 ` Alexander Sverdlin @ 2021-01-12 10:40 ` Ard Biesheuvel 2021-01-12 11:22 ` Alexander Sverdlin 2021-01-12 13:55 ` Alexander Sverdlin 0 siblings, 2 replies; 12+ messages in thread From: Ard Biesheuvel @ 2021-01-12 10:40 UTC (permalink / raw) To: Alexander Sverdlin Cc: Linus Walleij, Geert Uytterhoeven, Arnd Bergmann, Linux ARM, Russell King - ARM Linux On Tue, 12 Jan 2021 at 11:34, Alexander Sverdlin <alexander.sverdlin@nokia.com> wrote: > > Hi Ard! > > On 11/01/2021 11:30, Ard Biesheuvel wrote: > > Now that the decompressor will take memreserve entries into account when > > placing the uncompressed kernel in memory on DT platforms, we no longer > > have to override TEXT_OFFSET to stay clear of the memory reservation that > > exists at the base of memory on these platforms. > > > > Signed-off-by: Ard Biesheuvel <ardb@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? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-12 10:40 ` Ard Biesheuvel @ 2021-01-12 11:22 ` Alexander Sverdlin 2021-01-12 13:55 ` Alexander Sverdlin 1 sibling, 0 replies; 12+ messages in thread From: Alexander Sverdlin @ 2021-01-12 11:22 UTC (permalink / raw) To: Ard Biesheuvel Cc: Linus Walleij, Geert Uytterhoeven, Arnd Bergmann, Linux ARM, Russell King - ARM Linux Hi! On 12/01/2021 11:40, Ard Biesheuvel wrote: >>> Now that the decompressor will take memreserve entries into account when >>> placing the uncompressed kernel in memory on DT platforms, we no longer >>> have to override TEXT_OFFSET to stay clear of the memory reservation that >>> exists at the base of memory on these platforms. >>> >>> Signed-off-by: Ard Biesheuvel <ardb@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? Yes the U-Boot takes the address (extracted from vmlinux, or elf) from the uImage, and decompresses to this address. > 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. Is it supported for ARM32? I only see CONFIG_RELOCATABLE in the arch/arm64/Kconfig > Maybe the issue is that the old offset is 3 MiB? Hmm, there is no issue with the old offset... -- Best regards, Alexander Sverdlin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-12 10:40 ` Ard Biesheuvel 2021-01-12 11:22 ` Alexander Sverdlin @ 2021-01-12 13:55 ` Alexander Sverdlin 2021-01-12 14:05 ` Ard Biesheuvel 1 sibling, 1 reply; 12+ messages in thread From: Alexander Sverdlin @ 2021-01-12 13:55 UTC (permalink / raw) To: Ard Biesheuvel Cc: Linus Walleij, Geert Uytterhoeven, Arnd Bergmann, Linux ARM, Russell King - ARM Linux Hi Ard, On 12/01/2021 11:40, Ard Biesheuvel wrote: >>> Signed-off-by: Ard Biesheuvel <ardb@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... -- Best regards, Alexander Sverdlin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-12 13:55 ` Alexander Sverdlin @ 2021-01-12 14:05 ` Ard Biesheuvel 2021-01-12 14:21 ` Alexander Sverdlin 0 siblings, 1 reply; 12+ messages in thread From: Ard Biesheuvel @ 2021-01-12 14:05 UTC (permalink / raw) To: Alexander Sverdlin Cc: Linus Walleij, Geert Uytterhoeven, Arnd Bergmann, Linux ARM, Russell King - ARM Linux On Tue, 12 Jan 2021 at 14:55, Alexander Sverdlin <alexander.sverdlin@nokia.com> wrote: > > Hi Ard, > > On 12/01/2021 11:40, Ard Biesheuvel wrote: > >>> Signed-off-by: Ard Biesheuvel <ardb@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, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-12 14:05 ` Ard Biesheuvel @ 2021-01-12 14:21 ` Alexander Sverdlin 2021-01-13 17:49 ` Ard Biesheuvel 0 siblings, 1 reply; 12+ messages in thread From: Alexander Sverdlin @ 2021-01-12 14:21 UTC (permalink / raw) To: Ard Biesheuvel Cc: Linus Walleij, Geert Uytterhoeven, Arnd Bergmann, Linux ARM, Russell King - ARM Linux 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? -- Best regards, Alexander Sverdlin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-12 14:21 ` Alexander Sverdlin @ 2021-01-13 17:49 ` Ard Biesheuvel 2021-01-13 21:26 ` Russell King - ARM Linux admin 0 siblings, 1 reply; 12+ messages in thread From: Ard Biesheuvel @ 2021-01-13 17:49 UTC (permalink / raw) To: Alexander Sverdlin Cc: Linus Walleij, Geert Uytterhoeven, Arnd Bergmann, Linux ARM, Russell King - ARM Linux On Tue, 12 Jan 2021 at 15:21, Alexander Sverdlin <alexander.sverdlin@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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-13 17:49 ` Ard Biesheuvel @ 2021-01-13 21:26 ` Russell King - ARM Linux admin 2021-01-13 22:43 ` Ard Biesheuvel 0 siblings, 1 reply; 12+ messages in thread From: Russell King - ARM Linux admin @ 2021-01-13 21:26 UTC (permalink / raw) To: Ard Biesheuvel Cc: Linus Walleij, Geert Uytterhoeven, Alexander Sverdlin, Arnd Bergmann, Linux ARM On Wed, Jan 13, 2021 at 06:49:17PM +0100, Ard Biesheuvel wrote: > 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 No, that is incorrect on several counts. 1. PAGE_OFFSET is the virtual address offset of the start of RAM as seen by the kernel; the boot loader has no knowledge of this. You mean essentially what the kernel calls PHYS_OFFSET. 2. TEXT_OFFSET is the offset from the start of RAM to the kernel image both in terms of what the kernel calls PAGE_OFFSET and PHYS_OFFSET. Essentially, the page mapped at PAGE_OFFSET in the kernel's virtual address space is the physical page at PHYS_OFFSET when the MMU is off. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack 2021-01-13 21:26 ` Russell King - ARM Linux admin @ 2021-01-13 22:43 ` Ard Biesheuvel 0 siblings, 0 replies; 12+ messages in thread From: Ard Biesheuvel @ 2021-01-13 22:43 UTC (permalink / raw) To: Russell King - ARM Linux admin Cc: Linus Walleij, Geert Uytterhoeven, Alexander Sverdlin, Arnd Bergmann, Linux ARM On Wed, 13 Jan 2021 at 22:26, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Wed, Jan 13, 2021 at 06:49:17PM +0100, Ard Biesheuvel wrote: > > 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 > > No, that is incorrect on several counts. > Nevertheless, it is literally what booting.rst claims: """ When booting a raw (non-zImage) kernel the constraints are tighter. In this case the kernel must be loaded at an offset into system equal to TEXT_OFFSET - PAGE_OFFSET. """ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/booting.rst#n180 so we might want to fix that. > 1. PAGE_OFFSET is the virtual address offset of the start of RAM as > seen by the kernel; the boot loader has no knowledge of this. You > mean essentially what the kernel calls PHYS_OFFSET. > > 2. TEXT_OFFSET is the offset from the start of RAM to the kernel image > both in terms of what the kernel calls PAGE_OFFSET and PHYS_OFFSET. > > Essentially, the page mapped at PAGE_OFFSET in the kernel's virtual > address space is the physical page at PHYS_OFFSET when the MMU is off. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-01-13 22:45 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-11 10:30 [PATCH 0/2] ARM: remove TEXT_OFFSET override for Axxia Ard Biesheuvel 2021-01-11 10:30 ` [PATCH 1/2] ARM: take memreserve FDT entries into account when discovering base of RAM Ard Biesheuvel 2021-01-11 10:30 ` [PATCH 2/2] ARM: axxia: remove TEXT_OFFSET override hack Ard Biesheuvel 2021-01-12 10:34 ` Alexander Sverdlin 2021-01-12 10:40 ` Ard Biesheuvel 2021-01-12 11:22 ` Alexander Sverdlin 2021-01-12 13:55 ` Alexander Sverdlin 2021-01-12 14:05 ` Ard Biesheuvel 2021-01-12 14:21 ` Alexander Sverdlin 2021-01-13 17:49 ` Ard Biesheuvel 2021-01-13 21:26 ` Russell King - ARM Linux admin 2021-01-13 22:43 ` Ard Biesheuvel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.