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