| Message ID | 1326182048-26418-1-git-send-email-shawn.guo@linaro.org |
|---|---|
| State | Accepted |
| Commit | fa34f6b25b3c92f27b245c52378a0d2af24aaa19 |
| Delegated to: | Stefano Babic |
| Headers | show |
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
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; }
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(-)