Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size

2016-05-03 Thread Tom Rini
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

2016-05-03 Thread Derald Woods
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 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

2016-05-01 Thread Derald D. Woods

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

2016-05-01 Thread Tom Rini
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

2016-04-30 Thread Derald D. Woods

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

2016-04-29 Thread Adam Ford
On Wed, Apr 27, 2016 at 5:46 PM, 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 

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

2016-04-28 Thread Tom Rini
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

2016-04-28 Thread Adam Ford
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

2016-04-28 Thread Tom Rini
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