Made a #MNTReform kernel for #Guix ... and used my MNT Reform2 rk3588 to build the kernel and successfully booted to #Debian !
With 32GB of ram, 8 moderately fast arm64 cores and an NVMe disk, it seems quite viable to run Guix.
Probably still missing some functionality, but the screen, mouse, keyboard, ethernet all work, at least!
Thanks @josch for organizing those patches so nicely for the reform-debian-packages repository!
Have not tested booting #GuixSystem yet, but... probably?
That is my near-term goal, anyways...
@vagrantc @josch I will try it when I get my machine. I wonder if it is possible to rewrite only the u-boot partition and not touch the SPL/TPL partitions? Instead of creating and writing a complete partition+SPL+TPL+uboot image. Then this could go all into normal Guix, and it would be able to do a system reconfiguration that includes uboot. If the user wants to update SPL/TPL, some separate proprietary process is needed.
The SPL and TPL bits are produced by #UBoot so in short the answer is no.
It is theoretically possible to have SPL and TPL be independent implementations, but you would have to make sure they continue to work with each new u-boot version, and that just sounds like asking for an endless source of problems.
It is a tiny little piece of DDR training code. If you really want to fix the problem properly, find someone to create an independent implementation of that.
Boot tested #Guix System on the #MNTReform tonight!
After a few fiddly bits getting the right modules into the initrd and successfully running "guix system init" ... much to my surprise... it booted successfully on the first try!
As they say, this is not my first rodeo...
Substitute availability for aarch64 has been quite good the last couple days, otherwise I might still be compiling things!
Will push a fairly minimal example system configuration to the WIP branch tomorrow.
I am well aware of the challenge on the #Debian side too, having brought up more than a few arm systems there too... but there is no comparison!
In #Guix the initrd has a hard-coded(?) list of modules loaded with insmod... In order... no attempt at dependency resolution at runtime or initrd creation. You can add modules to the list, or specify your own list entirely, which is what did for the #MNTReform this time.
The 90s haunt the 2020s sometimes. :)