Hell Denis,
Denis 'GNUtoo' Carikli <[email protected]> writes: > Though there are some harder issues: > > - The serial port speed and path (like /dev/ttyS0 or /dev/ttyMXC0) > varies between computers. > > Maybe there is something in UEFI to somehow retrieve the serial > ports. In any case with the devicetree we do have access to the > computer name. > > Here's an example on the rockpro64: > root@rockpro64 ~# strings \ > /sys/firmware/devicetree/base/compatible > pine64,rockpro64-v2.1 > pine64,rockpro64 > rockchip,rk3399 > > So in the worst case we can have a database of device <-> serial > port settings and have a service use that. This could be shipped in > a generic image. > > Though might also be possible to retrieve these from the device tree > as well (it requires upstream support for that): Yes, but I would expect upstream to give it to us. I do not think we should have to do any work about it. Most device trees already do give the preferred serial port to us. Then, it is exposed by the kernel at /proc/consoles. And this is already respected by Guix System for two months or so. If you make an agetty service with #f for the device (and that is part of %base-services), the preferred console will be picked up. I do not think poking in the device device tree is preferred or wise, when there is already the kernel that does so and provides to us the information we need. > The 4 ARM images could be: > > - Two with GRUB for ARM UEFI: one 32bit, one 64bit. This would require > u-boot to then load GRUB (this should already work on some > ARM computers). We already do provide an AArch64 installer iso as part of the 1.5.0 release. And while it currently has its issues, like the fact that there are devices it does not boot on even though it easily could (see https://codeberg.org/guix/guix/issues/4883, https://codeberg.org/guix/guix/pulls/5876), I think that it serves as a proof of concept that can be extended upon. As mentioned previously about the /proc/consoles, it uses that for starting the consoles and it worked on the devices it boots on. As for ARMv7, the platform is barely supported by Guix. I do not think we should be generating official images for it or advocating its use (I have removed the mention saying that Guix System works on ARMv7 on the download page for the 1.5.0 release) unless someone steps up to maintain it properly. Figuring out and resolving issues with it. See https://codeberg.org/guix/guix/issues/1849. Since there are almost no users using it, it's hard to assess its actual state. > > - Two without u-boot (32bit and 64bit) but with the > /boot/extlinux/extlinux.conf that is required by u-boot to boot. > > We could also extend that to x86 somehow and have 5 images: > > - Two with BIOS (32 and 64bit) > - Two with UEFI (32 and 64bit) Why though? We can support both BIOS and UEFI inside of one image. We already do for the images for VMs that are part of the release and also with the iso installer. Since on x86_64 the situation is much better in terms of support of booting devices with the linux-libre kernel (no need for special image position etc.), I am not sure what generating these images would serve us here? I mean... we could potentially offer more types of images, an installer with a DE, VM images for servers and so on. But I don't really understand what your goal is here. Again similar situation with i686 to armhf. There are numerous issues, pretty much no DEs run as Qt doesn't build. Also suggestions to drop it from the build farms in the Codeberg thread. I am not sure if we should be investing much time to maintaining something that is becoming quite obsolete. Of course if there are individuals who are willing to do it, it's good for us. But we first need those and the issues to get solved prior to generating more images IMO. > - One with UEFI 32bit and a 64bit OS. Sorry, what does that mean exactly? Rutherther
