[U-Boot] [PATCH 1/2] boards: ls2080: Fix default bootargs

[U-Boot] [PATCH 1/2] boards: ls2080: Fix default bootargs

[York Sun]

A white space is missing in multiple-line string for bootargs.

Signed-off-by: York Sun <york.sun@nxp.com>
---

 include/configs/ls2080a_common.h |    2 +-
 include/configs/ls2080ardb.h     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 8bff81b..5e555aa 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -269,7 +269,7 @@ unsigned long long get_qixis_addr(void);
 	" 0x580800000 \0"
 
 #define CONFIG_BOOTARGS		"console=ttyS0,115200 root=/dev/ram0 " \
-				"earlycon=uart8250,mmio,0x21c0500" \
+				"earlycon=uart8250,mmio,0x21c0500 " \
 				"ramdisk_size=0x2000000 default_hugepagesz=2m" \
 				" hugepagesz=2m hugepages=256"
 #define CONFIG_BOOTCOMMAND	"fsl_mc apply dpl 0x580700000 &&" \
diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index b2c0181..3ca8d08 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -333,7 +333,7 @@ unsigned long get_board_sys_clk(void);
 
 #undef CONFIG_BOOTARGS
 #define CONFIG_BOOTARGS		"console=ttyS1,115200 root=/dev/ram0 " \
-				"earlycon=uart8250,mmio,0x21c0600" \
+				"earlycon=uart8250,mmio,0x21c0600 " \
 				"ramdisk_size=0x2000000 default_hugepagesz=2m" \
 				" hugepagesz=2m hugepages=256"
 
-- 
1.7.9.5

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

[York Sun]

If set, fdt_high restricts the address used by copying device tree.
It doesn't help much to set a default address without knowing how
much memory is available, or how memory is used. Setting fdt_high
to a specical value (0xffffffffffffffff) disables this copying.

Signed-off-by: York Sun <york.sun@nxp.com>

---

 include/configs/ls2080a_common.h |    2 +-
 include/configs/ls2080aqds.h     |    2 +-
 include/configs/ls2080ardb.h     |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 5e555aa..f04a1a4 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -259,7 +259,7 @@ unsigned long long get_qixis_addr(void);
 	"kernel_addr=0x100000\0"		\
 	"ramdisk_addr=0x800000\0"		\
 	"ramdisk_size=0x2000000\0"		\
-	"fdt_high=0xa0000000\0"			\
+	"fdt_high=0xffffffffffffffff\0"		\
 	"initrd_high=0xffffffffffffffff\0"	\
 	"kernel_start=0x581200000\0"		\
 	"kernel_load=0xa0000000\0"		\
diff --git a/include/configs/ls2080aqds.h b/include/configs/ls2080aqds.h
index dab3820..77af295 100644
--- a/include/configs/ls2080aqds.h
+++ b/include/configs/ls2080aqds.h
@@ -342,7 +342,7 @@ unsigned long get_board_ddr_clk(void);
 	"kernel_addr=0x100000\0"		\
 	"ramdisk_addr=0x800000\0"		\
 	"ramdisk_size=0x2000000\0"		\
-	"fdt_high=0xa0000000\0"			\
+	"fdt_high=0xffffffffffffffff\0"		\
 	"initrd_high=0xffffffffffffffff\0"	\
 	"kernel_start=0x581100000\0"		\
 	"kernel_load=0xa0000000\0"		\
diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 3ca8d08..87b6b04 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -323,7 +323,7 @@ unsigned long get_board_sys_clk(void);
 	"kernel_addr=0x100000\0"		\
 	"ramdisk_addr=0x800000\0"		\
 	"ramdisk_size=0x2000000\0"		\
-	"fdt_high=0xa0000000\0"			\
+	"fdt_high=0xffffffffffffffff\0"		\
 	"initrd_high=0xffffffffffffffff\0"	\
 	"kernel_start=0x581100000\0"		\
 	"kernel_load=0xa0000000\0"		\
-- 
1.7.9.5

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

[Scott Wood]

On Mon, 2016-02-29 at 15:58 -0800, York Sun wrote:
> If set, fdt_high restricts the address used by copying device tree.
> It doesn't help much to set a default address without knowing how
> much memory is available, or how memory is used. Setting fdt_high
> to a specical value (0xffffffffffffffff) disables this copying.
> 
> Signed-off-by: York Sun <york.sun@nxp.com>

Is there a limit that Linux needs the fdt to be under?

I'd hope fdt_high wouldn't cause the device tree to be relocated beyond the
end of memory, or in reserved memory...

-Scott

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

[york sun]

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.

York


________________________________________
From: Scott Wood <oss@buserror.net>
Sent: Monday, February 29, 2016 4:00 PM
To: york sun; U-Boot Mailing List
Cc: Prabhakar Kushwaha
Subject: Re: [U-Boot] [PATCH 2/2] boards: ls2080: Disable fdt copying by default

On Mon, 2016-02-29 at 15:58 -0800, York Sun wrote:
> If set, fdt_high restricts the address used by copying device tree.
> It doesn't help much to set a default address without knowing how
> much memory is available, or how memory is used. Setting fdt_high
> to a specical value (0xffffffffffffffff) disables this copying.
>
> Signed-off-by: York Sun <york.sun@nxp.com>

