On Mon, 17 Mar 2025 12:30:29 -0700 Vagrant Cascadian <vagr...@debian.org> wrote:
> On 2025-03-16, Denis 'GNUtoo' Carikli wrote: > > On Thu, 13 Mar 2025 00:37:09 -0700 > > Vagrant Cascadian <vagr...@debian.org> wrote: > >> I have successfully built and booted a > >> linux-libre-arm64-mnt-reform@6.12 kernel on a "MNT Reform2 with > >> RCORE RK3588 Module" ... running Debian, I know... but Guix System > >> cannot be too far off! In theory it also supports the other MNT > >> Reform platforms, but I have not tested! > > [...] > >> One could not be enabled due to DEBLOBBING the wifi drivers, and > >> the other may need a closer look. Although the second was for a > >> platform I am not currently using, so... :) > > What is the WiFi chip being used[1]? > > Heh. Hard to tell, because I am running linux-libre. :) Using 'sudo dmesg' usually prints something with DEBLOBBED and the driver name. Another option is to use lspci like that: > # lspci -s 02:00.0 > 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network > Adapter (PCI-Express) (rev 01) root@primary_laptop /home/gnutoo# lspci -s 02:00.0 -v > 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network > Adapter (PCI-Express) (rev 01) > [...] > Kernel driver in use: ath9k > Kernel modules: ath9k > Looking at the card through the transparent case bottom (yes!): > > WLE200NX 7A > > A quick search says some Compex dual-band wifi, but not sure what that > translates to in linux driver terms... > > The original MNT/Reform used the Atheros ath9k, if I recall correctly > ... could possibly switch back to that too, presumably, if that has > libre drivers. It does. There are also ath9k compatible chips that support both 2.4 GHz and 5GHz. If you want WiFi to work in conferences or other very crowded environments (like a flat with a ton of people) you need a chip which support 5GHz. > > An option could also be to upstream as much as possible of the DTS > > somehow (basically only send the easy dts patches) to be able to > > more easily track what is missing upstream and so find out why this > > or that patches are really needed. > > Yes, that is indeed the eventual goal and best outcome, but for the > near future we still have to use patches Indeed, I was just pointing in addition to shipping a patched kernel (which is required to make the hardware work), some very limited upstream contributions are a good idea to get reliable information on what patches are really required because things evolve upstream. Reading or trying to remove some of the patches you currently use to try to understand the consequences is probably still be required anyway, but just having that done doesn't provide some easy way to test things on more recent kernel versions. > There is some good news on that front, too: > > > https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts?h=next-20250317 Nice. I'm currently offline so I'll try to remember to take a look later on. Also note that I don't have an MNT Reform but I'm very curious about them. Denis.
pgpUShjrTrmbu.pgp
Description: OpenPGP digital signature
