[U-Boot] 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(-)

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 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
>

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