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

Derald Woods woods.technical at gmail.com
Tue May 3 20:37:41 CEST 2016 

On Sun, May 1, 2016 at 12:09 PM, Derald D. Woods <woods.technical at 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!
>>
>>
>


-- 
Derald D. Woods

More information about the U-Boot mailing list