[PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Currently, the start address of physical memory is obtained by masking
the program counter with a fixed mask of 0xf8000000.  This mask value
was chosen as a balance between the requirements of different platforms.
However, this does require that the start address of physical memory is
a multiple of 128 MiB, precluding booting Linux on platforms where this
requirement is not fulfilled.

Fix this limitation by obtaining the start address from the DTB instead,
if available (either explicitly passed, or appended to the kernel).
Fall back to the traditional method when needed.

This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
i.e. not at a multiple of 128 MiB.

Suggested-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Against arm/for-next.

Tested with the following configurations:
  - zImage + DTB (r8a7791/koelsch),
  - uImage + DTB (r8a73a4/ape6evm, r7s72100/rskrza1, r7s9210/rza2mevb),
  - zImage with appended DTB (r8a7740/armadillo, sh73a0/kzm9g).

v2:
  - Use "cmp r0, #-1", instead of "cmn r0, #1",
  - Add missing stack setup,
  - Support appended DTBs.

v1: https://lore.kernel.org/linux-arm-kernel/20200121192741.20597-1-geert+renesas@glider.be/
---
 arch/arm/boot/compressed/Makefile            |  6 ++-
 arch/arm/boot/compressed/fdt_get_mem_start.c | 52 ++++++++++++++++++++
 arch/arm/boot/compressed/head.S              | 52 +++++++++++++++++++-
 3 files changed, 108 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/compressed/fdt_get_mem_start.c

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index da599c3a11934332..bbfecd648a1a3b57 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -86,12 +86,15 @@ libfdt_objs	:= $(addsuffix .o, $(basename $(libfdt)))
 $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/%
 	$(call cmd,shipped)
 
-$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
+$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o fdt_get_mem_start.o): \
 	$(addprefix $(obj)/,$(libfdt_hdrs))
 
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
 OBJS	+= $(libfdt_objs) atags_to_fdt.o
 endif
+ifeq ($(CONFIG_USE_OF),y)
+OBJS	+= $(libfdt_objs) fdt_get_mem_start.o
+endif
 
 targets       := vmlinux vmlinux.lds piggy_data piggy.o \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
@@ -116,6 +119,7 @@ CFLAGS_fdt.o := $(nossp-flags-y)
 CFLAGS_fdt_ro.o := $(nossp-flags-y)
 CFLAGS_fdt_rw.o := $(nossp-flags-y)
 CFLAGS_fdt_wip.o := $(nossp-flags-y)
+CFLAGS_fdt_get_mem_start.o := $(nossp-flags-y)
 
 ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,) -fno-builtin -I$(obj)
 asflags-y := -DZIMAGE
diff --git a/arch/arm/boot/compressed/fdt_get_mem_start.c b/arch/arm/boot/compressed/fdt_get_mem_start.c
new file mode 100644
index 0000000000000000..2c5ac47f656317ee
--- /dev/null
+++ b/arch/arm/boot/compressed/fdt_get_mem_start.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <libfdt.h>
+
+static const void *getprop(const void *fdt, const char *node_path,
+			   const char *property)
+{
+	int offset = fdt_path_offset(fdt, node_path);
+
+	if (offset == -FDT_ERR_NOTFOUND)
+		return NULL;
+
+	return fdt_getprop(fdt, offset, property, NULL);
+}
+
+static uint32_t get_addr_size(const void *fdt)
+{
+	const __be32 *addr_len = getprop(fdt, "/", "#address-cells");
+
+	if (!addr_len) {
+		/* default */
+		return 1;
+	}
+
+	return fdt32_to_cpu(*addr_len);
+}
+
+/*
+ * Get the start of physical memory
+ */
+
+unsigned long fdt_get_mem_start(const void *fdt)
+{
+	const __be32 *memory;
+	uint32_t addr_size;
+
+	if (!fdt)
+		return -1;
+
+	if (*(__be32 *)fdt != cpu_to_fdt32(FDT_MAGIC))
+		return -1;
+
+	/* Find the first memory node */
+	memory = getprop(fdt, "/memory", "reg");
+	if (!memory)
+		return -1;
+
+	/* There may be multiple cells on LPAE platforms */
+	addr_size = get_addr_size(fdt);
+
+	return fdt32_to_cpu(memory[addr_size - 1]);
+}
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 927f5dc413d7dff2..aa2d7de2ddc86fa8 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -235,8 +235,56 @@ not_angel:
 		.text
 
 #ifdef CONFIG_AUTO_ZRELADDR
