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 <[email protected]> > > --- > > 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.
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
signature.asc
Description: PGP signature
