On 03/01/2016 09:35 AM, Scott Wood wrote:
On Tue, 2016-03-01 at 16:48 +0000, york sun wrote:
On 03/01/2016 08:01 AM, Scott Wood wrote:
On Tue, 2016-03-01 at 06:03 +0000, Bhupesh Sharma wrote:
From: york sun Sent: Tuesday, March 01, 2016 11:30 AM
On 02/29/2016 09:20 PM, Bhupesh Sharma wrote:
> From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of > Scott > Wood > Sent: Tuesday, March 01, 2016 7:13 AM > > On Tue, 2016-03-01 at 00:08 +0000, york sun wrote: >> Sorry for top posting. I am on outlook web access. >> >> There may be some limitation on fdt relocation. Without setting >> fdt_high, u -boot relocates the device tree toward the end of >> useable memory. I haven't got a chance to debug why it doesn't >> work. >> >> This patch is to disable the relocation by default. A magic >> number >> 0xa0000000 doesn't make much sense here. > > I agree, if the number is arbitrary. But if Linux has a > limitation, > as it does on arm32, then it should be expressed here. >
There are explicit requirements for placement of DTB for aarch64 linux. Linux versions prior to v4.2 also require that the DTB be placed within the 512 MB region starting at text_offset bytes below the kernel
Image:
http://lxr.free-electrons.com/source/Documentation/arm64/booting.txt #L 43
York - have you tested this patch against older kernels like 3.18?
Bhupesh,
Thanks for the link. It may explained why Linux doesn't boot if fdt_high is not set properly on kernel prior 4.2.
I proposed to disable fdt copying by default. It doesn't mean we cannot will won't use fdt_high. My point is, setting an arbitrary value doesn't make much sense.
It's not arbitrary if it comes from a Linux requirement.
Even kernel requires device tree to be within 512MB from kernel image, it doesn't warrant a magic number, because the kernel image location is not fixed.
It's not "512MB from kernel image". It's "within the 512 MB region starting at text_offset bytes below the kernel Image" which, when combined with "The Image must be placed text_offset bytes from a 2MB aligned base address near the start of usable system RAM and called there" means that if RAM starts at 0x80000000, the actual limit is "near" (and no lower than) 0xa0000000, which makes 0xa0000000 a good default.
I get your point. Basically you expect U-Boot has default setting for a default use, and you expect U-Boot knows the exact memory location and size. It is reasonable.
I was debugging high region memory. I have to abandon low region all together so Linux can boot from high region memory.
I can drop this patch for now and revisit it when we decide to move to high region memory.
York