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.
http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/ri...
CONFIG_PREBOOT="cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x10000;"
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?
live well, vagrant