Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RISC-V and VisionFive 2 testing #6212

Open
MichaIng opened this issue Mar 4, 2023 · 98 comments
Open

RISC-V and VisionFive 2 testing #6212

MichaIng opened this issue Mar 4, 2023 · 98 comments
Assignees
Milestone

Comments

@MichaIng
Copy link
Owner

MichaIng commented Mar 4, 2023

Some software titles may not be supported on RISC-V in general, or because no RISC-V binaries or packages are provided yet. Most of these cases have been identified already and related software titles have been disabled for the RISC-V architecture for now.

Other software titles may only be unsupported on the particular VisionFive 2 SBC, or the kernel build we use. This is known for Docker, likely other container engines, the NFS server and the SMB client, but there may be more. We aim to generate own kernel builds, with added features the next week(s). Any help to create an rebase a fork on latest upstream Linux 5.15 is highly appreciated.

Again other software titles may not be supported with latest PHP, Python and other runtime environments and libraries, provided by Debian Sid. The RISC-V architecture is not yet officially supported by Debian, but only with the dedicated Debian ports repository and Debian Sid/unstable suite. Currently, this mostly equals Bookworm, which is the reason DietPi identifies as this. A list of software titles tested on Bookworm can be found here: https://github.com/MichaIng/DietPi/wiki/Debian-Bookworm-testing

As an introduction, read our blog post: https://dietpi.com/blog/?p=2629

@MichaIng MichaIng added this to the v8.15 milestone Mar 4, 2023
@MichaIng MichaIng changed the title RISC-V and VisionFive 2 testing issue RISC-V and VisionFive 2 testing Mar 5, 2023
@MichaIng MichaIng pinned this issue Mar 5, 2023
@lgray
Copy link

lgray commented Mar 10, 2023

Hi, just updated the bootloader and got dietpi running on my VF2, thanks a lot for this! One first major issue is that I only see half the amount of RAM that's available on my board (8 GB model). If I use the starfivetech debian image the full amount shows up, but both armbian and dietpi show half that! Any pointers would be greatly appreciated!

@MichaIng
Copy link
Owner Author

Thanks for the info, I read about this on https://forum.rvspace.org. @StephanStS your's is definitely a 4 GiB model, right?

I did already rebase the kernel onto latest upstream 5.15.y, which only required trivial conflict resolving. Will try a build later today. Then will have a look at known fixes for HDMI, e.g. here: https://github.com/hexdump0815/linux-starfive-visionfive2-kernel/tree/main/misc.vf2/patches

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 10, 2023

Have you updated the SPI bootloader? Some open issues state that it has been fixed since a while:

apt install mtd-utils
curl -fLO 'https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.10.4/u-boot-spl.bin.normal.out'
curl -fLO 'https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.10.4/visionfive2_fw_payload.img'
flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
flashcp -v visionfive2_fw_payload.img /dev/mtd1
rm u-boot-spl.bin.normal.out visionfive2_fw_payload.img

@lgray
Copy link

lgray commented Mar 10, 2023

Yes I updated the bootloader and fw-payload before installing dietpi. What's the best way I can check the versions of uboot / fw-payload just to make sure?

@MichaIng
Copy link
Owner Author

Ah okay, indeed not fixed when not using the 4 partitions layout and uEnv.txt to run different boot commands: starfive-tech/VisionFive2#20 (comment)

I'll check where the U-Boot environment is located, so we can adjust it to apply the needed visionfive2_mem_set and also enable eMMC boot (which AFAIK currently does not work).

@MichaIng MichaIng modified the milestones: v8.15, v8.16 Mar 11, 2023
@congocongo
Copy link

@MichaIng Ethernet does not work on hardware rev 1.2a, but it works fine on 5.15.0-starfive kernel

@MichaIng
Copy link
Owner Author

Many thanks for testing and reporting. Did you test both Ethernet ports? It works fine on revision 1.3 here, but not sure whether on both Ethernet ports. @StephanStS could you test switching the port, after

sed -i 's/eth0/eth1/' /etc/network/interfaces

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 13, 2023

And to compare:

root@DietPi:~# dmesg | grep eth
[    0.645534] starfive-eth-plat 16030000.ethernet: User ID: 0x41, Synopsys ID: 0x52
[    0.645573] starfive-eth-plat 16030000.ethernet:     DWMAC4/5
[    0.645596] starfive-eth-plat 16030000.ethernet: DMA HW capability register supported
[    0.645623] starfive-eth-plat 16030000.ethernet: RX Checksum Offload Engine supported
[    0.645648] starfive-eth-plat 16030000.ethernet: Wake-Up On Lan supported
[    0.645741] starfive-eth-plat 16030000.ethernet: TSO supported
[    0.645764] starfive-eth-plat 16030000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    0.645793] starfive-eth-plat 16030000.ethernet: Enabled L3L4 Flow TC (entries=1)
[    0.645821] starfive-eth-plat 16030000.ethernet: Enabled RFS Flow TC (entries=8)
[    0.645848] starfive-eth-plat 16030000.ethernet: TSO feature enabled
[    0.645869] starfive-eth-plat 16030000.ethernet: Using 40 bits DMA width
[    0.877423] starfive-eth-plat 16040000.ethernet: User ID: 0x41, Synopsys ID: 0x52
[    0.877461] starfive-eth-plat 16040000.ethernet:     DWMAC4/5
[    0.877483] starfive-eth-plat 16040000.ethernet: DMA HW capability register supported
[    0.877509] starfive-eth-plat 16040000.ethernet: RX Checksum Offload Engine supported
[    0.877535] starfive-eth-plat 16040000.ethernet: Wake-Up On Lan supported
[    0.877620] starfive-eth-plat 16040000.ethernet: TSO supported
[    0.877642] starfive-eth-plat 16040000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    0.877670] starfive-eth-plat 16040000.ethernet: Enabled L3L4 Flow TC (entries=1)
[    0.877698] starfive-eth-plat 16040000.ethernet: Enabled RFS Flow TC (entries=8)
[    0.877724] starfive-eth-plat 16040000.ethernet: TSO feature enabled
[    0.877745] starfive-eth-plat 16040000.ethernet: Using 40 bits DMA width
[   12.274068] starfive-eth-plat 16030000.ethernet eth0: PHY [stmmac-0:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[   12.275607] starfive-eth-plat 16030000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   12.276592] starfive-eth-plat 16030000.ethernet eth0: No Safety Features support found
[   12.276644] starfive-eth-plat 16030000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[   12.277839] starfive-eth-plat 16030000.ethernet eth0: configuring for phy/rgmii-id link mode
[   14.364137] starfive-eth-plat 16030000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[71598.171890] starfive-eth-plat 16040000.ethernet eth1: PHY [stmmac-1:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[71598.172518] starfive-eth-plat 16040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[71598.281235] starfive-eth-plat 16040000.ethernet eth1: No Safety Features support found
[71598.281284] starfive-eth-plat 16040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[71598.282447] starfive-eth-plat 16040000.ethernet eth1: configuring for phy/rgmii-id link mode

The end is bringing up the second port formally, however, without cable attached and actual data transfer tested yet.

@congocongo
Copy link

congocongo commented Mar 13, 2023

A second eth is YT8512B, not YT8531 on rev 1.2a

Linux DietPi 5.15.98 #1 SMP Fri Mar 10 18:44:22 CET 2023 riscv64 GNU/Linux

[    0.513157] starfive-eth-plat 16030000.ethernet: User ID: 0x41, Synopsys ID: 0x52
[    0.513196] starfive-eth-plat 16030000.ethernet: 	DWMAC4/5
[    0.513219] starfive-eth-plat 16030000.ethernet: DMA HW capability register supported
[    0.513245] starfive-eth-plat 16030000.ethernet: RX Checksum Offload Engine supported
[    0.513271] starfive-eth-plat 16030000.ethernet: Wake-Up On Lan supported
[    0.513363] starfive-eth-plat 16030000.ethernet: TSO supported
[    0.513387] starfive-eth-plat 16030000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    0.513416] starfive-eth-plat 16030000.ethernet: Enabled L3L4 Flow TC (entries=1)
[    0.513444] starfive-eth-plat 16030000.ethernet: Enabled RFS Flow TC (entries=8)
[    0.513470] starfive-eth-plat 16030000.ethernet: TSO feature enabled
[    0.513492] starfive-eth-plat 16030000.ethernet: Using 40 bits DMA width
[    0.746781] starfive-eth-plat 16040000.ethernet: User ID: 0x41, Synopsys ID: 0x52
[    0.746818] starfive-eth-plat 16040000.ethernet: 	DWMAC4/5
[    0.746840] starfive-eth-plat 16040000.ethernet: DMA HW capability register supported
[    0.746866] starfive-eth-plat 16040000.ethernet: RX Checksum Offload Engine supported
[    0.746891] starfive-eth-plat 16040000.ethernet: Wake-Up On Lan supported
[    0.746975] starfive-eth-plat 16040000.ethernet: TSO supported
[    0.746997] starfive-eth-plat 16040000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    0.747025] starfive-eth-plat 16040000.ethernet: Enabled L3L4 Flow TC (entries=1)
[    0.747052] starfive-eth-plat 16040000.ethernet: Enabled RFS Flow TC (entries=8)
[    0.747079] starfive-eth-plat 16040000.ethernet: TSO feature enabled
[    0.747100] starfive-eth-plat 16040000.ethernet: Using 40 bits DMA width
[   11.065020] starfive-eth-plat 16030000.ethernet eth0: PHY [stmmac-0:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[   11.065868] starfive-eth-plat 16030000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   11.066855] starfive-eth-plat 16030000.ethernet eth0: No Safety Features support found
[   11.066907] starfive-eth-plat 16030000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[   11.068055] starfive-eth-plat 16030000.ethernet eth0: configuring for phy/rgmii-id link mode
[   14.364477] starfive-eth-plat 16030000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
[  233.172002] starfive-eth-plat 16030000.ethernet eth0: Link is Down
[  246.153305] starfive-eth-plat 16030000.ethernet eth0: PHY [stmmac-0:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[  246.153580] starfive-eth-plat 16030000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[  246.153882] starfive-eth-plat 16030000.ethernet eth0: No Safety Features support found
[  246.153901] starfive-eth-plat 16030000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[  246.153917] starfdive-eth-plat 16030000.ethernet eth0: configuring for phy/rgmii-id link mode

root@DietPi:/etc/network# ethtool eth0
Settings for eth0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	master-slave cfg: preferred slave
	master-slave status: slave
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	MDI-X: Unknown
	Supports Wake-on: ug
	Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
	Link detected: yes


root@DietPi:/etc/network# ethtool eth1
netlink error: Device or resource busy
netlink error: Device or resource busy
netlink error: Device or resource busy
netlink error: Device or resource busy
netlink error: Device or resource busy
No data available


root@DietPi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6c:cf:39:00:21:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.88.60/24 brd 192.168.88.255 scope global eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 6c:cf:39:00:21:84 brd ff:ff:ff:ff:ff:ff


root@DietPi:~# ip r
default via 192.168.88.1 dev eth0 onlink 
192.168.88.0/24 dev eth0 proto kernel scope link src 192.168.88.60 

root@DietPi:~# ping 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
From 192.168.88.60 icmp_seq=1 Destination Host Unreachable
From 192.168.88.60 icmp_seq=2 Destination Host Unreachable
From 192.168.88.60 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.88.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4120ms
pipe 3

@congocongo
Copy link

congocongo commented Mar 13, 2023

compare it with vendor's build:

Linux starfive 5.15.0-starfive #1 SMP Mon Feb 27 14:03:14 EST 2023 riscv64 GNU/Linux

[    1.278085] starfive-eth-plat 16030000.ethernet: force_sf_dma_mode is ignored if force_thresh_dma_mode is set.
[    1.289466] starfive-eth-plat 16030000.ethernet: User ID: 0x41, Synopsys ID: 0x52
[    1.297753] starfive-eth-plat 16030000.ethernet: 	DWMAC4/5
[    1.303804] starfive-eth-plat 16030000.ethernet: DMA HW capability register supported
[    1.312449] starfive-eth-plat 16030000.ethernet: RX Checksum Offload Engine supported
[    1.321094] starfive-eth-plat 16030000.ethernet: Wake-Up On Lan supported
[    1.328585] starfive-eth-plat 16030000.ethernet: TSO supported
[    1.335016] starfive-eth-plat 16030000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    1.344241] starfive-eth-plat 16030000.ethernet: Enabled Flow TC (entries=1)
[    1.352023] starfive-eth-plat 16030000.ethernet: TSO feature enabled
[    1.359036] starfive-eth-plat 16030000.ethernet: Using 40 bits DMA width
[    1.647333] starfive-eth-plat 16040000.ethernet: force_sf_dma_mode is ignored if force_thresh_dma_mode is set.
[    1.658771] starfive-eth-plat 16040000.ethernet: User ID: 0x41, Synopsys ID: 0x52
[    1.667055] starfive-eth-plat 16040000.ethernet: 	DWMAC4/5
[    1.673105] starfive-eth-plat 16040000.ethernet: DMA HW capability register supported
[    1.681747] starfive-eth-plat 16040000.ethernet: RX Checksum Offload Engine supported
[    1.690393] starfive-eth-plat 16040000.ethernet: Wake-Up On Lan supported
[    1.697881] starfive-eth-plat 16040000.ethernet: TSO supported
[    1.704313] starfive-eth-plat 16040000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    1.713547] starfive-eth-plat 16040000.ethernet: Enabled Flow TC (entries=1)
[    1.721327] starfive-eth-plat 16040000.ethernet: TSO feature enabled
[    1.728342] starfive-eth-plat 16040000.ethernet: Using 40 bits DMA width
[    6.890982] starfive-eth-plat 16030000.ethernet end0: renamed from eth0
[    6.946865] starfive-eth-plat 16040000.ethernet end1: renamed from eth1
[   13.887244] starfive-eth-plat 16030000.ethernet end0: PHY [stmmac-0:00] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[   13.898627] starfive-eth-plat 16030000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   13.912425] starfive-eth-plat 16030000.ethernet end0: No Safety Features support found
[   13.920408] starfive-eth-plat 16030000.ethernet end0: IEEE 1588-2008 Advanced Timestamp supported
[   13.943766] starfive-eth-plat 16030000.ethernet end0: configuring for phy/rgmii-id link mode
[   13.974442] starfive-eth-plat 16040000.ethernet end1: PHY [stmmac-1:00] driver [YT8512B Ethernet] (irq=POLL)
[   13.985089] starfive-eth-plat 16040000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-0
[   13.993446] starfive-eth-plat 16040000.ethernet end1: No Safety Features support found
[   13.993461] starfive-eth-plat 16040000.ethernet end1: IEEE 1588-2008 Advanced Timestamp supported
[   14.034533] starfive-eth-plat 16040000.ethernet end1: configuring for phy/rgmii-id link mode
[   18.088672] starfive-eth-plat 16030000.ethernet end0: Link is Up - 1Gbps/Full - flow control off

root@starfive:~# ethtool end0
Settings for end0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	master-slave cfg: preferred slave
	master-slave status: slave
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	MDI-X: Unknown
	Supports Wake-on: ug
	Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
	Link detected: yes


root@starfive:~# ethtool end1
Settings for end1:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 10Mb/s
	Duplex: Half
	Auto-negotiation: on
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	MDI-X: Unknown
	Supports Wake-on: ug
	Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
	Link detected: no

root@starfive:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6c:cf:39:00:21:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.88.60/24 brd 192.168.88.255 scope global dynamic noprefixroute end0
       valid_lft 540sec preferred_lft 540sec
3: end1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 6c:cf:39:00:21:84 brd ff:ff:ff:ff:ff:ff


root@starfive:~# ip r
default via 192.168.88.1 dev end0 proto dhcp src 192.168.88.60 metric 100 
192.168.88.0/24 dev end0 proto kernel scope link src 192.168.88.60 metric 100 

root@starfive:~# ping 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=0.360 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=0.363 ms
64 bytes from 192.168.88.1: icmp_seq=3 ttl=64 time=0.397 ms
^C
--- 192.168.88.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2052ms
rtt min/avg/max/mdev = 0.360/0.373/0.397/0.016 ms

@MichaIng
Copy link
Owner Author

And did you test using eth1 on your image?

Yours and our logs match nearly 100%, the only difference is that somehow in your case eth0 is identified as 100Mbps adapter and in our case as well as in your case with vendor kernel as 1Gbps adapter (which is of course correct). I have somehow the impression that there is an issue with dealing our link attributes with the router. Also the link goes down after some minutes, while is is up at first. Just to rule that out, does it help to detach and reattach the cable, then:

ifdown eth0
ifup eth0
sleep 5
ping 192.168.88.1

And another test: Does it help to add stmmaceth=chain_mode:1 to the end of the kernel command-line (append line) in /boot/extlinux/extlinux.conf and reboot to apply the change? I didn't fully understand the purpose of this option and on our test system it didn't make any difference (I also ran benchmarks), so I removed it compared to StarFive's Debian images.

@congocongo
Copy link

I just copied fresh device tree from vendor's image and now it works. Only first eth is avaliable, looks like there is no driver for YT8512B in kernel. rev 1.2a was supplied with YT8531(1Gb)/YT8512B(100Mb) PHY on board.

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 14, 2023

Is this the same with the StarFive image?

Support for this chip was added here: MichaIng/linux@e036d07
Then, without removing the support declaration at the top of the file, "inverted" here (whatever this means, since code was only moved around, not really removed, from what I see): MichaIng/linux@3c9ef2d

These commits are from StarFive kernel repository, so should be the same there.

Also the device tree should be identical, at least the raw dts is 🤔.

@congocongo
Copy link

congocongo commented Mar 15, 2023

It works on Starfive. And I copied dtb from this release https://forum.rvspace.org/t/visionfive-2-debian-image-202302-released/2132
from folder 202302

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 15, 2023

I've no idea then. The device tree source and the Ethernet driver source are 100% identical and it works well on V1.3. If on your V1.2 neither of both Ethernet adapters work with the device tree from our build, something in mainline Linux 5.15.y must have changed, outside of those drivers and device tree, but affecting them on build time. And this must affect V1.2 only, V1.3 not, even for the Ethernet adapter which uses the same chip. Very strange.

Just to be sure: You copied the jh7110-visionfive-v2.dtb (and only this!) from the latest StarFive Debian image and installed it on our image to /usr/lib/linux-image-visionfive2/starfive/jh7110-visionfive-v2.dtb? Did you run a diff on them to see whether there is an actual difference? Not sure whether builds are reproducible and may contain compiler/environment related differences though.

And also please assure you can reliably trigger the issue by swapping the device trees back and forth and that it is not a coincidence while the issue is unrelated to the device tree, as searching through possibly affecting upstream 5.15.y commits is time consuming as I have no idea where to start 🤔.

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 15, 2023

I moved a new kernel build in place

Update can be applied via:

cd /tmp
curl -O 'https://dietpi.com/downloads/binaries/linux-image-visionfive2.deb'
dpkg -i linux-image-visionfive2.deb
rm linux-image-visionfive2.deb

Added builtin features

  • Framebuffer device for console on HDMI
  • Fixed DRM for X11/desktop sessions on HDMI
  • IPv6
  • zswap with zstd as default compression
  • binfmt_misc: automatic emulation handler selection, e.g. using Box64 (if installed) when executing x86_64 binaries

Added kernel modules

  • F2FS and Brtfs filesystem types
  • NFS kernel server
  • SMB/CIFS client/mounts
  • tun/OpenVPN
  • WireGuard
  • zram with zstd as default compression

Turned builtins into modules

  • Bluetooth
  • WiFi
  • Plan 9
  • Camera drivers
  • overlayfs
  • exFAT
  • NTFS
  • NFS client/mounts
  • nf_tables packet duplication and FIB lookups
  • Goodix and Tinker FT5406 touchscreens

Removed kernel modules

  • StarFive mailbox

Removed builtin features

  • VirtIO drives, used by virtual machines
  • /dev/pty* legacy pseudo terminal devices
  • /dev/hvc* hypervisor virtual console devices

Other changes

  • Kernel modules are now xz-compressed
  • Default CPU governor is now schedutil (only relevant until dietpi-preboot or cpufrequtils change it in userland)
  • Default hostname is now DietPi (only relevant until the init system changes it in userland)
  • Solved a kernel error at boot, happened as we do not use an initramfs
  • Fixed U-Boot env SPI address in device tree, so fw_printenv now generally can find it at /dev/mtd2

Check out the source code here: https://github.com/MichaIng/linux
I'll keep rebasing all changes onto latest upstream Linux 5.15.y release as well merging commits from the StarFive repo.

@congocongo
Copy link

congocongo commented Mar 16, 2023

Will try this kernel. Maybe better to wait when they send patches to upstream? They are actively do it now:

https://lore.kernel.org/lkml/?q=JH71x0

btw I decompiled dtb files:

--- jh7110-visionfive-v2.dtb.dietpi.dts	2023-03-16 16:26:13.199095247 +0300
+++ jh7110-visionfive-v2.dtb.starfive.dts	2023-03-16 16:28:22.569130546 +0300
@@ -347,18 +347,6 @@
 			phandle = <0x2f>;
 		};
 
-		multi-phyctrl@10210000 {
-			compatible = "starfive,phyctrl";
-			reg = <0x00 0x10210000 0x00 0x10000>;
-			phandle = <0x3a>;
-		};
-
-		pcie1-phyctrl@10220000 {
-			compatible = "starfive,phyctrl";
-			reg = <0x00 0x10220000 0x00 0x10000>;
-			phandle = <0x3f>;
-		};
-
 		stg_syscon@10240000 {
 			compatible = "syscon";
 			reg = <0x00 0x10240000 0x00 0x1000>;
@@ -414,7 +402,7 @@
 			#clock-cells = <0x01>;
 			power-domains = <0x1d 0x04>;
 			status = "okay";
-			phandle = <0x47>;
+			phandle = <0x45>;
 		};
 
 		clock-controller@19810000 {
@@ -822,7 +810,7 @@
 			};
 
 			pcie0_perst_default {
-				phandle = <0x3d>;
+				phandle = <0x3c>;
 
 				perst-pins {
 					starfive,pins = <0x1a>;
@@ -834,7 +822,7 @@
 			};
 
 			pcie0_perst_active {
-				phandle = <0x3e>;
+				phandle = <0x3d>;
 
 				perst-pins {
 					starfive,pins = <0x1a>;
@@ -846,7 +834,7 @@
 			};
 
 			pcie0_wake_default {
-				phandle = <0x3b>;
+				phandle = <0x3a>;
 
 				wake-pins {
 					starfive,pins = <0x20>;
@@ -857,7 +845,7 @@
 			};
 
 			pcie0_clkreq_default {
-				phandle = <0x3c>;
+				phandle = <0x3b>;
 
 				clkreq-pins {
 					starfive,pins = <0x1b>;
@@ -868,7 +856,7 @@
 			};
 
 			pcie1_perst_default {
-				phandle = <0x42>;
+				phandle = <0x40>;
 
 				perst-pins {
 					starfive,pins = <0x1c>;
@@ -880,7 +868,7 @@
 			};
 
 			pcie1_perst_active {
-				phandle = <0x43>;
+				phandle = <0x41>;
 
 				perst-pins {
 					starfive,pins = <0x1c>;
@@ -892,7 +880,7 @@
 			};
 
 			pcie1_wake_default {
-				phandle = <0x40>;
+				phandle = <0x3e>;
 
 				wake-pins {
 					starfive,pins = <0x15>;
@@ -903,7 +891,7 @@
 			};
 
 			pcie1_clkreq_default {
-				phandle = <0x41>;
+				phandle = <0x3f>;
 
 				clkreq-pins {
 					starfive,pins = <0x1d>;
@@ -1077,7 +1065,7 @@
 			};
 
 			inno_hdmi-pins {
-				phandle = <0x51>;
+				phandle = <0x4f>;
 
 				inno_hdmi-scl {
 					starfive,pins = <0x00>;
@@ -1133,7 +1121,7 @@
 			#gpio-cells = <0x02>;
 			ngpios = <0x04>;
 			status = "okay";
-			phandle = <0x5a>;
+			phandle = <0x58>;
 		};
 
 		tmon@120e0000 {
@@ -1279,7 +1267,7 @@
 
 					endpoint {
 						remote-endpoint = <0x24>;
-						phandle = <0x4e>;
+						phandle = <0x4c>;
 					};
 				};
 			};
@@ -1299,17 +1287,10 @@
 
 					endpoint {
 						remote-endpoint = <0x26>;
-						phandle = <0x4f>;
+						phandle = <0x4d>;
 					};
 				};
 			};
-
-			touchscreen@14 {
-				compatible = "goodix,gt911";
-				reg = <0x14>;
-				irq-gpios = <0x25 0x1e 0x00>;
-				reset-gpios = <0x25 0x1f 0x00>;
-			};
 		};
 
 		i2c@12030000 {
@@ -1620,10 +1601,10 @@
 			ethernet-phy@0 {
 				rxc_dly_en = <0x01>;
 				tx_delay_sel_fe = <0x05>;
-				tx_delay_sel = <0x0a>;
-				tx_inverted_10 = <0x01>;
-				tx_inverted_100 = <0x01>;
-				tx_inverted_1000 = <0x01>;
+				tx_delay_sel = <0x09>;
+				tx_inverted_10 = <0x00>;
+				tx_inverted_100 = <0x00>;
+				tx_inverted_1000 = <0x00>;
 			};
 		};
 
@@ -1660,10 +1641,10 @@
 
 			ethernet-phy@1 {
 				tx_delay_sel_fe = <0x05>;
-				tx_delay_sel = <0x00>;
+				tx_delay_sel = <0x09>;
 				rxc_dly_en = <0x00>;
-				tx_inverted_10 = <0x01>;
-				tx_inverted_100 = <0x01>;
+				tx_inverted_10 = <0x00>;
+				tx_inverted_100 = <0x00>;
 				tx_inverted_1000 = <0x00>;
 			};
 		};
@@ -1713,8 +1694,8 @@
 			compatible = "starfive,jh7110-tdm";
 			reg = <0x00 0x10090000 0x00 0x1000>;
 			reg-names = "tdm";
-			clocks = <0x1b 0xb8 0x1b 0xb9 0x1b 0xba 0x10 0x1b 0xbb 0x1b 0x11>;
-			clock-names = "clk_tdm_ahb\0clk_tdm_apb\0clk_tdm_internal\0clk_tdm_ext\0clk_tdm\0mclk_inner";
+			clocks = <0x1b 0x09 0x1b 0xb8 0x1b 0x0c 0x1b 0xb9 0x1b 0xba 0x10 0x1b 0xbb 0x1b 0x11>;
+			clock-names = "clk_ahb0\0clk_tdm_ahb\0clk_apb0\0clk_tdm_apb\0clk_tdm_internal\0clk_tdm_ext\0clk_tdm\0mclk_inner";
 			resets = <0x1c 0x69 0x1c 0x6b 0x1c 0x6a>;
 			reset-names = "tdm_ahb\0tdm_apb\0tdm_rst";
 			dmas = <0x32 0x14 0x01 0x32 0x15 0x01>;
@@ -1749,7 +1730,7 @@
 			status = "okay";
 			pinctrl-names = "default";
 			pinctrl-0 = <0x33>;
-			phandle = <0x57>;
+			phandle = <0x55>;
 		};
 
 		i2stx@100c0000 {
@@ -1766,8 +1747,8 @@
 			compatible = "starfive,jh7110-pdm";
 			reg = <0x00 0x100d0000 0x00 0x1000>;
 			reg-names = "pdm";
-			clocks = <0x1b 0xb6 0x1b 0xb7 0x1b 0x12 0x11>;
-			clock-names = "pdm_mclk\0pdm_apb\0clk_mclk\0mclk_ext";
+			clocks = <0x1b 0xb6 0x1b 0x0c 0x1b 0xb7 0x1b 0x12 0x11>;
+			clock-names = "pdm_mclk\0clk_apb0\0pdm_apb\0clk_mclk\0mclk_ext";
 			resets = <0x1c 0x61 0x1c 0x62>;
 			reset-names = "pdm_dmic\0pdm_apb";
 			#sound-dai-cells = <0x00>;
@@ -1776,8 +1757,8 @@
 		i2srx_mst@100e0000 {
 			compatible = "starfive,jh7110-i2srx-master";
 			reg = <0x00 0x100e0000 0x00 0x1000>;
-			clocks = <0x1b 0x0c 0x1b 0xaf 0x1b 0xb0 0x1b 0xb2 0x1b 0xb3 0x1b 0xb5 0x1b 0x12 0x11>;
-			clock-names = "apb0\0i2srx_apb\0i2srx_bclk_mst\0i2srx_lrck_mst\0i2srx_bclk\0i2srx_lrck\0mclk\0mclk_ext";
+			clocks = <0x1b 0x0c 0x1b 0xaf 0x1b 0xb0 0x1b 0xb2 0x1b 0xb3 0x1b 0xb5>;
+			clock-names = "apb0\0i2srx_apb\0i2srx_bclk_mst\0i2srx_lrck_mst\0i2srx_bclk\0i2srx_lrck";
 			resets = <0x1c 0x63 0x1c 0x64>;
 			reset-names = "rst_apb_rx\0rst_bclk_rx";
 			dmas = <0x32 0x18 0x01>;
@@ -1790,8 +1771,8 @@
 		i2srx_3ch@100e0000 {
 			compatible = "starfive,jh7110-i2srx\0snps,designware-i2s";
 			reg = <0x00 0x100e0000 0x00 0x1000>;
-			clocks = <0x1b 0x0c 0x1b 0xaf 0x1b 0x10 0x1b 0x11 0x1b 0xb0 0x1b 0xb2 0x1b 0xb3 0x1b 0xb5 0x1b 0x12 0x11 0x0e 0x0f>;
-			clock-names = "apb0\03ch-apb\0audioroot\0mclk-inner\0bclk_mst\03ch-lrck\0rx-bclk\0rx-lrck\0mclk\0mclk_ext\0bclk-ext\0lrck-ext";
+			clocks = <0x1b 0x0c 0x1b 0xaf 0x1b 0x10 0x1b 0x11 0x1b 0xb0 0x1b 0xb2 0x1b 0xb3 0x1b 0xb5 0x1b 0x12 0x0e 0x0f>;
+			clock-names = "apb0\03ch-apb\0audioroot\0mclk-inner\0bclk_mst\03ch-lrck\0rx-bclk\0rx-lrck\0mclk\0bclk-ext\0lrck-ext";
 			resets = <0x1c 0x63 0x1c 0x64>;
 			dmas = <0x32 0x18 0x01>;
 			dma-names = "rx";
@@ -1815,7 +1796,7 @@
 			status = "okay";
 			pinctrl-names = "default";
 			pinctrl-0 = <0x36>;
-			phandle = <0x54>;
+			phandle = <0x52>;
 		};
 
 		i2stx_4ch1@120c0000 {
@@ -1856,7 +1837,7 @@
 			compatible = "starfive,jh7110-pwmdac-dit";
 			#sound-dai-cells = <0x00>;
 			status = "okay";
-			phandle = <0x58>;
+			phandle = <0x56>;
 		};
 
 		dmic_codec {
@@ -1989,7 +1970,6 @@
 			reg-names = "reg\0config";
 			device_type = "pci";
 			starfive,stg-syscon = <0x1e 0xc0 0xc4 0x130 0x1b8>;
-			starfive,phyctrl = <0x3a 0x28 0x80>;
 			bus-range = <0x00 0xff>;
 			ranges = <0x82000000 0x00 0x30000000 0x00 0x30000000 0x00 0x8000000 0xc3000000 0x09 0x00 0x09 0x00 0x00 0x40000000>;
 			msi-parent = <0x03>;
@@ -2005,9 +1985,9 @@
 			clock-names = "noc\0tl\0axi_mst0\0apb";
 			status = "okay";
 			pinctrl-names = "default\0perst-default\0perst-active";
-			pinctrl-0 = <0x3b 0x3c>;
-			pinctrl-1 = <0x3d>;
-			pinctrl-2 = <0x3e>;
+			pinctrl-0 = <0x3a 0x3b>;
+			pinctrl-1 = <0x3c>;
+			pinctrl-2 = <0x3d>;
 		};
 
 		pcie@2C000000 {
@@ -2019,7 +1999,6 @@
 			reg-names = "reg\0config";
 			device_type = "pci";
 			starfive,stg-syscon = <0x1e 0x270 0x274 0x2e0 0x368>;
-			starfive,phyctrl = <0x3f 0x28 0x80>;
 			bus-range = <0x00 0xff>;
 			ranges = <0x82000000 0x00 0x38000000 0x00 0x38000000 0x00 0x8000000 0xc3000000 0x09 0x80000000 0x09 0x80000000 0x00 0x40000000>;
 			msi-parent = <0x03>;
@@ -2035,9 +2014,9 @@
 			clock-names = "noc\0tl\0axi_mst0\0apb";
 			status = "okay";
 			pinctrl-names = "default\0perst-default\0perst-active";
-			pinctrl-0 = <0x40 0x41>;
-			pinctrl-1 = <0x42>;
-			pinctrl-2 = <0x43>;
+			pinctrl-0 = <0x3e 0x3f>;
+			pinctrl-1 = <0x40>;
+			pinctrl-2 = <0x41>;
 		};
 
 		mailbox@0 {
@@ -2050,26 +2029,26 @@
 			interrupts = <0x1a 0x1b>;
 			#mbox-cells = <0x02>;
 			status = "okay";
-			phandle = <0x44>;
+			phandle = <0x42>;
 		};
 
 		mailbox_client@0 {
 			compatible = "starfive,mailbox-test";
 			mbox-names = "rx\0tx";
-			mboxes = <0x44 0x00 0x01 0x44 0x01 0x00>;
+			mboxes = <0x42 0x00 0x01 0x42 0x01 0x00>;
 			status = "okay";
 		};
 
 		display-subsystem {
 			compatible = "starfive,jh7110-display\0verisilicon,display-subsystem";
-			ports = <0x45>;
+			ports = <0x43>;
 			status = "okay";
 		};
 
 		dssctrl@295B0000 {
 			compatible = "starfive,jh7110-dssctrl\0verisilicon,dss-ctrl\0syscon";
 			reg = <0x00 0x295b0000 0x00 0x90>;
-			phandle = <0x46>;
+			phandle = <0x44>;
 		};
 
 		tda988x_pin {
@@ -2092,8 +2071,8 @@
 
 					endpoint@0 {
 						reg = <0x00>;
-						remote-endpoint = <0x45>;
-						phandle = <0x48>;
+						remote-endpoint = <0x43>;
+						phandle = <0x46>;
 					};
 				};
 			};
@@ -2101,11 +2080,11 @@
 
 		dc8200@29400000 {
 			compatible = "starfive,jh7110-dc8200\0verisilicon,dc8200";
-			verisilicon,dss-syscon = <0x46>;
+			verisilicon,dss-syscon = <0x44>;
 			reg = <0x00 0x29400000 0x00 0x100 0x00 0x29400800 0x00 0x2000 0x00 0x17030000 0x00 0x1000>;
 			interrupts = <0x5f>;
 			status = "okay";
-			clocks = <0x1b 0x3c 0x1b 0x3a 0x1b 0x3e 0x1b 0x3d 0x47 0x07 0x47 0x08 0x47 0x04 0x47 0x05 0x47 0x06 0x1b 0x3e 0x47 0x09 0x18 0x47 0x01 0x47 0x27 0x47 0x28>;
+			clocks = <0x1b 0x3c 0x1b 0x3a 0x1b 0x3e 0x1b 0x3d 0x45 0x07 0x45 0x08 0x45 0x04 0x45 0x05 0x45 0x06 0x1b 0x3e 0x45 0x09 0x18 0x45 0x01 0x45 0x27 0x45 0x28>;
 			clock-names = "noc_disp\0vout_src\0top_vout_axi\0top_vout_ahb\0pix_clk\0vout_pix1\0axi_clk\0core_clk\0vout_ahb\0vout_top_axi\0vout_top_lcd\0hdmitx0_pixelclk\0dc8200_pix0\0dc8200_pix0_out\0dc8200_pix1_out";
 			resets = <0x1c 0x2b 0x1c 0xe0 0x1c 0xe1 0x1c 0xe2 0x1c 0x1a>;
 			reset-names = "rst_vout_src\0rst_axi\0rst_ahb\0rst_core\0rst_noc_disp";
@@ -2116,20 +2095,20 @@
 
 				endpoint@0 {
 					reg = <0x00>;
-					remote-endpoint = <0x48>;
-					phandle = <0x45>;
+					remote-endpoint = <0x46>;
+					phandle = <0x43>;
 				};
 
 				endpoint@1 {
 					reg = <0x01>;
-					remote-endpoint = <0x49>;
-					phandle = <0x52>;
+					remote-endpoint = <0x47>;
+					phandle = <0x50>;
 				};
 
 				endpoint@2 {
 					reg = <0x02>;
-					remote-endpoint = <0x4a>;
-					phandle = <0x4b>;
+					remote-endpoint = <0x48>;
+					phandle = <0x49>;
 				};
 			};
 		};
@@ -2146,8 +2125,8 @@
 					reg = <0x00>;
 
 					endpoint {
-						remote-endpoint = <0x4b>;
-						phandle = <0x4a>;
+						remote-endpoint = <0x49>;
+						phandle = <0x48>;
 					};
 				};
 
@@ -2155,8 +2134,8 @@
 					reg = <0x01>;
 
 					endpoint {
-						remote-endpoint = <0x4c>;
-						phandle = <0x50>;
+						remote-endpoint = <0x4a>;
+						phandle = <0x4e>;
 					};
 				};
 			};
@@ -2165,13 +2144,13 @@
 		mipi-dphy@295e0000 {
 			compatible = "starfive,jh7110-mipi-dphy-tx\0m31,mipi-dphy-tx";
 			reg = <0x00 0x295e0000 0x00 0x10000>;
-			clocks = <0x47 0x0e>;
+			clocks = <0x45 0x0e>;
 			clock-names = "dphy_txesc";
 			resets = <0x1c 0xea 0x1c 0xeb>;
 			reset-names = "dphy_sys\0dphy_txbytehs";
 			#phy-cells = <0x00>;
 			status = "okay";
-			phandle = <0x4d>;
+			phandle = <0x4b>;
 		};
 
 		mipi@295d0000 {
@@ -2179,11 +2158,11 @@
 			reg = <0x00 0x295d0000 0x00 0x10000>;
 			interrupts = <0x62>;
 			reg-names = "dsi";
-			clocks = <0x47 0x0b 0x47 0x0a 0x47 0x0d 0x47 0x0c>;
+			clocks = <0x45 0x0b 0x45 0x0a 0x45 0x0d 0x45 0x0c>;
 			clock-names = "sys\0apb\0txesc\0dpi";
 			resets = <0x1c 0xe3 0x1c 0xe4 0x1c 0xe5 0x1c 0xe6 0x1c 0xe7 0x1c 0xe8>;
 			reset-names = "dsi_dpi\0dsi_apb\0dsi_rxesc\0dsi_sys\0dsi_txbytehs\0dsi_txesc";
-			phys = <0x4d>;
+			phys = <0x4b>;
 			phy-names = "dphy";
 			status = "okay";
 
@@ -2198,13 +2177,13 @@
 
 					endpoint@0 {
 						reg = <0x00>;
-						remote-endpoint = <0x4e>;
+						remote-endpoint = <0x4c>;
 						phandle = <0x24>;
 					};
 
 					endpoint@1 {
 						reg = <0x01>;
-						remote-endpoint = <0x4f>;
+						remote-endpoint = <0x4d>;
 						phandle = <0x26>;
 					};
 				};
@@ -2213,8 +2192,8 @@
 					reg = <0x01>;
 
 					endpoint {
-						remote-endpoint = <0x50>;
-						phandle = <0x4c>;
+						remote-endpoint = <0x4e>;
+						phandle = <0x4a>;
 					};
 				};
 			};
@@ -2225,14 +2204,14 @@
 			reg = <0x00 0x29590000 0x00 0x4000>;
 			interrupts = <0x63>;
 			status = "okay";
-			clocks = <0x47 0x11 0x47 0x0f 0x47 0x10 0x18>;
+			clocks = <0x45 0x11 0x45 0x0f 0x45 0x10 0x18>;
 			clock-names = "sysclk\0mclk\0bclk\0pclk";
 			resets = <0x1c 0xe9>;
 			reset-names = "hdmi_tx";
 			#sound-dai-cells = <0x00>;
 			pinctrl-names = "default";
-			pinctrl-0 = <0x51>;
-			phandle = <0x55>;
+			pinctrl-0 = <0x4f>;
+			phandle = <0x53>;
 
 			port {
 				#address-cells = <0x01>;
@@ -2240,8 +2219,8 @@
 
 				endpoint@0 {
 					reg = <0x00>;
-					remote-endpoint = <0x52>;
-					phandle = <0x49>;
+					remote-endpoint = <0x50>;
+					phandle = <0x47>;
 				};
 			};
 		};
@@ -2262,18 +2241,18 @@
 			simple-audio-card,dai-link@0 {
 				reg = <0x00>;
 				format = "i2s";
-				bitclock-master = <0x53>;
-				frame-master = <0x53>;
+				bitclock-master = <0x51>;
+				frame-master = <0x51>;
 				mclk-fs = <0x100>;
 				status = "okay";
 
 				cpu {
-					sound-dai = <0x54>;
-					phandle = <0x53>;
+					sound-dai = <0x52>;
+					phandle = <0x51>;
 				};
 
 				codec {
-					sound-dai = <0x55>;
+					sound-dai = <0x53>;
 				};
 			};
 		};
@@ -2294,17 +2273,17 @@
 			simple-audio-card,dai-link@0 {
 				reg = <0x00>;
 				format = "left_j";
-				bitclock-master = <0x56>;
-				frame-master = <0x56>;
+				bitclock-master = <0x54>;
+				frame-master = <0x54>;
 				status = "okay";
 
 				cpu {
-					sound-dai = <0x57>;
-					phandle = <0x56>;
+					sound-dai = <0x55>;
+					phandle = <0x54>;
 				};
 
 				codec {
-					sound-dai = <0x58>;
+					sound-dai = <0x56>;
 				};
 			};
 		};
