Help needed, my dtb file got overwritten

Since I tried to base my Arch Linux Image with VisionFive2 Software v2.8.0. Every time I boot the image, the file /boot/boot/dtbs/starfive/jh7110-visionfive-v2.dtb gets overwritten.

Before reboot:

root@starfive:/boot/boot/dtbs
# rm -rf sifive starfive

root@starfive:/boot/boot/dtbs
# cp -a 5.15.2-rt20-cwt9/* .

root@starfive:/boot/boot/dtbs
# md5sum starfive/jh7110-visionfive-v2.dtb *-cwt9/starfive/jh7110-visionfive-v2.dtb
99286979328534c3115fd12bfc0fdecb  starfive/jh7110-visionfive-v2.dtb
99286979328534c3115fd12bfc0fdecb  5.15.2-rt20-cwt9/starfive/jh7110-visionfive-v2.dtb

After reboot:

root@starfive:/boot/boot/dtbs
# md5sum starfive/jh7110-visionfive-v2.dtb *-cwt9/starfive/jh7110-visionfive-v2.dtb
ef0729d3b3678dd89adc8e0865a38ff3  starfive/jh7110-visionfive-v2.dtb
99286979328534c3115fd12bfc0fdecb  5.15.2-rt20-cwt9/starfive/jh7110-visionfive-v2.dtb

And then I tried to see what was changed:

root@starfive:/boot/boot/dtbs
# dtc -I dtb -O dts starfive/jh7110-visionfive-v2.dtb -o /tmp/now.dts 2>/dev/null

root@starfive:/boot/boot/dtbs
# dtc -I dtb -O dts 5.15.2-rt20-cwt9/starfive/jh7110-visionfive-v2.dtb -o /tmp/cwt9.dts 2>/dev/null

root@starfive:/boot/boot/dtbs
# diff -u /tmp/cwt9.dts /tmp/now.dts

And here the diff:

--- /tmp/cwt9.dts       2023-02-08 13:31:29.284983576 +0700
+++ /tmp/now.dts        2023-02-08 13:31:21.567837497 +0700
@@ -1611,10 +1611,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>;
                        };
                };

@@ -1651,10 +1651,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>;
                        };
                };
@@ -2395,7 +2395,7 @@

        memory@40000000 {
                device_type = "memory";
-               reg = <0x00 0x40000000 0x01 0x00>;
+               reg = <0x00 0x40000000 0x02 0x00>;
        };

        reserved-memory {

This might be the reason for the recent ethernet issues I’ve been having with my image.

2 Likes

set_fdt_distro=if test ${chip_vision} = A; then if test ${memory_size} = 200000000; then run chipa_gmac_set;run visionfive2_mem_set;fatwrite mmc ${fatbootpart} ${fdt_addr_r} ${bootdir}/dtbs/${fdtfile} ${filesize};else run chipa_gmac_set;run visionfive2_mem_set;fatwrite mmc ${fatbootpart} ${fdt_addr_r} ${bootdir}/dtbs/${fdtfile} ${filesize};fi;else run visionfive2_mem_set;fatwrite mmc ${fatbootpart} ${fdt_addr_r} ${bootdir}/dtbs/${fdtfile} ${filesize};fi;

From uboot’s printenv.

1 Like

Why it wants to do that for the board revision “A”?

Edit: Oh from the script, both revisions got overwritten?

No clue, but from a glance there’s an else, and another fatwrite.

I do not know where these variables are stored either. They’re either hardcoded into u-boot itself, or perhaps that’s what the W25X10CL SPI flash does store.

I had seen a document on the boot process a few days ago, but it’s from early 2022 i.e. a year ago, and very inaccurate from a glance. The page where it was just disappeared.

1 Like

Hmm.

We urgently need a relatively clean u-boot build, now.

1 Like

I absolutely agree, the uboot env is quite a mess…

For now: the env ist store on the same qspi flash as u-boot itself, the according region just isn’t exposed via the device tree…

I needed access to the u-boot env from linux, this might help understanding/fixing issues in u-boot without needing to connect to the uart: Accessing U-Boot env from linux

4 Likes

Upstream U-boot already accepted jh7110 support, you can try that.
https://patchwork.ozlabs.org/project/uboot/cover/20230329034224.26545-1-yanhong.wang@starfivetech.com/

Yes, looks like u-boot default script is overwriting the dtb file:

And the reason you see the difference is because:

I don’t think the fatwrite is really necessary here, and we probably should open a github issue against starfive

4 Likes

Upstream u-boot also modify dtb for multiple board revision support/ram size support and many boards are using this method. However, they didn’t modify dtb file, only data in ram passing to kernel. And sf’s upstream series won’t modify dtb file in storage device either.

2 Likes

Yes, it looks like a bug to me.

1 Like

tbh the upstream patch series looks pretty minimal compared to the currently used u-boot. there are init functions missing for the ethernet phy, usb,… i’d be interrested to know what works and what doesn’t with upstream u-boot but didn’t have time for it until now

@valium have you check upstream status page?
pcie: [v5,0/3] Add StarFive JH7110 PCIe drvier support - Patchwork
eth: [v3,00/11] Add ethernet driver for StarFive JH7110 SoC - Patchwork

no, i was reading the source on github…
thank you for the hint. I just glanced over the patch series and noticed that the eth patches also contain the memory size fixup via the function fdt_fixup_memory()
this looks like a really good idea but is nowhere to be found in their own repo on github.
Maybe i’ll build upstream u-boot with those series applied to test them.

1 Like

created an gh issue: Overwriting dtbs on storage devices · Issue #49 · starfive-tech/u-boot · GitHub
Feel free to comment on it.

@cwt it’s been a while, but if you still have this issue (and as a reference for others) you can run on the u-boot console

env set set_fdt_distro
env save

to completely disable this function or set it to only use part of it, e.g. without the fat write command

3 Likes