Still in the dark. I will wait.
Aubrey
Still in the dark. I will wait.
Aubrey
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.
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:
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
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:
dtc
executablescripts/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)dtc -I dtb -O dts /sys/firmware/fdt -o /root/vf2.dts
. Ignore warnings./root/vf2.dts
with your favourite text editor, go to sections which says nor-flash@0 {
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 */
};
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.
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.
@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.
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
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.
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?
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:
flashcp
as described in [2]flashcp
as described in [2] finally worked without an error[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.
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
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.
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.