From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tuomas Tynkkynen <tuomas@tuxera.com>
Date: Thu, 24 May 2018 17:57:53 +0300
Subject: [U-Boot] [PATCH 1/2] rpi: Fix fdt_high & initrd_high for 64-bit
 builds
In-Reply-To: <3c4004b2-0d79-a621-7885-641ac788958b@suse.de>
References: <0b70df8a8962cbf835c6d79d89fa49f820334f35.camel@tuxera.com>
 <20180420100349.27194-1-tuomas@tuxera.com>
 <20180420100349.27194-2-tuomas@tuxera.com>
 <3c4004b2-0d79-a621-7885-641ac788958b@suse.de>
Message-ID: <20180524175753.5d6fac8b@duuni>
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

Hi Alex,

On Thu, 24 May 2018 09:51:57 +0200
Alexander Graf <agraf@suse.de> wrote:

> On 20.04.18 12:03, Tuomas Tynkkynen wrote:
> > The magic value that disables relocation is dependent on the CPU word
> > size, so the current 'ffffffff' is doing the wrong thing on aarch64.
> > 
> > Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>  
> 
> The BCM283x series of SOCs is limited to 32bit address space, so I don't
> quite see why the current (int)-1 is wrong?
> 
> 

The comparison for the magic "don't relocate value" is done by parsing
the variable as ulong and then comparing to ~0. So on 64-bit, ffffffff
gets interpreted as literal 0xffffffff limit for the relocation (which
I think in practice is the same as not specifying initrd_high at all
since the end of DRAM is lower than that) instead.