Dear Marek, > From: Marek Vasut <ma...@denx.de> > Sent: vendredi 3 avril 2020 23:27 > > On 4/3/20 10:28 AM, Patrick Delaunay wrote: > > Add protection in dram_bank_mmu_setup() to avoid access to bd->bi_dram > > before relocation. > > > > This patch allow to use the generic weak function dram_bank_mmu_setup > > to activate the MMU and the data cache in SPL or in U-Boot before > > relocation, when bd->bi_dram is not yet initialized. > > > > In this cases, the MMU must be initialized explicitly with > > mmu_set_region_dcache_behaviour function. > > > > Signed-off-by: Patrick Delaunay <patrick.delau...@st.com> > > --- > > > > arch/arm/lib/cache-cp15.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c > > index f8d20960da..54509f11c3 100644 > > --- a/arch/arm/lib/cache-cp15.c > > +++ b/arch/arm/lib/cache-cp15.c > > @@ -91,6 +91,10 @@ __weak void dram_bank_mmu_setup(int bank) > > bd_t *bd = gd->bd; > > int i; > > > > + /* bd->bi_dram is available only after relocation */ > > + if ((gd->flags & GD_FLG_RELOC) == 0) > > + return; > > Why not just set the bd->bi_dram correctly before this is called ?
Just set "bd->bi_dram" seens as a hack. For me the bd struct can be updated only in common/board_f.c after reserve_board() for U-Boot Or other spl_set_bd() called in board_init_r() for SPL. And that can cause issue if CONFIG_NR_DRAM_BANKS > 1 (even it is not the case today for STM32MP1). But if this kind of protection is not correct here I prefer come back to overidde of the weak fucntio dram_bank_mmu_setup in stm32mp arch (it is the reason this weak definition) Patrick
