$ ls /sys/class/pci_bus/
0000:00  0000:01  0001:00  0001:01

In reply to @alex:tunstall.xyz
On my system (vendor kernel, not 6.11), it shows up under 0001:00.

What branch of the vendor kernel are you using? I'm building the kernel right now and I have this:

  boot.kernelPackages = let
    starfive_pkg = { lib, fetchurl, buildLinux, ... }@args:
      buildLinux (args // rec {
        version = "6.10.0";
        modDirVersion = version;

        src = fetchurl {
          url = "https://github.com/starfive-tech/linux/archive/37087c6cd7f818990c3c37d2e3cb01b05fc8bb69.tar.gz";
          hash = "sha256-n3By/goN6+SEjd7a8zirhqTZyb6qvqZPDb9TYd4riQI=";
        };

        kernelPatches = [];

        structuredExtraConfig = with lib.kernel; {
          PINCTRL_STARFIVE_JH7110_SYS = yes;
          SERIAL_8250_DW = yes;
        };

        extraMeta.branch = "esmil_starlight";
      } // (args.argsOverride or {}));
  in pkgs.recurseIntoAttrs (pkgs.linuxPackagesFor (pkgs.callPackage starfive_pkg {}));

I went based on activity on GitHub.

[  431.435107] rcu: rcu_sched kthread timer wakeup didn't happen for 100268 jiffies! g4449 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[  431.450921] rcu:     Possible timer handling issue on cpu=0 timer-softirq=1268
[  431.462411] rcu: rcu_sched kthread starved for 100276 jiffies! g4449 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[  431.477377] rcu:     Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[  431.490929] rcu: RCU grace-period kthread stack dump:
[  431.500539] task:rcu_sched       state:R stack:0     pid:17    ppid:2      flags:0x00000000
[  431.513528] Call Trace:
[  431.520563] [<ffffffff80e9db9e>] __schedule+0x37c/0xafc
[  431.530394] [<ffffffff80e9e376>] schedule+0x58/0xf2
[  431.539818] [<ffffffff80ea4d2e>] schedule_timeout+0x92/0x18e
[  431.549966] [<ffffffff800bacc2>] rcu_gp_fqs_loop+0x2f8/0x3fa
[  431.560048] [<ffffffff800bde90>] rcu_gp_kthread+0x132/0x178
[  431.569996] [<ffffffff800422be>] kthread+0xe8/0x108
[  431.579180] [<ffffffff8000411a>] ret_from_fork+0xe/0x20

This isn't good, serial is filled with this.

Did alsa-firmware regress for anyone else or is it because of my unusual hostPlatform configuration?

configure: error: C compiler cannot create executables

Hello! Today I tried to flash image from Nick Cao on my VisionFive 2, but I’m getting weird errors on boot:
Can't set block device
Importing environment from mmc1 ...

Warning: Input data exceeds 1048576 bytes - truncated

Info: input data size = 1048578 = 0x100002

Error: "boot2" not defined

switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:3...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Card did not respond to voltage select! : -110
No EFI system partition
ethernet@16030000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@16040000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@16030000 Waiting for PHY auto negotiation to complete......... TIMEOUT !

I don’t have an Ethernet connection for this board, as I use wireless network. I tried to boot directly from mmc using boot_mmc0, but that also failed. I see this line:
libfdt fdt_check_header(): FDT_ERR_BADMAGIC

Does it mean that current image is broken?