From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@nvidia.com>
Date: Mon, 07 Nov 2011 14:27:34 -0700
Subject: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're
 loadable at any address
In-Reply-To: <20111107202633.92FE4189301B@gemini.denx.de>
References: <1320164902-24190-1-git-send-email-swarren@nvidia.com>
	<1320164902-24190-3-git-send-email-swarren@nvidia.com>
	<20111105222012.DB7541893014@gemini.denx.de>
	<74CDBE0F657A3D45AFBB94109FB122FF173F9A5035@HQMAIL01.nvidia.com>
	<20111107202633.92FE4189301B@gemini.denx.de>
Message-ID: <4EB84D46.2070800@nvidia.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

(Sigh, resending again to avoid rejected MIME encoding)

On 11/07/2011 01:26 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <74CDBE0F657A3D45AFBB94109FB122FF173F9A5035@HQMAIL01.nvidia.com> you wrote:
>>
>>> Your own IH_TYPE_*_REL patches are queued and will be merged soon.
>>
>> Oh. I kept pushing and pushing on these and kept meeting resistance. I
> 
> There was no resistance ever.  There were just the normal review
> comments.
> 
>> had absolutely no idea at all that there was agreement over those patches;
>> the reviews just stopped happening after you refused to look at them
> 
> If there are no further complaints that usually menas the stuff is
> sitting in the queue waiting to be processed.  Sorry, but my bandwidth
> _is_ limited.
> 
>> Anyway, I have withdrawn my support for those patches; please don't apply
>> them. In my opinion, this new solution is far superior because:
> 
> Argh... So we are back at square one.
> 
> The problem with this new approach is that Linux kernel images are NOT
> freely relocatable.  They do have a fix entry point, even if this is
> not an absolute address, but a relative one.

That's simply not true ARM Linux zImages /are/ relocatable - as far as
I'm aware, they can run from anywhere in SDRAM. I've certainly tested
loading ARM zImages at a few random locations and it works fine, and
I've been told by senior Linux kernel people that this is intentional.
(Well, there is a restriction that the image must be somewhere within
the first 128M of RAM for PATCH_PHYS_VIRT(?) to operate correctly, but
I'd still count that as been almost arbitrarily relocatable)

> The natural way to
> handle this is exactly that:  add support for images with relative
> )offset based) load and entry point addresses.
> 
> Your new approahc is indeed simpler - actually it is too simplistic,
> as you cannot record load address / entry point information any more.
> It may work when using the kernel wrapper - but what if you don't want
> to do that?

Note that the only thing that made my IH_TYPE_*_REL work was this exact
same runs-at-any-location feature of ARM zImages; there was never
anything in the kernel that allowed it to solely run at "some specific
offset from the base of SDRAM"; that was just the first way I thought of
modifying U-Boot to enable this current feature.

-- 
nvpublic