On 2019-12-17, Vagrant Cascadian wrote: > On 2019-12-18, Mitsuya Shibata wrote: >> What is the content of /boot/extlinux/extlinux.conf? >> >> On my environment (Ubuntu 19.10 with amd64), >> I need to set 'U_BOOT_FDT_DIR="noexist"' in /etc/default/u-boot, >> then execute "u-boot-update". ... > Nice catch, this workaround worked for me with both 5.3.x from unstable > and 5.4.x from experimental by essentially not configuring it to use any > .dtb file and just using the device-tree loaded by qemu/opensbi at > $fdtcontroladdr ... which the u-boot packages in Debian were patched to > support: > > https://patchwork.ozlabs.org/patch/1151125/ > > There's some discussion on it about weather it's correct to use > $fdtcontroladdr vs. $fdt_addr_r and other various issues, so the patch > has not landed in upstream u-boot yet. I've updated the patch against u-boot v2020.01-rc5... it would be good to further investigate what would be needed to get it upstream. >> Another perspective, Linux 5.3 introduced new image header for RISC-V. >> >> RISC-V: Add an Image header that boot loader can parse. >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0f327f2aaad6a87356cbccfa390d4d3b64d0d3b6 > > This was backported to Debian's linux 5.2.6-1. But apparently what was accepted upstream was a bit different from what was backported to linux 5.2.x in Debian... >> For this, following patch will be needed which is committed after v2019.10. >> >> https://gitlab.denx.de/u-boot/u-boot/commit/70d64a4c7646aa51c0334618ccb9af0132d9d834 > > I'll be testing u-boot 2020.01-rc5 soon and seeing what changes may be > needed... I've got the u-boot-qemu v2020.01-rc5 building with an updated patch, and linux 5.3 and 5.4 as packaged in Debian work, the older 5.2 kernels don't work, but those aren't really present in Debian's riscv64 port any longer, so I'm guessing that shouldn't be an issue. live well, vagrant
Attachment:
signature.asc
Description: PGP signature