Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
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> 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 0x4021 > >> -#define SRAM_SCRATCH_SPACE_ADDR0x4020E000 > >> +#define SRAM_SCRATCH_SPACE_ADDR0x4020F000 > >> #define LOW_LEVEL_SRAM_STACK0x4020FFFC > >> 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: 0x4020 - 0x4020 > >> DDR1: 0x8000 - 0xBFFF > >> 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 - 0x4020: Area for the SPL stack > >> 0x8000 - 0x8007: Area for the SPL BSS. > >> 0x8010: 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 > >> 0x8700 - 0x8707: Area for the SPL BSS. > >> 0x8708 - 0x870F: 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_SIZE0x10 > >> -#include > >> /* 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 0x4020 > >> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - > >> CONFIG_SPL_TEXT_BASE) > >> + > >> +#include > >> /* 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 > >> -#undef CONFIG_SPL_MAX_SIZE > >> -#undef CONFIG_SPL_TEXT_BASE > >> #define CONFIG_SPL_TEXT_BASE 0x4020 > >> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - > >> CONFIG_SPL_TEXT_BASE) > >> +#include > >> #define CONFIG_BCH > >> diff --git
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
On Sun, May 1, 2016 at 12:09 PM, Derald D. Woodswrote: > 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 0x4021 >> -#define SRAM_SCRATCH_SPACE_ADDR0x4020E000 >> +#define SRAM_SCRATCH_SPACE_ADDR0x4020F000 >> #define LOW_LEVEL_SRAM_STACK0x4020FFFC >> 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: 0x4020 - 0x4020 >> DDR1: 0x8000 - 0xBFFF >> 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 - 0x4020: Area for the SPL stack >> 0x8000 - 0x8007: Area for the SPL BSS. >> 0x8010: 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 >> 0x8700 - 0x8707: Area for the SPL BSS. >> 0x8708 - 0x870F: 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_SIZE0x10 >> -#include >> /* 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 0x4020 >> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - >> CONFIG_SPL_TEXT_BASE) >> + >> +#include >> /* 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 >> -#undef CONFIG_SPL_MAX_SIZE >> -#undef CONFIG_SPL_TEXT_BASE >> #define CONFIG_SPL_TEXT_BASE 0x4020 >> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - >> CONFIG_SPL_TEXT_BASE) >> +#include >> #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
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
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 0x4021 -#define SRAM_SCRATCH_SPACE_ADDR0x4020E000 +#define SRAM_SCRATCH_SPACE_ADDR0x4020F000 #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: 0x4020 - 0x4020 DDR1: 0x8000 - 0xBFFF 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 - 0x4020: Area for the SPL stack 0x8000 - 0x8007: Area for the SPL BSS. 0x8010: 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 0x8700 - 0x8707: Area for the SPL BSS. 0x8708 - 0x870F: 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_SIZE0x10 -#include /* 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 0x4020 -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) + +#include /* 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 -#undef CONFIG_SPL_MAX_SIZE -#undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x4020 -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) +#include #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 -
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
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_END0x4021 -#define SRAM_SCRATCH_SPACE_ADDR0x4020E000 +#define SRAM_SCRATCH_SPACE_ADDR0x4020F000 #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: 0x4020 - 0x4020 DDR1: 0x8000 - 0xBFFF 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 - 0x4020: Area for the SPL stack 0x8000 - 0x8007: Area for the SPL BSS. 0x8010: 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 0x8700 - 0x8707: Area for the SPL BSS. 0x8708 - 0x870F: 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_START0x80208000 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x10 -#include /* 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 0x4020 -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) + +#include /* 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 -#undef CONFIG_SPL_MAX_SIZE -#undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x4020 -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE) +#include #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 -
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
On Wed, Apr 27, 2016 at 5:46 PM, Tom Riniwrote: > While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only > from 0x4020 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 > Cc: Steve Sakoman > Signed-off-by: Tom Rini Tested-By: Adam Ford > --- > 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 0x4020 > -#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 > #undef CONFIG_SPL_MAX_SIZE > -#define CONFIG_SPL_MAX_SIZE(64*1024) > #undef CONFIG_SPL_TEXT_BASE > #define CONFIG_SPL_TEXT_BASE 0x4020 > +#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - > CONFIG_SPL_TEXT_BASE) > > #define CONFIG_BCH > > -- > 1.9.1 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
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. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
I am hoping to look at this tomorrow at work. Any suggested toolchain you recommend? On Apr 28, 2016 5:45 PM, "Tom Rini"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 0x4020 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 > > Cc: Steve Sakoman > > Signed-off-by: Tom Rini > > 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 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
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 0x4020 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> Cc: Steve Sakoman > Signed-off-by: Tom Rini 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 signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot