In reply to @alex:tunstall.xyz
It might not be a u-boot issue because when I booted the vendor's Debian image using the same u-boot I use for NixOS, it ran at 1.5 GHz. Or maybe you've run into a completely different problem with similar symptoms?

In reply to @misuzu:matrix.org
That's likely a kernel issue, I've had no issues flashing latest firmware via recovery

In reply to @alex:tunstall.xyz
It is: the DTB comes from the kernel.

In reply to @misuzu:matrix.org
I've just tried 6.4.0-rc6 and it's still at 500000

How interesting. Perhaps that is the default at boot and the system is unable to change it?

If you set the governor to userspace and try setting other frequencies via scaling_setspeed, are you able to get anything other than 500 MHz?

In reply to @alex:tunstall.xyz

How interesting. Perhaps that is the default at boot and the system is unable to change it?

If you set the governor to userspace and try setting other frequencies via scaling_setspeed, are you able to get anything other than 500 MHz?

In reply to @misuzu:matrix.org
Nope, tried 375000, 750000 and 1500000, still 500000

In reply to @alex:tunstall.xyz
I was on upstream 6.4.0 (from commit 4964ce0a869e) when I wrote that. I assume from your repository that this behaviour is from a build of e5a381c51d624ffd8784db908a58ae227d0608a4?

In reply to @thefossguy:matrix.org
by upstream, do you mean StarFive's repo or Linus' tree? I belive Linus' tree is missing support for the eMMC node for the VF2 dtsi (haven't checked for -next).

In reply to @alex:tunstall.xyz
FWIW I tried mainline too but it didn't boot and I don't have the hardware to debug failed boots.

For microSD, mmc1 is the correct node btw. I don't think mmc0 is used in the VF2, but it seems like it's for eMMC.

[nixos@nixos:/etc/nixos]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk1     179:0    0 232.2G  0 disk 
├─mmcblk1p1 179:1    0   256M  0 part /boot
└─mmcblk1p2 179:2    0 231.9G  0 part /nix/store
                                      /

artemis: RE your past problems with libtool cross-compiling on Gentoo. I think I found the issue: if you run nix itself in a containerized environment nix silently falls back into the mode without a sandbox enabled (due to a sandbox-fallback = true) and happily runs unsandboxed builds in /tmp. ALl the bianries in /usr/bin and whatnot are available to the builds and this impurity contaminates the environemtn with /usr/lib library search paths breaks the builds.

The easy way to check it is to set sandbox-fallback = false in /etc/nix/nix.conf, restart nix-daemon and try to build something. If it fails that means you have been using unsandboxed builds.

In reply to @trofi:matrix.org
What environment did you use to run nix? Real machine, a VM or some container?