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 <dannenb...@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@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
