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-boun...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
