[PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again

Pali Rohar pali at kernel.org
Fri Jan 6 17:40:44 CET 2023


On Friday 06 January 2023 10:13:34 Patrick DELAUNAY wrote:
> Hi,
> 
> On 1/5/23 20:25, Pali Rohar wrote:
> > Ok, so it is working...
> > 
> > On Thursday 05 January 2023 19:31:19 Patrick DELAUNAY wrote:
> > > I tested on STM32MP157C-EV1 on my side...
> > > 
> > > with 1GiB mermory size
> > > 
> > > U-Boot is booting on next TOP (for trusted boot with TF-A and OP-TEE)
> > > 
> > > 
> > > 
> > > U-Boot 2023.01-rc4-00386-gb429e78942de (Jan 05 2023 - 17:44:04 +0100)
> > > 
> > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)
> > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)
> > > CPU: STM32MP157C?? Rev.Z
> > > Model: STMicroelectronics STM32MP157C eval daughter on eval mother
> > > Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1)
> > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)
> > > DRAM:  1 GiB
> > > ....
> > > 
> > > 
> > > STM32MP> bdinfo
> > > boot_params = 0x00000000
> > > DRAM bank   = 0x00000000
> > > -> start    = 0xc0000000
> > > -> size     = 0x3ffff000         <<<<<< the patch is applied - 4kiB here !!!
> > But this is wrong. DRAM bank size should not be changed. I think that in
> > U-Boot is another issue which propagates mapped U-Boot RAM size/range to
> > the places where should be real DDR size.
> 
> 
> Yes it is wrong
> 
> and it is introduced by your patch...
> 
> 
> in the STM32MP15x platfrorm are using the genric weak function
> 
> 
> ./common/board_f.c:267
> 
> 
> __weak int dram_init_banksize(void)
> {
>     gd->bd->bi_dram[0].start = gd->ram_base;
>     gd->bd->bi_dram[0].size = get_effective_memsize();
> 
>     return 0;
> }
> 
> For me:
> 
> get_effective_memsize() must return the effective size of the DDR
> 
> and NOT -4KiB to avoid side effects in other part of the code (LMB for
> example)

Ok, this needs to be reworked. But seems it is not just simple issue.

> 
> I think today we need to revert your patch.

Hard revert without anything else is not the solution. As it will break
all 36-bit powerpc boards with 4GB of DDR RAM on which is u-boot running
in 32-bit mode.


More information about the U-Boot mailing list