From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Date: Sun, 26 Nov 2017 15:04:57 +0100 Subject: [U-Boot] U-Boot proper(not SPL) relocate option In-Reply-To: <8da48f85-01b8-dcce-91cf-2ebdc289912b@rock-chips.com> References: <8da48f85-01b8-dcce-91cf-2ebdc289912b@rock-chips.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi Kever, Am 21.11.2017 um 10:33 schrieb Kever Yang: >     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. In addition to what others have commented, chain-loading a development (proper) U-Boot from (proper) U-Boot is a nice feature on aarch64 SoCs. It relies on U-Boot being able to start executing from low memory, where it does not conflict with the U-Boot in high memory calling it. Blocking this for all Rockchip SoCs just for the sake of saving some memory in SDRAM/storage does not sound appealing. That does not affect SPL of course. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)