[U-Boot] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[U-Boot] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

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

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 <shawn.guo@linaro.org>
---
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(-)

diff --git a/README b/README
index ff72e47..1c3713c 100644
--- a/README
+++ b/README
@@ -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
diff --git a/common/image.c b/common/image.c
index 77ca6e4..8c4137c 100644
--- a/common/image.c
+++ b/common/image.c
@@ -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] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[Shawn Guo]

Gentle ping?

Regards,
Shawn

On Tue, Jan 10, 2012 at 03:54:08PM +0800, Shawn Guo wrote:
> 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 <shawn.guo@linaro.org>
> ---
> 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(-)
> 
> diff --git a/README b/README
> index ff72e47..1c3713c 100644
> --- a/README
> +++ b/README
> @@ -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
> diff --git a/common/image.c b/common/image.c
> index 77ca6e4..8c4137c 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -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] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[Stefano Babic]

On 10/01/2012 08:54, Shawn Guo wrote:
> 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 <shawn.guo@linaro.org>
> ---

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

[U-Boot] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[Simon Glass]

Hi Stefan,

On Wed, Feb 8, 2012 at 3:39 AM, Stefano Babic <sbabic@denx.de> wrote:
> On 10/01/2012 08:54, Shawn Guo wrote:
>> 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 <shawn.guo@linaro.org>
>> ---
>
> 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.

I'm not familiar with this code, but will take a look. Also copying Jerry.

Regards,
Simon

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

[U-Boot] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[Simon Glass]

Hi Shawn,

On Mon, Jan 9, 2012 at 11:54 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> 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 <shawn.guo@linaro.org>
> ---
> 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(-)
>
> diff --git a/README b/README
> index ff72e47..1c3713c 100644
> --- a/README
> +++ b/README
> @@ -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.

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.

Otherwise, it looks fine to me, so FWIW:

Acked-by: Simon Glass <sjg@chromium.org>

> +
> ? ? ? ? ? ? ? ? ?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
> diff --git a/common/image.c b/common/image.c
> index 77ca6e4..8c4137c 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -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

[U-Boot] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[Shawn Guo]

Hi Simon,

Thanks for looking at the patch.

On 9 February 2012 09:37, Simon Glass <sjg@chromium.org> wrote:
...
>> ? 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.
>
All the numbers above come from the real case of Freescale i.MX6Q
Sabrelite board:

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

Regards,
Shawn

[U-Boot] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[Simon Glass]

Hi Shawn,

On Thu, Feb 9, 2012 at 10:51 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Hi Simon,
>
> Thanks for looking at the patch.
>
> On 9 February 2012 09:37, Simon Glass <sjg@chromium.org> wrote:
> ...
>>> ? 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.
>>
> 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.

Regards,
Simon

>
> Regards,
> Shawn

[U-Boot] [PATCH v3] common/image.c: align usage of fdt_high with initrd_high

[Stefano Babic]

On 09/02/2012 20:43, Simon Glass wrote:

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

Hi guys,

thanks everybody for reviewing - I will merge now this patch into
u-boot-imx.

Best regards,
Stefano Babic

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