floss.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
For people who care about, support, and build Free, Libre, and Open Source Software (FLOSS).

Administered by:

Server stats:

685
active users

Made a kernel for ... and used my MNT Reform2 rk3588 to build the kernel and successfully booted to !

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!

git.savannah.gnu.org/cgit/guix

Thanks @josch for organizing those patches so nicely for the reform-debian-packages repository!

source.mnt.re/reform/reform-de

git.savannah.gnu.orgguix.git - GNU Guix and GNU Guix System

@vagrantc @josch Great work! I am still waiting for my Rk3588 order, but will try your Linux-libre-based kernel when I receive it. Can it boot to Guix? Did you notice any non-free stuff in those patches?

Vagrant Cascadian

@jas @josch

Have not tested booting 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.

@jas @josch

The SPL and TPL bits are produced by 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.

@vagrantc @jas Is the license situation at least better than it was with i.MX 8MQ where we are not even allowed to distribute the proprietary DDR training blob in non-free-firmware?

@jas @josch

Boot tested System on the 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.

@vagrantc @jas The problem of "getting the right modules into initrd" is one that we also have on Debian. You can find the full list we need in the reform-tools repository at `initramfs-tools/reform.conf`.

@josch @jas

I am well aware of the challenge on the side too, having brought up more than a few arm systems there too... but there is no comparison!

In 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 this time.

The 90s haunt the 2020s sometimes. :)

issues.guix.gnu.org/48266

issues.guix.gnu.orgsupport dynamic loading of modules from initrd