+#ifdef CONFIG_USE_OF
 		/*
-		 * Find the start of physical memory.  As we are executing
+		 * Find the start of physical memory.
+		 * Try the DTB first, if available.
+		 */
+		adr	r0, LC0
+		ldr	r1, [r0]	@ get absolute LC0
+		ldr	sp, [r0, #28]	@ get stack location
+		sub	r1, r0, r1	@ compute relocation offset
+		add	sp, sp, r1	@ apply relocation
+
+#ifdef CONFIG_ARM_APPENDED_DTB
+		/*
+		 * Look for an appended DTB. If found, use it and
+		 * move stack away from it.
+		 */
+		ldr	r6, [r0, #12]	@ get &_edata
+		add	r6, r6, r1	@ relocate it
+		ldmia	r6, {r0, r5}	@ get DTB signature and size
+#ifndef __ARMEB__
+		ldr	r1, =0xedfe0dd0	@ sig is 0xd00dfeed big endian
+		/* convert DTB size to little endian */
+		eor	r2, r5, r5, ror #16
+		bic	r2, r2, #0x00ff0000
+		mov	r5, r5, ror #8
+		eor	r5, r5, r2, lsr #8
+#else
+		ldr	r1, =0xd00dfeed
+#endif
+		cmp	r0, r1		@ do we have a DTB there?
+		bne	1f
+
+		mov	r8, r6		@ use it if so
+		/* preserve 64-bit alignment */
+		add	r5, r5, #7
+		bic	r5, r5, #7
+		add	sp, sp, r5	@ and move stack above it
+
+1:
+#endif /* CONFIG_ARM_APPENDED_DTB */
+
+		mov	r0, r8
+		bl	fdt_get_mem_start
+		mov	r4, r0
+		cmp	r0, #-1
+		bne	1f
+#endif /* CONFIG_USE_OF */
+
+		/*
+		 * Fall back to the traditional method.  As we are executing
 		 * without the MMU on, we are in the physical address space.
 		 * We just need to get rid of any offset by aligning the
 		 * address.
@@ -254,6 +302,8 @@ not_angel:
 		 */
 		mov	r4, pc
 		and	r4, r4, #0xf8000000
+
+1:
 		/* Determine final kernel image address. */
 		add	r4, r4, #TEXT_OFFSET
 #else
-- 
2.17.1

[PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Currently, the start address of physical memory is obtained by masking
the program counter with a fixed mask of 0xf8000000.  This mask value
was chosen as a balance between the requirements of different platforms.
However, this does require that the start address of physical memory is
a multiple of 128 MiB, precluding booting Linux on platforms where this
requirement is not fulfilled.

Fix this limitation by obtaining the start address from the DTB instead,
if available (either explicitly passed, or appended to the kernel).
Fall back to the traditional method when needed.

This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
i.e. not at a multiple of 128 MiB.

Suggested-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Against arm/for-next.

Tested with the following configurations:
  - zImage + DTB (r8a7791/koelsch),
  - uImage + DTB (r8a73a4/ape6evm, r7s72100/rskrza1, r7s9210/rza2mevb),
  - zImage with appended DTB (r8a7740/armadillo, sh73a0/kzm9g).

v2:
  - Use "cmp r0, #-1", instead of "cmn r0, #1",
  - Add missing stack setup,
  - Support appended DTBs.

v1: https://lore.kernel.org/linux-arm-kernel/20200121192741.20597-1-geert+renesas@glider.be/
---
 arch/arm/boot/compressed/Makefile            |  6 ++-
 arch/arm/boot/compressed/fdt_get_mem_start.c | 52 ++++++++++++++++++++
 arch/arm/boot/compressed/head.S              | 52 +++++++++++++++++++-
 3 files changed, 108 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/compressed/fdt_get_mem_start.c

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index da599c3a11934332..bbfecd648a1a3b57 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -86,12 +86,15 @@ libfdt_objs	:= $(addsuffix .o, $(basename $(libfdt)))
 $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/%
 	$(call cmd,shipped)
 
-$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
+$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o fdt_get_mem_start.o): \
 	$(addprefix $(obj)/,$(libfdt_hdrs))
 
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
 OBJS	+= $(libfdt_objs) atags_to_fdt.o
 endif
+ifeq ($(CONFIG_USE_OF),y)
+OBJS	+= $(libfdt_objs) fdt_get_mem_start.o
+endif
 
 targets       := vmlinux vmlinux.lds piggy_data piggy.o \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
@@ -116,6 +119,7 @@ CFLAGS_fdt.o := $(nossp-flags-y)
 CFLAGS_fdt_ro.o := $(nossp-flags-y)
 CFLAGS_fdt_rw.o := $(nossp-flags-y)
 CFLAGS_fdt_wip.o := $(nossp-flags-y)
+CFLAGS_fdt_get_mem_start.o := $(nossp-flags-y)
 
 ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,) -fno-builtin -I$(obj)
 asflags-y := -DZIMAGE
diff --git a/arch/arm/boot/compressed/fdt_get_mem_start.c b/arch/arm/boot/compressed/fdt_get_mem_start.c
new file mode 100644
index 0000000000000000..2c5ac47f656317ee
--- /dev/null
+++ b/arch/arm/boot/compressed/fdt_get_mem_start.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <libfdt.h>
+
+static const void *getprop(const void *fdt, const char *node_path,
+			   const char *property)
+{
+	int offset = fdt_path_offset(fdt, node_path);
+
+	if (offset == -FDT_ERR_NOTFOUND)
+		return NULL;
+
+	return fdt_getprop(fdt, offset, property, NULL);
+}
+
+static uint32_t get_addr_size(const void *fdt)
+{
+	const __be32 *addr_len = getprop(fdt, "/", "#address-cells");
+
+	if (!addr_len) {
+		/* default */
+		return 1;
+	}
+
+	return fdt32_to_cpu(*addr_len);
+}
+
+/*
+ * Get the start of physical memory
+ */
+
+unsigned long fdt_get_mem_start(const void *fdt)
+{
+	const __be32 *memory;
+	uint32_t addr_size;
+
+	if (!fdt)
+		return -1;
+
+	if (*(__be32 *)fdt != cpu_to_fdt32(FDT_MAGIC))
+		return -1;
+
+	/* Find the first memory node */
+	memory = getprop(fdt, "/memory", "reg");
+	if (!memory)
+		return -1;
+
+	/* There may be multiple cells on LPAE platforms */
+	addr_size = get_addr_size(fdt);
+
+	return fdt32_to_cpu(memory[addr_size - 1]);
+}
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 927f5dc413d7dff2..aa2d7de2ddc86fa8 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -235,8 +235,56 @@ not_angel:
 		.text
 
 #ifdef CONFIG_AUTO_ZRELADDR
+#ifdef CONFIG_USE_OF
 		/*
-		 * Find the start of physical memory.  As we are executing
+		 * Find the start of physical memory.
+		 * Try the DTB first, if available.
+		 */
+		adr	r0, LC0
+		ldr	r1, [r0]	@ get absolute LC0
+		ldr	sp, [r0, #28]	@ get stack location
+		sub	r1, r0, r1	@ compute relocation offset
+		add	sp, sp, r1	@ apply relocation
+
+#ifdef CONFIG_ARM_APPENDED_DTB
+		/*
+		 * Look for an appended DTB. If found, use it and
+		 * move stack away from it.
+		 */
+		ldr	r6, [r0, #12]	@ get &_edata
+		add	r6, r6, r1	@ relocate it
+		ldmia	r6, {r0, r5}	@ get DTB signature and size
+#ifndef __ARMEB__
+		ldr	r1, =0xedfe0dd0	@ sig is 0xd00dfeed big endian
+		/* convert DTB size to little endian */
+		eor	r2, r5, r5, ror #16
+		bic	r2, r2, #0x00ff0000
+		mov	r5, r5, ror #8
+		eor	r5, r5, r2, lsr #8
+#else
+		ldr	r1, =0xd00dfeed
+#endif
+		cmp	r0, r1		@ do we have a DTB there?
+		bne	1f
+
+		mov	r8, r6		@ use it if so
+		/* preserve 64-bit alignment */
+		add	r5, r5, #7
+		bic	r5, r5, #7
+		add	sp, sp, r5	@ and move stack above it
+
+1:
+#endif /* CONFIG_ARM_APPENDED_DTB */
+
+		mov	r0, r8
+		bl	fdt_get_mem_start
+		mov	r4, r0
+		cmp	r0, #-1
+		bne	1f
+#endif /* CONFIG_USE_OF */
+
+		/*
+		 * Fall back to the traditional method.  As we are executing
 		 * without the MMU on, we are in the physical address space.
 		 * We just need to get rid of any offset by aligning the
 		 * address.
@@ -254,6 +302,8 @@ not_angel:
 		 */
 		mov	r4, pc
 		and	r4, r4, #0xf8000000
+
+1:
 		/* Determine final kernel image address. */
 		add	r4, r4, #TEXT_OFFSET
 #else
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Nicolas Pitre]

On Mon, 27 Jan 2020, Geert Uytterhoeven wrote:

> Currently, the start address of physical memory is obtained by masking
> the program counter with a fixed mask of 0xf8000000.  This mask value
> was chosen as a balance between the requirements of different platforms.
> However, this does require that the start address of physical memory is
> a multiple of 128 MiB, precluding booting Linux on platforms where this
> requirement is not fulfilled.
> 
> Fix this limitation by obtaining the start address from the DTB instead,
> if available (either explicitly passed, or appended to the kernel).
> Fall back to the traditional method when needed.
> 
> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> i.e. not at a multiple of 128 MiB.
> 
> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Nicolas Pitre <nico@fluxnic.net>



> ---
> Against arm/for-next.
> 
> Tested with the following configurations:
>   - zImage + DTB (r8a7791/koelsch),
>   - uImage + DTB (r8a73a4/ape6evm, r7s72100/rskrza1, r7s9210/rza2mevb),
>   - zImage with appended DTB (r8a7740/armadillo, sh73a0/kzm9g).
> 
> v2:
>   - Use "cmp r0, #-1", instead of "cmn r0, #1",
>   - Add missing stack setup,
>   - Support appended DTBs.
> 
> v1: https://lore.kernel.org/linux-arm-kernel/20200121192741.20597-1-geert+renesas@glider.be/
> ---
>  arch/arm/boot/compressed/Makefile            |  6 ++-
>  arch/arm/boot/compressed/fdt_get_mem_start.c | 52 ++++++++++++++++++++
>  arch/arm/boot/compressed/head.S              | 52 +++++++++++++++++++-
>  3 files changed, 108 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/compressed/fdt_get_mem_start.c
> 
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index da599c3a11934332..bbfecd648a1a3b57 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -86,12 +86,15 @@ libfdt_objs	:= $(addsuffix .o, $(basename $(libfdt)))
>  $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/%
>  	$(call cmd,shipped)
>  
> -$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
> +$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o fdt_get_mem_start.o): \
>  	$(addprefix $(obj)/,$(libfdt_hdrs))
>  
>  ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>  OBJS	+= $(libfdt_objs) atags_to_fdt.o
>  endif
> +ifeq ($(CONFIG_USE_OF),y)
> +OBJS	+= $(libfdt_objs) fdt_get_mem_start.o
> +endif
>  
>  targets       := vmlinux vmlinux.lds piggy_data piggy.o \
>  		 lib1funcs.o ashldi3.o bswapsdi2.o \
> @@ -116,6 +119,7 @@ CFLAGS_fdt.o := $(nossp-flags-y)
>  CFLAGS_fdt_ro.o := $(nossp-flags-y)
>  CFLAGS_fdt_rw.o := $(nossp-flags-y)
>  CFLAGS_fdt_wip.o := $(nossp-flags-y)
> +CFLAGS_fdt_get_mem_start.o := $(nossp-flags-y)
>  
>  ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,) -fno-builtin -I$(obj)
>  asflags-y := -DZIMAGE
> diff --git a/arch/arm/boot/compressed/fdt_get_mem_start.c b/arch/arm/boot/compressed/fdt_get_mem_start.c
> new file mode 100644
> index 0000000000000000..2c5ac47f656317ee
> --- /dev/null
> +++ b/arch/arm/boot/compressed/fdt_get_mem_start.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <libfdt.h>
> +
> +static const void *getprop(const void *fdt, const char *node_path,
> +			   const char *property)
> +{
> +	int offset = fdt_path_offset(fdt, node_path);
> +
> +	if (offset == -FDT_ERR_NOTFOUND)
> +		return NULL;
> +
> +	return fdt_getprop(fdt, offset, property, NULL);
> +}
> +
> +static uint32_t get_addr_size(const void *fdt)
> +{
> +	const __be32 *addr_len = getprop(fdt, "/", "#address-cells");
> +
> +	if (!addr_len) {
> +		/* default */
> +		return 1;
> +	}
> +
> +	return fdt32_to_cpu(*addr_len);
> +}
> +
> +/*
> + * Get the start of physical memory
> + */
> +
> +unsigned long fdt_get_mem_start(const void *fdt)
> +{
> +	const __be32 *memory;
> +	uint32_t addr_size;
> +
> +	if (!fdt)
> +		return -1;
> +
> +	if (*(__be32 *)fdt != cpu_to_fdt32(FDT_MAGIC))
> +		return -1;
> +
> +	/* Find the first memory node */
> +	memory = getprop(fdt, "/memory", "reg");
> +	if (!memory)
> +		return -1;
> +
> +	/* There may be multiple cells on LPAE platforms */
> +	addr_size = get_addr_size(fdt);
> +
> +	return fdt32_to_cpu(memory[addr_size - 1]);
> +}
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 927f5dc413d7dff2..aa2d7de2ddc86fa8 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -235,8 +235,56 @@ not_angel:
>  		.text
>  
>  #ifdef CONFIG_AUTO_ZRELADDR
> +#ifdef CONFIG_USE_OF
>  		/*
> -		 * Find the start of physical memory.  As we are executing
> +		 * Find the start of physical memory.
> +		 * Try the DTB first, if available.
> +		 */
> +		adr	r0, LC0
> +		ldr	r1, [r0]	@ get absolute LC0
> +		ldr	sp, [r0, #28]	@ get stack location
> +		sub	r1, r0, r1	@ compute relocation offset
> +		add	sp, sp, r1	@ apply relocation
> +
> +#ifdef CONFIG_ARM_APPENDED_DTB
> +		/*
> +		 * Look for an appended DTB. If found, use it and
> +		 * move stack away from it.
> +		 */
> +		ldr	r6, [r0, #12]	@ get &_edata
> +		add	r6, r6, r1	@ relocate it
> +		ldmia	r6, {r0, r5}	@ get DTB signature and size
> +#ifndef __ARMEB__
> +		ldr	r1, =0xedfe0dd0	@ sig is 0xd00dfeed big endian
> +		/* convert DTB size to little endian */
> +		eor	r2, r5, r5, ror #16
> +		bic	r2, r2, #0x00ff0000
> +		mov	r5, r5, ror #8
> +		eor	r5, r5, r2, lsr #8
> +#else
> +		ldr	r1, =0xd00dfeed
> +#endif
> +		cmp	r0, r1		@ do we have a DTB there?
> +		bne	1f
> +
> +		mov	r8, r6		@ use it if so
> +		/* preserve 64-bit alignment */
> +		add	r5, r5, #7
> +		bic	r5, r5, #7
> +		add	sp, sp, r5	@ and move stack above it
> +
> +1:
> +#endif /* CONFIG_ARM_APPENDED_DTB */
> +
> +		mov	r0, r8
> +		bl	fdt_get_mem_start
> +		mov	r4, r0
> +		cmp	r0, #-1
> +		bne	1f
> +#endif /* CONFIG_USE_OF */
> +
> +		/*
> +		 * Fall back to the traditional method.  As we are executing
>  		 * without the MMU on, we are in the physical address space.
>  		 * We just need to get rid of any offset by aligning the
>  		 * address.
> @@ -254,6 +302,8 @@ not_angel:
>  		 */
>  		mov	r4, pc
>  		and	r4, r4, #0xf8000000
> +
> +1:
>  		/* Determine final kernel image address. */
>  		add	r4, r4, #TEXT_OFFSET
>  #else
> -- 
> 2.17.1
> 
> 

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Nicolas Pitre]

On Mon, 27 Jan 2020, Geert Uytterhoeven wrote:

> Currently, the start address of physical memory is obtained by masking
> the program counter with a fixed mask of 0xf8000000.  This mask value
> was chosen as a balance between the requirements of different platforms.
> However, this does require that the start address of physical memory is
> a multiple of 128 MiB, precluding booting Linux on platforms where this
> requirement is not fulfilled.
> 
> Fix this limitation by obtaining the start address from the DTB instead,
> if available (either explicitly passed, or appended to the kernel).
> Fall back to the traditional method when needed.
> 
> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> i.e. not at a multiple of 128 MiB.
> 
> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Nicolas Pitre <nico@fluxnic.net>



> ---
> Against arm/for-next.
> 
> Tested with the following configurations:
>   - zImage + DTB (r8a7791/koelsch),
>   - uImage + DTB (r8a73a4/ape6evm, r7s72100/rskrza1, r7s9210/rza2mevb),
>   - zImage with appended DTB (r8a7740/armadillo, sh73a0/kzm9g).
> 
> v2:
>   - Use "cmp r0, #-1", instead of "cmn r0, #1",
>   - Add missing stack setup,
>   - Support appended DTBs.
> 
> v1: https://lore.kernel.org/linux-arm-kernel/20200121192741.20597-1-geert+renesas@glider.be/
> ---
>  arch/arm/boot/compressed/Makefile            |  6 ++-
>  arch/arm/boot/compressed/fdt_get_mem_start.c | 52 ++++++++++++++++++++
>  arch/arm/boot/compressed/head.S              | 52 +++++++++++++++++++-
>  3 files changed, 108 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/compressed/fdt_get_mem_start.c
> 
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index da599c3a11934332..bbfecd648a1a3b57 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -86,12 +86,15 @@ libfdt_objs	:= $(addsuffix .o, $(basename $(libfdt)))
>  $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/%
>  	$(call cmd,shipped)
>  
> -$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
> +$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o fdt_get_mem_start.o): \
>  	$(addprefix $(obj)/,$(libfdt_hdrs))
>  
>  ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>  OBJS	+= $(libfdt_objs) atags_to_fdt.o
>  endif
> +ifeq ($(CONFIG_USE_OF),y)
> +OBJS	+= $(libfdt_objs) fdt_get_mem_start.o
> +endif
>  
>  targets       := vmlinux vmlinux.lds piggy_data piggy.o \
>  		 lib1funcs.o ashldi3.o bswapsdi2.o \
> @@ -116,6 +119,7 @@ CFLAGS_fdt.o := $(nossp-flags-y)
>  CFLAGS_fdt_ro.o := $(nossp-flags-y)
>  CFLAGS_fdt_rw.o := $(nossp-flags-y)
>  CFLAGS_fdt_wip.o := $(nossp-flags-y)
> +CFLAGS_fdt_get_mem_start.o := $(nossp-flags-y)
>  
>  ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,) -fno-builtin -I$(obj)
>  asflags-y := -DZIMAGE
> diff --git a/arch/arm/boot/compressed/fdt_get_mem_start.c b/arch/arm/boot/compressed/fdt_get_mem_start.c
> new file mode 100644
> index 0000000000000000..2c5ac47f656317ee
> --- /dev/null
> +++ b/arch/arm/boot/compressed/fdt_get_mem_start.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <libfdt.h>
> +
> +static const void *getprop(const void *fdt, const char *node_path,
> +			   const char *property)
> +{
> +	int offset = fdt_path_offset(fdt, node_path);
> +
> +	if (offset == -FDT_ERR_NOTFOUND)
> +		return NULL;
> +
> +	return fdt_getprop(fdt, offset, property, NULL);
> +}
> +
> +static uint32_t get_addr_size(const void *fdt)
> +{
> +	const __be32 *addr_len = getprop(fdt, "/", "#address-cells");
> +
> +	if (!addr_len) {
> +		/* default */
> +		return 1;
> +	}
> +
> +	return fdt32_to_cpu(*addr_len);
> +}
> +
> +/*
> + * Get the start of physical memory
> + */
> +
> +unsigned long fdt_get_mem_start(const void *fdt)
> +{
> +	const __be32 *memory;
> +	uint32_t addr_size;
> +
> +	if (!fdt)
> +		return -1;
> +
> +	if (*(__be32 *)fdt != cpu_to_fdt32(FDT_MAGIC))
> +		return -1;
> +
> +	/* Find the first memory node */
> +	memory = getprop(fdt, "/memory", "reg");
> +	if (!memory)
> +		return -1;
> +
> +	/* There may be multiple cells on LPAE platforms */
> +	addr_size = get_addr_size(fdt);
> +
> +	return fdt32_to_cpu(memory[addr_size - 1]);
> +}
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 927f5dc413d7dff2..aa2d7de2ddc86fa8 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -235,8 +235,56 @@ not_angel:
>  		.text
>  
>  #ifdef CONFIG_AUTO_ZRELADDR
> +#ifdef CONFIG_USE_OF
>  		/*
> -		 * Find the start of physical memory.  As we are executing
> +		 * Find the start of physical memory.
> +		 * Try the DTB first, if available.
> +		 */
> +		adr	r0, LC0
> +		ldr	r1, [r0]	@ get absolute LC0
> +		ldr	sp, [r0, #28]	@ get stack location
> +		sub	r1, r0, r1	@ compute relocation offset
> +		add	sp, sp, r1	@ apply relocation
> +
> +#ifdef CONFIG_ARM_APPENDED_DTB
> +		/*
> +		 * Look for an appended DTB. If found, use it and
> +		 * move stack away from it.
> +		 */
> +		ldr	r6, [r0, #12]	@ get &_edata
> +		add	r6, r6, r1	@ relocate it
> +		ldmia	r6, {r0, r5}	@ get DTB signature and size
> +#ifndef __ARMEB__
> +		ldr	r1, =0xedfe0dd0	@ sig is 0xd00dfeed big endian
> +		/* convert DTB size to little endian */
> +		eor	r2, r5, r5, ror #16
> +		bic	r2, r2, #0x00ff0000
> +		mov	r5, r5, ror #8
> +		eor	r5, r5, r2, lsr #8
> +#else
> +		ldr	r1, =0xd00dfeed
> +#endif
> +		cmp	r0, r1		@ do we have a DTB there?
> +		bne	1f
> +
> +		mov	r8, r6		@ use it if so
> +		/* preserve 64-bit alignment */
> +		add	r5, r5, #7
> +		bic	r5, r5, #7
> +		add	sp, sp, r5	@ and move stack above it
> +
> +1:
> +#endif /* CONFIG_ARM_APPENDED_DTB */
> +
> +		mov	r0, r8
> +		bl	fdt_get_mem_start
> +		mov	r4, r0
> +		cmp	r0, #-1
> +		bne	1f
> +#endif /* CONFIG_USE_OF */
> +
> +		/*
> +		 * Fall back to the traditional method.  As we are executing
>  		 * without the MMU on, we are in the physical address space.
>  		 * We just need to get rid of any offset by aligning the
>  		 * address.
> @@ -254,6 +302,8 @@ not_angel:
>  		 */
>  		mov	r4, pc
>  		and	r4, r4, #0xf8000000
> +
> +1:
>  		/* Determine final kernel image address. */
>  		add	r4, r4, #TEXT_OFFSET
>  #else
> -- 
> 2.17.1
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Marek Szyprowski]

Hi Geert,

On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> Currently, the start address of physical memory is obtained by masking
> the program counter with a fixed mask of 0xf8000000.  This mask value
> was chosen as a balance between the requirements of different platforms.
> However, this does require that the start address of physical memory is
> a multiple of 128 MiB, precluding booting Linux on platforms where this
> requirement is not fulfilled.
>
> Fix this limitation by obtaining the start address from the DTB instead,
> if available (either explicitly passed, or appended to the kernel).
> Fall back to the traditional method when needed.
>
> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> i.e. not at a multiple of 128 MiB.
>
> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> Against arm/for-next.

This patch landed recently in linux-next. It breaks legacy booting from 
the zImage + appended DT + cmdline/memory info provided via ATAGs. I 
will debug it further once I find some spare time. What I noticed so 
far, the cmdline/memory info is not read from the ATAGs, only the values 
provided via appended DT are used.

> Tested with the following configurations:
>    - zImage + DTB (r8a7791/koelsch),
>    - uImage + DTB (r8a73a4/ape6evm, r7s72100/rskrza1, r7s9210/rza2mevb),
>    - zImage with appended DTB (r8a7740/armadillo, sh73a0/kzm9g).
>
> v2:
>    - Use "cmp r0, #-1", instead of "cmn r0, #1",
>    - Add missing stack setup,
>    - Support appended DTBs.
>
> v1: https://lore.kernel.org/linux-arm-kernel/20200121192741.20597-1-geert+renesas@glider.be/
> ---
>   arch/arm/boot/compressed/Makefile            |  6 ++-
>   arch/arm/boot/compressed/fdt_get_mem_start.c | 52 ++++++++++++++++++++
>   arch/arm/boot/compressed/head.S              | 52 +++++++++++++++++++-
>   3 files changed, 108 insertions(+), 2 deletions(-)
>   create mode 100644 arch/arm/boot/compressed/fdt_get_mem_start.c
>
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index da599c3a11934332..bbfecd648a1a3b57 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -86,12 +86,15 @@ libfdt_objs	:= $(addsuffix .o, $(basename $(libfdt)))
>   $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/%
>   	$(call cmd,shipped)
>   
> -$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
> +$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o fdt_get_mem_start.o): \
>   	$(addprefix $(obj)/,$(libfdt_hdrs))
>   
>   ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>   OBJS	+= $(libfdt_objs) atags_to_fdt.o
>   endif
> +ifeq ($(CONFIG_USE_OF),y)
> +OBJS	+= $(libfdt_objs) fdt_get_mem_start.o
> +endif
>   
>   targets       := vmlinux vmlinux.lds piggy_data piggy.o \
>   		 lib1funcs.o ashldi3.o bswapsdi2.o \
> @@ -116,6 +119,7 @@ CFLAGS_fdt.o := $(nossp-flags-y)
>   CFLAGS_fdt_ro.o := $(nossp-flags-y)
>   CFLAGS_fdt_rw.o := $(nossp-flags-y)
>   CFLAGS_fdt_wip.o := $(nossp-flags-y)
> +CFLAGS_fdt_get_mem_start.o := $(nossp-flags-y)
>   
>   ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,) -fno-builtin -I$(obj)
>   asflags-y := -DZIMAGE
> diff --git a/arch/arm/boot/compressed/fdt_get_mem_start.c b/arch/arm/boot/compressed/fdt_get_mem_start.c
> new file mode 100644
> index 0000000000000000..2c5ac47f656317ee
> --- /dev/null
> +++ b/arch/arm/boot/compressed/fdt_get_mem_start.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <libfdt.h>
> +
> +static const void *getprop(const void *fdt, const char *node_path,
> +			   const char *property)
> +{
> +	int offset = fdt_path_offset(fdt, node_path);
> +
> +	if (offset == -FDT_ERR_NOTFOUND)
> +		return NULL;
> +
> +	return fdt_getprop(fdt, offset, property, NULL);
> +}
> +
> +static uint32_t get_addr_size(const void *fdt)
> +{
> +	const __be32 *addr_len = getprop(fdt, "/", "#address-cells");
> +
> +	if (!addr_len) {
> +		/* default */
> +		return 1;
> +	}
> +
> +	return fdt32_to_cpu(*addr_len);
> +}
> +
> +/*
> + * Get the start of physical memory
> + */
> +
> +unsigned long fdt_get_mem_start(const void *fdt)
> +{
> +	const __be32 *memory;
> +	uint32_t addr_size;
> +
> +	if (!fdt)
> +		return -1;
> +
> +	if (*(__be32 *)fdt != cpu_to_fdt32(FDT_MAGIC))
> +		return -1;
> +
> +	/* Find the first memory node */
> +	memory = getprop(fdt, "/memory", "reg");
> +	if (!memory)
> +		return -1;
> +
> +	/* There may be multiple cells on LPAE platforms */
> +	addr_size = get_addr_size(fdt);
> +
> +	return fdt32_to_cpu(memory[addr_size - 1]);
> +}
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 927f5dc413d7dff2..aa2d7de2ddc86fa8 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -235,8 +235,56 @@ not_angel:
>   		.text
>   
>   #ifdef CONFIG_AUTO_ZRELADDR
> +#ifdef CONFIG_USE_OF
>   		/*
> -		 * Find the start of physical memory.  As we are executing
> +		 * Find the start of physical memory.
> +		 * Try the DTB first, if available.
> +		 */
> +		adr	r0, LC0
> +		ldr	r1, [r0]	@ get absolute LC0
> +		ldr	sp, [r0, #28]	@ get stack location
> +		sub	r1, r0, r1	@ compute relocation offset
> +		add	sp, sp, r1	@ apply relocation
> +
> +#ifdef CONFIG_ARM_APPENDED_DTB
> +		/*
> +		 * Look for an appended DTB. If found, use it and
> +		 * move stack away from it.
> +		 */
> +		ldr	r6, [r0, #12]	@ get &_edata
> +		add	r6, r6, r1	@ relocate it
> +		ldmia	r6, {r0, r5}	@ get DTB signature and size
> +#ifndef __ARMEB__
> +		ldr	r1, =0xedfe0dd0	@ sig is 0xd00dfeed big endian
> +		/* convert DTB size to little endian */
> +		eor	r2, r5, r5, ror #16
> +		bic	r2, r2, #0x00ff0000
> +		mov	r5, r5, ror #8
> +		eor	r5, r5, r2, lsr #8
> +#else
> +		ldr	r1, =0xd00dfeed
> +#endif
> +		cmp	r0, r1		@ do we have a DTB there?
> +		bne	1f
> +
> +		mov	r8, r6		@ use it if so
> +		/* preserve 64-bit alignment */
> +		add	r5, r5, #7
> +		bic	r5, r5, #7
> +		add	sp, sp, r5	@ and move stack above it
> +
> +1:
> +#endif /* CONFIG_ARM_APPENDED_DTB */
> +
> +		mov	r0, r8
> +		bl	fdt_get_mem_start
> +		mov	r4, r0
> +		cmp	r0, #-1
> +		bne	1f
> +#endif /* CONFIG_USE_OF */
> +
> +		/*
> +		 * Fall back to the traditional method.  As we are executing
>   		 * without the MMU on, we are in the physical address space.
>   		 * We just need to get rid of any offset by aligning the
>   		 * address.
> @@ -254,6 +302,8 @@ not_angel:
>   		 */
>   		mov	r4, pc
>   		and	r4, r4, #0xf8000000
> +
> +1:
>   		/* Determine final kernel image address. */
>   		add	r4, r4, #TEXT_OFFSET
>   #else

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Marek Szyprowski]

Hi Geert,

On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> Currently, the start address of physical memory is obtained by masking
> the program counter with a fixed mask of 0xf8000000.  This mask value
> was chosen as a balance between the requirements of different platforms.
> However, this does require that the start address of physical memory is
> a multiple of 128 MiB, precluding booting Linux on platforms where this
> requirement is not fulfilled.
>
> Fix this limitation by obtaining the start address from the DTB instead,
> if available (either explicitly passed, or appended to the kernel).
> Fall back to the traditional method when needed.
>
> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> i.e. not at a multiple of 128 MiB.
>
> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> Against arm/for-next.

This patch landed recently in linux-next. It breaks legacy booting from 
the zImage + appended DT + cmdline/memory info provided via ATAGs. I 
will debug it further once I find some spare time. What I noticed so 
far, the cmdline/memory info is not read from the ATAGs, only the values 
provided via appended DT are used.

> Tested with the following configurations:
>    - zImage + DTB (r8a7791/koelsch),
>    - uImage + DTB (r8a73a4/ape6evm, r7s72100/rskrza1, r7s9210/rza2mevb),
>    - zImage with appended DTB (r8a7740/armadillo, sh73a0/kzm9g).
>
> v2:
>    - Use "cmp r0, #-1", instead of "cmn r0, #1",
>    - Add missing stack setup,
>    - Support appended DTBs.
>
> v1: https://lore.kernel.org/linux-arm-kernel/20200121192741.20597-1-geert+renesas@glider.be/
> ---
>   arch/arm/boot/compressed/Makefile            |  6 ++-
>   arch/arm/boot/compressed/fdt_get_mem_start.c | 52 ++++++++++++++++++++
>   arch/arm/boot/compressed/head.S              | 52 +++++++++++++++++++-
>   3 files changed, 108 insertions(+), 2 deletions(-)
>   create mode 100644 arch/arm/boot/compressed/fdt_get_mem_start.c
>
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index da599c3a11934332..bbfecd648a1a3b57 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -86,12 +86,15 @@ libfdt_objs	:= $(addsuffix .o, $(basename $(libfdt)))
>   $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/%
>   	$(call cmd,shipped)
>   
> -$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
> +$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o fdt_get_mem_start.o): \
>   	$(addprefix $(obj)/,$(libfdt_hdrs))
>   
>   ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>   OBJS	+= $(libfdt_objs) atags_to_fdt.o
>   endif
> +ifeq ($(CONFIG_USE_OF),y)
> +OBJS	+= $(libfdt_objs) fdt_get_mem_start.o
> +endif
>   
>   targets       := vmlinux vmlinux.lds piggy_data piggy.o \
>   		 lib1funcs.o ashldi3.o bswapsdi2.o \
> @@ -116,6 +119,7 @@ CFLAGS_fdt.o := $(nossp-flags-y)
>   CFLAGS_fdt_ro.o := $(nossp-flags-y)
>   CFLAGS_fdt_rw.o := $(nossp-flags-y)
>   CFLAGS_fdt_wip.o := $(nossp-flags-y)
> +CFLAGS_fdt_get_mem_start.o := $(nossp-flags-y)
>   
>   ccflags-y := -fpic $(call cc-option,-mno-single-pic-base,) -fno-builtin -I$(obj)
>   asflags-y := -DZIMAGE
> diff --git a/arch/arm/boot/compressed/fdt_get_mem_start.c b/arch/arm/boot/compressed/fdt_get_mem_start.c
> new file mode 100644
> index 0000000000000000..2c5ac47f656317ee
> --- /dev/null
> +++ b/arch/arm/boot/compressed/fdt_get_mem_start.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <libfdt.h>
> +
> +static const void *getprop(const void *fdt, const char *node_path,
> +			   const char *property)
> +{
> +	int offset = fdt_path_offset(fdt, node_path);
> +
> +	if (offset == -FDT_ERR_NOTFOUND)
> +		return NULL;
> +
> +	return fdt_getprop(fdt, offset, property, NULL);
> +}
> +
> +static uint32_t get_addr_size(const void *fdt)
> +{
> +	const __be32 *addr_len = getprop(fdt, "/", "#address-cells");
> +
> +	if (!addr_len) {
> +		/* default */
> +		return 1;
> +	}
> +
> +	return fdt32_to_cpu(*addr_len);
> +}
> +
> +/*
> + * Get the start of physical memory
> + */
> +
> +unsigned long fdt_get_mem_start(const void *fdt)
> +{
> +	const __be32 *memory;
> +	uint32_t addr_size;
> +
> +	if (!fdt)
> +		return -1;
> +
> +	if (*(__be32 *)fdt != cpu_to_fdt32(FDT_MAGIC))
> +		return -1;
> +
> +	/* Find the first memory node */
> +	memory = getprop(fdt, "/memory", "reg");
> +	if (!memory)
> +		return -1;
> +
> +	/* There may be multiple cells on LPAE platforms */
> +	addr_size = get_addr_size(fdt);
> +
> +	return fdt32_to_cpu(memory[addr_size - 1]);
> +}
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 927f5dc413d7dff2..aa2d7de2ddc86fa8 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -235,8 +235,56 @@ not_angel:
>   		.text
>   
>   #ifdef CONFIG_AUTO_ZRELADDR
> +#ifdef CONFIG_USE_OF
>   		/*
> -		 * Find the start of physical memory.  As we are executing
> +		 * Find the start of physical memory.
> +		 * Try the DTB first, if available.
> +		 */
> +		adr	r0, LC0
> +		ldr	r1, [r0]	@ get absolute LC0
> +		ldr	sp, [r0, #28]	@ get stack location
> +		sub	r1, r0, r1	@ compute relocation offset
> +		add	sp, sp, r1	@ apply relocation
> +
> +#ifdef CONFIG_ARM_APPENDED_DTB
> +		/*
> +		 * Look for an appended DTB. If found, use it and
> +		 * move stack away from it.
> +		 */
> +		ldr	r6, [r0, #12]	@ get &_edata
> +		add	r6, r6, r1	@ relocate it
> +		ldmia	r6, {r0, r5}	@ get DTB signature and size
> +#ifndef __ARMEB__
> +		ldr	r1, =0xedfe0dd0	@ sig is 0xd00dfeed big endian
> +		/* convert DTB size to little endian */
> +		eor	r2, r5, r5, ror #16
> +		bic	r2, r2, #0x00ff0000
> +		mov	r5, r5, ror #8
> +		eor	r5, r5, r2, lsr #8
> +#else
> +		ldr	r1, =0xd00dfeed
> +#endif
> +		cmp	r0, r1		@ do we have a DTB there?
> +		bne	1f
> +
> +		mov	r8, r6		@ use it if so
> +		/* preserve 64-bit alignment */
> +		add	r5, r5, #7
> +		bic	r5, r5, #7
> +		add	sp, sp, r5	@ and move stack above it
> +
> +1:
> +#endif /* CONFIG_ARM_APPENDED_DTB */
> +
> +		mov	r0, r8
> +		bl	fdt_get_mem_start
> +		mov	r4, r0
> +		cmp	r0, #-1
> +		bne	1f
> +#endif /* CONFIG_USE_OF */
> +
> +		/*
> +		 * Fall back to the traditional method.  As we are executing
>   		 * without the MMU on, we are in the physical address space.
>   		 * We just need to get rid of any offset by aligning the
>   		 * address.
> @@ -254,6 +302,8 @@ not_angel:
>   		 */
>   		mov	r4, pc
>   		and	r4, r4, #0xf8000000
> +
> +1:
>   		/* Determine final kernel image address. */
>   		add	r4, r4, #TEXT_OFFSET
>   #else

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Marek,

On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> > Currently, the start address of physical memory is obtained by masking
> > the program counter with a fixed mask of 0xf8000000.  This mask value
> > was chosen as a balance between the requirements of different platforms.
> > However, this does require that the start address of physical memory is
> > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > requirement is not fulfilled.
> >
> > Fix this limitation by obtaining the start address from the DTB instead,
> > if available (either explicitly passed, or appended to the kernel).
> > Fall back to the traditional method when needed.
> >
> > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > i.e. not at a multiple of 128 MiB.
> >
> > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > ---
> > Against arm/for-next.
>
> This patch landed recently in linux-next. It breaks legacy booting from
> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> will debug it further once I find some spare time. What I noticed so
> far, the cmdline/memory info is not read from the ATAGs, only the values
> provided via appended DT are used.

Oops, something happening like this was one of my biggest worries when
posting this patch... Sorry for the breakage.

IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?

I'll have a closer look later today.
In the mean time, I've sent some debug code I used when developing
this patch, which may be useful, hopefully.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Marek,

On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> > Currently, the start address of physical memory is obtained by masking
> > the program counter with a fixed mask of 0xf8000000.  This mask value
> > was chosen as a balance between the requirements of different platforms.
> > However, this does require that the start address of physical memory is
> > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > requirement is not fulfilled.
> >
> > Fix this limitation by obtaining the start address from the DTB instead,
> > if available (either explicitly passed, or appended to the kernel).
> > Fall back to the traditional method when needed.
> >
> > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > i.e. not at a multiple of 128 MiB.
> >
> > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > ---
> > Against arm/for-next.
>
> This patch landed recently in linux-next. It breaks legacy booting from
> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> will debug it further once I find some spare time. What I noticed so
> far, the cmdline/memory info is not read from the ATAGs, only the values
> provided via appended DT are used.

Oops, something happening like this was one of my biggest worries when
posting this patch... Sorry for the breakage.

IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?

I'll have a closer look later today.
In the mean time, I've sent some debug code I used when developing
this patch, which may be useful, hopefully.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

25.02.2020 14:40, Geert Uytterhoeven пишет:
> Hi Marek,
> 
> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>> Currently, the start address of physical memory is obtained by masking
>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>> was chosen as a balance between the requirements of different platforms.
>>> However, this does require that the start address of physical memory is
>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>> requirement is not fulfilled.
>>>
>>> Fix this limitation by obtaining the start address from the DTB instead,
>>> if available (either explicitly passed, or appended to the kernel).
>>> Fall back to the traditional method when needed.
>>>
>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>> i.e. not at a multiple of 128 MiB.
>>>
>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>>> ---
>>> Against arm/for-next.
>>
>> This patch landed recently in linux-next. It breaks legacy booting from
>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>> will debug it further once I find some spare time. What I noticed so
>> far, the cmdline/memory info is not read from the ATAGs, only the values
>> provided via appended DT are used.
> 
> Oops, something happening like this was one of my biggest worries when
> posting this patch... Sorry for the breakage.
> 
> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> 
> I'll have a closer look later today.
> In the mean time, I've sent some debug code I used when developing
> this patch, which may be useful, hopefully.

Hello,

NVIDIA Tegra is also affected by this patch. A week ago an updated
version of the patch was pushed into linux-next and now machine doesn't
boot at all.

I couldn't find v3 on the ML, so replying to the v2. Please take a look
and fix the problem, or revert/drop the offending patch, thanks in advance.

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

25.02.2020 14:40, Geert Uytterhoeven пишет:
> Hi Marek,
> 
> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>> Currently, the start address of physical memory is obtained by masking
>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>> was chosen as a balance between the requirements of different platforms.
>>> However, this does require that the start address of physical memory is
>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>> requirement is not fulfilled.
>>>
>>> Fix this limitation by obtaining the start address from the DTB instead,
>>> if available (either explicitly passed, or appended to the kernel).
>>> Fall back to the traditional method when needed.
>>>
>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>> i.e. not at a multiple of 128 MiB.
>>>
>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>>> ---
>>> Against arm/for-next.
>>
>> This patch landed recently in linux-next. It breaks legacy booting from
>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>> will debug it further once I find some spare time. What I noticed so
>> far, the cmdline/memory info is not read from the ATAGs, only the values
>> provided via appended DT are used.
> 
> Oops, something happening like this was one of my biggest worries when
> posting this patch... Sorry for the breakage.
> 
> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> 
> I'll have a closer look later today.
> In the mean time, I've sent some debug code I used when developing
> this patch, which may be useful, hopefully.

Hello,

NVIDIA Tegra is also affected by this patch. A week ago an updated
version of the patch was pushed into linux-next and now machine doesn't
boot at all.

I couldn't find v3 on the ML, so replying to the v2. Please take a look
and fix the problem, or revert/drop the offending patch, thanks in advance.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

25.02.2020 14:40, Geert Uytterhoeven пишет:
> Hi Marek,
> 
> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>> Currently, the start address of physical memory is obtained by masking
>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>> was chosen as a balance between the requirements of different platforms.
>>> However, this does require that the start address of physical memory is
>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>> requirement is not fulfilled.
>>>
>>> Fix this limitation by obtaining the start address from the DTB instead,
>>> if available (either explicitly passed, or appended to the kernel).
>>> Fall back to the traditional method when needed.
>>>
>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>> i.e. not at a multiple of 128 MiB.
>>>
>>> Suggested-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>>> Reviewed-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
>>> ---
>>> Against arm/for-next.
>>
>> This patch landed recently in linux-next. It breaks legacy booting from
>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>> will debug it further once I find some spare time. What I noticed so
>> far, the cmdline/memory info is not read from the ATAGs, only the values
>> provided via appended DT are used.
> 
> Oops, something happening like this was one of my biggest worries when
> posting this patch... Sorry for the breakage.
> 
> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> 
> I'll have a closer look later today.
> In the mean time, I've sent some debug code I used when developing
> this patch, which may be useful, hopefully.

Hello,

NVIDIA Tegra is also affected by this patch. A week ago an updated
version of the patch was pushed into linux-next and now machine doesn't
boot at all.

I couldn't find v3 on the ML, so replying to the v2. Please take a look
and fix the problem, or revert/drop the offending patch, thanks in advance.

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry,

On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>> Currently, the start address of physical memory is obtained by masking
> >>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>> was chosen as a balance between the requirements of different platforms.
> >>> However, this does require that the start address of physical memory is
> >>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>> requirement is not fulfilled.
> >>>
> >>> Fix this limitation by obtaining the start address from the DTB instead,
> >>> if available (either explicitly passed, or appended to the kernel).
> >>> Fall back to the traditional method when needed.
> >>>
> >>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>> i.e. not at a multiple of 128 MiB.
> >>>
> >>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> >>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> >>> ---
> >>> Against arm/for-next.
> >>
> >> This patch landed recently in linux-next. It breaks legacy booting from
> >> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >> will debug it further once I find some spare time. What I noticed so
> >> far, the cmdline/memory info is not read from the ATAGs, only the values
> >> provided via appended DT are used.
> >
> > Oops, something happening like this was one of my biggest worries when
> > posting this patch... Sorry for the breakage.
> >
> > IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> >
> > I'll have a closer look later today.
> > In the mean time, I've sent some debug code I used when developing
> > this patch, which may be useful, hopefully.
>
> NVIDIA Tegra is also affected by this patch. A week ago an updated
> version of the patch was pushed into linux-next and now machine doesn't
> boot at all.

I'm sorry to hear that.

Did v2 work for you?
Are you sure this updated version is the culprit? There are several other
recent changes to head.S in arm/for-next.

Do you boot a separate DTB or an appended DTB?
Do you use ATAGS?

> I couldn't find v3 on the ML, so replying to the v2. Please take a look
> and fix the problem, or revert/drop the offending patch, thanks in advance.

V3 is v2 combined with "[PATCH] ARM: boot: Fix ATAGs with appended DTB"
(https://lore.kernel.org/linux-renesas-soc/20200225144749.19815-1-geert+renesas@glider.be/).


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry,

On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>> Currently, the start address of physical memory is obtained by masking
> >>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>> was chosen as a balance between the requirements of different platforms.
> >>> However, this does require that the start address of physical memory is
> >>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>> requirement is not fulfilled.
> >>>
> >>> Fix this limitation by obtaining the start address from the DTB instead,
> >>> if available (either explicitly passed, or appended to the kernel).
> >>> Fall back to the traditional method when needed.
> >>>
> >>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>> i.e. not at a multiple of 128 MiB.
> >>>
> >>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> >>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> >>> ---
> >>> Against arm/for-next.
> >>
> >> This patch landed recently in linux-next. It breaks legacy booting from
> >> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >> will debug it further once I find some spare time. What I noticed so
> >> far, the cmdline/memory info is not read from the ATAGs, only the values
> >> provided via appended DT are used.
> >
> > Oops, something happening like this was one of my biggest worries when
> > posting this patch... Sorry for the breakage.
> >
> > IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> >
> > I'll have a closer look later today.
> > In the mean time, I've sent some debug code I used when developing
> > this patch, which may be useful, hopefully.
>
> NVIDIA Tegra is also affected by this patch. A week ago an updated
> version of the patch was pushed into linux-next and now machine doesn't
> boot at all.

I'm sorry to hear that.

Did v2 work for you?
Are you sure this updated version is the culprit? There are several other
recent changes to head.S in arm/for-next.

Do you boot a separate DTB or an appended DTB?
Do you use ATAGS?

> I couldn't find v3 on the ML, so replying to the v2. Please take a look
> and fix the problem, or revert/drop the offending patch, thanks in advance.

V3 is v2 combined with "[PATCH] ARM: boot: Fix ATAGs with appended DTB"
(https://lore.kernel.org/linux-renesas-soc/20200225144749.19815-1-geert+renesas@glider.be/).


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry,

On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> >> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>> Currently, the start address of physical memory is obtained by masking
> >>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>> was chosen as a balance between the requirements of different platforms.
> >>> However, this does require that the start address of physical memory is
> >>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>> requirement is not fulfilled.
> >>>
> >>> Fix this limitation by obtaining the start address from the DTB instead,
> >>> if available (either explicitly passed, or appended to the kernel).
> >>> Fall back to the traditional method when needed.
> >>>
> >>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>> i.e. not at a multiple of 128 MiB.
> >>>
> >>> Suggested-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> >>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> >>> Reviewed-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> >>> ---
> >>> Against arm/for-next.
> >>
> >> This patch landed recently in linux-next. It breaks legacy booting from
> >> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >> will debug it further once I find some spare time. What I noticed so
> >> far, the cmdline/memory info is not read from the ATAGs, only the values
> >> provided via appended DT are used.
> >
> > Oops, something happening like this was one of my biggest worries when
> > posting this patch... Sorry for the breakage.
> >
> > IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> >
> > I'll have a closer look later today.
> > In the mean time, I've sent some debug code I used when developing
> > this patch, which may be useful, hopefully.
>
> NVIDIA Tegra is also affected by this patch. A week ago an updated
> version of the patch was pushed into linux-next and now machine doesn't
> boot at all.

I'm sorry to hear that.

Did v2 work for you?
Are you sure this updated version is the culprit? There are several other
recent changes to head.S in arm/for-next.

Do you boot a separate DTB or an appended DTB?
Do you use ATAGS?

> I couldn't find v3 on the ML, so replying to the v2. Please take a look
> and fix the problem, or revert/drop the offending patch, thanks in advance.

V3 is v2 combined with "[PATCH] ARM: boot: Fix ATAGs with appended DTB"
(https://lore.kernel.org/linux-renesas-soc/20200225144749.19815-1-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org/).


Gr{oetje,eeting}s,

                        Geert

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

19.03.2020 11:18, Geert Uytterhoeven пишет:
> Hi Dmitry,
> 
> On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>> 25.02.2020 14:40, Geert Uytterhoeven пишет:
>>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>>>> Currently, the start address of physical memory is obtained by masking
>>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>>>> was chosen as a balance between the requirements of different platforms.
>>>>> However, this does require that the start address of physical memory is
>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>> requirement is not fulfilled.
>>>>>
>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>> Fall back to the traditional method when needed.
>>>>>
>>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>>>> i.e. not at a multiple of 128 MiB.
>>>>>
>>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> ---
>>>>> Against arm/for-next.
>>>>
>>>> This patch landed recently in linux-next. It breaks legacy booting from
>>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>>>> will debug it further once I find some spare time. What I noticed so
>>>> far, the cmdline/memory info is not read from the ATAGs, only the values
>>>> provided via appended DT are used.
>>>
>>> Oops, something happening like this was one of my biggest worries when
>>> posting this patch... Sorry for the breakage.
>>>
>>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
>>>
>>> I'll have a closer look later today.
>>> In the mean time, I've sent some debug code I used when developing
>>> this patch, which may be useful, hopefully.
>>
>> NVIDIA Tegra is also affected by this patch. A week ago an updated
>> version of the patch was pushed into linux-next and now machine doesn't
>> boot at all.
> 
> I'm sorry to hear that.
> 
> Did v2 work for you?

Same as it was for Marek.

> Are you sure this updated version is the culprit? There are several other
> recent changes to head.S in arm/for-next.

Yes

> Do you boot a separate DTB or an appended DTB?

Appended

> Do you use ATAGS?

Yes

>> I couldn't find v3 on the ML, so replying to the v2. Please take a look
>> and fix the problem, or revert/drop the offending patch, thanks in advance.
> 
> V3 is v2 combined with "[PATCH] ARM: boot: Fix ATAGs with appended DTB"
> (https://lore.kernel.org/linux-renesas-soc/20200225144749.19815-1-geert+renesas@glider.be/).

Thank you for the clarification.

I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
disabling thumb2 build fixes the problem. Please correct it in the next
version of the patch, thanks in advance.

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

19.03.2020 11:18, Geert Uytterhoeven пишет:
> Hi Dmitry,
> 
> On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>> 25.02.2020 14:40, Geert Uytterhoeven пишет:
>>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>>>> Currently, the start address of physical memory is obtained by masking
>>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>>>> was chosen as a balance between the requirements of different platforms.
>>>>> However, this does require that the start address of physical memory is
>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>> requirement is not fulfilled.
>>>>>
>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>> Fall back to the traditional method when needed.
>>>>>
>>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>>>> i.e. not at a multiple of 128 MiB.
>>>>>
>>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> ---
>>>>> Against arm/for-next.
>>>>
>>>> This patch landed recently in linux-next. It breaks legacy booting from
>>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>>>> will debug it further once I find some spare time. What I noticed so
>>>> far, the cmdline/memory info is not read from the ATAGs, only the values
>>>> provided via appended DT are used.
>>>
>>> Oops, something happening like this was one of my biggest worries when
>>> posting this patch... Sorry for the breakage.
>>>
>>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
>>>
>>> I'll have a closer look later today.
>>> In the mean time, I've sent some debug code I used when developing
>>> this patch, which may be useful, hopefully.
>>
>> NVIDIA Tegra is also affected by this patch. A week ago an updated
>> version of the patch was pushed into linux-next and now machine doesn't
>> boot at all.
> 
> I'm sorry to hear that.
> 
> Did v2 work for you?

Same as it was for Marek.

> Are you sure this updated version is the culprit? There are several other
> recent changes to head.S in arm/for-next.

Yes

> Do you boot a separate DTB or an appended DTB?

Appended

> Do you use ATAGS?

Yes

>> I couldn't find v3 on the ML, so replying to the v2. Please take a look
>> and fix the problem, or revert/drop the offending patch, thanks in advance.
> 
> V3 is v2 combined with "[PATCH] ARM: boot: Fix ATAGs with appended DTB"
> (https://lore.kernel.org/linux-renesas-soc/20200225144749.19815-1-geert+renesas@glider.be/).

Thank you for the clarification.

I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
disabling thumb2 build fixes the problem. Please correct it in the next
version of the patch, thanks in advance.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

19.03.2020 11:18, Geert Uytterhoeven пишет:
> Hi Dmitry,
> 
> On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> 25.02.2020 14:40, Geert Uytterhoeven пишет:
>>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
>>> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>>>> Currently, the start address of physical memory is obtained by masking
>>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>>>> was chosen as a balance between the requirements of different platforms.
>>>>> However, this does require that the start address of physical memory is
>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>> requirement is not fulfilled.
>>>>>
>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>> Fall back to the traditional method when needed.
>>>>>
>>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>>>> i.e. not at a multiple of 128 MiB.
>>>>>
>>>>> Suggested-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>>>>> Reviewed-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
>>>>> ---
>>>>> Against arm/for-next.
>>>>
>>>> This patch landed recently in linux-next. It breaks legacy booting from
>>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>>>> will debug it further once I find some spare time. What I noticed so
>>>> far, the cmdline/memory info is not read from the ATAGs, only the values
>>>> provided via appended DT are used.
>>>
>>> Oops, something happening like this was one of my biggest worries when
>>> posting this patch... Sorry for the breakage.
>>>
>>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
>>>
>>> I'll have a closer look later today.
>>> In the mean time, I've sent some debug code I used when developing
>>> this patch, which may be useful, hopefully.
>>
>> NVIDIA Tegra is also affected by this patch. A week ago an updated
>> version of the patch was pushed into linux-next and now machine doesn't
>> boot at all.
> 
> I'm sorry to hear that.
> 
> Did v2 work for you?

Same as it was for Marek.

> Are you sure this updated version is the culprit? There are several other
> recent changes to head.S in arm/for-next.

Yes

> Do you boot a separate DTB or an appended DTB?

Appended

> Do you use ATAGS?

Yes

>> I couldn't find v3 on the ML, so replying to the v2. Please take a look
>> and fix the problem, or revert/drop the offending patch, thanks in advance.
> 
> V3 is v2 combined with "[PATCH] ARM: boot: Fix ATAGs with appended DTB"
> (https://lore.kernel.org/linux-renesas-soc/20200225144749.19815-1-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org/).

Thank you for the clarification.

I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
disabling thumb2 build fixes the problem. Please correct it in the next
version of the patch, thanks in advance.

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry,

On Thu, Mar 19, 2020 at 3:35 PM Dmitry Osipenko <digetx@gmail.com> wrote:
> 19.03.2020 11:18, Geert Uytterhoeven пишет:
> > On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> >> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> >>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> >>> <m.szyprowski@samsung.com> wrote:
> >>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>>>> Currently, the start address of physical memory is obtained by masking
> >>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>>>> was chosen as a balance between the requirements of different platforms.
> >>>>> However, this does require that the start address of physical memory is
> >>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>>>> requirement is not fulfilled.
> >>>>>
> >>>>> Fix this limitation by obtaining the start address from the DTB instead,
> >>>>> if available (either explicitly passed, or appended to the kernel).
> >>>>> Fall back to the traditional method when needed.
> >>>>>
> >>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>>>> i.e. not at a multiple of 128 MiB.
> >>>>>
> >>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> >>>>> ---
> >>>>> Against arm/for-next.
> >>>>
> >>>> This patch landed recently in linux-next. It breaks legacy booting from
> >>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >>>> will debug it further once I find some spare time. What I noticed so
> >>>> far, the cmdline/memory info is not read from the ATAGs, only the values
> >>>> provided via appended DT are used.
> >>>
> >>> Oops, something happening like this was one of my biggest worries when
> >>> posting this patch... Sorry for the breakage.
> >>>
> >>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> >>>
> >>> I'll have a closer look later today.
> >>> In the mean time, I've sent some debug code I used when developing
> >>> this patch, which may be useful, hopefully.
> >>
> >> NVIDIA Tegra is also affected by this patch. A week ago an updated
> >> version of the patch was pushed into linux-next and now machine doesn't
> >> boot at all.
> >
> > I'm sorry to hear that.
> >
> > Did v2 work for you?
>
> Same as it was for Marek.
>
> > Are you sure this updated version is the culprit? There are several other
> > recent changes to head.S in arm/for-next.
>
> Yes
>
> > Do you boot a separate DTB or an appended DTB?
>
> Appended
>
> > Do you use ATAGS?
>
> Yes

Thanks for the info!

> I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
> disabling thumb2 build fixes the problem. Please correct it in the next
> version of the patch, thanks in advance.

Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
a difference for the few board combos I've tried (with/without appended DTB).
So it must be related to ATAGS.  Will dive deeper...

P.S. I never realized CONFIG_THUMB2_KERNEL=y had such a big size
impact: my kernel shrunk by ca. 1 MiB.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry,

On Thu, Mar 19, 2020 at 3:35 PM Dmitry Osipenko <digetx@gmail.com> wrote:
> 19.03.2020 11:18, Geert Uytterhoeven пишет:
> > On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> >> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> >>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> >>> <m.szyprowski@samsung.com> wrote:
> >>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>>>> Currently, the start address of physical memory is obtained by masking
> >>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>>>> was chosen as a balance between the requirements of different platforms.
> >>>>> However, this does require that the start address of physical memory is
> >>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>>>> requirement is not fulfilled.
> >>>>>
> >>>>> Fix this limitation by obtaining the start address from the DTB instead,
> >>>>> if available (either explicitly passed, or appended to the kernel).
> >>>>> Fall back to the traditional method when needed.
> >>>>>
> >>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>>>> i.e. not at a multiple of 128 MiB.
> >>>>>
> >>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> >>>>> ---
> >>>>> Against arm/for-next.
> >>>>
> >>>> This patch landed recently in linux-next. It breaks legacy booting from
> >>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >>>> will debug it further once I find some spare time. What I noticed so
> >>>> far, the cmdline/memory info is not read from the ATAGs, only the values
> >>>> provided via appended DT are used.
> >>>
> >>> Oops, something happening like this was one of my biggest worries when
> >>> posting this patch... Sorry for the breakage.
> >>>
> >>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> >>>
> >>> I'll have a closer look later today.
> >>> In the mean time, I've sent some debug code I used when developing
> >>> this patch, which may be useful, hopefully.
> >>
> >> NVIDIA Tegra is also affected by this patch. A week ago an updated
> >> version of the patch was pushed into linux-next and now machine doesn't
> >> boot at all.
> >
> > I'm sorry to hear that.
> >
> > Did v2 work for you?
>
> Same as it was for Marek.
>
> > Are you sure this updated version is the culprit? There are several other
> > recent changes to head.S in arm/for-next.
>
> Yes
>
> > Do you boot a separate DTB or an appended DTB?
>
> Appended
>
> > Do you use ATAGS?
>
> Yes

Thanks for the info!

> I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
> disabling thumb2 build fixes the problem. Please correct it in the next
> version of the patch, thanks in advance.

Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
a difference for the few board combos I've tried (with/without appended DTB).
So it must be related to ATAGS.  Will dive deeper...

P.S. I never realized CONFIG_THUMB2_KERNEL=y had such a big size
impact: my kernel shrunk by ca. 1 MiB.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry,

On Thu, Mar 19, 2020 at 3:35 PM Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 19.03.2020 11:18, Geert Uytterhoeven пишет:
> > On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> >>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> >>> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> >>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>>>> Currently, the start address of physical memory is obtained by masking
> >>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>>>> was chosen as a balance between the requirements of different platforms.
> >>>>> However, this does require that the start address of physical memory is
> >>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>>>> requirement is not fulfilled.
> >>>>>
> >>>>> Fix this limitation by obtaining the start address from the DTB instead,
> >>>>> if available (either explicitly passed, or appended to the kernel).
> >>>>> Fall back to the traditional method when needed.
> >>>>>
> >>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>>>> i.e. not at a multiple of 128 MiB.
> >>>>>
> >>>>> Suggested-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> >>>>> Reviewed-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> >>>>> ---
> >>>>> Against arm/for-next.
> >>>>
> >>>> This patch landed recently in linux-next. It breaks legacy booting from
> >>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >>>> will debug it further once I find some spare time. What I noticed so
> >>>> far, the cmdline/memory info is not read from the ATAGs, only the values
> >>>> provided via appended DT are used.
> >>>
> >>> Oops, something happening like this was one of my biggest worries when
> >>> posting this patch... Sorry for the breakage.
> >>>
> >>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> >>>
> >>> I'll have a closer look later today.
> >>> In the mean time, I've sent some debug code I used when developing
> >>> this patch, which may be useful, hopefully.
> >>
> >> NVIDIA Tegra is also affected by this patch. A week ago an updated
> >> version of the patch was pushed into linux-next and now machine doesn't
> >> boot at all.
> >
> > I'm sorry to hear that.
> >
> > Did v2 work for you?
>
> Same as it was for Marek.
>
> > Are you sure this updated version is the culprit? There are several other
> > recent changes to head.S in arm/for-next.
>
> Yes
>
> > Do you boot a separate DTB or an appended DTB?
>
> Appended
>
> > Do you use ATAGS?
>
> Yes

Thanks for the info!

> I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
> disabling thumb2 build fixes the problem. Please correct it in the next
> version of the patch, thanks in advance.

Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
a difference for the few board combos I've tried (with/without appended DTB).
So it must be related to ATAGS.  Will dive deeper...

P.S. I never realized CONFIG_THUMB2_KERNEL=y had such a big size
impact: my kernel shrunk by ca. 1 MiB.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

20.03.2020 12:18, Geert Uytterhoeven пишет:
...
> Thanks for the info!
> 
>> I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
>> disabling thumb2 build fixes the problem. Please correct it in the next
>> version of the patch, thanks in advance.
> 
> Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
> a difference for the few board combos I've tried (with/without appended DTB).
> So it must be related to ATAGS.  Will dive deeper...
> 
> P.S. I never realized CONFIG_THUMB2_KERNEL=y had such a big size
> impact: my kernel shrunk by ca. 1 MiB.

A quick observation tells that fdt_get_mem_start() returns a wrong
address with CONFIG_THUMB2_KERNEL=y, I haven't tried to look further yet.

Disabling all ATAGS options in kernel's config doesn't help.

Kernel config:
https://gist.github.com/digetx/b7c4e1d2d4dae0c5566748c0d7f1e884

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

20.03.2020 12:18, Geert Uytterhoeven пишет:
...
> Thanks for the info!
> 
>> I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
>> disabling thumb2 build fixes the problem. Please correct it in the next
>> version of the patch, thanks in advance.
> 
> Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
> a difference for the few board combos I've tried (with/without appended DTB).
> So it must be related to ATAGS.  Will dive deeper...
> 
> P.S. I never realized CONFIG_THUMB2_KERNEL=y had such a big size
> impact: my kernel shrunk by ca. 1 MiB.

A quick observation tells that fdt_get_mem_start() returns a wrong
address with CONFIG_THUMB2_KERNEL=y, I haven't tried to look further yet.

Disabling all ATAGS options in kernel's config doesn't help.

Kernel config:
https://gist.github.com/digetx/b7c4e1d2d4dae0c5566748c0d7f1e884

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

20.03.2020 12:18, Geert Uytterhoeven пишет:
...
> Thanks for the info!
> 
>> I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
>> disabling thumb2 build fixes the problem. Please correct it in the next
>> version of the patch, thanks in advance.
> 
> Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
> a difference for the few board combos I've tried (with/without appended DTB).
> So it must be related to ATAGS.  Will dive deeper...
> 
> P.S. I never realized CONFIG_THUMB2_KERNEL=y had such a big size
> impact: my kernel shrunk by ca. 1 MiB.

A quick observation tells that fdt_get_mem_start() returns a wrong
address with CONFIG_THUMB2_KERNEL=y, I haven't tried to look further yet.

Disabling all ATAGS options in kernel's config doesn't help.

Kernel config:
https://gist.github.com/digetx/b7c4e1d2d4dae0c5566748c0d7f1e884

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry et al,

On Fri, Mar 20, 2020 at 10:18 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Mar 19, 2020 at 3:35 PM Dmitry Osipenko <digetx@gmail.com> wrote:
> > 19.03.2020 11:18, Geert Uytterhoeven пишет:
> > > On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> > >> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > >>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > >>> <m.szyprowski@samsung.com> wrote:
> > >>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> > >>>>> Currently, the start address of physical memory is obtained by masking
> > >>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
> > >>>>> was chosen as a balance between the requirements of different platforms.
> > >>>>> However, this does require that the start address of physical memory is
> > >>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> > >>>>> requirement is not fulfilled.
> > >>>>>
> > >>>>> Fix this limitation by obtaining the start address from the DTB instead,
> > >>>>> if available (either explicitly passed, or appended to the kernel).
> > >>>>> Fall back to the traditional method when needed.
> > >>>>>
> > >>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > >>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > >>>>> i.e. not at a multiple of 128 MiB.
> > >>>>>
> > >>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > >>>>> ---
> > >>>>> Against arm/for-next.
> > >>>>
> > >>>> This patch landed recently in linux-next. It breaks legacy booting from
> > >>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> > >>>> will debug it further once I find some spare time. What I noticed so
> > >>>> far, the cmdline/memory info is not read from the ATAGs, only the values
> > >>>> provided via appended DT are used.
> > >>>
> > >>> Oops, something happening like this was one of my biggest worries when
> > >>> posting this patch... Sorry for the breakage.
> > >>>
> > >>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> > >>>
> > >>> I'll have a closer look later today.
> > >>> In the mean time, I've sent some debug code I used when developing
> > >>> this patch, which may be useful, hopefully.
> > >>
> > >> NVIDIA Tegra is also affected by this patch. A week ago an updated
> > >> version of the patch was pushed into linux-next and now machine doesn't
> > >> boot at all.

> > I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
> > disabling thumb2 build fixes the problem. Please correct it in the next
> > version of the patch, thanks in advance.
>
> Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
> a difference for the few board combos I've tried (with/without appended DTB).
> So it must be related to ATAGS.  Will dive deeper...

I managed to reproduce it without ATAGS.

Turns out to be a bad interaction with commit 184bf653a7a452c1 ("ARM:
decompressor: factor out routine to obtain the inflated image size"),
which removed one entry from the data array at LC0.  While that commit
updated all then-existing users, merging Ard's pull request didn't take
into account that a new user had emerged, which also needed updating.

When CONFIG_THUMB2_KERNEL=y, the stack pointer becomes 2-byte
instead of 4-byte aligned, causing a crash.
When CONFIG_THUMB2_KERNEL=n, it still works, probably by accident.

                adr     r0, LC0
                ldr     r1, [r0]        @ get absolute LC0
-               ldr     sp, [r0, #28]   @ get stack location
+               ldr     sp, [r0, #24]   @ get stack location

in arch/arm/boot/compressed/head.S fixes the issue for me.

Will send v4 shortly.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry et al,

On Fri, Mar 20, 2020 at 10:18 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Mar 19, 2020 at 3:35 PM Dmitry Osipenko <digetx@gmail.com> wrote:
> > 19.03.2020 11:18, Geert Uytterhoeven пишет:
> > > On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> > >> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > >>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > >>> <m.szyprowski@samsung.com> wrote:
> > >>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> > >>>>> Currently, the start address of physical memory is obtained by masking
> > >>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
> > >>>>> was chosen as a balance between the requirements of different platforms.
> > >>>>> However, this does require that the start address of physical memory is
> > >>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> > >>>>> requirement is not fulfilled.
> > >>>>>
> > >>>>> Fix this limitation by obtaining the start address from the DTB instead,
> > >>>>> if available (either explicitly passed, or appended to the kernel).
> > >>>>> Fall back to the traditional method when needed.
> > >>>>>
> > >>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > >>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > >>>>> i.e. not at a multiple of 128 MiB.
> > >>>>>
> > >>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > >>>>> ---
> > >>>>> Against arm/for-next.
> > >>>>
> > >>>> This patch landed recently in linux-next. It breaks legacy booting from
> > >>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> > >>>> will debug it further once I find some spare time. What I noticed so
> > >>>> far, the cmdline/memory info is not read from the ATAGs, only the values
> > >>>> provided via appended DT are used.
> > >>>
> > >>> Oops, something happening like this was one of my biggest worries when
> > >>> posting this patch... Sorry for the breakage.
> > >>>
> > >>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> > >>>
> > >>> I'll have a closer look later today.
> > >>> In the mean time, I've sent some debug code I used when developing
> > >>> this patch, which may be useful, hopefully.
> > >>
> > >> NVIDIA Tegra is also affected by this patch. A week ago an updated
> > >> version of the patch was pushed into linux-next and now machine doesn't
> > >> boot at all.

> > I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
> > disabling thumb2 build fixes the problem. Please correct it in the next
> > version of the patch, thanks in advance.
>
> Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
> a difference for the few board combos I've tried (with/without appended DTB).
> So it must be related to ATAGS.  Will dive deeper...

I managed to reproduce it without ATAGS.

Turns out to be a bad interaction with commit 184bf653a7a452c1 ("ARM:
decompressor: factor out routine to obtain the inflated image size"),
which removed one entry from the data array at LC0.  While that commit
updated all then-existing users, merging Ard's pull request didn't take
into account that a new user had emerged, which also needed updating.

When CONFIG_THUMB2_KERNEL=y, the stack pointer becomes 2-byte
instead of 4-byte aligned, causing a crash.
When CONFIG_THUMB2_KERNEL=n, it still works, probably by accident.

                adr     r0, LC0
                ldr     r1, [r0]        @ get absolute LC0
-               ldr     sp, [r0, #28]   @ get stack location
+               ldr     sp, [r0, #24]   @ get stack location

in arch/arm/boot/compressed/head.S fixes the issue for me.

Will send v4 shortly.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Geert Uytterhoeven]

Hi Dmitry et al,

On Fri, Mar 20, 2020 at 10:18 AM Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> On Thu, Mar 19, 2020 at 3:35 PM Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 19.03.2020 11:18, Geert Uytterhoeven пишет:
> > > On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > >>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > >>> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> > >>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> > >>>>> Currently, the start address of physical memory is obtained by masking
> > >>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
> > >>>>> was chosen as a balance between the requirements of different platforms.
> > >>>>> However, this does require that the start address of physical memory is
> > >>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> > >>>>> requirement is not fulfilled.
> > >>>>>
> > >>>>> Fix this limitation by obtaining the start address from the DTB instead,
> > >>>>> if available (either explicitly passed, or appended to the kernel).
> > >>>>> Fall back to the traditional method when needed.
> > >>>>>
> > >>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > >>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > >>>>> i.e. not at a multiple of 128 MiB.
> > >>>>>
> > >>>>> Suggested-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> > >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> > >>>>> Reviewed-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> > >>>>> ---
> > >>>>> Against arm/for-next.
> > >>>>
> > >>>> This patch landed recently in linux-next. It breaks legacy booting from
> > >>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> > >>>> will debug it further once I find some spare time. What I noticed so
> > >>>> far, the cmdline/memory info is not read from the ATAGs, only the values
> > >>>> provided via appended DT are used.
> > >>>
> > >>> Oops, something happening like this was one of my biggest worries when
> > >>> posting this patch... Sorry for the breakage.
> > >>>
> > >>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> > >>>
> > >>> I'll have a closer look later today.
> > >>> In the mean time, I've sent some debug code I used when developing
> > >>> this patch, which may be useful, hopefully.
> > >>
> > >> NVIDIA Tegra is also affected by this patch. A week ago an updated
> > >> version of the patch was pushed into linux-next and now machine doesn't
> > >> boot at all.

> > I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
> > disabling thumb2 build fixes the problem. Please correct it in the next
> > version of the patch, thanks in advance.
>
> Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
> a difference for the few board combos I've tried (with/without appended DTB).
> So it must be related to ATAGS.  Will dive deeper...

I managed to reproduce it without ATAGS.

Turns out to be a bad interaction with commit 184bf653a7a452c1 ("ARM:
decompressor: factor out routine to obtain the inflated image size"),
which removed one entry from the data array at LC0.  While that commit
updated all then-existing users, merging Ard's pull request didn't take
into account that a new user had emerged, which also needed updating.

When CONFIG_THUMB2_KERNEL=y, the stack pointer becomes 2-byte
instead of 4-byte aligned, causing a crash.
When CONFIG_THUMB2_KERNEL=n, it still works, probably by accident.

                adr     r0, LC0
                ldr     r1, [r0]        @ get absolute LC0
-               ldr     sp, [r0, #28]   @ get stack location
+               ldr     sp, [r0, #24]   @ get stack location

in arch/arm/boot/compressed/head.S fixes the issue for me.

Will send v4 shortly.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

20.03.2020 16:43, Geert Uytterhoeven пишет:
...
> Will send v4 shortly.

Awesome, I'll test the v4.

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

20.03.2020 16:43, Geert Uytterhoeven пишет:
...
> Will send v4 shortly.

Awesome, I'll test the v4.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

20.03.2020 16:43, Geert Uytterhoeven пишет:
...
> Will send v4 shortly.

Awesome, I'll test the v4.

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Russell King - ARM Linux admin]

On Thu, Mar 19, 2020 at 04:11:00AM +0300, Dmitry Osipenko wrote:
> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > Hi Marek,
> > 
> > On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>> Currently, the start address of physical memory is obtained by masking
> >>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>> was chosen as a balance between the requirements of different platforms.
> >>> However, this does require that the start address of physical memory is
> >>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>> requirement is not fulfilled.
> >>>
> >>> Fix this limitation by obtaining the start address from the DTB instead,
> >>> if available (either explicitly passed, or appended to the kernel).
> >>> Fall back to the traditional method when needed.
> >>>
> >>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>> i.e. not at a multiple of 128 MiB.
> >>>
> >>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> >>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> >>> ---
> >>> Against arm/for-next.
> >>
> >> This patch landed recently in linux-next. It breaks legacy booting from
> >> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >> will debug it further once I find some spare time. What I noticed so
> >> far, the cmdline/memory info is not read from the ATAGs, only the values
> >> provided via appended DT are used.
> > 
> > Oops, something happening like this was one of my biggest worries when
> > posting this patch... Sorry for the breakage.
> > 
> > IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> > 
> > I'll have a closer look later today.
> > In the mean time, I've sent some debug code I used when developing
> > this patch, which may be useful, hopefully.
> 
> Hello,
> 
> NVIDIA Tegra is also affected by this patch. A week ago an updated
> version of the patch was pushed into linux-next and now machine doesn't
> boot at all.
> 
> I couldn't find v3 on the ML, so replying to the v2. Please take a look
> and fix the problem, or revert/drop the offending patch, thanks in advance.

I'll drop the patch. It's clear that this is going to be difficult,
so I would ask you to test the next version, rather than waiting for
it to appear in linux-next.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Russell King - ARM Linux admin]

On Thu, Mar 19, 2020 at 04:11:00AM +0300, Dmitry Osipenko wrote:
> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > Hi Marek,
> > 
> > On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>> Currently, the start address of physical memory is obtained by masking
> >>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>> was chosen as a balance between the requirements of different platforms.
> >>> However, this does require that the start address of physical memory is
> >>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>> requirement is not fulfilled.
> >>>
> >>> Fix this limitation by obtaining the start address from the DTB instead,
> >>> if available (either explicitly passed, or appended to the kernel).
> >>> Fall back to the traditional method when needed.
> >>>
> >>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>> i.e. not at a multiple of 128 MiB.
> >>>
> >>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> >>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> >>> ---
> >>> Against arm/for-next.
> >>
> >> This patch landed recently in linux-next. It breaks legacy booting from
> >> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >> will debug it further once I find some spare time. What I noticed so
> >> far, the cmdline/memory info is not read from the ATAGs, only the values
> >> provided via appended DT are used.
> > 
> > Oops, something happening like this was one of my biggest worries when
> > posting this patch... Sorry for the breakage.
> > 
> > IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> > 
> > I'll have a closer look later today.
> > In the mean time, I've sent some debug code I used when developing
> > this patch, which may be useful, hopefully.
> 
> Hello,
> 
> NVIDIA Tegra is also affected by this patch. A week ago an updated
> version of the patch was pushed into linux-next and now machine doesn't
> boot at all.
> 
> I couldn't find v3 on the ML, so replying to the v2. Please take a look
> and fix the problem, or revert/drop the offending patch, thanks in advance.

I'll drop the patch. It's clear that this is going to be difficult,
so I would ask you to test the next version, rather than waiting for
it to appear in linux-next.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Russell King - ARM Linux admin]

On Thu, Mar 19, 2020 at 04:11:00AM +0300, Dmitry Osipenko wrote:
> 25.02.2020 14:40, Geert Uytterhoeven пишет:
> > Hi Marek,
> > 
> > On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
> > <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> >> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
> >>> Currently, the start address of physical memory is obtained by masking
> >>> the program counter with a fixed mask of 0xf8000000.  This mask value
> >>> was chosen as a balance between the requirements of different platforms.
> >>> However, this does require that the start address of physical memory is
> >>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>> requirement is not fulfilled.
> >>>
> >>> Fix this limitation by obtaining the start address from the DTB instead,
> >>> if available (either explicitly passed, or appended to the kernel).
> >>> Fall back to the traditional method when needed.
> >>>
> >>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> >>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> >>> i.e. not at a multiple of 128 MiB.
> >>>
> >>> Suggested-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> >>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> >>> Reviewed-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
> >>> ---
> >>> Against arm/for-next.
> >>
> >> This patch landed recently in linux-next. It breaks legacy booting from
> >> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
> >> will debug it further once I find some spare time. What I noticed so
> >> far, the cmdline/memory info is not read from the ATAGs, only the values
> >> provided via appended DT are used.
> > 
> > Oops, something happening like this was one of my biggest worries when
> > posting this patch... Sorry for the breakage.
> > 
> > IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
> > 
> > I'll have a closer look later today.
> > In the mean time, I've sent some debug code I used when developing
> > this patch, which may be useful, hopefully.
> 
> Hello,
> 
> NVIDIA Tegra is also affected by this patch. A week ago an updated
> version of the patch was pushed into linux-next and now machine doesn't
> boot at all.
> 
> I couldn't find v3 on the ML, so replying to the v2. Please take a look
> and fix the problem, or revert/drop the offending patch, thanks in advance.

I'll drop the patch. It's clear that this is going to be difficult,
so I would ask you to test the next version, rather than waiting for
it to appear in linux-next.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

19.03.2020 12:25, Russell King - ARM Linux admin пишет:
> On Thu, Mar 19, 2020 at 04:11:00AM +0300, Dmitry Osipenko wrote:
>> 25.02.2020 14:40, Geert Uytterhoeven пишет:
>>> Hi Marek,
>>>
>>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>>>> Currently, the start address of physical memory is obtained by masking
>>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>>>> was chosen as a balance between the requirements of different platforms.
>>>>> However, this does require that the start address of physical memory is
>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>> requirement is not fulfilled.
>>>>>
>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>> Fall back to the traditional method when needed.
>>>>>
>>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>>>> i.e. not at a multiple of 128 MiB.
>>>>>
>>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> ---
>>>>> Against arm/for-next.
>>>>
>>>> This patch landed recently in linux-next. It breaks legacy booting from
>>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>>>> will debug it further once I find some spare time. What I noticed so
>>>> far, the cmdline/memory info is not read from the ATAGs, only the values
>>>> provided via appended DT are used.
>>>
>>> Oops, something happening like this was one of my biggest worries when
>>> posting this patch... Sorry for the breakage.
>>>
>>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
>>>
>>> I'll have a closer look later today.
>>> In the mean time, I've sent some debug code I used when developing
>>> this patch, which may be useful, hopefully.
>>
>> Hello,
>>
>> NVIDIA Tegra is also affected by this patch. A week ago an updated
>> version of the patch was pushed into linux-next and now machine doesn't
>> boot at all.
>>
>> I couldn't find v3 on the ML, so replying to the v2. Please take a look
>> and fix the problem, or revert/drop the offending patch, thanks in advance.
> 
> I'll drop the patch. It's clear that this is going to be difficult,
> so I would ask you to test the next version, rather than waiting for
> it to appear in linux-next.

Thank you very much! I'll be happy to try v4, please feel free to CC me.

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

19.03.2020 12:25, Russell King - ARM Linux admin пишет:
> On Thu, Mar 19, 2020 at 04:11:00AM +0300, Dmitry Osipenko wrote:
>> 25.02.2020 14:40, Geert Uytterhoeven пишет:
>>> Hi Marek,
>>>
>>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>>>> Currently, the start address of physical memory is obtained by masking
>>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>>>> was chosen as a balance between the requirements of different platforms.
>>>>> However, this does require that the start address of physical memory is
>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>> requirement is not fulfilled.
>>>>>
>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>> Fall back to the traditional method when needed.
>>>>>
>>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>>>> i.e. not at a multiple of 128 MiB.
>>>>>
>>>>> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
>>>>> ---
>>>>> Against arm/for-next.
>>>>
>>>> This patch landed recently in linux-next. It breaks legacy booting from
>>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>>>> will debug it further once I find some spare time. What I noticed so
>>>> far, the cmdline/memory info is not read from the ATAGs, only the values
>>>> provided via appended DT are used.
>>>
>>> Oops, something happening like this was one of my biggest worries when
>>> posting this patch... Sorry for the breakage.
>>>
>>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
>>>
>>> I'll have a closer look later today.
>>> In the mean time, I've sent some debug code I used when developing
>>> this patch, which may be useful, hopefully.
>>
>> Hello,
>>
>> NVIDIA Tegra is also affected by this patch. A week ago an updated
>> version of the patch was pushed into linux-next and now machine doesn't
>> boot at all.
>>
>> I couldn't find v3 on the ML, so replying to the v2. Please take a look
>> and fix the problem, or revert/drop the offending patch, thanks in advance.
> 
> I'll drop the patch. It's clear that this is going to be difficult,
> so I would ask you to test the next version, rather than waiting for
> it to appear in linux-next.

Thank you very much! I'll be happy to try v4, please feel free to CC me.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Dmitry Osipenko]

19.03.2020 12:25, Russell King - ARM Linux admin пишет:
> On Thu, Mar 19, 2020 at 04:11:00AM +0300, Dmitry Osipenko wrote:
>> 25.02.2020 14:40, Geert Uytterhoeven пишет:
>>> Hi Marek,
>>>
>>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
>>> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote:
>>>>> Currently, the start address of physical memory is obtained by masking
>>>>> the program counter with a fixed mask of 0xf8000000.  This mask value
>>>>> was chosen as a balance between the requirements of different platforms.
>>>>> However, this does require that the start address of physical memory is
>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>> requirement is not fulfilled.
>>>>>
>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>> Fall back to the traditional method when needed.
>>>>>
>>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
>>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
>>>>> i.e. not at a multiple of 128 MiB.
>>>>>
>>>>> Suggested-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>>>>> Reviewed-by: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
>>>>> ---
>>>>> Against arm/for-next.
>>>>
>>>> This patch landed recently in linux-next. It breaks legacy booting from
>>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I
>>>> will debug it further once I find some spare time. What I noticed so
>>>> far, the cmdline/memory info is not read from the ATAGs, only the values
>>>> provided via appended DT are used.
>>>
>>> Oops, something happening like this was one of my biggest worries when
>>> posting this patch... Sorry for the breakage.
>>>
>>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?
>>>
>>> I'll have a closer look later today.
>>> In the mean time, I've sent some debug code I used when developing
>>> this patch, which may be useful, hopefully.
>>
>> Hello,
>>
>> NVIDIA Tegra is also affected by this patch. A week ago an updated
>> version of the patch was pushed into linux-next and now machine doesn't
>> boot at all.
>>
>> I couldn't find v3 on the ML, so replying to the v2. Please take a look
>> and fix the problem, or revert/drop the offending patch, thanks in advance.
> 
> I'll drop the patch. It's clear that this is going to be difficult,
> so I would ask you to test the next version, rather than waiting for
> it to appear in linux-next.

Thank you very much! I'll be happy to try v4, please feel free to CC me.