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

Wed Nov 22 08:47:58 UTC 2017

Hi Chris,

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

As fair as I remember there was CONFIG_PRELOAD something before SPL
(u-boot delivered two binaries).

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

As I mentioned before - the continous space from RAM start till end -
u-boot size is crucial for updating - i.e when rootfs needs to be
flashed.

But, I do agree with above arguments.

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

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/20171122/440b49e9/attachment.sig>