Flashcp => /dev/mtd0 2.11.5

[mzs]

Thanks so it works with sdcard.img but not starfive-jh7110-VF2-SD-wayland.img.

[philrandal]

I tried it from the wayland image first, without success. Doing it from sdcard.img worked, and the partition sizes had changed.

[omac777]

yes I am using starfive-jh7110-VF2-SD-wayland.img
oi oi ouch …so I’ll flash my spl and the payload in the mtd0 and mtd1 as they existed there before I erased them LOL

root@starfive:/home/user# flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 33/33 (100%)
Writing data: 129k/129k (100%)
Verifying data: 129k/129k (100%)

root@starfive:/home/user# flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 722/722 (100%)
Writing data: 2886k/2886k (100%)
Verifying data: 2886k/2886k (100%)

I was able to power/boot up after this. Phew.

[mzs]

@omac777

I hope I can power up and boot up ok after this.

Change the switches to boot from SDIO3.0 and it will read “spl” and “uboot” from the first two partitions of the SD card. But you did erase your u-boot environmental variables. Worst case in the das u-boot environment do a env default -a -f followed by a env save and that will repopulate it with the default configuration.

[mzs]

Speed reading a lot of source code, it looks like both documents are out of date with what should be in the source code.

Offset	Length	Description	Partition	GUID
0x0	0x4400	GUID Partition Table	not applicable	not applicable
0x4400	0xFBC00	SPL	/dev/mtd0	5B193300-FC78-40CD-8002-E86C45580B47
0xF0000	0x10000	U-Boot environment variables	last 64KiB of /dev/mtd0	if it had a partition 3DE21764-95BD-54BD-A5C3-4ABE786F38A8
0x100000	0x400000	fw_payload.img (OpenSBI + U-Boot)	/dev/mtd1	2E54B353-1271-4842-806F-E436D6AF6985
0x500000	0xB00000	Linux Filesystem	/dev/mtd2	0FC63DAF-8483-4772-8E79-3D69D8477DE4

# apt install mtd-utils
# mtdpart del /dev/mtd 2
# mtdpart del /dev/mtd 1
# mtdpart del /dev/mtd 0
# mtdpart add /dev/mtd "loader1" 0x4400 0xFBC00
# mtdpart add /dev/mtd "loader2"0x100000 0x400000
# mtdpart add /dev/mtd "system" 0x500000 0xB00000
# wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/u-boot-spl.bin.normal.out
# wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/visionfive2_fw_payload.img
# flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
# flashcp -v visionfive2_fw_payload.img  /dev/mtd1

My guess is that 11MiB filesystem will be used to boot from NMVe, or USB, storage in the near future.

I still do not think that the above procedure is enough because the BootROM in the SoC finds the SPL by searching the GPT (GUID Partition Table) for the correct GUID “5B193300-FC78-40CD-8002-E86C45580B47”, and I do not know how to set that from UNIX, anyone know ? If /dev/mtd was accessible could I just modify the partition type (GUID) as root with fdisk /dev/mtd or gdisk /dev/mtd, or would that cause problems ?

[Stromkiller]

Hello all,

Thanks for all of the replies.
I see there are still uncertainties about this issue.
Any idea when we might have a definitive solution?

Regards

Aubrey

[Stat_headcrabed]

Seems u-boot itself could handle this?

u-boot/u-boot/blob/master/doc/README.gpt

https://lists.denx.de/pipermail/u-boot/2017-May/thread.html#290700
https://lists.denx.de/pipermail/u-boot/2017-May/290702.html

[Stromkiller]

Still in the dark. I will wait.

Aubrey

[philrandal]

In the 2.11.5 release notes:

“Expand the MTD0 partition size in QSPI flash…”

As I said before, updating the flash worked for me from the sdcard.img, but didn’t from the full wayland image.

Hopefully this will get resolved in the next set of updates.

[omac777]

The other uncertainty I have is why are there two different images from Starfive?
Shouldn’t the sdcard.img be the basis on which the wayland was built?
Why are the kernel include constants/environment variables different to the point I couldn’t modify the mtd device from the wayland image?

Please consider:

• continuous integration workflow steps to assert mtd device can be added/deleted with an image before release
• continuous integration workflow steps to assert gpu drivers, opencl and cuda are installed, configured, tested and benchmarked before release
• provide some reports/logs about that as well to in order for developers/backers/users to see progress and easily see where tests fail

I’m sure a lot of people here would love to do more tests and report their success and failures. It’s important the Starfive team empowers developers/backers/users to help report bugs and the surrounding details. It would be good to provide us with something like Phoronix test suite but specifically testing against VF2 specific capabilities and benchmarking VF2 specific capabilities as well. Is there a github project that covers this area anywhere? I haven’t delved too much into all the VF2 github stuff, but to save some time is there anybody here that is aware these aspects of the project and could provide some light on these matters?

Thank you in advance

[Stat_headcrabed]

I noticed that your partition layout is different from others’. What did you do to that before?

[Stromkiller]

I am not sure if I understand your English.
Up to this point, I have not altered any /dev/mt* partition.

Aubrey

[strlcat]

If there is no way to programmatically tell Linux kernel a change (think you have no CONFIG_MTD_PARTITIONED_MASTER kernel config enabled), all you can do:

