[U-Boot] [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL
From: Stephen Warren swarren@nvidia.com
64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE when building. Fix the binman .dts file so that it doesn't use undefined values.
Signed-off-by: Stephen Warren swarren@nvidia.com --- arch/arm/dts/tegra-u-boot.dtsi | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/tegra-u-boot.dtsi b/arch/arm/dts/tegra-u-boot.dtsi index cde591c5fca4..4f692ee97572 100644 --- a/arch/arm/dts/tegra-u-boot.dtsi +++ b/arch/arm/dts/tegra-u-boot.dtsi @@ -1,5 +1,11 @@ #include <config.h>
+#ifdef CONFIG_SPL_TEXT_BASE +#define U_BOOT_OFFSET (CONFIG_SYS_TEXT_BASE - CONFIG_SPL_TEXT_BASE) +#else +#define U_BOOT_OFFSET 0 +#endif + / { binman { multiple-images; @@ -9,8 +15,7 @@ u-boot-spl { }; u-boot { - pos = <(CONFIG_SYS_TEXT_BASE - - CONFIG_SPL_TEXT_BASE)>; + pos = <(U_BOOT_OFFSET)>; }; };
@@ -21,8 +26,7 @@ u-boot-spl { }; u-boot { - pos = <(CONFIG_SYS_TEXT_BASE - - CONFIG_SPL_TEXT_BASE)>; + pos = <(U_BOOT_OFFSET)>; }; };
@@ -32,8 +36,7 @@ u-boot-spl { }; u-boot-nodtb { - pos = <(CONFIG_SYS_TEXT_BASE - - CONFIG_SPL_TEXT_BASE)>; + pos = <(U_BOOT_OFFSET)>; }; }; };
From: Stephen Warren swarren@nvidia.com
No 64-bit Tegra uses SPL. Remove various unused definitions from config headers.
Signed-off-by: Stephen Warren swarren@nvidia.com --- include/configs/tegra-common.h | 2 ++ include/configs/tegra186-common.h | 5 ----- include/configs/tegra210-common.h | 5 ----- 3 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 3cdd9741b241..75e36c0b759d 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -84,11 +84,13 @@ CONFIG_SYS_INIT_RAM_SIZE - \ GENERATED_GBL_DATA_SIZE)
+#ifndef CONFIG_ARM64 /* Defines for SPL */ #define CONFIG_SPL_FRAMEWORK #define CONFIG_SPL_MAX_FOOTPRINT (CONFIG_SYS_TEXT_BASE - \ CONFIG_SPL_TEXT_BASE) #define CONFIG_SYS_SPL_MALLOC_SIZE 0x00010000 +#endif
/* Misc utility code */ #define CONFIG_BOUNCE_BUFFER diff --git a/include/configs/tegra186-common.h b/include/configs/tegra186-common.h index 98e4fc2d252b..495d18555f3f 100644 --- a/include/configs/tegra186-common.h +++ b/include/configs/tegra186-common.h @@ -60,9 +60,4 @@ "fdt_addr_r=0x82000000\0" \ "ramdisk_addr_r=0x82100000\0"
-/* Defines for SPL */ -#define CONFIG_SPL_TEXT_BASE 0x80108000 -#define CONFIG_SYS_SPL_MALLOC_START 0x80090000 -#define CONFIG_SPL_STACK 0x800ffffc - #endif diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h index 4c05576a909e..93c9455e8ff3 100644 --- a/include/configs/tegra210-common.h +++ b/include/configs/tegra210-common.h @@ -60,11 +60,6 @@ "fdt_addr_r=0x82000000\0" \ "ramdisk_addr_r=0x82100000\0"
-/* Defines for SPL */ -#define CONFIG_SPL_TEXT_BASE 0x80108000 -#define CONFIG_SYS_SPL_MALLOC_START 0x80090000 -#define CONFIG_SPL_STACK 0x800ffffc - /* For USB EHCI controller */ #define CONFIG_EHCI_IS_TDI #define CONFIG_USB_EHCI_TXFIFO_THRESH 0x10
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
No 64-bit Tegra uses SPL. Remove various unused definitions from config headers.
Signed-off-by: Stephen Warren swarren@nvidia.com
include/configs/tegra-common.h | 2 ++ include/configs/tegra186-common.h | 5 ----- include/configs/tegra210-common.h | 5 ----- 3 files changed, 2 insertions(+), 10 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
From: Stephen Warren swarren@nvidia.com
U-Boot typically uses a hard-coded value for the stack pointer before relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate the initial SP at run-time. This is useful to avoid hard-coding addresses into U-Boot, so that can be loaded and executed at arbitrary addresses and thus avoid using arbitrary addresses at runtime. This option's value is the offset added to &_bss_start in order to calculate the stack pointer. This offset should be large enough so that the early malloc region, global data (gd), and early stack usage do not overlap any appended DTB.
Signed-off-by: Stephen Warren swarren@nvidia.com --- arch/arm/Kconfig | 13 +++++++++++++ arch/arm/lib/crt0_64.S | 3 +++ 2 files changed, 16 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f2c35e32c649..93b93c142929 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -19,6 +19,19 @@ config POSITION_INDEPENDENT from almost any address. This logic relies on the relocation information that is embedded into the binary to support U-Boot relocating itself to the top-of-RAM later during execution. + +config SYS_INIT_SP_BSS_OFFSET + int + help + U-Boot typically uses a hard-coded value for the stack pointer + before relocation. Define this option to instead calculate the + initial SP at run-time. This is useful to avoid hard-coding addresses + into U-Boot, so that can be loaded and executed at arbitrary + addresses and thus avoid using arbitrary addresses at runtime. This + option's value is the offset added to &_bss_start in order to + calculate the stack pointer. This offset should be large enough so + that the early malloc region, global data (gd), and early stack usage + do not overlap any appended DTB. endif
config STATIC_RELA diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index 9cb70552feda..a181283e0fa9 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -73,6 +73,9 @@ ENTRY(_main) ldr x0, =(CONFIG_TPL_STACK) #elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) ldr x0, =(CONFIG_SPL_STACK) +#elif defined(CONFIG_SYS_INIT_SP_BSS_OFFSET) + adr x0, __bss_start + add x0, x0, #CONFIG_SYS_INIT_SP_BSS_OFFSET #else ldr x0, =(CONFIG_SYS_INIT_SP_ADDR) #endif
Hi Stephen,
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
U-Boot typically uses a hard-coded value for the stack pointer before relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate the initial SP at run-time. This is useful to avoid hard-coding addresses into U-Boot, so that can be loaded and executed at arbitrary addresses and thus avoid using arbitrary addresses at runtime. This option's value is the offset added to &_bss_start in order to calculate the stack pointer. This offset should be large enough so that the early malloc region, global data (gd), and early stack usage do not overlap any appended DTB.
I don't see why this is an offset from bss_start - shouldn't it be bss_end?
Also this seems error-prone since we don't know how large the DTB is. Can we improve this, e.g. by:
- using binman to provide the stack start value or offset - checking the DTB size and automatically using the address immediately after it finishes (again I suppose binman could provide that)
Regards, Simon
On 01/07/2018 08:40 PM, Simon Glass wrote:
Hi Stephen,
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
U-Boot typically uses a hard-coded value for the stack pointer before relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate the initial SP at run-time. This is useful to avoid hard-coding addresses into U-Boot, so that can be loaded and executed at arbitrary addresses and thus avoid using arbitrary addresses at runtime. This option's value is the offset added to &_bss_start in order to calculate the stack pointer. This offset should be large enough so that the early malloc region, global data (gd), and early stack usage do not overlap any appended DTB.
I don't see why this is an offset from bss_start - shouldn't it be bss_end?
BSS can vary in size based on the set of config options enabled, code growth/shrinkage, etc. Thus, basing the initial SP address on bss_end would provide too much variability, and hence would be unsafe, whereas basing the initial SP address on bss_start always provides the exact same amount of available stack space (assuming an identical DTB for the comparison).
Also this seems error-prone since we don't know how large the DTB is. Can we improve this, e.g. by:
- using binman to provide the stack start value or offset
I'd rather not involve binman in the code generation process. Packaging is fine, but I think the source code and makefiles should dictate everything that goes into the actual binary to keep things simple.
I did originally think about having binman patch up the init SP address, but rejected it due to the complexity added by the extra step, and the fact that we'd be inventing a new tool (the new part of binman implemented for this feature) to do what we already have a perfectly good tool for already; the linker. I'm also looking to backport this change to an older branch of U-Boot that doesn't have binman, although I believe I'd have the same thought process either way.
- checking the DTB size and automatically using the address
immediately after it finishes (again I suppose binman could provide that)
Perhaps we can add an extra step in binman that validates the build; i.e. that (SYS_INIT_SP_BSS_OFFSET - size_of_dtb) > some_minimum_stack_size. That would be a useful error check, but prevent binman having to edit parts of the binary that were already created by the main build process. Note that for a given build, it should be completely deterministic whether DTB corruption occurs, and whether that corruption actually impacts U-Boot's operation, so any such check would be pretty much equivalent to just running U-Boot and seeing if it works. Admittedly the check might save some annoying debugging though, so would be a good idea.
Hi Stephen,
On 8 January 2018 at 11:34, Stephen Warren swarren@wwwdotorg.org wrote:
On 01/07/2018 08:40 PM, Simon Glass wrote:
Hi Stephen,
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
U-Boot typically uses a hard-coded value for the stack pointer before relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate the initial SP at run-time. This is useful to avoid hard-coding addresses into U-Boot, so that can be loaded and executed at arbitrary addresses and thus avoid using arbitrary addresses at runtime. This option's value is the offset added to &_bss_start in order to calculate the stack pointer. This offset should be large enough so that the early malloc region, global data (gd), and early stack usage do not overlap any appended DTB.
I don't see why this is an offset from bss_start - shouldn't it be bss_end?
BSS can vary in size based on the set of config options enabled, code growth/shrinkage, etc. Thus, basing the initial SP address on bss_end would provide too much variability, and hence would be unsafe, whereas basing the initial SP address on bss_start always provides the exact same amount of available stack space (assuming an identical DTB for the comparison).
OK. I suppose we are no worse off anyway, since the DTB can vary in size.
Also this seems error-prone since we don't know how large the DTB is. Can we improve this, e.g. by:
- using binman to provide the stack start value or offset
I'd rather not involve binman in the code generation process. Packaging is fine, but I think the source code and makefiles should dictate everything that goes into the actual binary to keep things simple.
I did originally think about having binman patch up the init SP address, but rejected it due to the complexity added by the extra step, and the fact that we'd be inventing a new tool (the new part of binman implemented for this feature) to do what we already have a perfectly good tool for already; the linker. I'm also looking to backport this change to an older branch of U-Boot that doesn't have binman, although I believe I'd have the same thought process either way.
There is actually a feature for this, or something similar:
http://git.denx.de/?p=u-boot.git;a=blob;f=tools/binman/README;h=08c3e56bdef8...
- checking the DTB size and automatically using the address
immediately after it finishes (again I suppose binman could provide that)
Perhaps we can add an extra step in binman that validates the build; i.e. that (SYS_INIT_SP_BSS_OFFSET - size_of_dtb) > some_minimum_stack_size. That would be a useful error check, but prevent binman having to edit parts of the binary that were already created by the main build process. Note that for a given build, it should be completely deterministic whether DTB corruption occurs, and whether that corruption actually impacts U-Boot's operation, so any such check would be pretty much equivalent to just running U-Boot and seeing if it works. Admittedly the check might save some annoying debugging though, so would be a good idea.
Sounds good. It could even be done in Makefile - we have a few checks that that at present. But if binman is a better place, that is fine.
Regards, Simon
On 01/08/2018 03:11 PM, Simon Glass wrote:
Hi Stephen,
On 8 January 2018 at 11:34, Stephen Warren swarren@wwwdotorg.org wrote:
On 01/07/2018 08:40 PM, Simon Glass wrote:
Hi Stephen,
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
U-Boot typically uses a hard-coded value for the stack pointer before relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate the initial SP at run-time. This is useful to avoid hard-coding addresses into U-Boot, so that can be loaded and executed at arbitrary addresses and thus avoid using arbitrary addresses at runtime. This option's value is the offset added to &_bss_start in order to calculate the stack pointer. This offset should be large enough so that the early malloc region, global data (gd), and early stack usage do not overlap any appended DTB.
I don't see why this is an offset from bss_start - shouldn't it be bss_end?
BSS can vary in size based on the set of config options enabled, code growth/shrinkage, etc. Thus, basing the initial SP address on bss_end would provide too much variability, and hence would be unsafe, whereas basing the initial SP address on bss_start always provides the exact same amount of available stack space (assuming an identical DTB for the comparison).
OK. I suppose we are no worse off anyway, since the DTB can vary in size.
I've sent a patch to check for overflow.
From: Stephen Warren swarren@nvidia.com
Enable CONFIG_SYS_INIT_SP_BSS_OFFSET for all 64-bit Tegra boards. Place the stack/... 512KiB from the end of the U-Boot binary. This should be plenty to accommodate the current DTBs (max 64 KiB), early malloc region (6KiB), stack usage, and plenty of slack, while still not placing it too far away from the U-Boot binary.
Signed-off-by: Stephen Warren swarren@nvidia.com --- arch/arm/mach-tegra/tegra186/Kconfig | 3 +++ arch/arm/mach-tegra/tegra210/Kconfig | 3 +++ include/configs/tegra-common.h | 2 ++ include/configs/tegra186-common.h | 5 ----- include/configs/tegra210-common.h | 5 ----- 5 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-tegra/tegra186/Kconfig b/arch/arm/mach-tegra/tegra186/Kconfig index b2e53b58caf8..479c0955eec6 100644 --- a/arch/arm/mach-tegra/tegra186/Kconfig +++ b/arch/arm/mach-tegra/tegra186/Kconfig @@ -21,6 +21,9 @@ endchoice config SYS_SOC default "tegra186"
+config SYS_INIT_SP_BSS_OFFSET + default 524288 + source "board/nvidia/p2771-0000/Kconfig"
endif diff --git a/arch/arm/mach-tegra/tegra210/Kconfig b/arch/arm/mach-tegra/tegra210/Kconfig index 3637473051b8..250738aed312 100644 --- a/arch/arm/mach-tegra/tegra210/Kconfig +++ b/arch/arm/mach-tegra/tegra210/Kconfig @@ -40,6 +40,9 @@ endchoice config SYS_SOC default "tegra210"
+config SYS_INIT_SP_BSS_OFFSET + default 524288 + source "board/nvidia/e2220-1170/Kconfig" source "board/nvidia/p2371-0000/Kconfig" source "board/nvidia/p2371-2180/Kconfig" diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 75e36c0b759d..2d98a6fa64a7 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -78,11 +78,13 @@
#define CONFIG_SYS_BOOTMAPSZ (256 << 20) /* 256M */
+#ifndef CONFIG_ARM64 #define CONFIG_SYS_INIT_RAM_ADDR CONFIG_STACKBASE #define CONFIG_SYS_INIT_RAM_SIZE CONFIG_SYS_MALLOC_LEN #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + \ CONFIG_SYS_INIT_RAM_SIZE - \ GENERATED_GBL_DATA_SIZE) +#endif
#ifndef CONFIG_ARM64 /* Defines for SPL */ diff --git a/include/configs/tegra186-common.h b/include/configs/tegra186-common.h index 495d18555f3f..1c8772a117e4 100644 --- a/include/configs/tegra186-common.h +++ b/include/configs/tegra186-common.h @@ -14,11 +14,6 @@ */ #define V_NS16550_CLK 408000000 /* 408MHz (pllp_out0) */
-/* - * Miscellaneous configurable options - */ -#define CONFIG_STACKBASE 0x82800000 /* 40MB */ - /*----------------------------------------------------------------------- * Physical Memory Map */ diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h index 93c9455e8ff3..35735f3b78e4 100644 --- a/include/configs/tegra210-common.h +++ b/include/configs/tegra210-common.h @@ -15,11 +15,6 @@ */ #define V_NS16550_CLK 408000000 /* 408MHz (pllp_out0) */
-/* - * Miscellaneous configurable options - */ -#define CONFIG_STACKBASE 0x82800000 /* 40MB */ - /*----------------------------------------------------------------------- * Physical Memory Map */
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
Enable CONFIG_SYS_INIT_SP_BSS_OFFSET for all 64-bit Tegra boards. Place the stack/... 512KiB from the end of the U-Boot binary. This should be plenty to accommodate the current DTBs (max 64 KiB), early malloc region (6KiB), stack usage, and plenty of slack, while still not placing it too far away from the U-Boot binary.
Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/mach-tegra/tegra186/Kconfig | 3 +++ arch/arm/mach-tegra/tegra210/Kconfig | 3 +++ include/configs/tegra-common.h | 2 ++ include/configs/tegra186-common.h | 5 ----- include/configs/tegra210-common.h | 5 ----- 5 files changed, 8 insertions(+), 10 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Stephen,
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Tuesday, December 19, 2017 6:31 PM To: Tom Warren TWarren@nvidia.com Cc: Simon Glass sjg@chromium.org; Tom Rini trini@konsulko.com; u- boot@lists.denx.de; Stephen Warren swarren@nvidia.com Subject: [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL
From: Stephen Warren swarren@nvidia.com
64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE when building. Fix the binman .dts file so that it doesn't use undefined values.
Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/dts/tegra-u-boot.dtsi | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
This series: Reviewed-by: Tom Warren twarren@nvidia.com
I'll wait a bit for other reviews & apply it to u-boot-tegra today or tomorrow.
Tom
diff --git a/arch/arm/dts/tegra-u-boot.dtsi b/arch/arm/dts/tegra-u-boot.dtsi index cde591c5fca4..4f692ee97572 100644 --- a/arch/arm/dts/tegra-u-boot.dtsi +++ b/arch/arm/dts/tegra-u-boot.dtsi @@ -1,5 +1,11 @@ #include <config.h>
+#ifdef CONFIG_SPL_TEXT_BASE +#define U_BOOT_OFFSET (CONFIG_SYS_TEXT_BASE - CONFIG_SPL_TEXT_BASE) +#else #define U_BOOT_OFFSET 0 #endif
/ { binman { multiple-images; @@ -9,8 +15,7 @@ u-boot-spl { }; u-boot {
pos = <(CONFIG_SYS_TEXT_BASE -CONFIG_SPL_TEXT_BASE)>;
pos = <(U_BOOT_OFFSET)>; };@@ -21,8 +26,7 @@ u-boot-spl { }; u-boot {
pos = <(CONFIG_SYS_TEXT_BASE -CONFIG_SPL_TEXT_BASE)>;
pos = <(U_BOOT_OFFSET)>; };@@ -32,8 +36,7 @@ u-boot-spl { }; u-boot-nodtb {
pos = <(CONFIG_SYS_TEXT_BASE -CONFIG_SPL_TEXT_BASE)>;
pos = <(U_BOOT_OFFSET)>; };-- 2.15.1
-- nvpublic
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE when building. Fix the binman .dts file so that it doesn't use undefined values.
Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/dts/tegra-u-boot.dtsi | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Stephen,
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Thursday, December 28, 2017 8:14 PM To: Stephen Warren swarren@wwwdotorg.org Cc: Tom Warren TWarren@nvidia.com; Tom Rini trini@konsulko.com; U-Boot Mailing List u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Subject: Re: [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE when building. Fix the binman .dts file so that it doesn't use undefined values.
Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/dts/tegra-u-boot.dtsi | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
I've applied this series to u-boot-tegra/master. I'll wait a bit to see how your new series (RAM bank/mem parsing) is received and then I'll apply it, too, and post a PR. I assume you expect the Linux kernel image header patches to go in thru TomR?
Tom -- nvpublic
On 01/03/2018 03:43 PM, Tom Warren wrote:
Stephen,
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Thursday, December 28, 2017 8:14 PM To: Stephen Warren swarren@wwwdotorg.org Cc: Tom Warren TWarren@nvidia.com; Tom Rini trini@konsulko.com; U-Boot Mailing List u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Subject: Re: [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE when building. Fix the binman .dts file so that it doesn't use undefined values.
Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/dts/tegra-u-boot.dtsi | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
I've applied this series to u-boot-tegra/master. I'll wait a bit to see how your new series (RAM bank/mem parsing) is received and then I'll apply it, too, and post a PR. I assume you expect the Linux kernel image header patches to go in thru TomR?
I think it's best to push them all through the Tegra path, since there will be a stream of common and Tegra patches all intermixed.
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Wednesday, January 3, 2018 3:44 PM To: Tom Warren TWarren@nvidia.com Cc: Simon Glass sjg@chromium.org; Tom Rini trini@konsulko.com; U-Boot Mailing List u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Subject: Re: [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL
On 01/03/2018 03:43 PM, Tom Warren wrote:
Stephen,
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Thursday, December 28, 2017 8:14 PM To: Stephen Warren swarren@wwwdotorg.org Cc: Tom Warren TWarren@nvidia.com; Tom Rini trini@konsulko.com; U-Boot Mailing List u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Subject: Re: [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL
On 19 December 2017 at 18:30, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE when building. Fix the binman .dts file so that it doesn't use undefined values.
Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/dts/tegra-u-boot.dtsi | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
I've applied this series to u-boot-tegra/master. I'll wait a bit to see how your new series (RAM bank/mem parsing) is received and then I'll apply it, too, and post a PR. I assume you expect the Linux kernel image header patches to go in thru TomR?
I think it's best to push them all through the Tegra path, since there will be a stream of common and Tegra patches all intermixed. OK, I'll apply them as they get reviewed/ACK'd. Thanks.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
participants (3)
-
Simon Glass -
Stephen Warren -
Tom Warren