On 2021-05-11, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Initially, I tried adding just the obviously mmc related modules, but >> this gave me guile prompt from the initramfs as it failed to find the >> rootfs. Notably, even with the above list, I still need to explore >> additional modules to load in order to get the display and keyboard to >> work from the initramfs, in case I wanted to use this with encrypted >> rootfs... >> >> The above list of modules could almost certainly be trimmed, but even >> getting a bootable system for pinebook pro took about 20 tries, and the >> process of defining the modules is further complicated by several >> factors... >> >> * The filesystem names of the modules (e.g. dw_mmc-pltfm) do not >> necessarily match the runtime name from lsmod (e.g. dw_mmc_pltfm). >> This becomes a good deal of trial and error to figure out which >> modules to add. >> >> * One needs to manually resolve the soft and hard dependencies of the >> modules, and ensure they are loaded, and include them in the list. >> >> * If upstream changes the module name (which does happen from time to >> time), you have to update the system config.scm to the new module >> names. >> >> * If some functionality changes from a module to a built-in, or >> vice-versa, the system config.scm needs manual updating. >> >> * Switching system between two different arm boards potentially requires >> entirely different lists of modules. > > Note that ‘guix system init’, ‘reconfigure’, and ‘deploy’ error out if > drivers for a storage device are missing (see > ‘check-device-initrd-modules’). Yes, I often have to tell it to skip those checks when using 'guix system init', as I'm installing to a microSD card by way of a usb-to-microSD adapter, and it guesses all the wrong modules. > Now, that doesn’t help if you’re using ‘guix system image’, which > perhaps is what you were doing? I wonder how we could take advantage of > that code in such a scenario. I sometimes do 'guix system image' for the initial pass, and then follow-up with init or reconfigure... >> Rather than handling modules one at a time, I would propose to at least >> add an option that can add whole directory trees of modules to the >> initrd (e.g. kernel/drivers/usb/)... and then use modprobe (or udev?) >> to handle the dependencies. Maybe opt-in at first, but longer-term, >> explore making it default? > > I remember Danny and I worked on something along these lines in the past > but it didn’t completely materialize (some of the machinery is already > here, though). That said, we still wouldn’t want to include too much in > the initrd, would we? Notably, at the moment it loads various virtio modules on all my baremetal systems, which is a bit uneccesary. :) Honestly, when debugging support for a new arm system, I'm of the opinion that more is better than less, as it takes way too many iterations to get to a working modular configuration. So at least an option to include even the kitchen sink drivers would be nice. :) live well, vagrant