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

[Patrick DELAUNAY]

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)


I think today we need to revert your patch.


regards

Patrick