[U-Boot] U-Boot proper(not SPL) relocate option

[Kever Yang]

Hi Lukasz,


     Thanks for your quick comments on this topic.
On 11/21/2017 06:29 PM, Lukasz Majewski wrote:
> Hi Kever,
>
>> Hi Guys,
>>
>>       I try to understand why we need to do the relocate in U-Boot.
>>   From the document README/crt0.S, I think the relocation feature comes
>> from some SoC have limited SRAM whose size is enough to load the whole
>> U-Boot, but not enough to run all the drivers.
>>
>>       I don't know how many SoCs/Archs still must use this feature,
>> but I'm sure all
>> Rockchip SoCs do not need this feature in both SPL and proper U-Boot,
>> because rockchip using SPL always running in SRAM to init DDR SDRAM,
>> and after DRAM available always running U-Boot in DRAM.
> I always thought that u-boot needs relocation to place itself in the
> "known" area of SDRAM (which ends in its very end).

I can understand this feature, we always do dram_init_banks() first,
then we relocate to 'known' area, then will be no risk to access memory.
I believe there must be some historical reason for some kind of device,
the relocate feature is a wonderful idea for it.

In another case, we can also have a choice for not relocate because:
- we still can have similar 'bdinfo' but without relocate, we can init 
dram info
     first, and then init SP, malloc area and so on, and then other 
driver init.
- All solution for Rockchip SoCs at least have 512MByte DRAM,
     which should be enough for U-Boot and could consider to be 'known' 
area,
     many other SoCs should be similar.
- Without relocate we can save many step, some of our customer really
     care much about the boot time duration.
     * no need to relocate everything
     * no need to copy all the code
     * no need init the driver more than once

Thanks,
- Kever
>
> In this way we can upload u-boot proper via SPL to any SDRAM location
> and then (after relocation) it puts itself to "known" location.
>
> (Please check bdinfo command for details).
>
> Having u-boot at known location helps with:
>
> - Using the non fragmented SDRAM to download updates
>
> - Booting u-boot on many different devices (with different amount of
>    RAM) -> you always download u-boot in the near of SDRAM beginning and
>    then it relocates itself appropriately.
>
>
> However, I'm not sure if we would need relocation in SPL (which
> runs in SRAM). It seems to me that SPL binary is so board specific, that
> we shouldn't need such generic feature there.
>
>> There is a CONFIG_SPL_SKIP_RELOCATE for SPL to skip the relocate,
>> can we have another CONFIG_SKIP_RELOCATE for U-Boot proper?
>>
>>
>> Here is the document from README:
>>
>> board_init_f():
>>           - purpose: set up the machine ready for running
>> board_init_r(): i.e. SDRAM and serial UART
>>           - global_data is available
>>           - stack is in SRAM
>>           - BSS is not available, so you cannot use global/static
>> variables, only stack variables and global_data
>>
>>           Non-SPL-specific notes:
>>           - dram_init() is called to set up DRAM. If already done in
>> SPL this
>>                   can do nothing
>>
>>           SPL-specific notes:
>>           - you can override the entire board_init_f() function with
>> your own version as needed.
>>           - preloader_console_init() can be called here in extremis
>>           - should set up SDRAM, and anything needed to make the UART
>> work
>>           - these is no need to clear BSS, it will be done by crt0.S
>>           - must return normally from this function (don't call
>> board_init_r()
>>                   directly)
>>
>> board_init_r():
>>           - purpose: main execution, common code
>>           - global_data is available
>>           - SDRAM is available
>>           - BSS is available, all static/global variables can be used
>>           - execution eventually continues to main_loop()
>>
>>           Non-SPL-specific notes:
>>           - U-Boot is relocated to the top of memory and is now
>> running from there.
>>
>>           SPL-specific notes:
>>           - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is
>> defined and
>>                   CONFIG_SPL_STACK_R_ADDR points into SDRAM
>>           - preloader_console_init() can be called here - typically
>> this is done by selecting CONFIG_SPL_BOARD_INIT and then
>> supplying a
>>                   spl_board_init() function containing this call
>>           - loads U-Boot or (in falcon mode) Linux
>>
>>
>> Thanks,
>> - Kever
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de