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.
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