On 2021-08-02, Pierre Langlois wrote: > Pierre Langlois writes: >>>> That being said, while it works on pinebookpro, I still need an extra >>>> patch on the rockpro64 in order to boot, both on master with u-boot >>>> 2021.07 :-/ (see #49550). >>>> >>>> Were you able to confirm the issue? I see it looks like we have the same >>>> configuration in debian and guix, CONFIG_USE_PREBOOT=y and the >>>> "inno-usb" patch applied, mmmm >>> >>> Seems like you fixed the core of that problem in another commit! >>> >>> Patch looks good to me, thanks for working on it! >> >> Thanks for the review! I've just pushed it as >> eb46c6c5c81695af475f7e1e416d05e51157fe60, with a couple of tweaks to >> make `guix lint' happy (the patch filename was a little too long, as >> well as a line was over the column limit). Great! > It turns out I broke a few u-boot packages :-/ https://ci.guix.gnu.org/eval/70864?status=failed Oh well... > u-boot-tools failing to build on aarch64 appears to be unrelated, it's > due to libical which builds just fine for me on my rockpro64. hrm... yeah, it has been a while since libical succeeded on aarch64: https://ci.guix.gnu.org/search?query=libical+system%3Aaarch64-linux Might be another case where the package doesn't build on some of the virtualized machines but builds fine on real hardware... Appears to have built fine on bordeaux: $ guix weather libical computing 1 package derivations for aarch64-linux... looking for 1 store items on https://ci.guix.gnu.org... https://ci.guix.gnu.org 0.0% substitutes available (0 out of 1) unknown substitute sizes 0.0 MiB on disk (uncompressed) 0.723 seconds per request (0.7 seconds in total) 1.4 requests per second 0.0% (0 out of 1) of the missing items are queued 1 queued builds aarch64-linux: 1 (100.0%) build rate: .00 builds per hour x86_64-linux: 39.79 builds per hour i686-linux: 0.00 builds per hour aarch64-linux: 0.00 builds per hour looking for 1 store items on https://bordeaux.guix.gnu.org... https://bordeaux.guix.gnu.org 100.0% substitutes available (1 out of 1) 0.5 MiB of nars (compressed) 7.4 MiB on disk (uncompressed) 0.872 seconds per request (0.9 seconds in total) 1.1 requests per second (continuous integration information unavailable) > However u-boot-vexpress I suspect u-boot-vexpress should just be dropped. The hardware was always unobtanium (e.g. you can't get it even with absurd sums of money); the only use-case was it was a platform supported in qemu early on, but there are better virtualization platform options these days (e.g. virt)... > u-boot-sifive-fu540 and u-boot-qemu-riscv64-smode are > real issues. Here are a couple of patches for them, they're pretty > trivial so I'll push them soon unless anybody objects: > From 26957dac52584457d43d6139e2edc49074c7ca44 Mon Sep 17 00:00:00 2001 > From: Pierre Langlois > Date: Mon, 2 Aug 2021 15:13:11 +0100 > Subject: [PATCH 2/2] gnu: Rename u-boot-sifive-fu540 to sifive-unleashed. > * gnu/packages/bootloaders.scm (u-boot-sifive-fu540): Rename to ... > (u-boot-sifive-unleashed): ... this. Change board name from sifive_fu540 to > sifive_unleashed. > * gnu/packages/patches/u-boot-riscv64-fix-extlinux.patch: Rename sifive_fu540 > to sifive_unleashed. Ah, sorry, I should have caught this, as I had to do this in the Debian packages too (but an earlier upload, so not as fresh in my memory)... Patch looks good to me, for what it's worth. :) It might normally be good to make a deprecated package for the name change, but again, since riscv64 is so experimental in guix it is probably not worth cluttering up with niche deprecated packages like this... live well, vagrant