Skip to contentSkip to conversation

boards: ls2080: Fix default bootargs

PATCH New York Sun 4 participants 15 messages Feb 29, 2016 – Mar 22, 2016

lore
Share & tools
lore

York Sun

author
#0 lore raw

PATCH 1/2 boards: ls2080: Fix default bootargs

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

Signed-off-by York Sun <[email protected]>

---

 include/configs/ls2080a_common.h |    2 +-
 include/configs/ls2080ardb.h     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
include/configs/ls2080a_common.h +1 -1
index 8bff81b..5e555aa 100644
@@ -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 &&" \
include/configs/ls2080ardb.h +1 -1
index b2c0181..3ca8d08 100644
@@ -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"
Signature · 1 line
1.7.9.5
author
#1 lore raw

PATCH 1/2 boards: ls2080: Fix default bootargs

Quoted 9 lines · York Sun

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

Signed-off-by York Sun <[email protected]>

---

 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

author
#2 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

In reply to 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 <[email protected]>

---

 include/configs/ls2080a_common.h |    2 +-
 include/configs/ls2080aqds.h     |    2 +-
 include/configs/ls2080ardb.h     |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
include/configs/ls2080a_common.h +1 -1
index 5e555aa..f04a1a4 100644
@@ -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"		\
include/configs/ls2080aqds.h +1 -1
index dab3820..77af295 100644
@@ -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"		\
include/configs/ls2080ardb.h +1 -1
index 3ca8d08..87b6b04 100644
@@ -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"		\
Signature · 1 line
1.7.9.5
#3 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 6 lines · 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 <[email protected]>

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

author
#4 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

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 <[email protected]>
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

Quoted 6 lines · 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 <[email protected]>

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

#5 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 8 lines · 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.

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

#6 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 17 lines

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

Quoted 6 lines · 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.

Quoted 6 lines
Quoted 2 lines

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

#7 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 24 lines · Prabhakar Kushwaha
Quoted 16 lines

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

Quoted 6 lines · 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.

Quoted 7 lines
Quoted 2 lines

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.

Quoted 4 lines

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

#8 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

In reply to Scott Wood
Quoted 11 lines

From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott Wood
Sent: Tuesday, March 01, 2016 7:13 AM

Quoted 6 lines · 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.

Quoted 6 lines
Quoted 2 lines

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

author
#9 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 18 lines · Bhupesh Sharma
Quoted 11 lines

From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott Wood
Sent: Tuesday, March 01, 2016 7:13 AM

Quoted 6 lines · 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.

Quoted 6 lines
Quoted 2 lines

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.

Quoted 7 lines

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

#10 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 37 lines

From: york sun
Sent: Tuesday, March 01, 2016 11:30 AM

Quoted 14 lines · Bhupesh Sharma
Quoted 14 lines

From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott Wood
Sent: Tuesday, March 01, 2016 7:13 AM

Quoted 8 lines · 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.

Quoted 7 lines
Quoted 3 lines

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:

Quoted 5 lines

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.

Quoted 7 lines

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.

Quoted 9 lines

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

#11 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 32 lines · Bhupesh Sharma
Quoted 32 lines

From: york sun
Sent: Tuesday, March 01, 2016 11:30 AM

Quoted 14 lines · Bhupesh Sharma
Quoted 14 lines

From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott Wood
Sent: Tuesday, March 01, 2016 7:13 AM

Quoted 8 lines · 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.

Quoted 7 lines
Quoted 3 lines

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:

Quoted 5 lines

http://lxr.free-electrons.com/source/Documentation/arm64/booting.txt#L
43

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

Quoted 8 lines
Quoted 8 lines

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.

Quoted 1 line
Quoted 1 line

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.

Quoted 2 lines
Quoted 2 lines

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.

Quoted 10 lines
Quoted 3 lines

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?

Quoted 10 lines
Quoted 8 lines

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

author
#12 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 35 lines · Scott Wood
Quoted 34 lines · Bhupesh Sharma
Quoted 34 lines

From: york sun
Sent: Tuesday, March 01, 2016 11:30 AM

Quoted 14 lines · Bhupesh Sharma
Quoted 14 lines

From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott Wood
Sent: Tuesday, March 01, 2016 7:13 AM

Quoted 8 lines · 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.

Quoted 7 lines
Quoted 3 lines

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:

Quoted 5 lines

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,

Quoted 8 lines
Quoted 6 lines
Quoted 6 lines

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.

Quoted 5 lines
Quoted 2 lines
Quoted 2 lines

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.

Quoted 6 lines
Quoted 3 lines
Quoted 3 lines

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.

Quoted 9 lines
Quoted 9 lines
Quoted 4 lines

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.

Quoted 5 lines
Quoted 2 lines

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.

Quoted 10 lines
Quoted 10 lines
Quoted 9 lines

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.

Quoted 5 lines
Quoted 1 line

+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

#13 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 53 lines · york sun
Quoted 52 lines · Scott Wood
Quoted 50 lines · Bhupesh Sharma
Quoted 50 lines

From: york sun
Sent: Tuesday, March 01, 2016 11:30 AM

Quoted 22 lines · Bhupesh Sharma
Quoted 13 lines

From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott
Wood
Sent: Tuesday, March 01, 2016 7:13 AM

Quoted 7 lines · 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.

Quoted 8 lines
Quoted 3 lines

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.

Quoted 5 lines

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:

Quoted 6 lines

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.

Quoted 5 lines
Quoted 1 line

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.

Quoted 10 lines
Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines

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?

Quoted 2 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 6 lines

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

author
#14 lore raw

PATCH 2/2 boards: ls2080: Disable fdt copying by default

Quoted 60 lines · Scott Wood
Quoted 53 lines · york sun
Quoted 52 lines · Scott Wood
Quoted 50 lines · Bhupesh Sharma
Quoted 50 lines

From: york sun
Sent: Tuesday, March 01, 2016 11:30 AM

Quoted 22 lines · Bhupesh Sharma
Quoted 13 lines

From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Scott
Wood
Sent: Tuesday, March 01, 2016 7:13 AM

Quoted 7 lines · 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.

Quoted 8 lines
Quoted 3 lines

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.

Quoted 5 lines

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:

Quoted 6 lines

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.

Quoted 5 lines
Quoted 1 line

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.

Quoted 6 lines

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