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

[Scott Wood]

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