HiFive Unmatched: U-Boot stuck when loading Ramdisk

[David Abdurachmanov]

On Fri, Oct 15, 2021 at 7:16 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Oct 15, 2021 at 06:29:09PM +0300, David Abdurachmanov wrote:
> > On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel <soeren at soeren-tempel.net> wrote:
> > >
> > > Hello,
> > >
> > > I hope this is the right way to report u-boot issues. I tried to reach
> > > out to the RISC-V subsystem maintainer beforehand but didn't receive a
> > > response, hence sending this to the ML.
> > >
> > > We are currently working on Alpine Linux support for the Hifive
> > > Unmatched and at least two of our developers have access to a board
> > > presently. While working on Alpine support, we noticed that U-Boot with
> > > sifive_unmatched_defconfig gets stuck while loading the Alpine
> > > initramfs. The last message received on the SiFive UART is:
> > >
> > >         Loading Ramdisk to ffa72000, end fffffc19 ...
> > >
> > > Afterwards, U-Boot is stuck. We ran into this problem on two different
> > > boards independently. Both with u-boot-2021.10 as well as u-boot master
> > > (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set
> > > initrd_high manually (i.e. change the address region the Ramdisk is
> > > loaded to) everything works as expected. For example, `setenv
> > > initrd_high 0x85000000`. Maybe the default address region used for the
> > > Ramdisk overlaps with the U-Boot stack/text region or something?
> > >
> > > I am not familiar with U-Boot internals, but briefly looking at the code
> > > and how the default Ramdisk address region is calculated, it seems to me
> > > that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration
> > > for the Unmatched and Unleashed doesn't. If I set it manually everything
> > > works as expected. For example:
> > >
> > >         diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h
> > >         index d63a5f62fb..e1d3cb4ec4 100644
> > >         --- a/include/configs/sifive-unmatched.h
> > >         +++ b/include/configs/sifive-unmatched.h
> > >         @@ -25,6 +25,7 @@
> > >
> > >          #endif
> > >
> > >         +#define CONFIG_SYS_BOOTMAPSZ   (256 << 20)
> > >          #define CONFIG_SYS_SDRAM_BASE          0x80000000
> > >          #define CONFIG_SYS_INIT_SP_ADDR                (CONFIG_SYS_SDRAM_BASE + SZ_2M)
> > >
> > > This causes the Ramdisk to be loaded to 8f9f7000, end 8ffffb3d by
> > > default which, looking at the Unmatched memory map, seems to be a more
> > > sensible address region for the Ramdisk:
> > >
> > >         Moving Image from 0x84000000 to 0x80200000, end=811a9000
> > >         ## Flattened Device Tree blob at 88000000
> > >            Booting using the fdt blob at 0x88000000
> > >            Loading Ramdisk to 8f9f7000, end 8ffffb3d ... OK
> > >            Loading Device Tree to 000000008f9f1000, end 000000008f9f660b ... OK
> > >
> > > If there is a better place to report this issue let me know. If you need
> > > more information to reproduce/debug this issue I would be very happy to
> > > help.
> >
> > Could you try these two changes together (see below)?
> >
> > diff --git a/include/configs/sifive-unmatched.h
> > b/include/configs/sifive-unmatched.h
> > index 7157295..7254e06 100644
> > --- a/include/configs/sifive-unmatched.h
> > +++ b/include/configs/sifive-unmatched.h
> > @@ -67,7 +67,7 @@
> > "scriptaddr=0x88100000\0" \
> > "pxefile_addr_r=0x88200000\0" \
> > "ramdisk_addr_r=0x88300000\0" \
> > - "kernel_comp_addr_r=0x90000000\0" \
> > + "kernel_comp_addr_r=0x90300000\0" \
> > "kernel_comp_size=0x4000000\0" \
> > "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
> > "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
> >
> > diff --git a/include/configs/sifive-unmatched.h
> > b/include/configs/sifive-unmatched.h
> > index 7254e06..3b72304 100644
> > --- a/include/configs/sifive-unmatched.h
> > +++ b/include/configs/sifive-unmatched.h
> > @@ -62,6 +62,8 @@
> > "name=system,size=-,bootable,type=${type_guid_gpt_system};"
> > #define CONFIG_EXTRA_ENV_SETTINGS \
> > + "fdt_high=0xffffffffffffffff\0" \
> > + "initrd_high=0xffffffffffffffff\0" \
> > "kernel_addr_r=0x84000000\0" \
> > "fdt_addr_r=0x88000000\0" \
> > "scriptaddr=0x88100000\0" \
>
> This second one is a hard NAK.  The root problem is, I believe, that
> risc-v, until the current dev tree (so v2022.01) doesn't set the flag to
> prevent itself from being overwritten when preparing to boot the OS.  So
> the correct change is indeed to set CONFIG_SYS_BOOTMAPSZ as this does
> tell U-Boot to always contain kernel/dtb/initrd to within that size
> window, from start of memory (roughly).  Disabling dtb/initrd relocation
> on the otherhand introduces the different frequent failure of dtb being
> loaded at 4-but-not-8-byte-aligned addresses and thus being unusable.

Yes, it seems to be the correct approach.

I believe all RISC-V boards (in upstream U-Boot and downstream too)
disable relocation. The only exception is probably SiFive Unmatched
right now and that causes some problems for distros (randomly).

I assume once LMB patchset lands someone will clean up riscv board configs.

david

>
> --
> Tom