[U-Boot,v2,3/3] rockchip: config: update CONFIG_SPL_MAX_SIZE for 64bit CPUs

Since we move the ATF bl31 entry for 64bit CPUs to 0x40000, we need to
limit the SPL size in 0x40000(start from 0) so that we don't need to do
the relocate for ATF loading.
Note that there will be separate BSS, STACK and MALLOC heap, so the size
0x40000(256KB) should be enough for SPL text.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---

Changes in v2: None

 include/configs/rk3328_common.h | 2 +-
 include/configs/rk3368_common.h | 2 +-
 include/configs/rk3399_common.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

> Since we move the ATF bl31 entry for 64bit CPUs to 0x40000, we need to
> limit the SPL size in 0x40000(start from 0) so that we don't need to do
> the relocate for ATF loading.
> Note that there will be separate BSS, STACK and MALLOC heap, so the size
> 0x40000(256KB) should be enough for SPL text.
> > Signed-off-by: Kever Yang <kever.yang@rock-chips.com> I tested this
series on top of v2019.10 with rockpro64-rk3399_defconfig. While it
builds fine, it does not work properly: U-Boot TPL
2019.10-00005-g7a0826a4f7-dirty (Oct 21 2019 - 10:12:53) Trying to boot
from BOOTROM Returning to boot ROM... U-Boot SPL
2019.10-00005-g7a0826a4f7-dirty (Oct 21 2019 - 10:12:53 +0200) Trying to
boot from MMC1 U-Boot TPL 2019.10-00005-g7a0826a4f7-dirty (Oct 21 2019 -
10:12:53) [boot loop] Size of u-boot-spl-nodtb.bin is 387k, so it does
not fit in 256K. (Overlap in data section?) Earlier I tried the same
u-boot version without this series but with bl31 entry point patched to
0x80000. This loads fine. One question, just for me to understand: Why
do we load u-boot SPL into limited space below bl31? Since we do not
return to SPL from bl31, we should not need to place SPL in secure DRAM.
What do I miss here? Thanks, Soeren

On 2019/10/21 下午6:06, Soeren Moch wrote:
> > Since we move the ATF bl31 entry for 64bit CPUs to 0x40000, we need to
> > limit the SPL size in 0x40000(start from 0) so that we don't need to do
> > the relocate for ATF loading.
> > Note that there will be separate BSS, STACK and MALLOC heap, so the size
> > 0x40000(256KB) should be enough for SPL text.
> > > Signed-off-by: Kever Yang <kever.yang@rock-chips.com> I tested this 
> series on top of v2019.10 with rockpro64-rk3399_defconfig. While it 
> builds fine, it does not work properly: U-Boot TPL 
> 2019.10-00005-g7a0826a4f7-dirty (Oct 21 2019 - 10:12:53) Trying to 
> boot from BOOTROM Returning to boot ROM... U-Boot SPL 
> 2019.10-00005-g7a0826a4f7-dirty (Oct 21 2019 - 10:12:53 +0200) Trying 
> to boot from MMC1 U-Boot TPL 2019.10-00005-g7a0826a4f7-dirty (Oct 21 
> 2019 - 10:12:53) [boot loop] Size of u-boot-spl-nodtb.bin is 387k, so 
> it does not fit in 256K. (Overlap in data section?)

If CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x50000 is removed, the size should 
be much smaller,

could you help to check the .config?

> Earlier I tried the same u-boot version without this series but with 
> bl31 entry point patched to 0x80000. This loads fine.


This series is to adapt the BL31 entry move to 0x40000.

> One question, just for me to understand: Why do we load u-boot SPL 
> into limited space below bl31? Since we do not return to SPL from 
> bl31, we should not need to place SPL in secure DRAM. What do I miss here?


The SPL is load by BootRom, and it always load/entry at offset 0 of 
DRAM, if we don't want to do

any relocate, it always below bl31.

Since the CPU is in secure move when running SPL, so it's fine to place 
it in secure DRAM,

the memory is secure or non secure is defined in bl31 and later.


Thanks,

- Kever

> Thanks, Soeren

On 21.10.19 12:15, Kever Yang wrote:
>
>
> On 2019/10/21 下午6:06, Soeren Moch wrote:
>> > Since we move the ATF bl31 entry for 64bit CPUs to 0x40000, we need to
>> > limit the SPL size in 0x40000(start from 0) so that we don't need to do
>> > the relocate for ATF loading.
>> > Note that there will be separate BSS, STACK and MALLOC heap, so the size
>> > 0x40000(256KB) should be enough for SPL text.
>> > > Signed-off-by: Kever Yang <kever.yang@rock-chips.com> I tested
>> this series on top of v2019.10 with rockpro64-rk3399_defconfig. While
>> it builds fine, it does not work properly: U-Boot TPL
>> 2019.10-00005-g7a0826a4f7-dirty (Oct 21 2019 - 10:12:53) Trying to
>> boot from BOOTROM Returning to boot ROM... U-Boot SPL
>> 2019.10-00005-g7a0826a4f7-dirty (Oct 21 2019 - 10:12:53 +0200) Trying
>> to boot from MMC1 U-Boot TPL 2019.10-00005-g7a0826a4f7-dirty (Oct 21
>> 2019 - 10:12:53) [boot loop] Size of u-boot-spl-nodtb.bin is 387k, so
>> it does not fit in 256K. (Overlap in data section?)
>
> If CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x50000 is removed, the size
> should be much smaller,
>
> could you help to check the .config?
>
Yes, indeed, thanks. My mistake in merging.
SPL is much smaller now.

When I tried to start this newly built idbloader, unfortunately my
RockPro64 board died. It also is not able to start with other SD cards
and images anymore. Very sad.

>> Earlier I tried the same u-boot version without this series but with
>> bl31 entry point patched to 0x80000. This loads fine.
>
>
> This series is to adapt the BL31 entry move to 0x40000.
>
Of course. I tried this before you sent this series.
>
>> One question, just for me to understand: Why do we load u-boot SPL
>> into limited space below bl31? Since we do not return to SPL from
>> bl31, we should not need to place SPL in secure DRAM. What do I miss
>> here?
>
>
> The SPL is load by BootRom, and it always load/entry at offset 0 of
> DRAM, if we don't want to do
>
> any relocate, it always below bl31.
>
Ah, BootRom can load TPL to arbitrary places, but then SPL can only be
loaded to address zero!?
Anyway, with the smaller SPL it should be fine this way.

Unfortunately I cannot test since my board broke down.

Regards,
Soeren
>
> Since the CPU is in secure move when running SPL, so it's fine to
> place it in secure DRAM,
>
> the memory is secure or non secure is defined in bl31 and later.
>
>
> Thanks,
>
> - Kever
>
>> Thanks, Soeren