From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Rini <trini@ti.com>
Date: Fri, 7 Mar 2014 11:50:25 -0500
Subject: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC
 and EVM
In-Reply-To: <C279DA448D408F43B343F09155C1EE9B0C399ADC@DFLE08.ent.ti.com>
References: <yes> <1392918914-15564-1-git-send-email-m-karicheri2@ti.com>
	<1392918914-15564-9-git-send-email-m-karicheri2@ti.com>
	<20140225221143.GK16805@bill-the-cat>
	<C279DA448D408F43B343F09155C1EE9B0C399671@DFLE08.ent.ti.com>
	<5318CCA4.9040800@ti.com>
	<C279DA448D408F43B343F09155C1EE9B0C399ADC@DFLE08.ent.ti.com>
Message-ID: <5319F8D1.2020107@ti.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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/07/2014 11:41 AM, Andrianov, Vitaly wrote:
> Hi Tom,
> 
> [snip]
>>>>
>>>>> +	"fdt_high=0xffffffff\0"						\
>>>>
>>>> Please don't do this, set it to the top of kernel low mem.
>>>>
>>>
>>> The EVM may have up to 8GB of DDR and u-boot can see the first 2GB
>>> with physical address range 0x80000000-0xffffffff.
>>> If we don't use the "fdt_high" environment variable, u-boot relocates
>>> the dtb to the end of that memory, which is outside of the lowmem.
>>
> [snip]
> 
>>> But K2 lowmem VA starts from 0xc0000000 and has size ~760MB. That
>>> corresponds to the physical range 0x80000000-0xaf800000.
>>> That is why we have to use the "fdt_high=0xffffffff" environment
>> variable.
>>>
>>> Have I missed something I u-boot memory configuration?
>>> Is there a way to tell u-boot to relocate fdt to the end lowmem?
>>
>> Yes, set fdt_high to 0xaf800000 instead :)
>>
> 
> I think there is a bug in the lmb_alloc_base() and this approach doesn't
> work.
> 
> else if (lmbbase < max_addr) {
> 	base = min(lmbbase + lmbsize, max_addr);
> 	base = lmb_align_down(base - size, align);
> } else
> 
> For boards that have DDR at the end of 32 bit address space the
> (lmbbase + lmbsize) = 0 which is < max_addr.
> So, base becomes 0, and moved to the "end of DDR" - size on the next line.
> 
> I tried a quick fix in the __lmb_alloc_base() and got the fdt relocated correctly.
> As I'm not sure that is only one buggy place in the lmb.c I don't want to commit
> the quick fix. Let's leave the "fdt_high=0xffffffff" in the Keystone2 for awhile      
> and change it later when we fix the bug.

If you're committing to look at this later then yes.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTGfjRAAoJENk4IS6UOR1WxBYQAKjH1cWlziYl74cR7FhPINWd
WEn7AtPKYLXs47D8dMYvshjrg9kBgjpy3VqDKf23t3yndBUugmznV5MdmSMlx2IQ
TuNg0ICqnXt/2NxclKwxtmznohIwx2t8gJ355UP9XzGrr17lf1+WglOvBolI0R0m
VjP3eBivHDlfwLHF3MWdLjmCjGn1sVDCng2JuZZIjfoqxGto2UsDllh1CQx2O9js
tOeAY+i5cHCag8b5+6jtujZ6GICwQ0vg2qB5XFXeOYAZWY+XTvlGgQCZ27RaspRF
pBHhlOH7iftUnKOTGt/HauEnB62TSfSPjan9ww48VA861fAkrpeANjtPz9uZQKwh
Hd/Ib0XOHrfKkReerF/C+R2vJjlYBfKeEFCvF+SuZApgIMX6am4gdHWiGgZq45/Q
YemR9Exj+KJ4MYZky/a8y2z8cowck+RsnpZozojFiPlNmuvXS+qXZste42nIYTRX
puZx4+xogoaLL4HHjOuKR6QlnCSQDvyxPvLPMNw5HbrZ3Eof0Uwxu2omnJpUvx2+
v/xl6gsqcxOZ07Mz7g3sGwsG5HWZPevFK8CZd8xDFQwj/DZo4pAJO7XFj4MZTgaM
Tg3bpsvQFugK9yU/F96Uoie0EYCpCsgGPu5moOSPYB4sl8OlkHj0Mw1oq3rpWF77
2bFm9XxAOL/awEM/X2l/
=n9Wd
-----END PGP SIGNATURE-----