From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Wed, 22 Nov 2017 09:47:58 +0100 Subject: [U-Boot] U-Boot proper(not SPL) relocate option In-Reply-To: References: <8da48f85-01b8-dcce-91cf-2ebdc289912b@rock-chips.com> <20171121112953.12d5176b@jawa> Message-ID: <20171122094727.2629c05a@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Chris, > On Wed, Nov 22, 2017 at 2:59 PM, Kever Yang > 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: