On Thu, Mar 21, 2019 at 11:02:37AM +0530, Lokesh Vutla wrote:
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@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
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.
Keystone2 is "huge" and we got a bit lucky on AM335x/etc/etc until recently.
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.
Ah, OK. I'll not worry too much that the TRM claims it's for the ROM only then and that'll save us some headroom on these otherwise constrained platforms.