[U-Boot] [PATCHv2 1/2] ti: keystone2: Move CONFIG_ISW_ENTRY_ADDR to a common place

[Lokesh Vutla]

Hi Tom,

On 20/03/19 8:09 PM, Tom Rini wrote:
> On Wed, Mar 20, 2019 at 07:03:52PM +0530, Lokesh Vutla wrote:
>>
>>
>> On 19/03/19 4:44 PM, Tom Rini wrote:
>>> The ISW_ENTRY_ADDR Kconfig option under mach-omap2 isn't a SoC specific
>>> notion but rather "where is our previous stage loaded in memory?"
>>> option.  Make use of this on ARCH_KEYSTONE rather than SPL_TEXT_BASE for
>>> our HS builds that are not using SPL anyhow.
>>>
>>> Cc: Vitaly Andrianov <vitalya at ti.com>
>>> Cc: Andrew F. Davis <afd at ti.com>
>>> Cc: Lokesh Vutla <lokeshvutla at ti.com>
>>> Signed-off-by: Tom Rini <trini at konsulko.com>
>>
>> Reviewed-by: Lokesh Vutla <lokeshvutla at ti.com?
> 
> Thanks.
> 
>>> ---
>>> On a related note, can we please move SRAM_SCRATCH_SPACE_ADDR to a more
>>> fixed location?  The build logic here is going to break again when more
>>
>> I guess you are talking about keystone2 devices. All omap platforms has sram
>> scratch space as last 1K.  Something similar can be done for keystone2 platforms
>> as well.
> 
> Well, as came up in another thread, that's not quite true for OMAP
> platforms.  Today we shove it in such a location that stack could grow

I see what you are talking about. Then CONFIG_SYS_INIT_SP_ADDR should be updated
to SRAM_SCRATCH_SPACE_ADDR instead of NON_SECURE_SRAM_END. I am surprised we
never faced an issue.

> into it, and IFF what the am437x TRM says is true, we've been violating
> rules wrt stack placement since forever (that "public stack" is for ROM

That public stack is used by ROM only while downloading the image. Once ROM
completes the download it is available for use by any bootloader.

Thanks and regards,
Lokesh

> use only).  We do shove sram scratch to the end of the download image
> area, yes.  And yes, moving forward and given how big the download area
> is for keystone2, I would like to see scratch moved to the last 1K of
> download and stack put below that, for safety.
>