[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only from 0x40200000 to 0x4020F000 and exceeding that will cause failure to boot. Further, we need to make sure that we don't run into SRAM_SCRATCH_SPACE_ADDR as once SPL is running we will write values there and would corrupt our running image.
Cc: Adam Ford aford173@gmail.com Cc: Steve Sakoman sakoman@gmail.com Signed-off-by: Tom Rini trini@konsulko.com --- include/configs/omap3_logic.h | 2 +- include/configs/omap3_overo.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h index 055dcb7..6c79643 100644 --- a/include/configs/omap3_logic.h +++ b/include/configs/omap3_logic.h @@ -34,7 +34,7 @@ #undef CONFIG_SPL_TEXT_BASE #undef CONFIG_SPL_MAX_SIZE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (64 * 1024) +#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
/* Display CPU and Board information */
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index c066eae5..fbd0c2a 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -12,9 +12,9 @@
#include <configs/ti_omap3_common.h> #undef CONFIG_SPL_MAX_SIZE -#define CONFIG_SPL_MAX_SIZE (64*1024) #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200000 +#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
#define CONFIG_BCH
On Wed, Apr 27, 2016 at 06:46:36PM -0400, Tom Rini wrote:
While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only from 0x40200000 to 0x4020F000 and exceeding that will cause failure to boot. Further, we need to make sure that we don't run into SRAM_SCRATCH_SPACE_ADDR as once SPL is running we will write values there and would corrupt our running image.
Cc: Adam Ford aford173@gmail.com Cc: Steve Sakoman sakoman@gmail.com Signed-off-by: Tom Rini trini@konsulko.com
First, this will break linking SPL on some toolchains. However, I am confident that in those cases the binary would not work or not be reliable. I will be fixing this properly in the next release for all toolchains. Applied to u-boot/master, thanks!
I am hoping to look at this tomorrow at work. Any suggested toolchain you recommend? On Apr 28, 2016 5:45 PM, "Tom Rini" trini@konsulko.com wrote:
On Wed, Apr 27, 2016 at 06:46:36PM -0400, Tom Rini wrote:
While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only from 0x40200000 to 0x4020F000 and exceeding that will cause failure to boot. Further, we need to make sure that we don't run into SRAM_SCRATCH_SPACE_ADDR as once SPL is running we will write values there and would corrupt our running image.
Cc: Adam Ford aford173@gmail.com Cc: Steve Sakoman sakoman@gmail.com Signed-off-by: Tom Rini trini@konsulko.com
First, this will break linking SPL on some toolchains. However, I am confident that in those cases the binary would not work or not be reliable. I will be fixing this properly in the next release for all toolchains. Applied to u-boot/master, thanks!
-- Tom
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
I am hoping to look at this tomorrow at work. Any suggested toolchain you recommend?
gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely fine but I haven't started using those SDKs I just made today.
On 04/28/2016 06:34 PM, Tom Rini wrote:
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
I am hoping to look at this tomorrow at work. Any suggested toolchain you recommend?
gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely fine but I haven't started using those SDKs I just made today.
Hi Tom,
Using gcc-5.3.0, for 'omap3_logic', I get the following:
---8<------------------------------------------ arm-cortexa8-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram' arm-cortexa8-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 948 bytes ---8<------------------------------------------
I built the compiler today with crosstool-ng.
gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)
What things could/should be removed, from the configuration, to avoid these kinds of things in the future?
I would expect that the default board configuration to be less sensitive, in general. I guess I want to know what is the right size for an OMAP3 with SPL enabled.
Changing compilers, just for this, can cause quite a ripple on projects and the products that are supported by them.
Derald Woods
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Sat, Apr 30, 2016 at 07:12:28PM -0500, Derald D. Woods wrote:
On 04/28/2016 06:34 PM, Tom Rini wrote:
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
I am hoping to look at this tomorrow at work. Any suggested toolchain you recommend?
gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely fine but I haven't started using those SDKs I just made today.
Hi Tom,
Using gcc-5.3.0, for 'omap3_logic', I get the following:
---8<------------------------------------------ arm-cortexa8-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram' arm-cortexa8-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 948 bytes ---8<------------------------------------------
That's odd, 5.3.1 from debian/unstable works.
I built the compiler today with crosstool-ng.
gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)
What things could/should be removed, from the configuration, to avoid these kinds of things in the future?
I would expect that the default board configuration to be less sensitive, in general. I guess I want to know what is the right size for an OMAP3 with SPL enabled.
Changing compilers, just for this, can cause quite a ripple on projects and the products that are supported by them.
So, the first thing to do would be to please try the following patch:
diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h index bc0e02a..6cef323 100644 --- a/arch/arm/include/asm/arch-omap3/omap.h +++ b/arch/arm/include/asm/arch-omap3/omap.h @@ -145,7 +145,7 @@ struct gpio {
#define NON_SECURE_SRAM_START 0x40208000 /* Works for GP & EMU */ #define NON_SECURE_SRAM_END 0x40210000 -#define SRAM_SCRATCH_SPACE_ADDR 0x4020E000 +#define SRAM_SCRATCH_SPACE_ADDR 0x4020F000
#define LOW_LEVEL_SRAM_STACK 0x4020FFFC
diff --git a/doc/SPL/README.omap3 b/doc/SPL/README.omap3 index c77ca43..cc54afe 100644 --- a/doc/SPL/README.omap3 +++ b/doc/SPL/README.omap3 @@ -33,8 +33,9 @@ SRAM: 0x40200000 - 0x4020FFFF DDR1: 0x80000000 - 0xBFFFFFFF
Option 1 (SPL only): -0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata -0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x40200800 - 0x4020EFFF: Area for SPL text, data and rodata +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) +0x4020FCB0 - 0x4020FFFF: Area for the SPL stack 0x80000000 - 0x8007FFFF: Area for the SPL BSS. 0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot 0x80208000 - 0x80307FFF: malloc() pool available to SPL. @@ -42,6 +43,7 @@ Option 1 (SPL only): Option 2 (SPL or X-Loader): 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot 0x87000000 - 0x8707FFFF: Area for the SPL BSS. 0x87080000 - 0x870FFFFF: malloc() pool available to SPL. diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h index 6c79643..ed03e07 100644 --- a/include/configs/omap3_logic.h +++ b/include/configs/omap3_logic.h @@ -28,13 +28,11 @@ #define CONFIG_SYS_SPL_MALLOC_START 0x80208000 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000
-#include <configs/ti_omap3_common.h>
/* Override default SPL info to minimize empty space and allow BCH8 in SPL */ -#undef CONFIG_SPL_TEXT_BASE -#undef CONFIG_SPL_MAX_SIZE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) + +#include <configs/ti_omap3_common.h>
/* Display CPU and Board information */
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index fbd0c2a..289c8e9 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -10,11 +10,8 @@ #define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */ #define CONFIG_NAND
-#include <configs/ti_omap3_common.h> -#undef CONFIG_SPL_MAX_SIZE -#undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) +#include <configs/ti_omap3_common.h>
#define CONFIG_BCH
diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 32877d1..ffd695f 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -68,9 +68,17 @@ /* TWL4030 */ #define CONFIG_TWL4030_POWER
-/* SPL */ +/* + * For SPL we say that our text base is at 0x40200800 for compatibility + * with HS and GP devices. We say that the maximum image size is the end + * of the downloaded image area minus the text base. If desired the text + * base can be lowered by individual platforms but the upper bound is a + * hard limit. + */ +#ifndef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200800 -#define CONFIG_SPL_MAX_SIZE (54 * 1024) +#endif +#define CONFIG_SPL_MAX_SIZE (0x4020F000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds" #define CONFIG_SPL_POWER_SUPPORT #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index 586d848..66592f0 100644 --- a/include/configs/ti_omap4_common.h +++ b/include/configs/ti_omap4_common.h @@ -143,12 +143,14 @@ BOOTENV
/* - * Defines for SPL - * It is known that this will break HS devices. Since the current size of - * SPL is overlapped with public stack and breaking non HS devices to boot. - * So moving TEXT_BASE down to non-HS limit. + * For SPL we set our text base to the start of the download image area for GP + * devices. HS devices will have to define this value instead. We say that + * the maximum image size is the end of the downloaded image area minus the + * text base. */ +#ifndef #define CONFIG_SPL_TEXT_BASE 0x40300000 +#endif #define CONFIG_SPL_MAX_SIZE (0x4030C000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
As this will allow for boards to bring themselves to the maximum binary size for GP parts on OMAP3. It's too late in the release cycle and needs broad testing, but giving it a whirl on omap3_logic would be a good start. Next, are you also using falcon mode? FAT and EXT2/3/4 fs support?
Part of the problem is that the defaults bring in a lot of wide ranging support right now and we need to move things to Kconfig to make it easy to turn those things off. The various partition table types shouldn't be too hard to migrate and for moving all Kconfigs, I'm just going to do that since there can be a bit of churn that makes those patches hard to apply.
Thanks!
On 05/01/2016 08:58 AM, Tom Rini wrote:
On Sat, Apr 30, 2016 at 07:12:28PM -0500, Derald D. Woods wrote:
On 04/28/2016 06:34 PM, Tom Rini wrote:
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
I am hoping to look at this tomorrow at work. Any suggested toolchain you recommend?
gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely fine but I haven't started using those SDKs I just made today.
Hi Tom,
Using gcc-5.3.0, for 'omap3_logic', I get the following:
---8<------------------------------------------ arm-cortexa8-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram' arm-cortexa8-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 948 bytes ---8<------------------------------------------
That's odd, 5.3.1 from debian/unstable works.
I built the compiler today with crosstool-ng.
gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)
What things could/should be removed, from the configuration, to avoid these kinds of things in the future?
I would expect that the default board configuration to be less sensitive, in general. I guess I want to know what is the right size for an OMAP3 with SPL enabled.
Changing compilers, just for this, can cause quite a ripple on projects and the products that are supported by them.
So, the first thing to do would be to please try the following patch:
diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h index bc0e02a..6cef323 100644 --- a/arch/arm/include/asm/arch-omap3/omap.h +++ b/arch/arm/include/asm/arch-omap3/omap.h @@ -145,7 +145,7 @@ struct gpio {
#define NON_SECURE_SRAM_START 0x40208000 /* Works for GP & EMU */ #define NON_SECURE_SRAM_END 0x40210000 -#define SRAM_SCRATCH_SPACE_ADDR 0x4020E000 +#define SRAM_SCRATCH_SPACE_ADDR 0x4020F000
#define LOW_LEVEL_SRAM_STACK 0x4020FFFC
diff --git a/doc/SPL/README.omap3 b/doc/SPL/README.omap3 index c77ca43..cc54afe 100644 --- a/doc/SPL/README.omap3 +++ b/doc/SPL/README.omap3 @@ -33,8 +33,9 @@ SRAM: 0x40200000 - 0x4020FFFF DDR1: 0x80000000 - 0xBFFFFFFF
Option 1 (SPL only): -0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata -0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x40200800 - 0x4020EFFF: Area for SPL text, data and rodata +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) +0x4020FCB0 - 0x4020FFFF: Area for the SPL stack 0x80000000 - 0x8007FFFF: Area for the SPL BSS. 0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot 0x80208000 - 0x80307FFF: malloc() pool available to SPL. @@ -42,6 +43,7 @@ Option 1 (SPL only): Option 2 (SPL or X-Loader): 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot 0x87000000 - 0x8707FFFF: Area for the SPL BSS. 0x87080000 - 0x870FFFFF: malloc() pool available to SPL. diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h index 6c79643..ed03e07 100644 --- a/include/configs/omap3_logic.h +++ b/include/configs/omap3_logic.h @@ -28,13 +28,11 @@ #define CONFIG_SYS_SPL_MALLOC_START 0x80208000 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000
-#include <configs/ti_omap3_common.h>
/* Override default SPL info to minimize empty space and allow BCH8 in SPL */ -#undef CONFIG_SPL_TEXT_BASE -#undef CONFIG_SPL_MAX_SIZE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
+#include <configs/ti_omap3_common.h>
/* Display CPU and Board information */
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index fbd0c2a..289c8e9 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -10,11 +10,8 @@ #define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */ #define CONFIG_NAND
-#include <configs/ti_omap3_common.h> -#undef CONFIG_SPL_MAX_SIZE -#undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) +#include <configs/ti_omap3_common.h>
#define CONFIG_BCH
diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 32877d1..ffd695f 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -68,9 +68,17 @@ /* TWL4030 */ #define CONFIG_TWL4030_POWER
-/* SPL */ +/*
- For SPL we say that our text base is at 0x40200800 for compatibility
- with HS and GP devices. We say that the maximum image size is the end
- of the downloaded image area minus the text base. If desired the text
- base can be lowered by individual platforms but the upper bound is a
- hard limit.
- */
+#ifndef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200800 -#define CONFIG_SPL_MAX_SIZE (54 * 1024) +#endif +#define CONFIG_SPL_MAX_SIZE (0x4020F000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds" #define CONFIG_SPL_POWER_SUPPORT #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index 586d848..66592f0 100644 --- a/include/configs/ti_omap4_common.h +++ b/include/configs/ti_omap4_common.h @@ -143,12 +143,14 @@ BOOTENV
/*
- Defines for SPL
- It is known that this will break HS devices. Since the current size of
- SPL is overlapped with public stack and breaking non HS devices to boot.
- So moving TEXT_BASE down to non-HS limit.
- For SPL we set our text base to the start of the download image area for GP
- devices. HS devices will have to define this value instead. We say that
- the maximum image size is the end of the downloaded image area minus the
*/
- text base.
+#ifndef #define CONFIG_SPL_TEXT_BASE 0x40300000 +#endif #define CONFIG_SPL_MAX_SIZE (0x4030C000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
Okay. That patch allows compilation to complete successfully. But ...
---8<-----------------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 11:50:16) Trying to boot from MMC1 Expected Linux image is not found. Trying to start U-boot
---8<-----------------------------------------------------
This is likely related to the "[U-Boot] spl_mmc: allow to load raw image" thread that is being discussed now.
My SD/MMC card is FAT on the first partition. The 'omap3_logic' board does not use RAW MMC access. So MLO and u-boot.img are simply files on the FAT filesystem.
Derald
As this will allow for boards to bring themselves to the maximum binary size for GP parts on OMAP3. It's too late in the release cycle and needs broad testing, but giving it a whirl on omap3_logic would be a good start. Next, are you also using falcon mode? FAT and EXT2/3/4 fs support?
Part of the problem is that the defaults bring in a lot of wide ranging support right now and we need to move things to Kconfig to make it easy to turn those things off. The various partition table types shouldn't be too hard to migrate and for moving all Kconfigs, I'm just going to do that since there can be a bit of churn that makes those patches hard to apply.
Thanks!
On Sun, May 1, 2016 at 12:09 PM, Derald D. Woods woods.technical@gmail.com wrote:
On 05/01/2016 08:58 AM, Tom Rini wrote:
On Sat, Apr 30, 2016 at 07:12:28PM -0500, Derald D. Woods wrote:
On 04/28/2016 06:34 PM, Tom Rini wrote:
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
I am hoping to look at this tomorrow at work. Any suggested toolchain
you recommend?
gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely fine but I haven't started using those SDKs I just made today.
Hi Tom,
Using gcc-5.3.0, for 'omap3_logic', I get the following:
---8<------------------------------------------ arm-cortexa8-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram' arm-cortexa8-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 948 bytes ---8<------------------------------------------
That's odd, 5.3.1 from debian/unstable works.
I built the compiler today with crosstool-ng.
gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)
What things could/should be removed, from the configuration, to avoid these kinds of things in the future?
I would expect that the default board configuration to be less sensitive, in general. I guess I want to know what is the right size for an OMAP3 with SPL enabled.
Changing compilers, just for this, can cause quite a ripple on projects and the products that are supported by them.
So, the first thing to do would be to please try the following patch:
diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h index bc0e02a..6cef323 100644 --- a/arch/arm/include/asm/arch-omap3/omap.h +++ b/arch/arm/include/asm/arch-omap3/omap.h @@ -145,7 +145,7 @@ struct gpio { #define NON_SECURE_SRAM_START 0x40208000 /* Works for GP & EMU */ #define NON_SECURE_SRAM_END 0x40210000 -#define SRAM_SCRATCH_SPACE_ADDR 0x4020E000 +#define SRAM_SCRATCH_SPACE_ADDR 0x4020F000 #define LOW_LEVEL_SRAM_STACK 0x4020FFFC diff --git a/doc/SPL/README.omap3 b/doc/SPL/README.omap3 index c77ca43..cc54afe 100644 --- a/doc/SPL/README.omap3 +++ b/doc/SPL/README.omap3 @@ -33,8 +33,9 @@ SRAM: 0x40200000 - 0x4020FFFF DDR1: 0x80000000 - 0xBFFFFFFF Option 1 (SPL only): -0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata -0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x40200800 - 0x4020EFFF: Area for SPL text, data and rodata +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) +0x4020FCB0 - 0x4020FFFF: Area for the SPL stack 0x80000000 - 0x8007FFFF: Area for the SPL BSS. 0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot 0x80208000 - 0x80307FFF: malloc() pool available to SPL. @@ -42,6 +43,7 @@ Option 1 (SPL only): Option 2 (SPL or X-Loader): 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot 0x87000000 - 0x8707FFFF: Area for the SPL BSS. 0x87080000 - 0x870FFFFF: malloc() pool available to SPL. diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h index 6c79643..ed03e07 100644 --- a/include/configs/omap3_logic.h +++ b/include/configs/omap3_logic.h @@ -28,13 +28,11 @@ #define CONFIG_SYS_SPL_MALLOC_START 0x80208000 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000 -#include <configs/ti_omap3_common.h> /* Override default SPL info to minimize empty space and allow BCH8 in SPL */ -#undef CONFIG_SPL_TEXT_BASE -#undef CONFIG_SPL_MAX_SIZE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
+#include <configs/ti_omap3_common.h> /* Display CPU and Board information */ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index fbd0c2a..289c8e9 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -10,11 +10,8 @@ #define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */ #define CONFIG_NAND -#include <configs/ti_omap3_common.h> -#undef CONFIG_SPL_MAX_SIZE -#undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) +#include <configs/ti_omap3_common.h> #define CONFIG_BCH diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 32877d1..ffd695f 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -68,9 +68,17 @@ /* TWL4030 */ #define CONFIG_TWL4030_POWER -/* SPL */ +/*
- For SPL we say that our text base is at 0x40200800 for compatibility
- with HS and GP devices. We say that the maximum image size is the end
- of the downloaded image area minus the text base. If desired the text
- base can be lowered by individual platforms but the upper bound is a
- hard limit.
- */
+#ifndef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200800 -#define CONFIG_SPL_MAX_SIZE (54 * 1024) +#endif +#define CONFIG_SPL_MAX_SIZE (0x4020F000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds" #define CONFIG_SPL_POWER_SUPPORT #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index 586d848..66592f0 100644 --- a/include/configs/ti_omap4_common.h +++ b/include/configs/ti_omap4_common.h @@ -143,12 +143,14 @@ BOOTENV /*
- Defines for SPL
- It is known that this will break HS devices. Since the current size of
- SPL is overlapped with public stack and breaking non HS devices to
boot.
- So moving TEXT_BASE down to non-HS limit.
- For SPL we set our text base to the start of the download image area
for GP
- devices. HS devices will have to define this value instead. We say
that
- the maximum image size is the end of the downloaded image area minus
the
*/
- text base.
+#ifndef #define CONFIG_SPL_TEXT_BASE 0x40300000 +#endif #define CONFIG_SPL_MAX_SIZE (0x4030C000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
Okay. That patch allows compilation to complete successfully. But ...
---8<-----------------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 11:50:16) Trying to boot from MMC1 Expected Linux image is not found. Trying to start U-boot
---8<-----------------------------------------------------
This is likely related to the "[U-Boot] spl_mmc: allow to load raw image" thread that is being discussed now.
My SD/MMC card is FAT on the first partition. The 'omap3_logic' board does not use RAW MMC access. So MLO and u-boot.img are simply files on the FAT filesystem.
Derald
Tom,
Is this patch landing in this release? I saw another patch, for the same purpose, on another board applied. Just wondering...
Derald
As this will allow for boards to bring themselves to the maximum binary
size for GP parts on OMAP3. It's too late in the release cycle and needs broad testing, but giving it a whirl on omap3_logic would be a good start. Next, are you also using falcon mode? FAT and EXT2/3/4 fs support?
Part of the problem is that the defaults bring in a lot of wide ranging support right now and we need to move things to Kconfig to make it easy to turn those things off. The various partition table types shouldn't be too hard to migrate and for moving all Kconfigs, I'm just going to do that since there can be a bit of churn that makes those patches hard to apply.
Thanks!
On Tue, May 03, 2016 at 01:37:41PM -0500, Derald Woods wrote:
On Sun, May 1, 2016 at 12:09 PM, Derald D. Woods woods.technical@gmail.com wrote:
On 05/01/2016 08:58 AM, Tom Rini wrote:
On Sat, Apr 30, 2016 at 07:12:28PM -0500, Derald D. Woods wrote:
On 04/28/2016 06:34 PM, Tom Rini wrote:
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
I am hoping to look at this tomorrow at work. Any suggested toolchain
you recommend?
gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely fine but I haven't started using those SDKs I just made today.
Hi Tom,
Using gcc-5.3.0, for 'omap3_logic', I get the following:
---8<------------------------------------------ arm-cortexa8-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram' arm-cortexa8-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 948 bytes ---8<------------------------------------------
That's odd, 5.3.1 from debian/unstable works.
I built the compiler today with crosstool-ng.
gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)
What things could/should be removed, from the configuration, to avoid these kinds of things in the future?
I would expect that the default board configuration to be less sensitive, in general. I guess I want to know what is the right size for an OMAP3 with SPL enabled.
Changing compilers, just for this, can cause quite a ripple on projects and the products that are supported by them.
So, the first thing to do would be to please try the following patch:
diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h index bc0e02a..6cef323 100644 --- a/arch/arm/include/asm/arch-omap3/omap.h +++ b/arch/arm/include/asm/arch-omap3/omap.h @@ -145,7 +145,7 @@ struct gpio { #define NON_SECURE_SRAM_START 0x40208000 /* Works for GP & EMU */ #define NON_SECURE_SRAM_END 0x40210000 -#define SRAM_SCRATCH_SPACE_ADDR 0x4020E000 +#define SRAM_SCRATCH_SPACE_ADDR 0x4020F000 #define LOW_LEVEL_SRAM_STACK 0x4020FFFC diff --git a/doc/SPL/README.omap3 b/doc/SPL/README.omap3 index c77ca43..cc54afe 100644 --- a/doc/SPL/README.omap3 +++ b/doc/SPL/README.omap3 @@ -33,8 +33,9 @@ SRAM: 0x40200000 - 0x4020FFFF DDR1: 0x80000000 - 0xBFFFFFFF Option 1 (SPL only): -0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata -0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x40200800 - 0x4020EFFF: Area for SPL text, data and rodata +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) +0x4020FCB0 - 0x4020FFFF: Area for the SPL stack 0x80000000 - 0x8007FFFF: Area for the SPL BSS. 0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot 0x80208000 - 0x80307FFF: malloc() pool available to SPL. @@ -42,6 +43,7 @@ Option 1 (SPL only): Option 2 (SPL or X-Loader): 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*) 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot 0x87000000 - 0x8707FFFF: Area for the SPL BSS. 0x87080000 - 0x870FFFFF: malloc() pool available to SPL. diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h index 6c79643..ed03e07 100644 --- a/include/configs/omap3_logic.h +++ b/include/configs/omap3_logic.h @@ -28,13 +28,11 @@ #define CONFIG_SYS_SPL_MALLOC_START 0x80208000 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000 -#include <configs/ti_omap3_common.h> /* Override default SPL info to minimize empty space and allow BCH8 in SPL */ -#undef CONFIG_SPL_TEXT_BASE -#undef CONFIG_SPL_MAX_SIZE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
+#include <configs/ti_omap3_common.h> /* Display CPU and Board information */ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index fbd0c2a..289c8e9 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -10,11 +10,8 @@ #define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */ #define CONFIG_NAND -#include <configs/ti_omap3_common.h> -#undef CONFIG_SPL_MAX_SIZE -#undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) +#include <configs/ti_omap3_common.h> #define CONFIG_BCH diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 32877d1..ffd695f 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -68,9 +68,17 @@ /* TWL4030 */ #define CONFIG_TWL4030_POWER -/* SPL */ +/*
- For SPL we say that our text base is at 0x40200800 for compatibility
- with HS and GP devices. We say that the maximum image size is the end
- of the downloaded image area minus the text base. If desired the text
- base can be lowered by individual platforms but the upper bound is a
- hard limit.
- */
+#ifndef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200800 -#define CONFIG_SPL_MAX_SIZE (54 * 1024) +#endif +#define CONFIG_SPL_MAX_SIZE (0x4020F000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds" #define CONFIG_SPL_POWER_SUPPORT #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index 586d848..66592f0 100644 --- a/include/configs/ti_omap4_common.h +++ b/include/configs/ti_omap4_common.h @@ -143,12 +143,14 @@ BOOTENV /*
- Defines for SPL
- It is known that this will break HS devices. Since the current size of
- SPL is overlapped with public stack and breaking non HS devices to
boot.
- So moving TEXT_BASE down to non-HS limit.
- For SPL we set our text base to the start of the download image area
for GP
- devices. HS devices will have to define this value instead. We say
that
- the maximum image size is the end of the downloaded image area minus
the
*/
- text base.
+#ifndef #define CONFIG_SPL_TEXT_BASE 0x40300000 +#endif #define CONFIG_SPL_MAX_SIZE (0x4030C000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
Okay. That patch allows compilation to complete successfully. But ...
---8<-----------------------------------------------------
U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 11:50:16) Trying to boot from MMC1 Expected Linux image is not found. Trying to start U-boot
---8<-----------------------------------------------------
This is likely related to the "[U-Boot] spl_mmc: allow to load raw image" thread that is being discussed now.
My SD/MMC card is FAT on the first partition. The 'omap3_logic' board does not use RAW MMC access. So MLO and u-boot.img are simply files on the FAT filesystem.
Derald
Tom,
Is this patch landing in this release? I saw another patch, for the same purpose, on another board applied. Just wondering...
No, this is too invasive as it changes the defaults for all OMAP3 platforms. The other platform is just making use of the changes you've already got on omap3_logic.
On Wed, Apr 27, 2016 at 5:46 PM, Tom Rini trini@konsulko.com wrote:
While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only from 0x40200000 to 0x4020F000 and exceeding that will cause failure to boot. Further, we need to make sure that we don't run into SRAM_SCRATCH_SPACE_ADDR as once SPL is running we will write values there and would corrupt our running image.
Cc: Adam Ford aford173@gmail.com Cc: Steve Sakoman sakoman@gmail.com Signed-off-by: Tom Rini trini@konsulko.com
Tested-By: Adam Ford aford173@gmail.com
include/configs/omap3_logic.h | 2 +- include/configs/omap3_overo.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h index 055dcb7..6c79643 100644 --- a/include/configs/omap3_logic.h +++ b/include/configs/omap3_logic.h @@ -34,7 +34,7 @@ #undef CONFIG_SPL_TEXT_BASE #undef CONFIG_SPL_MAX_SIZE #define CONFIG_SPL_TEXT_BASE 0x40200000 -#define CONFIG_SPL_MAX_SIZE (64 * 1024) +#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
/* Display CPU and Board information */
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index c066eae5..fbd0c2a 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -12,9 +12,9 @@
#include <configs/ti_omap3_common.h> #undef CONFIG_SPL_MAX_SIZE -#define CONFIG_SPL_MAX_SIZE (64*1024) #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200000 +#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)
#define CONFIG_BCH
-- 1.9.1
participants (4)
-
Adam Ford -
Derald D. Woods -
Derald Woods
-
Tom Rini