[U-Boot] [PATCH] TI: Rework SRAM definitions and maximums

Ladislav Michl
2016-09-06T13:13:00Z

On Sat, Aug 27, 2016 at 05:29:44PM +0530, Lokesh Vutla wrote:
> On Friday 26 August 2016 11:00 PM, Tom Rini wrote:
> > On all TI platforms the ROM defines a "downloaded image" area at or near
> > the start of SRAM which is followed by a reserved area. As it is at
> > best bad form and at worst possibly harmful in corner cases to write in
> > this reserved area, we stop doing that by adding in the define
> > NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
> > area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
> > At current we define the end of scratch space at 0x228 bytes past the
> > start of scratch space this this gives us a lot of room to grow. As
> > these scratch uses are non-optional today, all targets are modified to
> > respect this boundary.
> >
> > Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
>
> Verified on AM437x-GP EVM.
>
> Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
> Acked-by: Lokesh Vutla <lokeshvutla@ti.com>

Verified on IGEPv2.

Tested-by: Ladislav Michl <ladis@linux-mips.org>

Also note, that this patch and CONFIG_SPL_SYS_MALLOC_SIMPLE is needed
for sucessfull build (with gcc-5.4.0), otherwise compilation fails with:
arm-v7a-linux-gnueabi-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram'
arm-v7a-linux-gnueabi-ld.bfd: region `.sram' overflowed by 264 bytes
Just enabling CONFIG_SPL_SYS_MALLOC_SIMPLE without this patch makes
malloc in fat loading code fail and thus causes boot failure.

Best regards,
ladis