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

[Tom Rini]

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

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.

-- 
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/20190321/c1aa1d9f/attachment.sig>