> 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 could be in overlap with ramdisk, or something else. > Since we are using FIT image for this board, it is easy to set correct > load address for kernel/ramdisk/dtb. Device tree can be used in place. > However, it is user's choice on how to use the memory. We can write a > README as a guideline but it makes no sense to default to 0xa0000000.
Thanks York. I agree that 0xa0000000 was an address we found suitable during our earlier Linux boot attempts and we kept using it. Updating the README to add a suitable guideline seems like a proper approach to me. > > As I am working on enabling high region memory, I found it even more > inappropriate to set fdt_high to any arbitrary value. Actually, variables > including kernel_start, kernel_load, kernel_size should be removed. They > don't serve users well if the board doesn't have preloaded image to > specific address, which is almost certain on most boards. Those variables > are only useful for shipping boards from manufacture with preloaded > images. > +1 Regards, Bhupesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
