[U-Boot] U-Boot proper(not SPL) relocate option
Chris Packham
judge.packham at gmail.com
Wed Nov 22 07:29:28 UTC 2017
On Wed, Nov 22, 2017 at 2:59 PM, Kever Yang <kever.yang at rock-chips.com> wrote:
> 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.
(I can't really speak for u-boot but in general I think this applies).
In the old days there was no SPL. It was just the same bootloader
image. This image was written (or "burned") to a memory mapped
ROM/flash which could be executed directly in place. Then after the
RAM was initialised the image could be relocated and execution could
continue from the new address.
These days with SoCs that can boot from non-memory-mapped devices the
same tricks can't work which is where the SPL comes in.
The other thing with relocation is that u-boot likes to be at the very
top of RAM. This means we have all this nice contiguous space at the
bottom for the kernel/initrd/whatever .
We can't know at compile time where the top is as some boards may have
DIMMs an others may just have board variants with more or less memory
fitted. Which is why we need to set CONFIG_TEXTBASE to something that
is suitable for the lowest common denominator and relocate once we
know how much RAM we have.
> 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
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
More information about the U-Boot
mailing list