From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 15 Jul 2010 00:35:56 +0200 Subject: [U-Boot] (imp) uboot image size In-Reply-To: <20100714214943.4BFB6160691@gemini.denx.de> References: <20100714061023.59E49160691@gemini.denx.de> <4C3E0E3D.7060305@free.fr> <4C3E135B.7040403@free.fr> <20100714205340.539AA160691@gemini.denx.de> <4C3E2808.5040509@free.fr> <20100714214943.4BFB6160691@gemini.denx.de> Message-ID: <4C3E3BCC.4080805@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 14/07/2010 23:49, Wolfgang Denk a ?crit : > Dear Albert ARIBAUD, > > why not keeping the list on Cc:? Wrong and unintended action on my part, sorry: I hit the wrong reply button (maybe there's a Thunderbird plugin that helps avoiding this?). As I don't know if you meant this reply of yours to be made public eventually, I'm replying in private. If you want to switch back to the list, no problem for me. > In message<4C3E2808.5040509@free.fr> you wrote: >> >>> CONFIG_SKIP_LOWLEVEL_INIT is an ARM specific thing, and I am almost >>> sure that Sagar is on a PowerPC systems. >> >> I think we both asked what system Sagar is talking about. But yes, I am >> talking about ARM here -- the only architecture for which I can claim >> knowledge of u-boot init sequence if I have any. > > I understand this. Sagar probably doesn't. > >>> Be careful again. Do you really mean "relocate" here? And >>> "overloading" a running image is definitely NOT a safe operation. >> >> By "relocate" I mean the code that runs after low level init code once >> RAM is available: if CONFIG_SKIP_RELOCATION is not defined (again, on >> ARM, at least on arm926ejs) this relocation code moves u-boot from its >> current location to TEXT_BASE, then jumps to it. > > But that is actyally only copying the code, not relocating it. We need > to be very precise with these terms, as they mean different things. I understand your point -- indeed, the code was intended to run at TEXT_BASE, and the actual relocation is when it is stored in Flash (or RAM when TFTP'ed) and starts running there; the code I mentionede which is under !CONFIG_SKIP_RELOCATION actually "de-relocates" it back to where it should have been. >> As for "overloading", I should say "overwriting" actually, and it is >> quite safe -- as safe as booting u-boot at least, as this "overwriting" >> is the effect of the relocation I just described, which happens at every >> (ARM) u-boot NOR FLASH startup. > > I disagree. You do not "overwrite" any running code. If you mean "it is forbidden to overwrite any running code", you're right; but this never happens in the two scenarios I describe where (de)relocation happens: in the NOR Flash boot scenario, there is no code running at TEXT_BASE when U-boot gets copied there; in the "TFTP" scenario, granted the "chaining" u-boot is running at TEXT_BASE when it executes the 'go' to whereever in RAM the "chained" u-boot resides; but as soon as this "chained" u-boot starts executing, the "chaining" u-boot executes no more and never will again (there is caution of course to be taken regarding e.g. instruction cache, but this is taken care of in the u-boot startup code). >> For instance, when I boot my edmini from NOR Flash, its flashed u-boot >> starts, then relocates itself to TEXT_BASE in RAM and runs from there. I > > ...it gets copied to RAM... > >> can then do e.g. a tftp of a u-boot (which has low level init disabled >> but relocation enabled) to some location in RAM other than TEXT_BASE, >> and 'go' there. The RAM-loaded u-boot will relocate to TEXT_BASE and run >> there, and will never return (it will destroy the former u-boot's stack >> and establish its own). > > This may, or may not work. In general, it will NOT work unless you > make sure that your new copy does not assume it is running on a a > pre-initialized system. Precisely. That is why I specified that in such a scenario, the "chained" u-boot needs to have CONFIG_SKIP_LOWLEVEL_INIT set (implicitely assuming that the chaining u-boot should have it unset, but that may or may not be necessary--for instance, a Flash-based orion5x u-boot should, and a Flash-based kirkwood should not, have CONFIG_SKIP_LOWLEVEL_INIT unset). > Best regards, > > Wolfgang Denk Amicalement, -- Albert.