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

[Lukasz Majewski]

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).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171121/cbcfaa3c/attachment.sig>