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. > > It could be in overlap with ramdisk, or something else. How? It's an upper limit. It's not a directive to put the fdt at a specific address. U-Boot knows where the ramdisk is and should avoid overlapping them. > > Since we are using FIT image for this board, it is easy to set correct > > load address for kernel/ramdisk/dtb. How does FIT make that any easier? Picking correct addresses is the same challenge as before -- now it's just specified in a different location. > > 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. Updating a README that people won't read is better than having U-Boot do the right thing by default? > > 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 This is true regarding kernel_start/kernel_size, but not kernel_load which tells you what a sane place would be to load an image, rather than describing an image that is already there. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
