common/image.c: align usage of fdt_high with initrd_high

The commit message of a28afca (Add uboot "fdt_high" enviroment variable) states that fdt_high behaves similarly to the existing initrd_high. But fdt_high actually has an outstanding difference from initrd_high. The former specifies the start address, while the later specifies the end address.

As fdt_high and initrd_high will likely be used together, it'd be nice to have them behave same. The patch changes the behavior of fdt_high to have it aligned with initrd_high.

The document of fdt_high in README is updated with an example to demonstrate the usage of this environment variable.

Signed-off-by Shawn Guo <[email protected]>

---
Changes since v3:
* Fix the bug in case fdt_high=0xffffffff introduced by v1/v2.

 README         |    8 ++++++++
 common/image.c |   12 +++++-------
 2 files changed, 13 insertions(+), 7 deletions(-)

README +8 -0

index ff72e47..1c3713c 100644
@@ -3619,6 +3619,14 @@ List of environment variables (most likely not complete):
 
   fdt_high	- if set this restricts the maximum address that the
 		  flattened device tree will be copied into upon boot.
+		  For example, if you have a system with 1 GB memory
+		  at physical address 0x10000000, while Linux kernel
+		  only recognizes the first 704 MB as low memory, you
+		  may need to set fdt_high as 0x3C000000 to have the
+		  device tree blob be copied to the maximum address
+		  of the 704 MB low memory, so that Linux kernel can
+		  access it during the boot procedure.
+
 		  If this is set to the special value 0xFFFFFFFF then
 		  the fdt will not be copied at all on boot.  For this
 		  to work it must reside in writable memory, have

common/image.c +5 -7

index 77ca6e4..8c4137c 100644
@@ -1288,16 +1288,14 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree, ulong *of_size)
 
 		if (((ulong) desired_addr) == ~0UL) {
 			/* All ones means use fdt in place */
-			desired_addr = fdt_blob;
+			of_start = fdt_blob;
+			lmb_reserve(lmb, (ulong)of_start, of_len);
 			disable_relocation = 1;
-		}
-		if (desired_addr) {
+		} else if (desired_addr) {
 			of_start =
 			    (void *)(ulong) lmb_alloc_base(lmb, of_len, 0x1000,
-							   ((ulong)
-							    desired_addr)
-							   + of_len);
-			if (desired_addr && of_start != desired_addr) {
+							   (ulong)desired_addr);
+			if (of_start == 0) {
 				puts("Failed using fdt_high value for Device Tree");
 				goto error;
 			}

Signature · 1 line

1.7.4.1

The commit message of a28afca (Add uboot "fdt_high" enviroment variable) states that fdt_high behaves similarly to the existing initrd_high. But fdt_high actually has an outstanding difference from initrd_high. The former specifies the start address, while the later specifies the end address.

As fdt_high and initrd_high will likely be used together, it'd be nice to have them behave same. The patch changes the behavior of fdt_high to have it aligned with initrd_high.

The document of fdt_high in README is updated with an example to demonstrate the usage of this environment variable.

Signed-off-by Shawn Guo <[email protected]>

---

Quoted 10 lines · Shawn Guo

The commit message of a28afca (Add uboot "fdt_high" enviroment variable) states that fdt_high behaves similarly to the existing initrd_high. But fdt_high actually has an outstanding difference from initrd_high. The former specifies the start address, while the later specifies the end address.

As fdt_high and initrd_high will likely be used together, it'd be nice to have them behave same. ?The patch changes the behavior of fdt_high to have it aligned with initrd_high.

Quoted 5 lines

The document of fdt_high in README is updated with an example to demonstrate the usage of this environment variable.

Signed-off-by Shawn Guo <[email protected]>

---

Hi,

this patch seems to be required to test device tree on i.MX platform.

Simon, I have seen several patches from you regarding fdt - maybe you can add your ACK or NACK to this patch.

Stefano

--
=====================================================================
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 ?Email: office at denx.de
=====================================================================

The commit message of a28afca (Add uboot "fdt_high" enviroment variable) states that fdt_high behaves similarly to the existing initrd_high. But fdt_high actually has an outstanding difference from initrd_high. The former specifies the start address, while the later specifies the end address.

As fdt_high and initrd_high will likely be used together, it'd be nice to have them behave same. ?The patch changes the behavior of fdt_high to have it aligned with initrd_high.

The document of fdt_high in README is updated with an example to demonstrate the usage of this environment variable.

Signed-off-by Shawn Guo <[email protected]>

---
Changes since v3:
?* Fix the bug in case fdt_high=0xffffffff introduced by v1/v2.

?README ? ? ? ? | ? ?8 ++++++++ ?common/image.c | ? 12 +++++-------
?2 files changed, 13 insertions(+), 7 deletions(-)

README +0 -0

index ff72e47..1c3713c 100644
@@ -3619,6 +3619,14 @@ List of environment variables (most likely not complete):
 

? fdt_high ? ? - if set this restricts the maximum address that the

? ? ? ? ? ? ? ? ?flattened device tree will be copied into upon boot.
+ ? ? ? ? ? ? ? ? For example, if you have a system with 1 GB memory
+ ? ? ? ? ? ? ? ? at physical address 0x10000000, while Linux kernel
+ ? ? ? ? ? ? ? ? only recognizes the first 704 MB as low memory, you
+ ? ? ? ? ? ? ? ? may need to set fdt_high as 0x3C000000 to have the
+ ? ? ? ? ? ? ? ? device tree blob be copied to the maximum address
+ ? ? ? ? ? ? ? ? of the 704 MB low memory, so that Linux kernel can
+ ? ? ? ? ? ? ? ? access it during the boot procedure.

+
? ? ? ? ? ? ? ? ?If this is set to the special value 0xFFFFFFFF then ? ? ? ? ? ? ? ? ?the fdt will not be copied at all on boot. ?For this ? ? ? ? ? ? ? ? ?to work it must reside in writable memory, have

common/image.c +0 -0

index 77ca6e4..8c4137c 100644
@@ -1288,16 +1288,14 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree, ulong *of_size)
 
 ? ? ? ? ? ? ? ?if (((ulong) desired_addr) == ~0UL) {

? ? ? ? ? ? ? ? ? ? ? ?/* All ones means use fdt in place */
- ? ? ? ? ? ? ? ? ? ? ? desired_addr = fdt_blob;
+ ? ? ? ? ? ? ? ? ? ? ? of_start = fdt_blob;
+ ? ? ? ? ? ? ? ? ? ? ? lmb_reserve(lmb, (ulong)of_start, of_len);
? ? ? ? ? ? ? ? ? ? ? ?disable_relocation = 1;
- ? ? ? ? ? ? ? }
- ? ? ? ? ? ? ? if (desired_addr) {
+ ? ? ? ? ? ? ? } else if (desired_addr) {
? ? ? ? ? ? ? ? ? ? ? ?of_start =
? ? ? ? ? ? ? ? ? ? ? ? ? ?(void *)(ulong) lmb_alloc_base(lmb, of_len, 0x1000,
- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?((ulong)
- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? desired_addr)
- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+ of_len);
- ? ? ? ? ? ? ? ? ? ? ? if (desired_addr && of_start != desired_addr) {
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ulong)desired_addr);
+ ? ? ? ? ? ? ? ? ? ? ? if (of_start == 0) {
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?puts("Failed using fdt_high value for Device Tree"); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?goto error;
? ? ? ? ? ? ? ? ? ? ? ?}
--
1.7.4.1

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 9 lines

? fdt_high ? ? - if set this restricts the maximum address that the ? ? ? ? ? ? ? ? ?flattened device tree will be copied into upon boot.
+ ? ? ? ? ? ? ? ? For example, if you have a system with 1 GB memory
+ ? ? ? ? ? ? ? ? at physical address 0x10000000, while Linux kernel
+ ? ? ? ? ? ? ? ? only recognizes the first 704 MB as low memory, you
+ ? ? ? ? ? ? ? ? may need to set fdt_high as 0x3C000000 to have the
+ ? ? ? ? ? ? ? ? device tree blob be copied to the maximum address
+ ? ? ? ? ? ? ? ? of the 704 MB low memory, so that Linux kernel can
+ ? ? ? ? ? ? ? ? access it during the boot procedure.

I don't entirely understand that - 0x3c000000 is at a 768MB offset into kernel space think - where does the 64MB difference come from? Perhaps explain that a bit more.

Hi Simon,

Thanks for looking at the patch.

On 9 February 2012 09:37, Simon Glass <[email protected]> wrote:
...

Quoted 10 lines

Quoted 9 lines

? fdt_high ? ? - if set this restricts the maximum address that the ? ? ? ? ? ? ? ? ?flattened device tree will be copied into upon boot.
+ ? ? ? ? ? ? ? ? For example, if you have a system with 1 GB memory
+ ? ? ? ? ? ? ? ? at physical address 0x10000000, while Linux kernel
+ ? ? ? ? ? ? ? ? only recognizes the first 704 MB as low memory, you
+ ? ? ? ? ? ? ? ? may need to set fdt_high as 0x3C000000 to have the
+ ? ? ? ? ? ? ? ? device tree blob be copied to the maximum address
+ ? ? ? ? ? ? ? ? of the 704 MB low memory, so that Linux kernel can
+ ? ? ? ? ? ? ? ? access it during the boot procedure.

Quoted 4 lines

I don't entirely understand that - 0x3c000000 is at a 768MB offset into kernel space think - where does the 64MB difference come from? Perhaps explain that a bit more.

All the numbers above come from the real case of Freescale i.MX6Q Sabrelite board:

0x2C000000 (704 MB) + 0x10000000 (physical base) = 0x3C000000

Regards,
Shawn

Quoted 4 lines

All the numbers above come from the real case of Freescale i.MX6Q Sabrelite board:

0x2C000000 (704 MB) + 0x10000000 (physical base) = 0x3C000000

OK I see, thanks.