From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vagrant Cascadian Date: Wed, 18 Dec 2019 07:11:07 -0800 Subject: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot) In-Reply-To: References: <20190821190720.4286-1-david.abdurachmanov@sifive.com> <87r243g6us.fsf@yucca> <87imme1lzf.fsf@yucca> Message-ID: <87h81xpt2s.fsf@yucca> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2019-12-18, David Abdurachmanov wrote: > On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian 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 . >> >> >> >> 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 >> >> 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: