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

Patrick DELAUNAY patrick.delaunay at st.com
Thu Apr 9 20:32:29 CEST 2020

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()

> (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 :

	depends on ARM && !ARM64
	bool "Allows initializing BSS early before entering board_init_f"
	  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

> [...]



More information about the U-Boot mailing list