You should be able to get it onto the network. If you can't, you could try getting it to log to the disk, but you're practically debugging blind without UART.

You're not booting from NVMe, are you? That doesn't work on some firmware versions (not properly configured to try NVMe).

Another thing to note is the selected boot mode. The vendor image is more tolerant and can probably boot in most modes, whereas some NixOS images need you to boot from flash (no firmware partition).

In reply to @hsngrmpf:matrix.org
Though there is no hdmi output on any image I tried so far. Maybe the hdmi on my board is broken

It's very likely that your kernel doesn't have a driver for the HDMI. Check the version and what patches are being applied on top.

See: https://rvspace.org/en/project/JH7110_Upstream_Plan

Fixed a bunch of cross build issue with python packages and got home-assistant almost running, but there is one I'm having trouble with wrapping my head around. The python bcrypt library just builds its shared object for x86 instead of riscv
Any ideas why?

> nix-build -A pkgsCross.riscv64.python3Packages.bcrypt
/nix/store/xfc8xssvq2vwcn6126ml3m6fkdd1gzw0-python3.12-bcrypt-4.2.0-riscv64-unknown-linux-gnu

> file /nix/store/xfc8xssvq2vwcn6126ml3m6fkdd1gzw0-python3.12-bcrypt-4.2.0-riscv64-unknown-linux-gnu/lib/python3.12/site-packages/bcrypt/_bcrypt.cpython-312-riscv64-linux-gnu.so
/nix/store/xfc8xssvq2vwcn6126ml3m6fkdd1gzw0-python3.12-bcrypt-4.2.0-riscv64-unknown-linux-gnu/lib/python3.12/site-packages/bcrypt/_bcrypt.cpython-312-riscv64-linux-gnu.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

Oh I just noticed it has the riscv64 target triple in the file name, very weird.

No, rustc is multi-targeting because it's based on LLVM. It's probably being given the wrong build flags.

Have you looked through the build logs for anything suspicious?

In reply to @rosscomputerguy:matrix.org
Why does nixos-hardware use the upstream u-boot instead of the Starfive fork for the VisionFive 2? I'm looking to boot from an NVME and it looks like using the fork would be better.

Upstream is usually a better choice when the hardware support you need has been merged.

For extra hardware, applying patches onto upstream is a decent option because it helps test the patches before they get merged.

In reply to @rosscomputerguy:matrix.org
After running into a few things which don't like RISC-V or cross compiling (lsd, nix output monitor, Prism Launcher, and lua-language-server), I seem to be making good progress.