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

[Tom Rini]

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
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
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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190320/9a1aad9b/attachment.sig>