On Sun, May 1, 2016 at 12:09 PM, Derald D. Woods <woods.techni...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot