I noticed that your partition layout is different from others’. What did you do to that before?
I am not sure if I understand your English.
Up to this point, I have not altered any /dev/mt* partition.
Aubrey
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:
- Install device-tree-compiler or any other package that contains
dtcexecutable
1a. Alternatively, you can get one from any Linux’s tree asscripts/dtc/dtcaftermake menuconfigormake prepareormake dtbs(but you shall do this on the board itself, so it’s compiler will build right RISC-V version ofdtcexecutable for you) - Decompile current running kernel dtb into source:
dtc -I dtb -O dts /sys/firmware/fdt -o /root/vf2.dts. Ignore warnings. - Edit
/root/vf2.dtswith your favourite text editor, go to sections which saysnor-flash@0 { - Under
partitions {subsection next tonor-flash@0 {, keep three first lines intact, erase any subsections till end ofpartitions {section, the};closing so it will look like this:
partitions {
compatible = "fixed-partitions";
#address-cells = <0x01>;
#size-cells = <0x01>;
/* blank area */
};
- 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
Are you sure this won’t break partition GUID? starfive are using GPT over MTD for spi flash.
1 Like
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.
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.
2 Likes
@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.
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.
3 Likes
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
1 Like
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.
I dumped bootrom (from U-Boot prompt is easy: it sits statically at 0x2a000000) and I’m in progress of re-developing it back to C code. Huge WIP, hopefully I’ll finish at least logic traversing in next few weeks. (And hopefully I’ll just find matching pieces in previous JH7100 bootloader recovery sources). But without any guarantee.
5 Likes
booting from the SD…(switches)
root@starfive:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mtdblock0 31:0 0 128K 0 disk
mtdblock1 31:1 0 3M 0 disk
mtdblock2 31:2 0 1M 0 disk
root@starfive:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00001000 “spl”
mtd1: 00300000 00001000 “uboot”
mtd2: 00100000 00001000 “data”
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
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/jh7110-visionfive-v2-ac108.dtb
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/jh7110-visionfive-v2-wm8960.dtb
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/jh7110-visionfive-v2.dtb
wget https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/vf2-overlay-uart3-i2c.dtbo
mv *.dtb /boot/dtbs/starfive
mv *.dtbo /boot/dtbs/starfive/evb-overlay
reboot
cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00001000 “spl”
mtd1: 00300000 00001000 “uboot”
mtd2: 00100000 00001000 “data”
root@starfive:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mtdblock0 31:0 0 256K 0 disk
mtdblock1 31:1 0 3M 0 disk
mtdblock2 31:2 0 1M 0 disk
flashcp -Av u-boot-spl.bin.normal.out /dev/mtd0
flashcp -Av visionfive2_fw_payload.img /dev/mtd1
switches back to flash, insert SD, boots?
2 Likes
I also had this problem - the recommendation from issue #45 of [1] got me onto the right track. Here’s the steps I had to take in the end:
- (not sure if this step is actually required) flash the 069 image onto a microSD card, boot it, SSH onto the VF2, install mtd-utils, flash the version 2.5 SPL and firmware from the releases page of [1] with
flashcpas described in [2] - download and flash the 2.11 sdcard.img from the releases page of [1] (the 202303 image might work as well if I read the aforementioned issue #45 of [1] correctly, but the sdcard.img only has 800Mb and thus was faster to write), switch your VF2 to SDIO boot mode (see the boot mode settings in the quick start guide; I may not post more than two links in this reply yet because my account is too new) and again boot it and SSH onto it (the default root password is starfive); now, mtd0 had a size of 40000. I could only get the latest (3.0.4 as of now) firmware+SPL files onto the VF2 via a separate USB drive because neither scp nor wget would work, but now, flashing them with
flashcpas described in [2] finally worked without an error - set the boot method back to QSPI, now the VF2 would start even with the more recent VF2 debian images
[1] GitHub - starfive-tech/VisionFive2
[2] Updating SPL and U-Boot of Flash
Why not use 202306?
It can boot into X with SD Boot mode, without update SPL.
4 Likes
Thank you, good to know. My goal was to get the previous setup (with QSPI boot mode) running with the latest debian image and therefore I did not even try that one with the SD boot mode 
On the plus side of having wasted a couple of hours on the issue, I learned a couple of things on the way and the firmware is up to date now 
4 Likes
Just a warning! Do not do this with the latest FW (3.4.5) if u got a 8 GB device. I might just have bricked mine.
1 Like
For those just following this thread, Manux added scary words like “bricked”, but didn’t follow through here with the relief that he did not brick his board and bricking a board by messing up firmware uploads really isn’t possible - by design. Moving a jumper and installing from SD card was all it took.
Releasing an update with a fine print scary warning that it’ll make your board no longer work with Linux is not very friendly, though. I guess these dev boards have to remind you that with art comes suffering.
1 Like