diff mbox series

mx6cuboxi: don't disable fdt relocation

Message ID c61b1087089ee7135374198a418956474213c50c.1580835428.git.baruch@tkos.co.il
State Accepted
Commit 064e49ff5e433235ab10b2c29885be7039c1d719
Delegated to: Stefano Babic
Headers show
Series mx6cuboxi: don't disable fdt relocation | expand

Commit Message

Baruch Siach Feb. 4, 2020, 4:57 p.m. UTC
fdt_high value of 0xffffffff disables fdt relocation on boot. We don't
need that for Cubox-i/Hummingboard. Rely on generic code to find the
optimal fdt location at boot time.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 include/configs/mx6cuboxi.h | 1 -
 1 file changed, 1 deletion(-)

Comments

Fabio Estevam Feb. 5, 2020, 12:17 a.m. UTC | #1
Hi Baruch,

On Tue, Feb 4, 2020 at 1:57 PM Baruch Siach <baruch@tkos.co.il> wrote:
>
> fdt_high value of 0xffffffff disables fdt relocation on boot. We don't
> need that for Cubox-i/Hummingboard. Rely on generic code to find the
> optimal fdt location at boot time.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
>  include/configs/mx6cuboxi.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
> index 6d47e28fc72b..a6690367f8c5 100644
> --- a/include/configs/mx6cuboxi.h
> +++ b/include/configs/mx6cuboxi.h
> @@ -66,7 +66,6 @@
>         "ramdisk_addr_r=0x13000000\0" \
>         "ramdiskaddr=0x13000000\0" \
>         "initrd_high=0xffffffff\0" \
> -       "fdt_high=0xffffffff\0" \
>         "ip_dyn=yes\0" \
>         "console=" CONSOLE_DEV ",115200\0" \
>         "bootm_size=0x10000000\0" \

Maybe initrd_high could also be removed?
Tom Rini Feb. 5, 2020, 12:51 a.m. UTC | #2
On Tue, Feb 04, 2020 at 09:17:07PM -0300, Fabio Estevam wrote:
> Hi Baruch,
> 
> On Tue, Feb 4, 2020 at 1:57 PM Baruch Siach <baruch@tkos.co.il> wrote:
> >
> > fdt_high value of 0xffffffff disables fdt relocation on boot. We don't
> > need that for Cubox-i/Hummingboard. Rely on generic code to find the
> > optimal fdt location at boot time.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> >  include/configs/mx6cuboxi.h | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
> > index 6d47e28fc72b..a6690367f8c5 100644
> > --- a/include/configs/mx6cuboxi.h
> > +++ b/include/configs/mx6cuboxi.h
> > @@ -66,7 +66,6 @@
> >         "ramdisk_addr_r=0x13000000\0" \
> >         "ramdiskaddr=0x13000000\0" \
> >         "initrd_high=0xffffffff\0" \
> > -       "fdt_high=0xffffffff\0" \
> >         "ip_dyn=yes\0" \
> >         "console=" CONSOLE_DEV ",115200\0" \
> >         "bootm_size=0x10000000\0" \
> 
> Maybe initrd_high could also be removed?

In general, it's not as dangerous to not move it, so long as the rest of
the addresses in use are reasonable.  Whereas if the FDT isn't 8 byte
aligned (but only say 4) on arm64 everything blows up, and initrd:
"must reside entirely within a 1 GB aligned physical memory window of up
to 32 GB in size that fully covers the kernel Image as well."

So it's less risky to let it be.  Also, while relocating the DTB is
usually very quick (being kilobytes in size) initrds are megabytes.

All that said, no, I don't object too initrd_high=0xffffffff being
removed everywhere maintainers are happy with the trade-offs of doing
so.
Stefano Babic March 10, 2020, 3:31 p.m. UTC | #3
> fdt_high value of 0xffffffff disables fdt relocation on boot. We don't
> need that for Cubox-i/Hummingboard. Rely on generic code to find the
> optimal fdt location at boot time.
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic
diff mbox series

Patch

diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index 6d47e28fc72b..a6690367f8c5 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -66,7 +66,6 @@ 
 	"ramdisk_addr_r=0x13000000\0" \
 	"ramdiskaddr=0x13000000\0" \
 	"initrd_high=0xffffffff\0" \
-	"fdt_high=0xffffffff\0" \
 	"ip_dyn=yes\0" \
 	"console=" CONSOLE_DEV ",115200\0" \
 	"bootm_size=0x10000000\0" \