@@ -2343,7 +2322,7 @@
 			firmware-name = "e24_elf";
 			irq-mode = <0x01>;
 			mbox-names = "tx\0rx";
-			mboxes = <0x44 0x00 0x02 0x44 0x02 0x00>;
+			mboxes = <0x42 0x00 0x02 0x42 0x02 0x00>;
 			#address-cells = <0x01>;
 			#size-cells = <0x01>;
 			ranges = <0xc0000000 0x00 0xc0000000 0x200000>;
@@ -2356,7 +2335,7 @@
 		xrp@0 {
 			compatible = "cdns,xrp";
 			reg = <0x00 0x10230000 0x00 0x10000 0x00 0x10240000 0x00 0x10000>;
-			memory-region = <0x59>;
+			memory-region = <0x57>;
 			clocks = <0x1b 0xbe>;
 			clock-names = "core_clk";
 			resets = <0x1c 0x81 0x1c 0x82>;
@@ -2406,7 +2385,7 @@
 
 	memory@40000000 {
 		device_type = "memory";
-		reg = <0x00 0x40000000 0x01 0x00>;
+		reg = <0x00 0x40000000 0x02 0x00>;
 	};
 
 	reserved-memory {
@@ -2430,7 +2409,7 @@
 
 		xrpbuffer@f0000000 {
 			reg = <0x00 0xf0000000 0x00 0x1ffffff 0x00 0xf2000000 0x00 0x1000 0x00 0xf2001000 0x00 0xfff000 0x00 0xf3000000 0x00 0x1000>;
-			phandle = <0x59>;
+			phandle = <0x57>;
 		};
 	};
 
@@ -2438,7 +2417,7 @@
 		compatible = "gpio-leds";
 
 		led-ack {
-			gpios = <0x5a 0x03 0x00>;
+			gpios = <0x58 0x03 0x00>;
 			color = <0x02>;
 			function = "heartbeat";
 			linux,default-trigger = "heartbeat";
@@ -2449,6 +2428,6 @@
 	gpio-restart {
 		compatible = "gpio-restart";
 		gpios = <0x25 0x23 0x00>;
-		priority = <0xa0>;
+		priority = <0xe0>;
 	};
 };

@congocongo
Copy link

congocongo commented Mar 17, 2023

I tried 5.15.102 from your deb package. Still wrong ethphy settings in dtb file. btw if I'll copy starfive's dtb file it will broke pcie driver, your dtb settings for pcie is correct (on 5.15.102).

@MichaIng
Copy link
Owner Author

Okay, so all these phandle properties are internal addresses generated at build time, counted up for every added node. Since our device tree has two additional nodes (probably related to MichaIng/linux@85034f1), the addresses are up to 2 larger. You can also see the addresses with <...> on other properties changed the same way as the related phandle property it aims to point to.

Interesting is this part:

@@ -1620,10 +1601,10 @@
 			ethernet-phy@0 {
 				rxc_dly_en = <0x01>;
 				tx_delay_sel_fe = <0x05>;
-				tx_delay_sel = <0x0a>;
-				tx_inverted_10 = <0x01>;
-				tx_inverted_100 = <0x01>;
-				tx_inverted_1000 = <0x01>;
+				tx_delay_sel = <0x09>;
+				tx_inverted_10 = <0x00>;
+				tx_inverted_100 = <0x00>;
+				tx_inverted_1000 = <0x00>;
 			};
 		};
 
@@ -1660,10 +1641,10 @@
 
 			ethernet-phy@1 {
 				tx_delay_sel_fe = <0x05>;
-				tx_delay_sel = <0x00>;
+				tx_delay_sel = <0x09>;
 				rxc_dly_en = <0x00>;
-				tx_inverted_10 = <0x01>;
-				tx_inverted_100 = <0x01>;
+				tx_inverted_10 = <0x00>;
+				tx_inverted_100 = <0x00>;
 				tx_inverted_1000 = <0x00>;
 			};
 		};

Our device tree matches StarFive sources: https://github.com/starfive-tech/linux/blob/JH7110_VisionFive2_devel/arch/riscv/boot/dts/starfive/jh7110-visionfive-v2.dtsi#L593-L619
These have been changed here: starfive-tech/linux@b516027b3e
and here: starfive-tech/linux@4ea57bb614
last November.

I am pretty disturbed by the fact that obviously the StarFive device tree (likely the whole kernel) does not match their kernel sources, respectively is older than the sources from last November. I also found the commit for the additional two nodes now, from last month: starfive-tech/linux@2757ebeaf3

The one commit even states that it is for JH7110B+YT8531PHY while YT8512B obviously requires the old values. So they broke it intentionally. Since their Debian image works on the new revision as well, not sure about the benefit of the new values, and especially not sure why they e.g. did not add a new device tree for A12 (as they exist for A10 and A11), or set those values somehow in the drivers/variable if possible, instead of fixed in the device tree.

Probably the A12 revision was so rare that it wasn't seen important to keep supporting it 🤔.

The issue may be reported here: https://github.com/starfive-tech/linux/issues
But lately StarFive is not reacting to issues or pull requests on their repo.

@MichaIng
Copy link
Owner Author

Since I found this valuable information, here the upstream plan and status page: https://rvspace.org/en/project/JH7110_Upstream_Plan

All upstream mails/patches are linked, transparent to follow, including suggested changes by reviewers etc. Very interesting and looks great how upstreaming all relevant parts is driven.

@MichaIng
Copy link
Owner Author

[    4.448283] Waiting for root device PARTUUID=5f3ba2fd-01...
[    4.623779] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 300000Hz, actual 298192HZ div = 83)
[    5.073774] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 200000Hz, actual 199596HZ div = 124)
[    5.523774] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 100000Hz, actual 99798HZ div = 248)

So the bootloader successfully loaded the kernel and everything, it boots and waits for the root partition, but it seems to have issues accessing it, resulting in step-wise downclocking of the slot frequency, but it seems to not succeed. I am on a trip at the moment, so cannot verify whether 5f3ba2fd-01 really is the correct PARTUUID, but based on the other error(s), I suppose so.

I find it always strange when the bootloader succeeds detecting a boot media, loading the kernel and device tree from its filesystem, but then the kernel fails to load the very same filesystem as rootfs. No idea what the reason for this can be, would be actually interesting to know in how far U-Boot and a full Linux kernel behave differently when accessing the media/partition/filesystem for their tasks, so that it can have this result.

Booting the very same image from SD card works?

@EnricoGhiorzi
Copy link

EnricoGhiorzi commented Mar 22, 2024

Booting the very same image from SD card works?

It actually did! I thought I tried it before, but apparently not, or I made some mistake.

I even managed to flash it to nvme and it's working very well. The only issue is that boot fails and it requires me to run nvme_boot manually from the serial console, so it's quite annoying. Here is a log:

Edit: I see from the discussion above that the issue is known, but I tried to apply the default configuration with fw_config and update uboot as reccommended, and it did not work.

Ethernet MAC1 address: 6c:cf:39:00:75:5e
--------EEPROM INFO--------
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
In:    serial
Out:   serial
Err:   serial
Model: StarFive VisionFive V2
Net:   eth0: ethernet@16030000, eth1: ethernet@16040000
Hit any key to stop autoboot:  0
starfive_pcie pcie@2B000000: Port link down.
starfive_pcie pcie@2B000000: Starfive PCIe bus probed.
PCI: Failed autoconfig bar 10
starfive_pcie pcie@2C000000: Port link up.
starfive_pcie pcie@2C000000: Starfive PCIe bus probed.
PCI: Failed autoconfig bar 10
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
Device 0: Vendor: 0x144d Rev: 2B2QEXM7 Prod: S58SNM0W627999K
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
... is now current device
Try booting from NVME0 ...
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
## Warning: Input data exceeds 1048576 bytes - truncated
## Info: input data size = 1048578 = 0x100002
## Error: "boot2" not defined
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
Device 0: Vendor: 0x144d Rev: 2B2QEXM7 Prod: S58SNM0W627999K
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
... is now current device
Try booting from NVME0 ...
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
## Warning: Input data exceeds 1048576 bytes - truncated
## Info: input data size = 1048578 = 0x100002
## Error: "boot2" not defined
Card did not respond to voltage select! : -110
Card did not respond to voltage select! : -110
Tring booting distro ...
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
Device 0: Vendor: 0x144d Rev: 2B2QEXM7 Prod: S58SNM0W627999K
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
... is now current device
Try booting from NVME0 ...
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
## Warning: defaulting to text format
## Warning: Input data exceeds 1048576 bytes - truncated
## Info: input data size = 1048578 = 0x100002
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
** Invalid partition 3 **
Couldn't find partition nvme 0:3
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
fatwrite - write file into a dos filesystem
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
Usage:
fatwrite <interface> <dev[:part]> <addr> <filename> [<bytes> [<offset>]]
    - write file 'filename' from the address 'addr' in RAM
      to 'dev' on 'interface'
