[PATCH] mx6cuboxi: don't disable fdt relocation

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200204/2712fe9c/attachment.sig>