[U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)

[David Abdurachmanov]

On Thu, Dec 19, 2019 at 12:18 AM Vagrant Cascadian <vagrant at debian.org> wrote:
>
> On 2019-12-18, David Abdurachmanov wrote:
> > On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian <vagrant at 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 at 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 at 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.

david
>
>
> live well,
>   vagrant