[U-Boot] [PATCH 1/2] boards: ls2080: Fix default bootargs
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"
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" \
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
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
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
-----Original Message----- From: Scott Wood [mailto:oss@buserror.net] Sent: Tuesday, March 01, 2016 7:13 AM To: york sun york.sun@nxp.com; U-Boot Mailing List <u- boot@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
On Tue, 2016-03-01 at 03:55 +0000, Prabhakar Kushwaha wrote:
-----Original Message----- From: Scott Wood [mailto:oss@buserror.net] Sent: Tuesday, March 01, 2016 7:13 AM To: york sun york.sun@nxp.com; U-Boot Mailing List <u- boot@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
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#L43
York - have you tested this patch against older kernels like 3.18?
Regards, Bhupesh
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#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
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 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
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
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@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@1' configuration Trying 'kernel@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@1' configuration Trying 'ramdisk@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@1' configuration Trying 'fdt@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
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@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
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@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
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
participants (5)
-
Bhupesh Sharma -
Prabhakar Kushwaha -
Scott Wood -
York Sun -
york sun