1. Install device-tree-compiler or any other package that contains dtc executable
   1a. Alternatively, you can get one from any Linux’s tree as scripts/dtc/dtc after make menuconfig or make prepare or make dtbs (but you shall do this on the board itself, so it’s compiler will build right RISC-V version of dtc executable for you)
2. Decompile current running kernel dtb into source: dtc -I dtb -O dts /sys/firmware/fdt -o /root/vf2.dts. Ignore warnings.
3. Edit /root/vf2.dts with your favourite text editor, go to sections which says nor-flash@0 {
4. Under partitions { subsection next to nor-flash@0 {, keep three first lines intact, erase any subsections till end of partitions { section, the }; closing so it will look like this:

partitions {
    compatible = "fixed-partitions";
    #address-cells = <0x01>;
    #size-cells = <0x01>;
    /* blank area */
};

5. Make this section look like this now:

partitions {
    compatible = "fixed-partitions";
    #address-cells = <0x01>;
    #size-cells = <0x01>;

    spl@0 {
        reg = <0x00 0x80000>;
    };

    env@f0000 {
        reg = <0xf0000 0x10000>;
    };

    uboot@100000 {
        reg = <0x100000 0x400000>;
    };

    bootdata@500000 {
        reg = <0x500000 0xb00000>;
    };

    flashall@0 {
        reg = <0x00 0x1000000>;
    };
};

Notice I added bootdata and flashall sections just if anyone curious would also be able to use bootdata (11M of emptinness atm, useful for putting FIT images of tiny linuxes+initramfs+dtb) or backup whole QSPI by reading flashall which spans entire QSPI 16M space.
6. Recompile back: dtc -I dts -O dtb vf2.dts -o vf2-patched.dtb
7. Place vf2-patched.dtb in place of original in your /boot, or use it as an alternate version of original dtb by editing boot configs (YMMW).
8. Reboot and see the change.

Maybe DTB overlays (so-called DTBO) could help with situation, but I had no experience in getting them up.

HTH

[Stat_headcrabed]

Are you sure this won’t break partition GUID? starfive are using GPT over MTD for spi flash.

[strlcat]

Really?

Sorry, I thought QSPI NOR is just old fashioned “offset,size” partitioning (at least this is what I’ve got on boards shipped on December). My bad then.

[dtometzki]

Hello together,

my way was change:

admin@debian:~/linux$ git show 69121125a7a3
commit 69121125a7a3ef69044cc47eeb48577151f3c32a
Author: ziv.xu <ziv.xu@starfive.com>
Date:   Tue Mar 7 18:03:51 2023 +0800

    jh7110.dsti :expand mtd0 partition
    
    expand mtd0 partition
    
    Signed-off-by: ziv.xu <ziv.xu@starfive.com>

diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index 7696b0751a59..1841430670fa 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -365,7 +365,7 @@ partitions {
                                        #size-cells = <1>;
 
                                        spl@0 {
-                                               reg = <0x0 0x20000>;
+                                               reg = <0x0 0x40000>;
                                        };
                                        uboot@100000 {
                                                reg = <0x100000 0x300000>;

And rebuild the kernel or rebuild jh7110-visionfive-v2.dtb because jh7110.dtsi is included in it.
And then replace the file in /boot/dtbs/starfive/ and after reboot flashcp works again.

Please check git commit 69121125a7a3 is all what was done.

[Stat_headcrabed]

@mzs @strlcat Seems JH7110 doesn’t rely on GPT, that gpt code is for JH7100. We could just directly modify partition table in dts and flashcp.

[MichaIng]

The kernel just needs a fix to have /dev/mtd2 pointing to the correct address for the env: JH7110_VisionFive2_devel: jh7110.dtsi has wrong U-Boot fwenv data pointer · Issue #81 · starfive-tech/linux · GitHub

The original issue flashing SPL to /dev/mtd0 is known and the latest StarFive kernel is needed to solve it. No manual partitioning required.

[valium]

I think thats not true for the qspi flash.

As far as i understand it the GPT stuff is used, but contrary to what @mzs wrote i think its for loding SPL and u-boot from eMMC or SDCards directly.
The partitioning @strlcat provided is right for the qspi, env contains the u-boot env (confirmed) and works booting from Flash. No issues using this, just need to be aware that with this /dev/mtd1 is the u-boot en not u-boot itself. so to update u-boot you need to write it to /dev/mtd2 with the label u-boot

[mzs]

@valium

As far as i understand it the GPT stuff is used, but contrary to what @mzs wrote i think its for loding SPL and u-boot from eMMC or SDCards directly.

Here is an example, which is from a different U74-MC RISC-V core with a different boot ROM, where flash does use GPT: https://forums.sifive.com/t/booting-from-flash/5104.

But you are right, it really depends on what is hard-coded inside the boot ROM. StarFive have swapped the GPT Type for SPI+U-Boot and U-boot+OpenSBI to be the opposite of what SiFive use. So maybe it does not use GPT Types, even as a fallback, for QSPI flash. But why then does the addresses for QSPI NOR flash not start at 0 bytes instead of 17K, for Linux it does start at 0 bytes. So my belief is that that 17K was originally reserved for a GPT (Globally unique identifier Partition Table) with a valid GPT GUID’s for each partition on the flash, maybe I am wrong. But to me, without having dumped and disassembled the boot ROM to know for sure, that one boot method at least for flash has been depreciated. There is too much inconsistent/conflicting information between the documentation and the source code to know for sure. I’m sure someone will dump and disassemble the boot ROM and then we will know for sure.