Closed carlosedp closed 2 years ago
In Ubuntu we find that meta-sifive layer patches alone are not enough. We apply more patches to enable correct preboot, and to fix memory allocation of the initrd & kernel. As otherwise it doesn't boot.
For Ubuntu, you have to at least add the lines:
"fdt_high=0xffffffffffffffff\0" \
"initrd_high=0xffffffffffffffff\0" \
to the CONFIG_EXTRA_ENV_SETTINGS #define in include/configs/sifive-unmatched.h.
Thanks! I just applied it here and it worked. Do it work with other distros? Any idea why it's Ubuntu/Debian only?
I guess it's not required for OE. The way I found it was by comparing the old CONFIG_EXTRA_ENV_SETTINGS that used to get patched into a file called include/configs/sifive-hifive-unmatched-fu740.h
with the current CONFIG_EXTRA_ENV_SETTINGS that are part of a new file called include/configs/sifive-unmatched.h
.
The new file was added to U-Boot with this commit https://github.com/u-boot/u-boot/commit/70415e1e528db0856fedd4fa79b9f4a303a28c62#diff-81a3360df41d45f826e71e3e1112f522790a594ff8bc108a35fe0010de9f5728
Thanks! I just applied it here and it worked. Do it work with other distros? Any idea why it's Ubuntu/Debian only?
It was submitted upstream to u-boot, further issues were identified and are being worked on to improve there. Basically memory map in u-boot at the moment is sub-optimal and either requires time-consuming relocation on every boot, or fails to boot, or has low-ish limits on kernel/initrd sizes.
I came up with a different solution:
+ "bootm_size=0x20000000\0" \
I am not 100% sure if that's better (AFAICT it reserves more low address space for boot loader shenanigans which is needed here because the Ubuntu initrd is too large to fit inbetween the different images and thus overwrite something important (I forgot what)) but I have read on stackoverflow(?) that simply setting the *_high
addresses to the top is just a bad hack. However, quite a few boards have this setting in the repo so I am not very confident that this an established rule :)
IIRC (but might be wrong) we have noticed such issuies on BeagleV back in June. Doing something like this fdt_high=0xffffffffffffffff
disabled relocation in U-Boot, which seems to be broken on RISC-V. Just 7 days ago Tom Rini commented that after investigation it seems that it's most likely due to a lack of arch_lmb_reserve
on RISC-V.
https://github.com/starfive-tech/u-boot/issues/24#issuecomment-906014197
There is a patch posted on Aug 15: [PATCH 09/14] lmb: riscv: Add arch_lmb_reserve()
I am a bit surprised that I personally never hit this issue on any of the boards :/
We have increased CONFIG_SYS_BOOTM_LEN
to SZ_64M
to allow larger kernels and kinda match what majority of aarch64 boards do. There are a few boards that go to SZ_128M
in U-Boot.
Most likely kernel_comp_addr_r
should be fixed. That currently gives 125MiB instead of 128MiB. That was raised on the U-Boot mailing list, but I am not sure anyone sent a patch for that.
This issue is fixed.
I've built the latest versions of the images for OpenSBI, U-Boot and Linux Kernel, applied the patches from the meta-sifive repository but it freezes on load:
Using the same Kernel with previous firmware (built based on meta-sifive 2021.06 and uboot 2021.01) works fine: