[PATCH v2 1/2] arm: stm32mp: activate data cache in SPL and before relocation

[Marek Vasut]

On 4/9/20 8:32 PM, Patrick DELAUNAY wrote:
> Dear Marek,
> 
>> From: Marek Vasut <marex at denx.de>
>> Sent: vendredi 3 avril 2020 23:32
>>
>> On 4/3/20 11:25 AM, Patrick Delaunay wrote:
>> [...]
>>> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
>>> index 36a9205819..c22c1a9bbc 100644
>>> --- a/arch/arm/mach-stm32mp/cpu.c
>>> +++ b/arch/arm/mach-stm32mp/cpu.c
>>> @@ -75,6 +75,12 @@
>>>  #define PKG_SHIFT	27
>>>  #define PKG_MASK	GENMASK(2, 0)
>>>
>>> +/*
>>> + * early TLB into the .data section so that it not get cleared
>>> + * with 16kB allignment (see TTBR0_BASE_ADDR_MASK)  */
>>> +u8 early_tlb[PGTABLE_SIZE] __section(".data") __aligned(0x4000);
>>
>> Can you early-malloc this one ?
> 
> I try to early maloc and it is failing because my code in arch_cpu_init() is executed before 
> the early poll initialization done in spl_common_init () called by spl_early_init()
> So it too late for my use case....
> 
> And if I initialise the MMU and the cache after this function it is too late, as
> dm_init_and_scan and fdt parsin is also called in spl_common_init()

Aha, OK. Can you document it in the commit message ? That's a real good
piece of information.

>> (why do you need this in __section("data") ?)
> 
> I try to use .bss and it is failing because the bss is resetted to 0 in SPL 
> after board_init_f, and the MMU is cleared without notice.
> 
> In fact BBS is not available, board_init_f() can use only stack variables
> and global_data (see README:258).
> 
> When I investigate the issue, I found CONFIG_SPL_EARLY_BSS
> that explain this point :
> 
> config SPL_EARLY_BSS
> 	depends on ARM && !ARM64
> 	bool "Allows initializing BSS early before entering board_init_f"
> 	help
> 	  On some platform we have sufficient memory available early on to
> 	  allow setting up and using a basic BSS prior to entering
> 	  board_init_f. Activating this option will also de-activate the
> 	  clearing of BSS during the SPL relocation process, thus allowing
> 	  to carry state from board_init_f to board_init_r by way of BSS.
> 
> So it is s compromise between harcoded addred (end of SYSRAM)
> or glabal variable in .data section
> 
> V2 patch with .data seems more elegant for me (it avoid assumption on
> U-Boot size for preloc case).
> 
> And if you have size issue for SPL you can deactivate cache for SPL only
> (CONFIG_SPL_SYS_DCACHE_OFF).

OK