All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.