Retrieving file: /extlinux/extlinux.conf
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
Error reading config file
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
Device 0: Vendor: 0x144d Rev: 2B2QEXM7 Prod: S58SNM0W627999K
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
... is now current device
Try booting from NVME0 ...
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
## Warning: defaulting to text format
## Warning: Input data exceeds 1048576 bytes - truncated
## Info: input data size = 1048578 = 0x100002
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
** Invalid partition 3 **
Couldn't find partition nvme 0:3
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
fatwrite - write file into a dos filesystem
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
Usage:
fatwrite <interface> <dev[:part]> <addr> <filename> [<bytes> [<offset>]]
    - write file 'filename' from the address 'addr' in RAM
      to 'dev' on 'interface'
Retrieving file: /extlinux/extlinux.conf
** Invalid partition 3 **
Couldn't find partition nvme 0:3
Can't set block device
Error reading config file
Card did not respond to voltage select! : -110
Card did not respond to voltage select! : -110
StarFive # run nvme_boot

@EnricoGhiorzi
Copy link

My Star64 system is underperforming in the DietPi benchmark: I get a CPU time of ~25/30s when it should be possible to reach ~12s. Memory speed and even the nvme speed seem to be much lower than the best results for Star64/VisionFive2 on the benchmark page. What could be causing this? I checked htop and it seems there are no background processes using up my CPU.

@StephanStS
Copy link
Collaborator

My Star64 system is underperforming in the DietPi benchmark: I get a CPU time of ~25/30s when it should be possible to reach ~12s. Memory speed and even the nvme speed seem to be much lower than the best results for Star64/VisionFive2 on the benchmark page. What could be causing this? I checked htop and it seems there are no background processes using up my CPU.

Data of my VisionFive 2:

Benchmarks completed:
- CPU performance : Duration = 12.22 seconds (lower is faster)
- CPU temps       : Idle = 59 °C | Full load = 65 °C
- RootFS I/O      : Write = 78 MiB/s | Read = 100 MiB/s
- RAM I/O         : Write = 371 MiB/s | Read = 1079 MiB/s

Comparison to https://dietpi.com/survey/#benchmark:

  • Performance is identical
  • Temperature of my VF2 is lower. I have a heat sink like shown there in the blog post
  • RootFS I/O of my VF2 is faster, I am running from a NVMe disk
  • RAM I/O is identical

@EnricoGhiorzi
Copy link

EnricoGhiorzi commented Apr 10, 2024

Data of my VisionFive 2:

Is your VisionFive running the DietPi last image as-is or updated with apt update && apt upgrade? I do have a large heat-sink (and indeed temperature is fine) and I run from a NVME disk, so it's very strange I get lower results both on CPU performance and RootFS I/O. RAM might not be the same on Star64 but still I get much lower results on RAM I/O:

Benchmarks completed:
- CPU performance : Duration = 27.04 seconds (lower is faster)
- CPU temps       : Idle = 39 °C | Full load = 40 °C
- RootFS I/O      : Write = 70 MB/s  | Read = 189 MB/s
- RAM I/O         : Write = 246 MB/s | Read = 615 MB/s

I see the best results for Star64 on the benchmark survey are aligned to those for VF2, while I am aligned to the worst results (which are worse by a lot) so I think there is a software issue somewhere.

@EnricoGhiorzi
Copy link

EnricoGhiorzi commented Apr 10, 2024

Also, unrelated to the benchmark: graphical performances are awful, and I believe I am running on software rendering. I tried setting PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 but it does not seem to make a difference, though to be fare https://docs.mesa3d.org/drivers/powervr.html says it supports BXS-4-64 but it does not mention the BXS-4-32 on the JH7110. Is there anything to be done about it?

@StephanStS
Copy link
Collaborator

Data of my VisionFive 2:

Is your VisionFive running the DietPi last image as-is or updated with apt update && apt upgrade? I do have a large heat-sink (and indeed temperature is fine) and I run from a NVME disk, so it's very strange I get lower results both on CPU performance and RootFS I/O. RAM might not be the same on Star64 but still I get much lower results on RAM I/O, something like 200/600 MiB/s if I remember correctly (will post results later).

I see the best results for Star64 on the benchmark survey are aligned to those for VF2, while I am aligned to the worst results (which are worse by a lot) so I think there is a software issue somewhere.

I have an image running which I flashed about 4 weeks ago and then always did apt update resp. apt upgrade.
My running kernel is 6.1.81.

2024-04-11 17:55:32 root@DietPi:~# uname -a
Linux DietPi 6.1.81 #1 SMP Sat Mar  9 21:40:38 UTC 2024 riscv64 GNU/Linux

@StephanStS
Copy link
Collaborator

Also, unrelated to the benchmark: graphical performances are awful, and I believe I am running on software rendering. I tried setting PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 but it does not seem to make a difference, though to be fare https://docs.mesa3d.org/drivers/powervr.html says it supports BXS-4-64 but it does not mention the BXS-4-32 on the JH7110. Is there anything to be done about it?

My X11 on the VF2 in combination with xrdp runs quite smoothly and quick.
What you could try is to uninstall X11, Xfce, xrdp (whatever you installed as GUI stuff) and reinstall it. Sometimes this helped on my system. Might be caused by the many updates I got via the upgrade procedure.

@EnricoGhiorzi
Copy link

My running kernel is 6.1.81.

I have the same.

My X11 on the VF2 in combination with xrdp runs quite smoothly and quick.

Remote desktop seems to work much better than normal desktop, that's weird. I suspect it's because the remote desktop screen is smaller then my screen (1080p vs 4K).

Benchmark stubbornly sits around 24-30s no matter what I do, I wonder whether the system is actually running fine and the benchmark is faulty. Are there other benchmarks to compare?

@MichaIng MichaIng modified the milestones: v9.3, v9.4 Apr 16, 2024
@MichaIng
Copy link
Owner Author

Generally it is known that there is no native GPU acceleration yet, respectively it is not great, when not compiling vendor Mesa/X/libs/software which make use of the driver.

@EnricoGhiorzi
PVR_I_WANT_A_BROKEN_VULKAN_DRIVER has only any effect when the PVR Vulkan API is actually used, which is, AFAIK not the case with X11 OOTB, is it? However, there are actually libs and configs provided by StarFive to make use of them:

I am not a great fan of putting a bunch of random non-packaged files onto our images, which are old, I cannot find any documentation for, don't know which ones are really needed for which particular application etc. However, it could be tested. I would start with the powervr-ddk, inspecting the content trying to load the used kernel modules and see whether the contained firmware is used/needed by them, have the libs prepared etc. There is however no X config contained. The other archive contains one:

# X.Org X server configuration file.

Section "Device"
	Identifier	"Video Device"
	Driver     	"modesetting"
	# Option		"Atomic"		"true"
	# Option		"NoCursor"		"true"
EndSection

Section "OutputClass"
	Identifier	"starfive display"
	MatchDriver	"starfive"
	Option		"PrimaryGPU"	"true"
EndSection

Section "Monitor"
	Identifier	"Monitor"
	# Option		"DPMS"			"false"
EndSection

Section "Screen"
	Identifier	"Screen"
	Monitor		"Monitor"
	Device		"Video Device"
EndSection

Section "ServerLayout"
	Identifier      "Server Layout"
	Screen          "Screen"
EndSection

Section "ServerFlags"
	Option		"DefaultServerLayout"	"Server Layout"

	# Enable support for DRM format modifiers
	# Option		"Debug"			"dmabuf_capable"

	# Disable screen blanking. Disable DPMS in the Monitor section as well.
	# Option		"BlankTime"		"35790"
	# Option		"StandbyTime"		"35790"
	# Option		"SuspendTime"		"35790"
	# Option		"OffTime"		"35790"
EndSection

The lib dirs of the archives contain many common graphics APIs, with most of them being symlink which invoke PVR, if I understand it correctly.

The IMG driver version 1.19 is btw correct, matching the driver version shipped with our kernel build.

