[RFC 1/1] board: sifive: unmatched: use zero copy for initrd

[David Abdurachmanov]

On Tue, Jul 20, 2021 at 1:06 AM Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Jul 19, 2021 at 11:52:09PM +0200, Heinrich Schuchardt wrote:
> >
> >
> > On 19.07.21 23:38, Heinrich Schuchardt wrote:
> > > Booting Ubuntu Impish showed the following output:
> > >
> > >      relocaddr   = 0x00000000fff60000
> > >
> > >      Loading Ramdisk to fa118000, end fffff19d ...
> > >
> > > The initrd is overwriting the U-Boot binary. Booting fails.
> > >
> > > There is no need to copy the initrd from $ramdisk_addr_r.
> > > Set init_high = ~0UL to use zero copy.
> > >
> > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
> > > ---
> > > Generally copying to another memory location than $ramdisk_addr_r provides
> > > no benefit whatsoever.
> > >
> > > But we still should find out why the initrd relocation fails so badly.
> > > ---
> > >   include/configs/sifive-unmatched.h | 1 +
> > >   1 file changed, 1 insertion(+)
> > >
> > > diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h
> > > index d63a5f62fb..8dcfffedbe 100644
> > > --- a/include/configs/sifive-unmatched.h
> > > +++ b/include/configs/sifive-unmatched.h
> > > @@ -67,6 +67,7 @@
> > >     "scriptaddr=0x88100000\0" \
> > >     "pxefile_addr_r=0x88200000\0" \
> > >     "ramdisk_addr_r=0x88300000\0" \
> > > +   "initrd_high=0xffffffffffffffff\0" \
> > >     "kernel_comp_addr_r=0x90000000\0" \
> >
> > Tom remarked that kernel_comp_addr_r is poorly chosen as it will overlap
> > with initrd if initrd exceeds 125 MiB. Current RISC-V Linux thinks
> > initrd should fit into the first 128 MiB of RAM but that is an
> > unnecessary restriction in Linux.

While I don't expect this to be a major issue we should definitely fix it.
When I originally picked the value I wasn't thinking about it and
initrd images were small.

david

>
> I'll repeat what I said on IRC as well.  I lament that there does not
> seem to be as detailed "booting" requirements in Linux for RISC-V as
> there is for arm/aarch64 because we REALLY need something like:
> https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/ti_armv7_common.h#L32
> but for one or more RISC-V platforms (and well, MIPS and everyone else
> using device trees) that can be referenced when bringing up a new board
> to get good and always safe addresses to use.
>
> And I'll even say now that the ti_armv7_common.h example could be
> improved upon because I'm not super thrilled with the DTBO storage spot,
> but I don't have a better answer off the top of my head.
>
> --
> Tom