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. :) 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. >> Rather than embedding all those patches into guix, I could really use >> help with figuring out how to apply those patches from the git >> checkout! It is a lot of patch: Well, figured out a way to do that, trimming out the 1.2MB of patches in gnu/packages/patches and instead pulling them from the external git repository: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-linux-libre-arm64-mnt-reform&id=9d1e2ad4192baa53d2740e586cbed2beff64ac5c Might be better ways to do it, I spent a lot of time trying to figure out how to apply the patches as (source (patches ... or (source (snippet ... but instead had to use phases, as I could figure out how to reference the patches from the inputs! A few of the added phases could be improved in various ways (three copies of essentially the same code), and some of the substitutions could be better implemented as a patch. maybe. But it works and solved the biggest problems... I think it is good enough to propose a draft for merging... > 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, and you have to test those patches somehow to get them upstream! 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 Plenty of other patches needing upstreaming, but upstreaming is actually happening to some degree! More help is always needed, I am sure. :) live well, vagrant
signature.asc
Description: PGP signature
