[U-Boot] [PATCH 1/7] arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded

[Lokesh Vutla <lokeshvutla@ti.com>]

On 15/02/19 3:21 AM, Andrew F. Davis wrote:
> On 2/13/19 9:32 PM, Lokesh Vutla wrote:
>>
>>
>> On 14/02/19 12:07 AM, Andrew F. Davis wrote:
>>> On HS devices the 512b region of reset isolated memory called
>>> MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
>>> cannot use this memory. It is only used to store a single value
>>> left at the end of SRAM by ROM that will be needed later. Save
>>> that value to a global variable stored in the .data section.
>>> This section is used as .bss will be cleared between saving
>>> this value and using it.
>>>
>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>> ---
>>>  arch/arm/mach-k3/am6_init.c                  | 8 +++-----
>>>  arch/arm/mach-k3/include/mach/am6_hardware.h | 3 ---
>>>  2 files changed, 3 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
>>> index a5553190b4..462538e45d 100644
>>> --- a/arch/arm/mach-k3/am6_init.c
>>> +++ b/arch/arm/mach-k3/am6_init.c
>>> @@ -49,11 +49,11 @@ static void ctrl_mmr_unlock(void)
>>>  	mmr_unlock(CTRL_MMR0_BASE, 7);
>>>  }
>>>  
>>> +u32 bootindex __attribute__((section(".data")));
>>
>> After thinking a bit more I realized that backup bootmode might fail. R5 SPL is
>> fine but when it jumps to A53 SPL it is trying to read the bootindex again from
>> K3_BOOT_PARAM_TABLE_INDEX_VAL(this is already the case and is wrong). It is not
>> guaranteed that R5 SPL did not damage this ROM param table. We should somehow
>> pass bootindex to A53 SPL using scratchpad space.
>>
> 
> I don't know of any super good way to pass data from R5-SPL to A53-SPL,
> but I don't think MCU_PSRAM0 will be the way to do it. For all we know

Agreed.

> before A53-SPL has started the R5-SPL may have shutdown and something
> else has booted, which could have used that MCU local RAM space. I think
> we need something that gets passed to A53 anyway, maybe a DT fixup?

Yeah or we can update spl_boot_list array with both primary and secondary
bootdevices.

Actually this patch as such has no issues and is not introducing any new
regressions.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

For backup boot modes Ill take a look and try to address in a cleaner way.

Thanks and regards,
Lokesh