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@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 > > 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
pgpzR5wGbN8FP.pgp
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
