In reply to @alex:tunstall.xyz

There's the official documentation from the vendor and a few enthusiasts, but they're mostly for Debian.

For NixOS, there are a few repositories here and there that contain a bootable configuration. I've based my system configuration off of https://github.com/misuzu/nixos-vf2 (note that this was written for rev 1.3B; it has DTBs for other revisions, but might not work as well).

For NixOS, there are a few repositories here and there that contain a bootable configuration. I've based my system configuration off of https://github.com/misuzu/nixos-vf2

That's exactly the starting point I was looking for! Thank you!

note that this was written for rev 1.3B; it has DTBs for other revisions, but might not work as well

Good reminder about the split DTBs. From what I know, upstream u-boot will patch it on the fly but yes, for the moment, we need to explicitly set it.

In reply to @alex:tunstall.xyz
Given that you've (presumably) managed to boot Arch on the system, it should mostly be a matter of figuring out how to translate what you already know into NixOS configuration. The boot.* options should be of interest.

Yep, and I also have a working system (on a Pi with UEFI and tons of hacks). My confusion stems from the following wandering...

"If RISC-V isn't officially supported (yet), there should be a different repository I should point at, so I can get the RISC-V binaries from there."

That's why I asked here :)

In reply to @joepie91:pixie.town
Pratham Patel: I probably won't be able to help much since I know ~nothing about VF2, but here's some generic explanation that may or may not be a missing piece of understanding: Nix is at its core a build tool, and while most of its usage is for building packages for a system, there's no reason it has to be limited to that, and so it is also used as a build tool for the install image itself. essentially, the various ISOs that you can have for NixOS are "just" attributes of nixpkgs that you can evaluate and build like they are any other package. the architecture is an argument when initializing nixpkgs, though in this case I'm guessing you'd be cross-compiling so additional machinery (that I am not familiar with) may be necessary

In reply to @thefossguy:matrix.org

Yep, and I also have a working system (on a Pi with UEFI and tons of hacks). My confusion stems from the following wandering...

"If RISC-V isn't officially supported (yet), there should be a different repository I should point at, so I can get the RISC-V binaries from there."

That's why I asked here :)

NixOS is a source-based distribution: the Nixpkgs repository only specifies how to build packages (and provides an extensive x86_64 and aarch64 cache).

Not only that, but Nixpkgs has tools to change how packages are built, so if you find something that doesn't build, you can override it to fix it.

You'll find that on the latest version of nixos-unstable, a great deal of things already both cross-compile and natively compile to riscv64. It'll likely take several hours of compilation to build a complete system (esp. natively if your kernel doesn't support cpufreq scaling, since the default clock speed is 1GHz and not the full 1.5GHz), but as long as you're not hoping to use any Java packages or Haskell packages, most things will Just Work™.

In reply to @alex:tunstall.xyz

NixOS is a source-based distribution: the Nixpkgs repository only specifies how to build packages (and provides an extensive x86_64 and aarch64 cache).

Not only that, but Nixpkgs has tools to change how packages are built, so if you find something that doesn't build, you can override it to fix it.

You'll find that on the latest version of nixos-unstable, a great deal of things already both cross-compile and natively compile to riscv64. It'll likely take several hours of compilation to build a complete system (esp. natively if your kernel doesn't support cpufreq scaling, since the default clock speed is 1GHz and not the full 1.5GHz), but as long as you're not hoping to use any Java packages or Haskell packages, most things will Just Work™.

In reply to @alex:tunstall.xyz

NixOS is a source-based distribution: the Nixpkgs repository only specifies how to build packages (and provides an extensive x86_64 and aarch64 cache).

Not only that, but Nixpkgs has tools to change how packages are built, so if you find something that doesn't build, you can override it to fix it.

You'll find that on the latest version of nixos-unstable, a great deal of things already both cross-compile and natively compile to riscv64. It'll likely take several hours of compilation to build a complete system (esp. natively if your kernel doesn't support cpufreq scaling, since the default clock speed is 1GHz and not the full 1.5GHz), but as long as you're not hoping to use any Java packages or Haskell packages, most things will Just Work™.

In reply to @fgaz:matrix.org
by the way, I asked about risc-v ghc bindists here https://gitlab.haskell.org/ghc/ghc/-/issues/23519

Guess I'll have to keep trying to cross-compile then :(

(My last attempt at cross-compiling allocates 4GB of memory and then segfaults on startup.)

In reply to @thefossguy:matrix.org

Hello everyone, I am the "maintainer" of the unmaintained minimal Arch Linux image for the VisionFive 2. Recently I tried out NixOS and am using it on my Raspberry Pi as the "main computer" (my current x86 pc died so this is a temporary measure; but it works even with 'llvmpipe' because I'm using UEFI).

I came to know about the RISC-V effort and got curious. I was checking this issue on NixOS/nixpkgs and a thread mentioned about this IRC channel. So here I am.

Are there any "Here's how to get started on the VF2" guides?

I initially thought this was just for the HiFive Unmatched. Then I saw your youtube video and got some hope. Then I saw your repo and gave up all hope (because idk nix well enough; _yet_).

Since you are here, please accept my thank you :)    

In reply to @fgaz:matrix.org
the milkv pioneer crowfunding is out :O

It’s already in hands of some devs. One such is felixonmars, the guy behind the RISC-V port of Arch Linux. He got it up and running using the vendor 6.1 kernel.

If you have a Twitter acc, you can see this tweet: https://twitter.com/felixonmars/status/1675224365766705152

Has anyone worked out how to get the VF2 to run at 1.5GHz?

I'm using a kernel with the AXP15060 enabled and all the patches for PMIC and CPU freq applied, but the system still runs at 1GHz (the boot clock rate).

[nixos@nixos:/etc/nixos/nixos-vf2]$ sudo cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_{cur,max}_freq
1000000
1500000
[nixos@nixos:/etc/nixos/nixos-vf2]$ sudo cat /sys/devices/system/cpu/cpufreq/policy0/scaling_{driver,governor,cur_freq}
cpufreq-dt
performance
1500000

Also, the system isn't thermal throttling.

[nixos@nixos:/etc/nixos/nixos-vf2]$ cat /sys/class/thermal/thermal_zone0/temp
62769
[nixos@nixos:/etc/nixos/nixos-vf2]$ cat /sys/class/thermal/thermal_zone0/trip_point_0_{temp,type}
75000
passive

There isn't much in the kernel logs either.

axp20x-i2c 5-0036: AXP20x variant AXP15060 found
axp20x-i2c 5-0036: AXP20X driver loaded
[...]
cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 1000000 KHz, changing to: 1500000 KHz

In reply to @alex:tunstall.xyz

Has anyone worked out how to get the VF2 to run at 1.5GHz?

I'm using a kernel with the AXP15060 enabled and all the patches for PMIC and CPU freq applied, but the system still runs at 1GHz (the boot clock rate).

[nixos@nixos:/etc/nixos/nixos-vf2]$ sudo cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_{cur,max}_freq
1000000
1500000
[nixos@nixos:/etc/nixos/nixos-vf2]$ sudo cat /sys/devices/system/cpu/cpufreq/policy0/scaling_{driver,governor,cur_freq}
cpufreq-dt
performance
1500000

I've asked upstream because I couldn't work out what's wrong, inexperienced as I am at kernel hacking.

https://github.com/starfive-tech/VisionFive2/issues/55

In reply to @fgaz:matrix.org
sent an image.

Is that the devel branch kernel?

The CPU frequency shown is the max frequency, but is that also what you get for /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq?

Asking because I don't want to spend 10+ hours building the devel branch kernel (+ time needed to get it to build and work properly).