[U-Boot] SPL binary too large for OMAP4460 OCM

[Sricharan R]

On Wednesday 04 September 2013 06:48 PM, Tom Rini wrote:
> On Wed, Sep 04, 2013 at 11:43:01AM +0300, Oleg Kosheliev wrote:
>> Hi, Andr?
>>
>>> ________________________________________
>>> From: u-boot-bounces at lists.denx.de [u-boot-bounces at lists.denx.de] on
>> behalf of Andr? >Schaller [an.schall at googlemail.com]
>>> Sent: Wednesday, September 04, 2013 10:09 AM
>>> To: u-boot at lists.denx.de
>>> Subject: [U-Boot] SPL binary too large for OMAP4460 OCM
>>>
>>> Hi everybody,
>>>
>>> I need to add functionality to the SPL code. I tried to implement in a
>>> memory-saving way, however, the SPL is about 45 kB after compilation. To
>>> get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 *
>>> 1024). Now, the SPL as well as u-boot won't boot. After the device'
>>> (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output
>>> on terminal.
>>>
>>> My question: is it theoretically possible to to establish a successfully
>>> booting SPL with ~45 kB in size for this device? The device'
>>> on-chip-memory is 56kB so it could fit in there. If so, what needs to be
>>> configured / tuned to get it working? Are there any other features I
>>> could omit from the binary to make it smaller?
>>>
>>> Thanks a lot,
>>> Andr?
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>> We can use the area 0x40300000 - 0x4030bfff for downloading the SPL image.
>> If the image exceed this - it leads to corrupting the ROM code stack and
>> the device hangs up.
>> See my patch [U-Boot] [RFC PATCH] armv7:omap4-common: Correct check of the
>> SPL image size. (It's not in mainline. I'll do some corrections and send v2
>> soon.)
>> For HS devices the SPL image is loaded from the address 0x40304350. So we
>> have 0x4030bfff - 0x40304350 = 0x7CAF = 31,919 bytes for SPL.
>> The area from 0x40300000 till 0x40304350 in HS devices is used for security
>> data.
> FWIW, this issue is one reason I think we need to stop trying to make GP
> devices work kinda-sorta like the HS devices do and instead add a CONFIG
> for HS devices that sets things correctly.
>
>
 Yes, correct for OMAP4.

Regards,
 Sricharan