Hi, On Thu, Dec 19, 2019 at 1:42 PM David Abdurachmanov <david.abdurachma...@gmail.com> wrote: > > On Thu, Dec 19, 2019 at 12:18 AM Vagrant Cascadian <vagr...@debian.org> wrote: > > > > On 2019-12-18, David Abdurachmanov wrote: > > > On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian <vagr...@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 <w...@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 <vagr...@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/uboot-tools.spec#L36 > > > > > > 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/riscv64-set-fdt_addr.patch > > > > 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/riscv-bootargs-preboot.patch > > > > 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/2993c9b04e616df0848b655d7202a707a70fc876 > > I am updating kernel in Fedora/RISCV to 5.5-rc2 now thus I can > re-check various patches again. >
What's the status of this patch? Regards, Bin
