From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 8 Jul 2015 08:46:25 +0200 Subject: [U-Boot] hang: ARM64/Relocating u-boot from u-boot In-Reply-To: <20150707223652.5072A3805B1@gemini.denx.de> References: <20150707223652.5072A3805B1@gemini.denx.de> Message-ID: <20150708084625.5a18e9a5@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Wolfgang, On Wed, 08 Jul 2015 00:36:52 +0200, Wolfgang Denk wrote: > Dear Jagan, > > In message you wrote: > > > > I'm running u-boot from u-boot prompt, just like a standalone > > application with CONFIG_SYS_TEXT_BASE address. > ... (note: the board here identifies itself as "ARM64 Reference Board", which does not exist in the current U-Boot source code, so this is obviously a non-mainline(-yet?) port for which we could hardly give assistance anyway.) > > Has any one tried the same before, please let me know for any inputs? > > Actually this is even a FAQ: > > http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM If I may, this FAQ is slightly outdated, in that chainloading U-Boot is not only possible but actually made possible by design, at least for many ARM (and possibly some ARM64) targets, and I suspect for many non-ARM targets too, as long as they use SPL. First off: the FAQ is perfectly true if applied to running SPL from SPL. But you can easily run U-Boot from SPL -- that's actually the point of SPL in the first place -- and this is done, usually, by having SPL reset the hardware to the extent of getting external RAM working, and conversively having U-Boot reset the hardware in (OS) booting condition *except* for the external RAM part which U-Boot could not do anyway. IOW, on targets with SPL, U-Boot starts with the guarantee that all initializations needed for external RAM to work have been done, and it guarantees that it will not perform these external RAM inits again. And since an SPL-chainloaded U-Boot runs with external already initialized and does not initialize it again, it follows that this U-Boot is a valid environment for running another instance of itself, provided the new instance and current instances do not overwrite each other. And U-Boot relocates itself to the highest possible address, thereby freeing up its load address. Provided this load address was chosen low in external RAM, and provided the board has enough external RAM (which any board aiming to chainload a big Linux kernel from a smaller U-Boot should have), this allows loading U-Boot to its link-time address from a running U-Boot instance without any trashing of either instance. All of this makes it nont only perfectly possible for (SPL-run) U-Boot to chainload (SPL-run) U-Boot, it pretty much guarantees it. And while chainloading ans SPL-run U-Boot is useless in bringing up a board (where the effort is in SPL itself), it becomes very useful in adding or modifying all the rest of U-Boot, for instance tweaking the performance of a network driver. (on an OT note, I'd even say that a SPL-supported U-Bot which cannot chainload itself probably does not completely and/or properly reset the hardware into booting condition, but that's slightly beside the point.) Note that the above description applies to any target in which U-Boot starts from external RAM rather than IRAM or FLASH; not only those targets with SPL, but also those with a ROM bootloader capable to initialize the external RAM and chain to its payoad there, e.g. kirkwood. Maybe we could add an addendum to the FAQ for the SPL and ROM bootloader cases? > Best regards, > > Wolfgang Denk Amicalement, -- Albert.