On Sat, 17 Jan 2026 09:45:48 +0100 "Tanguy Le Carrour" <[email protected]> wrote:
> I would be more than happy to hear how any one else is working with > their SBC and what advice they would give me not to lose my time and > my sanity! 🤪 I've already asked questions like the ones you ask in this mailing list several times, tried to ask in person at the FOSDEM, at Guix events in Paris, etc, and I didn't have proper answers for years. In my case I have a background in all that (ARM, embedded, etc). That's how I started contributing code/packages to free software (with openembedded in 2009) and I've been around long enough, and contributed to projects with different approaches, so I know that there is more than one way to do things. Take u-boot and serial ports for instance. Serial ports can work in multiple speeds (9600, 115200, 1500000, etc). The Tow-Boot project wants to unify the configurations, which means using 115200 everywhere because that can work everywhere. Upstream U-Boot tend to match the vendor documentation instead. So you already have 2 ways to do it here. And both are perfectly valid. They just come with different tradeoffs. So when starting to contribute to Guix, I've all that in mind but there is no documentation anywhere on which approach has been chosen for ARM / SBCs. The way I found out was by sending patches to add support for the 64bit ARM computers I use, and deducing the policies actually in place from the interactions during the patch reviews. And here I was told not to deviate too much from the upstream configuration of u-boot. So I now know that if upstream u-boot uses 1500000, I should use that, and if u-boot also has documentation for the computer I use, I can also ship that (because it will also assume 1500000). It was chaotic at the beginning, but I'm starting to understand more and more how things are done through that. And if you're unsure how to do something and that nobody else has an answer, and that the manual isn't clear, then I think that the only way is also to send patches to fix the manual, and deduce the Guix way of doing things through the interaction during the review of the patches. For the rest of your questions I'll try my best, but as you see I also have huge gaps in my knowledge of how all that works in practice, hence this answer. > (*) I write cross-compile, but I actually tried both `--system` and > `--target`. They both work on the newer computer, but only `--system` > seems to work on the old one, but ends up failing with a weird error > on dangling link: > <https://lists.gnu.org/archive/html/help-guix/2026-01/msg00006.html> As I understand, when the target CPU is incompatible with the builder CPU, --target= does cross compile and --system uses QEMU (when it is properly configured) to build natively. I've no idea which one is best, that tends to depend a lot on the situation. When building without substitutes --target= is faster. However --system probably uses the exact same substitutes on the builder and the target. Though this needs to be tested in practice to be sure of that. And using --target probably requires to re-download everything at the first reconfigure as the build dependencies are different. This also needs to be tested to make sure it is still true. In my case I actually do have hardware to test (rock-4c-plus with 4GiB of RAM and 64bit ARM), but I need to find the time, and I want to improve the support for it and add more boards first. > I’m pretty much used to the process now and buying an USB-serial cable > made working with the board even easier, but I feel like it’s not the > proper way to move forward. This depends a lot on the (ARM) computer. Some don't have displays at all. On some the display don't work in u-boot. It's also very handy to get boot logs. The one you have seem to have good display support everywhere at least for now (I've not checked if it uses deprecated drivers in u-boot or not, but the boards that did are probably gone or adapted somehow by now). Building u-boot-a20-olinuxino-lime2 should tell anyway (it has a big warning at the end of the build if it uses deprecated drivers). So both approach look perfectly valid. Personally I would love it if all SBCs manufacturers included easy way to get access to the serial port, like through an USB connector, because it is extremely useful (you get the logs without having to take a picture etc, you can grep in it, you can share it on mailing lists, etc). Through once networking works, I do prefer SSH or a display+keyboard as I never managed to configure the serial ports console (export TERM=xterm) well enough to make all text editors / ncurses program work fine in them. > - install from a USB stick… FAILED What does FAILED means here? What command did you try? Personally I'm a bit confused with the status of the installer on ARM (32 and 64bit), the manual advises to do that: > guix system image --system=armhf-linux -e \ > '((@ (gnu system install) os-with-u-boot) \ > (@ (gnu system install) installation-os) \ "A20-OLinuXino-Lime2")' But then we also have things like a20-olinuxino-lime-installation-os in gnu/system/install.scm so I'm a bit lost in what is the way to go. I think that the following make more sense though: > guix system build --target=arm-linux-gnueabihf \ > -e '(@ (gnu system install) a20-olinuxino-lime2-emmc-installation-os)' I'll try to find the time to send a patch to fix that in the manual, this way I'll also have confirmation that this is the right way to do things. The rationale is that a20-olinuxino-lime2-emmc-installation-os has a bit more information (like the serial port) than the command in the manual, so it has more probability to do what is expected. I also don't know in which cases --system doesn't work (can it work on foreign distributions?) but maybe --system is better (does it always have substitutes?). The command I pasted also didn't work for me, so it looks like a new failure and I didn't start investigating yet. Here's the error: > arm-linux-gnueabihf-gcc -nostdlib -nostartfiles -shared -o > /tmp/guix-build-glibc-2.39.drv-0/build/elf/ld.so.new \ > -Wl,-z,relro -Wl,-z,defs \ \ > /tmp/guix-build-glibc-2.39.drv-0/build/elf/librtld.os > -Wl,--version-script=/tmp/guix-build-glibc-2.39.drv-0/build/ld.map > \ -Wl,-soname=ld-linux-armhf.so.3 objcopy: Unable to > recognise the format of the input file > `/tmp/guix-build-glibc-2.39.drv-0/build/libc_pic.os' make[2]: *** > [../Makerules:613: > /tmp/guix-build-glibc-2.39.drv-0/build/libc_pic.os.clean] Error 1 > make[2]: *** Waiting for unfinished jobs.... readelf -s > /tmp/guix-build-glibc-2.39.drv-0/build/elf/ld.so.new \ | gawk '($7 ~ > /^UND(|EF)$/ && $1 != "0:" && $4 != "REGISTER") { print; p=1 } END { > exit p != 0 }' mv -f > /tmp/guix-build-glibc-2.39.drv-0/build/elf/ld.so.new > /tmp/guix-build-glibc-2.39.drv-0/build/elf/ld.so make[2]: Leaving > directory '/tmp/guix-build-glibc-2.39.drv-0/glibc-2.39/elf' make[1]: > *** [Makefile:484: elf/subdir_lib] Error 2 make[1]: Leaving directory > '/tmp/guix-build-glibc-2.39.drv-0/glibc-2.39' make: *** [Makefile:9: > all] Error 2 error: in phase 'build': uncaught exception: %exception > #<&invoke-error program: "make" arguments: ("-j" "2" "--max-load=2") > exit-status: 2 term-signal: #f stop-signal: #f> phase `build' failed > after 743.5 seconds command "make" "-j" "2" "--max-load=2" failed > with status 2 build process 4 exited with status 256 And this fails when building glibc. > - cross-install from a running ARMbian… FAILED > - cross-compile* from my old D8… SLOW… FAILED Does the build fails? Personally the way I do installation so far (on 64bit ARM, I didn't deploy production 32bit ARM with Guix yet) is to build an image, like the one you have added in Guix, and once booted to somehow reconfigure the target. Though I didn't try that on armv7 yet. And ideally I want everything to work to have more options and be able to advise to get specific SBCs because they just work. > So I decided that I would give `guix deploy` a try. I would keep > cross-building everything on my computer(s) and push only the store > items to the board and reconfigure. > It sounds like a great plan! 😎 But the question is… am I being > delusional?! 😅 I lack practical knowledge. The only way to go seems to be to test it and to modify the manual afterward. Personally I found 'guix deploy' not very practical, mainly because my laptop is slow, and I need to keep it connected to the network for the build to work, but here, guix deploy might be the only way that makes sense here because of the low amount of RAM. Though you could also trying adding swap and so on and measuring guix pull and guix system reconfigure times. Note that we can now produce images with swap partitions. Note that I tried 'guix deploy' only many years ago, and I don't recall well if it cross-compiled or not. I vaguely remember that it did though. If it does you will have some packages that don't build. For instance at the time python programs couldn't work because the python build system of the time didn't support cross compilation. And it would also output the proper error messages. Here's an example: > $ guix build --target=aarch64-linux-gnu pelican > guix build: error: gnu/packages/python-xyz.scm:10513:2: > [email protected]: > build system `pyproject' does not support cross builds For a basic server use cases, I only had very few python programs. The biggest issues I had was certbot and then pelican (because I packaged several of my websites). Maybe there is a way around certbot. Another question is also that I have a lime2 with eMMC, and it is very similar to your lime2. I also have some lime1 A20 (512 MiB of RAM). U-boot uses separate configurations for all these. So making 3 image for these 3 boards is probably not ideal. There might be a way to somehow share almost everything but the machine name and the bootloader package by using a function and/or inheriting from another image. So here If I find the time I could also switch your image to the serial port while trying to do that. Though once my patch set for the am335x-evm is merged, I'll have hardware to test the 32bit ARM status. So I'll probably add a Baytrail tablet (because the patch is ready, to be able to test 32bit UEFI) and I'll then concentrate on switching the rock-4c-plus to linux-libre before and then add the rockpro64 before attempting more work with 32bit ARM, as this is quite urgent for me. Denis.
pgpt_0CEysOKg.pgp
Description: OpenPGP digital signature
