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@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: w...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