@MichaIng MichaIng modified the milestones: v9.4, v9.5 May 13, 2024
@EnricoGhiorzi
Copy link

Generally it is known that there is no native GPU acceleration yet, respectively it is not great, when not compiling vendor Mesa/X/libs/software which make use of the driver.

@EnricoGhiorzi PVR_I_WANT_A_BROKEN_VULKAN_DRIVER has only any effect when the PVR Vulkan API is actually used, which is, AFAIK not the case with X11 OOTB, is it? However, there are actually libs and configs provided by StarFive to make use of them:

Honestly this seems beyond my technical skills, and I'd rather wait to get Mesa support.

Instead, I think I am having a more puzzling issue: I benchmarked the Star64 with sbc-bench v0.9.65 and I get:

Checking cpufreq OPP (sifive,u74-mc):

No cpufreq support available. Measured on cpu1: 748 MHz (749.093/748.959/748.806)

which makes me believe the cpu is only going half-speed. This checks with the DietPi benchmark taking around 24s, twice as I would expect. Any idea what might be going on? I have been observing this since installation v9.2 to the latest update v9.4.2

@MichaIng
Copy link
Owner Author

MichaIng commented May 18, 2024

No cpufreq support available.

Oh you are right. I am quite sure this did work before. Strange, I rebase the kernel onto latest StarFive VF2 and upstream 6.1 only, without any relevant conflict lately, AFAIK.

Can anyone with a VisionFive 2 check whether CPUFreq is gone there as well, with latest kernel package?

root@Star64:~# cpu

 ─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     riscv64
 Temperature  |     34 °C / 93 °F : Cool runnings
 Governor     |     N/A

Governor N/A and no shown min/cur/max frequencies are the symptom.

EDIT: Related kernel errors:

[   20.954189] platform cpufreq-dt: deferred probe pending
[   32.873425] rcu: INFO: rcu_sched self-detected stall on CPU
[   32.879039] rcu:     1-....: (2099 ticks this GP) idle=65a4/1/0x4000000000000002 softirq=1553/1553 fqs=889
[   32.888453]  (t=2100 jiffies g=-159 q=64 ncpus=4)
[   32.888469] CPU: 1 PID: 261 Comm: (udev-worker) Tainted: G         C         6.1.91 #1
[   32.888483] Hardware name: Pine64 Star64 (DT)
[   32.888492] epc : apply_relocate_add+0x10c/0x234
[   32.888517]  ra : apply_relocate_add+0x76/0x234
[   32.888534] epc : ffffffff80007d78 ra : ffffffff80007ce2 sp : ffffffc8189bbc10
[   32.888546]  gp : ffffffff817b5ce8 tp : ffffffd8c5e70000 t0 : 0000000000011f6a
[   32.888557]  t1 : ffffffff800079a4 t2 : 000000000000eed3 s0 : ffffffc8189bbcb0
[   32.888567]  s1 : ffffffc81995d078 a0 : 0000000000011f6a a1 : ffffffff01dd4000
[   32.888578]  a2 : ffffffff01f6405c a3 : 000000000001c07f a4 : ffffffff01ee25e2
[   32.888588]  a5 : 00000000001af1f0 a6 : 00000000000fffff a7 : ffffffff01f64060
[   32.888598]  s2 : ffffffc81995c778 s3 : ffffffff0220c080 s4 : 0000000000000017
[   32.888609]  s5 : fffffffffffff000 s6 : 0000000000000014 s7 : ffffffff81001548
[   32.888619]  s8 : ffffffc81964e2d8 s9 : ffffffc81995c878 s10: 0000000000011f6a
[   32.888629]  s11: 000000000001bf97 t3 : ffffffd8c81e2880 t4 : 00000000002a0be8
[   32.888640]  t5 : ffffffff01f6405c t6 : ffffffff023f2000
[   32.888649] status: 0000000200000120 badaddr: 0000000000000000 cause: 8000000000000005
[   32.888661] [<ffffffff80007d78>] apply_relocate_add+0x10c/0x234
[   32.888679] [<ffffffff80088b24>] load_module+0x14e2/0x1944
[   32.888695] [<ffffffff8008903a>] __do_sys_init_module+0xb4/0xea
[   32.888710] [<ffffffff80089160>] sys_init_module+0xc/0x14
[   32.888723] [<ffffffff80003a8e>] ret_from_syscall+0x0/0x2
[   33.390609] eric-tx CALL alloc_txring !!!!

The CPUFreq driver probe remains pending, and then a CPU stall happens.

EDIT2: I think I found it. The following commit was missing on the Star64 dts: starfive-tech/linux@2191d96
I generally reduced the diff between the two device trees, to get a better overview if the differences. What is left now makes mostly sense, like some touchscreen/DSI display related nodes, different model and LED node names, and Fishwaldo added some rfkill nodes, which do not hurt: MichaIng/linux@c12b670
Rebuilding and testing the new kernel package.

@MichaIng
Copy link
Owner Author

Jep, that missing commit was the fix. Uploaded into our APT repo. Just fix it via:

apt update
apt upgrade

@EnricoGhiorzi
Copy link

Star64 working fine on v.9.5-beta and even with the latest VisionFive2 uboot (v5.12.0). Any chance to get the newly supported 6.6.20 kernel?

@MichaIng
Copy link
Owner Author

MichaIng commented Jun 9, 2024

Great!

Any chance to get the newly supported 6.6.20 kernel?

Yes, I recognised it and will work on a migration our end the next weeks.

@MichaIng MichaIng modified the milestones: v9.5, v9.6 Jun 10, 2024
@MichaIng MichaIng modified the milestones: v9.6, v9.7 Jul 10, 2024
@MichaIng MichaIng modified the milestones: v9.7, v9.8 Aug 26, 2024
@tehinfidel
Copy link

tehinfidel commented Sep 8, 2024

In testing dietpi 9.7.1 with kernel 6.1.97 on Milk-V Mars (running the StarFive Vision 5 dietpi distribution -- it boots which is better than ubuntu -- but needs a bit of work on the module config as the Mars has no camera), I did some digging as docker was failing to come up. It seems the kernel is missing at least the modules: CONFIG_BRIDGE and CONFIG_BRIDGE_NETFILTER (and possibly CONFIG_BRIDGE_EBTABLES* and some related; I just compiled them all.)

I have not 100% confirmed this is the final RC, as I am having some difficulty exactly simulating the build environment, despite copying the running config from /proc/config.gz to a fresh linux-6.1.97 build directory and using cross-compilation to create the modules, I ran into unknown tracing symbols, so after disabling tracing, I'm now receiving an Oops upon modprobe br_netfilter.

I am sure I am not properly simulating the dietpi kernel build environment exactly correct.

  1. Is there a guide for any dietpi-specific instructions for the kernel build environment?
  2. Failing the above, during the next build run or 6.6.20 port mentioned above, can one attempt enabling CONFIG_BRIDGE, CONFIG_BRIDGE_NETFILTER, and CONFIG_BRIDGE_EBTABLES* as an attempt to get docker working?

Update 9/9:
In digging further, I have been able to successfully build the stp, llc, and bridge modules without kernel Oops, but
I believe the 6.1.97 kernel config was built via copying .config files from previous versions -- which makes sense and saves time when reconfiguring. However, when compiling against the updated .config file generated after make menuconfig, the functions stp_ext_add/del are not found, which appear to be enabled by the CONFIG_SKB_EXTENSIONS config setting, which is not present in /proc/config.gz file on the distributed kernel. Still digging, but I believe options to enable SKB (net/core/skbuff.c) have been changed from previous iterations of the kernel, and as such the currently distributed kernel does not have the necessary symbols:

[ 1666.979912] br_netfilter: Unknown symbol __skb_ext_del (err -2)
[ 1666.980012] br_netfilter: Unknown symbol skb_ext_add (err -2)

Update 9/10:
It appears that CONFIG_SKB_EXTENSIONS is automatically defined by other kernel options when one or more of several CONFIG_BRIDGE extensions are selected; I believe the issue when attempting to add the bridge modules is due to the linux-image-visionfive2:6.1.97-dietpi1 package not having the bridge modules selected originally, which makes sense. I'm attempting to recompile the entire kernel now.

(FTR, I realize that this comment is in relation to enabling bridging for docker on a different risc-v device, but using the distributed visionfive kernel. As I believe I've gotten the hang of compiling the same kernel as listed in this issue, I will move this to a general dietpi forum post shortly.)

@MichaIng MichaIng modified the milestones: v9.8, v9.9 Oct 18, 2024
@MichaIng MichaIng modified the milestones: v9.9, v9.10 Dec 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests