[U-Boot] [PATCH 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space

[Andreas Dannenberg]

Tom et al.,

On Thu, May 09, 2019 at 11:27:25AM -0500, Andreas Dannenberg wrote:
<snip>
> > > Won't HS devices fail while accessing this region? We should drop it altogether.
> > > 
> > 
> > HS devices cannot read this before SYSFW is loaded as by default it is
> > left firewalled by ROM. This read happens after SYSFW loading so it does
> > work currently, but no guarantee SYSFW will always remove this firewall
> > by default, we may need a driver that does an explicit device get for
> > this region to be sure it is powered and accessible (it is on a
> > different reset domain, it may need special handling).
> 
> Yes this is understood. For others reading this, this is how it is done
> in our current production U-Boot tree (upstream U-Boot does not yet have
> SYSFW loading capability).
> 
> > I think we should avoid using this scratchpad for a couple other
> > reasons. After R5 SPL has finished bootloading is handled by A53 cores,
> > the R5 will be repurposed and other software will run on it, possibly
> > wiping out the memory here. Anything we want to pass form R5 to A53
> > should use a non-R5-local memory, not this scratchpad. We need the same
> > for passing the original boot media info also.
> > 
> > A lot of pitfalls for just 512 bytes of RAM..
> 
> I don't disagree, this approach is limited, it's just the "easiest" we
> started using when creating the initial solution. Let's find/align on a
> different memory region.

After additional alignment internally with Lokesh and Andrew we agreed
on that for the time being we would like to move forward with the
solution proposed here as it relates to the use of the scratchpad SRAM.
It works for all current use cases including "high security" type
devices as it stands. We may re-visit and evolve the solution should a
need arise when adding support for a future device (so far there is no
such need on our immediate radar screen).

I also just rebased the solution on the latest upstream/master tree and
confirmed that it still works as expected.

--
Andreas Dannenberg
Texas Instruments Inc

> While at it, there is a need to pass additional data across our three
> boot stages (R5 SPL -> A53 SPL -> A53 U-Boot); for example I'd at some
> point like to carry forward peripheral initialization state (so we don't
> have to re-probe stuff 3 times), amongst other things, for which I was
> eyeing to use the new CONFIG_BLOBLIST* feature. So if we can identify a
> new/dedicated memory region for such data it would be a good opportunity
> to also start making use of the BLOBLIST feature at the same time,
> creating a more scalable solution.