RISC-V and VisionFive 2 testing #6212
Comments
MichaIng
added
Testing/testers required 🔽
RISC-V
MichaIng
changed the title
|
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! |
|
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 |
|
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 |
|
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? |
|
Ah okay, indeed not fixed when not using the 4 partitions layout and I'll check where the U-Boot environment is located, so we can adjust it to apply the needed |
|
@MichaIng Ethernet does not work on hardware rev 1.2a, but it works fine on 5.15.0-starfive kernel |
|
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 |
|
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 modeThe end is bringing up the second port formally, however, without cable attached and actual data transfer tested yet. |
|
A second eth is YT8512B, not YT8531 on rev 1.2a |
|
compare it with vendor's build: |
|
And did you test using Yours and our logs match nearly 100%, the only difference is that somehow in your case ifdown eth0
ifup eth0
sleep 5
ping 192.168.88.1And another test: Does it help to add |
|
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. |
|
Is this the same with the StarFive image? Support for this chip was added here: MichaIng/linux@e036d07 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 🤔. |
|
It works on Starfive. And I copied dtb from this release https://forum.rvspace.org/t/visionfive-2-debian-image-202302-released/2132 |
|
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 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 🤔. |
I moved a new kernel build in placeUpdate 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.debAdded builtin features
Added kernel modules
Turned builtins into modules
Removed kernel modules
Removed builtin features
Other changes
Check out the source code here: https://github.com/MichaIng/linux |
|
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>;
};
}; |
|
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). |
|
Okay, so all these 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 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 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 |
|
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. |
|
Hi, Have discover your image for SF2 but is not booting that strange and have the last firmware. Best Regards |
|
Hi, on https://dietpi.com/blog/?p=2629 you asked for reports of the experience. Thank you so much for adding support for the VisionFive 2, it works great! My only question is, is there a plan to enable CONFIG_EXT4_FS_SECURITY and CONFIG_BTRFS_FS_POSIX_ACL in the kernel build? My use case is a Samba server and my setup makes heavy use of xattr security attributes. |
|
I have a Star64 which I am trying to boot from emmc with the latest DietPi image. I did update the bootloader following the instructions at https://dietpi.com/blog/?p=2629 and I also used |
|
Do you have some logs to see where exactly it hangs? To be true, IIRC, I did not test with eMMC yet on Star64 |
I can't seem to get the whole log through screen for some reason, but only the last part. Hope it's enough Edit: I tried another distribution (NixOS) and I had a similar issue so it might not be related to DietPi. Still no idea what is happening. |
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 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? |
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 Edit: I see from the discussion above that the issue is known, but I tried to apply the default configuration with |
|
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: Comparison to
|
Is your VisionFive running the DietPi last image as-is or updated with 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. |
|
Also, unrelated to the benchmark: graphical performances are awful, and I believe I am running on software rendering. I tried setting |
I have an image running which I flashed about 4 weeks ago and then always did |
My X11 on the VF2 in combination with xrdp runs quite smoothly and quick. |
I have the same.
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? |
|
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
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"
EndSectionThe The IMG driver version 1.19 is btw correct, matching the driver version shipped with our kernel build. |
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: 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 |
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/AGovernor N/A and no shown min/cur/max frequencies are the symptom. EDIT: Related kernel errors: 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 |
|
Jep, that missing commit was the fix. Uploaded into our APT repo. Just fix it via: apt update
apt upgrade |
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
The text was updated successfully, but these errors were encountered: