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

Wed Nov 22 08:51:49 UTC 2017

Hi Kever,

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

As I've written in the other mail - in some scenarios we don't want to
have fragmented memory (e.g. rootfs flashing).

Would this "fragmented" 512 MiB enough to flash all your binaries?

>      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

I do find your arguments perfectly valid (as in the end customer
decides what features are in u-boot).

Please prepare patches and send them for review.

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

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/9f81b57c/attachment.sig>