On Thu, Dec 19, 2019 at 12:18 AM Vagrant Cascadian vagrant@debian.org wrote:
On 2019-12-18, David Abdurachmanov wrote:
On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian vagrant@debian.org wrote:
On 2019-09-25, Vagrant Cascadian wrote:
On 2019-08-21, David Abdurachmanov wrote:
Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot commands in RISC-V targets and broke extlinux support as reported by Fu Wei wefu@redhat.com.
The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT to Kconfig.
Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
Please CC me on future updates to the patch series.
Tested-by: Vagrant Cascadian vagrant@debian.org
This patch, or something like it, is still needed with u-boot v2020.01-rc5 for extlinux support to load the device-tree from the boot firmware.
Is there a new approach in the works, or any chance to see something like this get merged soon?
I do carry several experiment patches in Fedora/RISCV, which I didn't yet sent for a review. Basically that allows me to boot a single Fedora/RISCV disk image on QEMU virt machine and SiFive Unleashed.
See: http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/ub...
Note some of the patches were merged in rc5.
Thanks! I'll give your patches some testing when I get a chance.
Some potentially quite naive questions:
You would want the following two patches: http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/ri...
Why does it need fdt_addr=0x88000000 need to be set (and to the same value as fdt_addr_r)? According to README fdt_addr is for the flash media, which I don't think is used in the qemu case, at least. Is fdt_addr being (ab)used for some other purpose? I guess the README also gives free reign to use the variables for other purposes... but it would be good to know why that is needed vs. just using fdt_addr_r as documented.
The comments in uboot-tools.spec explain it. This is only needed if you use EXTLINUX to boot your image. IIRC EXTLINUX will assume DTB blob is available at fdt_addr or you can load one via fdt/fdtdir label in extlinux.conf (never tried). If you are booting in some other way you probably don't care about it.
http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/ri...
CONFIG_PREBOOT="cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x10000;"
This used to solve memory corruption for DTB in v5.3 kernel IIRC. That was fixed in v5.4 kernel thus should be removed (I will test later).
What does cp.l do?
Do you need to force setting the console in CONFIG_BOOTARGS? It seemed to autodetect the console on the installations I have running, possibly getting the chosen console from device-tree?
It doesn't detect it for me. Well it does on QEMU, but not on SiFive Unleashed. Both use different console (ttyS0 vs ttySIF0). I think the kernel doesn't look into chosen console expect powerpc IIRC.
I can retest since this was added: https://github.com/torvalds/linux/commit/2993c9b04e616df0848b655d7202a707a70...
I am updating kernel in Fedora/RISCV to 5.5-rc2 now thus I can re-check various patches again.
david
live well, vagrant