Is there a limit that Linux needs the fdt to be under?

I'd hope fdt_high wouldn't cause the device tree to be relocated beyond the
end of memory, or in reserved memory...

-Scott

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

[Scott Wood]

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.

-Scott

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

[Prabhakar Kushwaha]

> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Tuesday, March 01, 2016 7:13 AM
> To: york sun <york.sun@nxp.com>; U-Boot Mailing List <u-
> boot at lists.denx.de>
> Cc: Prabhakar Kushwaha <prabhakar@freescale.com>
> Subject: Re: [U-Boot] [PATCH 2/2] boards: ls2080: Disable fdt copying by
> default
> 
> 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.
> 

Just for understanding purpose.  
u-boot in case of arm32 can only access memory in 32 bit range. 
 Will there be possibility of u-boot copying dtb in any memory not accessible to core. 

--prabhakar

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

[Scott Wood]

On Tue, 2016-03-01 at 03:55 +0000, Prabhakar Kushwaha wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss at buserror.net]
> > Sent: Tuesday, March 01, 2016 7:13 AM
> > To: york sun <york.sun@nxp.com>; U-Boot Mailing List <u-
> > boot at lists.denx.de>
> > Cc: Prabhakar Kushwaha <prabhakar@freescale.com>
> > Subject: Re: [U-Boot] [PATCH 2/2] boards: ls2080: Disable fdt copying by
> > default
> > 
> > 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.
> > 
> 
> Just for understanding purpose.  
> u-boot in case of arm32 can only access memory in 32 bit range. 
>  Will there be possibility of u-boot copying dtb in any memory not
> accessible to core. 

No, but that is not the only limitation that needs to be honored regarding
device tree and initrd placement.

-Scott

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

[Bhupesh Sharma]

> 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#L43

York - have you tested this patch against older kernels like 3.18?

Regards,
Bhupesh

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

[york sun]

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

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.

York

