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

[Vagrant Cascadian <vagrant@debian.org>]

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/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.


> 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;"

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191218/1acaeeea/attachment.sig>