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@ti.com Cc: Andrew F. Davis afd@ti.com Cc: Lokesh Vutla lokeshvutla@ti.com Signed-off-by: Tom Rini trini@konsulko.com
Reviewed-by: Lokesh Vutla <lokeshvutla@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.