[U-Boot] [PATCH 2/2] boards: ls2080: Disable fdt copying by default

[Bhupesh Sharma]

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