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

[Andreas Dannenberg]

Andrew,

On Thu, May 09, 2019 at 12:03:31PM -0400, Andrew F. Davis wrote:
> On 5/8/19 11:52 PM, Lokesh Vutla wrote:
> > 
> > 
> > On 09/05/19 3:07 AM, Andreas Dannenberg wrote:
> >> The board detection scheme employed on various TI EVMs makes use of
> >> SRAM scratch space to share data read from an on-board EEPROM between
> >> the different bootloading stages. Map the associated definition that's
> >> used to locate this data into the SRAM scratch space we use on AM654x.
> >>
> >> Signed-off-by: Andreas Dannenberg <dannenberg at ti.com>
> >> ---
> >>  arch/arm/mach-k3/include/mach/am6_hardware.h | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h
> >> index 3343233aa3..6df7631545 100644
> >> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h
> >> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
> >> @@ -44,4 +44,7 @@
> >>  #define CTRLMMR_LOCK_KICK1				0x0100c
> >>  #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL			0xd172bc5a
> >>  
> >> +/* MCU SCRATCHPAD usage */
> >> +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE
> > 
> > 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.

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.

--
Andreas Dannenberg
Texas Instruments Inc


> Andrew
> 
> > Thanks and regards,
> > Lokesh
> > 
> >> +
> >>  #endif /* __ASM_ARCH_AM6_HARDWARE_H */
> >>
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> >