[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 

[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

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

[york sun]

On 03/01/2016 08:01 AM, Scott Wood wrote:
> 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.

Even kernel requires device tree to be within 512MB from kernel image, it
doesn't warrant a magic number, because the kernel image location is not fixed.

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

Yes, it is an upper limit. U-Boot will try to put device tree right under that
limit, if possible, regardless where the kernel image is.

As for the overlapping, you could load FIT image into memory, near the location
of fdt_high. U-Boot knows the location _after_ uncompressing/copying.

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

Picking correct address is the same challenges, but at least not twice. And the
kernel address is also in FIT image, together with device tree address. It may
be less used by us, but the feature is there.

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

I can't agree having fdt_high at 0xa0000000 is the right thing. Let me explain.
With two patches (v6) I sent earlier regarding FIT image address handling, we
are able to use 64-bit addresses in FIT image. It opens the door to use high
region memory on ls2080 series boards. For example, if I load the FIT image into
location 0x80_c000_0000 (it can be any reachable address, including in IFC),
when U-Boot boots it with bootm, the image is decoded as

=> bootm
## Loading kernel from FIT Image at 80c0000000 ...
   Using 'config at 1' configuration
   Trying 'kernel at 1' kernel subimage
     Description:  ARM64 Linux kernel
     Created:      2016-02-29  21:08:40 UTC
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x80c00000e0
     Data Size:    4480978 Bytes = 4.3 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x8080080000
     Entry Point:  0x8080080000
   Verifying Hash Integrity ... OK
## Loading ramdisk from FIT Image at 80c0000000 ...
   Using 'config at 1' configuration
   Trying 'ramdisk at 1' ramdisk subimage
     Description:  LS2 Ramdisk
     Created:      2016-02-29  21:08:40 UTC
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x80c04495d8
     Data Size:    28700629 Bytes = 27.4 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x80a0000000
     Entry Point:  unavailable
   Verifying Hash Integrity ... OK
   Loading ramdisk from 0x80c04495d8 to 0x80a0000000
## Loading fdt from FIT Image at 80c0000000 ...
   Using 'config at 1' configuration
   Trying 'fdt at 1' fdt subimage
     Description:  Flattened Device Tree blob
     Created:      2016-02-29  21:08:40 UTC
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x80c0446170
     Data Size:    13279 Bytes = 13 KiB
     Architecture: AArch64
   Verifying Hash Integrity ... OK
   Loading fdt from 0x80c0446170 to 0x8090000000
   Booting using the fdt blob at 0x8090000000
   Uncompressing Kernel Image ... OK
   reserving fdt memory region: addr=80000000 size=10000
   Using Device Tree in place at 0000008090000000, end 00000080900063de

Please note the addresses 0x80_8008_0000, 0x80_a000_0000, 0x80_9000_0000 are put
into the its file by me. I can specify any addresses as far as they meet kernel
requirement. In this case, the kernel load/entry address dictates where the
device tree image should be. The best chance to make it right is to specify
device tree address in the same its file, and use it in place. "fdt_high"
totally defeats this purpose.

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

The kernel_load is used by copying image from NOR flash into memory. It is not
totally insane, but not necessary. As I explained in above FIT image example, if
the ramdisk load address is set correctly, there is no need to copy the image at
the first place. U-Boot will copy individual images from FIT to their
destinations. Besides, you can ignore the low region and use high region memory
for kernel if you want (after the FIT image patches are merged). We will discuss
if the low region memory should be kept when we come to this issue later.

York

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

[Scott Wood]

On Tue, 2016-03-01 at 16:48 +0000, york sun wrote:
> On 03/01/2016 08:01 AM, Scott Wood wrote:
> > 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.
> 
> Even kernel requires device tree to be within 512MB from kernel image, it
> doesn't warrant a magic number, because the kernel image location is not
> fixed.

It's not "512MB from kernel image".  It's "within the 512 MB region starting
at text_offset bytes below the kernel Image" which, when combined with "The
Image must be placed text_offset bytes from a 2MB aligned base address near
the start of usable system RAM and called there" means that if RAM starts at
0x80000000, the actual limit is "near" (and no lower than) 0xa0000000, which
makes 0xa0000000 a good default.

> > 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.
> 
> Yes, it is an upper limit. U-Boot will try to put device tree right under
> that
> limit, if possible, regardless where the kernel image is.

If it's ignoring the kernel image when selecting a location, that's a bug that
should be fixed.

> As for the overlapping, you could load FIT image into memory, near the
> location
> of fdt_high. U-Boot knows the location _after_ uncompressing/copying.

Knows which location after uncompressing/copying what?

In any case, having a good default location for the FIT is why kernel_load
should stay.

> > > > 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.
> 
> Picking correct address is the same challenges, but at least not twice.

Twice?

>  And the kernel address is also in FIT image, together with device tree 
> address. It may be less used by us, but the feature is there.

Not sure what you mean here.

> Please note the addresses 0x80_8008_0000, 0x80_a000_0000, 0x80_9000_0000 are
> put
> into the its file by me. I can specify any addresses as far as they meet
> kernel
> requirement. 

This does not meet the kernel requirement unless you consider 0x80_8000_0000
to be "near the start of usable system RAM", with any RAM below that unused by
Linux.

> In this case, the kernel load/entry address dictates where the
> device tree image should be. The best chance to make it right is to specify
> device tree address in the same its file, and use it in place. "fdt_high"
> totally defeats this purpose.

I don't think it's unreasonable for U-Boot to know what the start of system
RAM is supposed to be, and have the environment variables set accordingly. 
 You're trying to leave the start of system RAM up to the user, which is an
unusual situation and shouldn't be used to judge the merits of fdt_high in
general.  I can maybe see disabling relocation for this specific target due to
its problematic memory map, if we decide we need to support both, but that's a
different justification than "this is an arbitrary magic number".  I hope our
future chips have a conforming memory map that avoids the problem.

> > 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.
> 
> The kernel_load is used by copying image from NOR flash into memory.

It's a destination for loading an image, regardless of where it's loaded from.

>  It is not
> totally insane, but not necessary. As I explained in above FIT image
> example, if
> the ramdisk load address is set correctly, there is no need to copy the
> image at
> the first place.

What does that have to do with it?

If I'm putting together a FIT image, how do I choose the addresses if I have
no idea where the user is going to load the FIT image itself?

Our ARM targets have too few helpful environment variables, not too many.  I
really miss what our PPC targets provided with nfsboot, etc. (there was room
for improvement there, but getting rid of it entirely just makes more work for
the user).

-Scott

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

[york sun]

On 03/01/2016 09:35 AM, Scott Wood wrote:
> On Tue, 2016-03-01 at 16:48 +0000, york sun wrote:
>> On 03/01/2016 08:01 AM, Scott Wood wrote:
>>> 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.
>>
>> Even kernel requires device tree to be within 512MB from kernel image, it
>> doesn't warrant a magic number, because the kernel image location is not
>> fixed.
> 
> It's not "512MB from kernel image".  It's "within the 512 MB region starting
> at text_offset bytes below the kernel Image" which, when combined with "The
> Image must be placed text_offset bytes from a 2MB aligned base address near
> the start of usable system RAM and called there" means that if RAM starts at
> 0x80000000, the actual limit is "near" (and no lower than) 0xa0000000, which
> makes 0xa0000000 a good default.

I get your point. Basically you expect U-Boot has default setting for a default
use, and you expect U-Boot knows the exact memory location and size. It is
reasonable.

I was debugging high region memory. I have to abandon low region all together so
Linux can boot from high region memory.

I can drop this patch for now and revisit it when we decide to move to high
region memory.

York

[U-Boot] [PATCH 1/2] boards: ls2080: Fix default bootargs

[york sun]

On 02/29/2016 03:58 PM, York Sun wrote:
> A white space is missing in multiple-line string for bootargs.
> 
> Signed-off-by: York Sun <york.sun@nxp.com>
> ---
> 
>  include/configs/ls2080a_common.h |    2 +-
>  include/configs/ls2080ardb.h     |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

Applied to u-boot-fsl-qoriq, awaiting upstream.

York