[U-Boot] [PATCH v3] 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 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; }

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

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

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@denx.de =====================================================================

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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

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

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

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
participants (3)
-
Shawn Guo
-
Simon Glass
-
Stefano Babic