Hello all,
on running this - flashcp -v u-boot-spl.bin.normal.out /dev/mtd0, I am receiving this message “u-boot-spl.bin.normal.out won’t fit into /dev/mtd0!”
Any ideas??
root@starfive:/uu/Transit# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00001000 “spl”
mtd1: 00300000 00001000 “uboot”
mtd2: 00100000 00001000 “data”
root@starfive:/uu/Transit#
Regards
Aubrey
My guess is that part of the document you are probably following is out of date. That the current partition table for the QSPI NOR FLASH was changed to be this:
| Offset | Length | Description |
|---|---|---|
| 0x0 | 0x80000 | SPL |
| 0xF0000 | 0x10000 | U-Boot environment variables |
| 0x100000 | 0x400000 | fw_payload.img (OpenSBI + U-Boot) |
| 0x600000 | 0x1000000 | Reseved |
I did a quick sanity check to conform this:
offset 0xF0000 is where the U-Boot environment variables are stored, and
offset 0x100000 is where the fw_payload.img is stored. Both of which match the above table.
I would make a backup copy of the existing 16MiB QSPI NOR FLASH partition table, deleted the current partitions and create three new ones with the start offset and length shown above. One for “SPL”, one for “U-Boot environment variables”, and one for “fw_payload.img (OpenSBI + U-Boot)”.
Or I could bypass creating new partitions by writing u-boot-spl.bin.normal.out, since “u-boot-spl.bin.normal.out” starts at sector 0, it must actually contain the partition table, a nice little shortcut. But you would need to do a I just checked and it does not appear to have a partition table, which confused me.# partprobe /dev/mtd to avoid a reboot, to inform the OS that the partition table has changed if you did it that way. Otherwise what the OS though it knew about the partition table would be out of sync with the partition table on flash.
To have a backup copy of the information in the existing table, I would probably use a command like the following (always handy to have in case anything goes wrong, but should not be needed):
# sfdisk -l /dev/mtd
or
# sfdisk -J /dev/mtd
or
# fdisk -l /dev/mtd
(Done mostly to have a record of the existing partition types used, so that the new partitions can have the same type)
Looks like you need to use “mtdpart” to delete the existing partitions and create 3 new ones. e.g.
# apt install mtd-utils
# mtdpart del /dev/mtd 2
# mtdpart del /dev/mtd 1
# mtdpart del /dev/mtd 0
# mtdpart add /dev/mtd "spl" 0x0 0x80000"
# mtdpart add /dev/mtd "data" 0xF0000 0x10000"
# mtdpart add /dev/mtd "uboot" 0x100000 0x400000"
# 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/mtd2
Note the “/dev/mtd2” and not “/dev/mtd1”
ref: http://git.infradead.org/mtd-utils.git/blob/HEAD:/misc-utils/mtdpart.c or http://www.linux-mtd.infradead.org/
EDIT:
I just found what I initially thought was a contradiction in the source code, but it just looks like no partition is actually created for where the U-Boot environment variables are stored. There are 3 partitions created on the flash:
https://github.com/starfive-tech/u-boot/blob/…/include/configs/starfive-visionfive2.h#L264-L267
"type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
"type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
"type_guid_gpt_system=" TYPE_GUID_SYSTEM "\0" \
"partitions=" PARTS_DEFAULT "\0" \
https://github.com/starfive-tech/u-boot/blob/…/include/configs/starfive-visionfive2.h#L97-L99
#define TYPE_GUID_LOADER1 "5B193300-FC78-40CD-8002-E86C45580B47"
#define TYPE_GUID_LOADER2 "2E54B353-1271-4842-806F-E436D6AF6985"
#define TYPE_GUID_SYSTEM "0FC63DAF-8483-4772-8E79-3D69D8477DE4"
Which correspond to “HiFive Unleashed FSBL”, “HiFive Unleashed BBL” and “Linux filesystem data” respectively. Or u-boot-spl.bin.normal.out , visionfive2_fw_payload.img and Linux filesystem respectively.
Oh and:
https://github.com/starfive-tech/u-boot/blob/…/include/configs/starfive-visionfive2.h#L165-L168
#define PARTS_DEFAULT \
"name=loader1,start=17K,size=1M,type=${type_guid_gpt_loader1};" \
"name=loader2,size=4MB,type=${type_guid_gpt_loader2};" \
"name=system,size=-,bootable,type=${type_guid_gpt_system};"
So from 17KiB to 1MiB and 17 KiB is for storing u-boot-spl.bin.normal.out
From 1MiB and 17KiB to 5MiB and 17KiB is for storing visionfive2_fw_payload.img
From 5MiB and 17KiB to the end of the FLASH, ‘-’ to denote all remaining space, is a bootable partition of 11247KiB for files.
so:
| Offset | Length | Description | Partition | GUID |
|---|---|---|---|---|
| 0x0 | 0x4400 | GUID Partition Table | not applicable | not applicable |
| 0x4400 | 0x100000 | SPL | /dev/mtd0 | 5B193300-FC78-40CD-8002-E86C45580B47 |
| 0xF0000 | 0x10000 | U-Boot environment variables | first 64KiB of last 81KiB of /dev/mtd0 | shared with SPL |
| 0x104400 | 0x400000 | fw_payload.img (OpenSBI + U-Boot) | /dev/mtd1 | 2E54B353-1271-4842-806F-E436D6AF6985 |
| 0x504400 | 0x1000000 | Linux Filesystem | /dev/mtd2 | 0FC63DAF-8483-4772-8E79-3D69D8477DE4 |
I was expecting to see a partition of GUID of “3DE21764-95BD-54BD-A5C3-4ABE786F38A8” AKA “U-Boot environment” but one does not exist the data is hidden in 64KiB of the last 81KiB of the “5B193300-FC78-40CD-8002-E86C45580B47” AKA “HiFive Unleashed FSBL” just 17KiB before the start of the GUID “0FC63DAF-8483-4772-8E79-3D69D8477DE4” AKA “HiFive Unleashed BBL”.
So it looks like both documents are out of date.
Hmm, this is mine on 2.11.5:
root@serval:/usr/src/jh7110/JH7110_u-boot# ls -ld spl/u-boot-spl.bin
-rwxr-xr-x 1 root root 128824 Mar 26 15:43 spl/u-boot-spl.bin*
But since it’s already soon to hit 131072, this might be me lucky.
fwitw:
I did a flashcp for both u-boot-spl.bin.normal.out and visionfive2_fw_payload.img with the latest (v2.11.5) versions following the QuickStart guide (which was updated a few days ago, and linked from the release notes).
I am also running the latest 2.11.5 SD minimal image from the google drive, I only just upgraded this morning and everything so far looks good. (*)
Here is what I see, for reference.
root@rose:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
(*) As good as it gets with these releases 
… thankyou 
I think I need to do that too. I’m not having issues now but might as the spl grows. Maybe how to set the partition could be something for the release notes or QuickStart?
I managed to erase the partitions:
root@starfive:/home/user# flash_erase /dev/mtd2 0 0
Erasing 1024 Kibyte @ 0 -- 100 % complete
root@starfive:/home/user# flash_erase /dev/mtd1 0 0
Erasing 3072 Kibyte @ 0 -- 100 % complete
root@starfive:/home/user# flash_erase /dev/mtd0 0 0
Erasing 256 Kibyte @ 0 -- 100 % complete
But no matter what I try to add the partition, it doesn’t work:
mtdpart add /dev/mtd0 "spl" "0x0" "0x80000"
mtdpart: error!: Failed to issue BLKPG ioctl
error 22 (Invalid argument)
root@starfive:/home/user# mtdpart add /dev/mtd0 "spl" 0x0 0x80000
mtdpart: error!: Failed to issue BLKPG ioctl
error 22 (Invalid argument)
root@starfive:/home/user# mtdpart add /dev/mtd0 spl 0x0 0x80000
mtdpart: error!: Failed to issue BLKPG ioctl
error 22 (Invalid argument)
root@starfive:/home/user# mtdpart add /dev/mtd spl 0x0 0x80000
mtdpart: error!: Cannot open /dev/mtd
error 2 (No such file or directory)
root@starfive:/home/user# mtdpart add /dev/mtd0 "spl" "0x0" "0x80000"
mtdpart: error!: Failed to issue BLKPG ioctl
error 22 (Invalid argument)
root@starfive:/home/user# mtdpart add /dev/mtd "spl" "0x0" "0x80000"
mtdpart: error!: Cannot open /dev/mtd
error 2 (No such file or directory)
What I don’t get is the original partitions seem to still be there.
cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
erasing the contents of a partition is different to deleting a partition.
mtdpart del /dev/mtd 2
mtdpart: error!: Cannot open /dev/mtd
error 2 (No such file or directory)
But there are devices:
root@starfive:/home/user# ls -la /dev/mtd*
crw------- 1 root root 90, 0 Dec 22 06:26 /dev/mtd0
crw------- 1 root root 90, 1 Dec 22 06:26 /dev/mtd0ro
crw------- 1 root root 90, 2 Dec 22 06:26 /dev/mtd1
crw------- 1 root root 90, 3 Dec 22 06:26 /dev/mtd1ro
crw------- 1 root root 90, 4 Dec 22 06:26 /dev/mtd2
crw------- 1 root root 90, 5 Dec 22 06:26 /dev/mtd2ro
brw-rw---- 1 root disk 31, 0 Dec 22 06:26 /dev/mtdblock0
brw-rw---- 1 root disk 31, 1 Dec 22 06:26 /dev/mtdblock1
brw-rw---- 1 root disk 31, 2 Dec 22 06:26 /dev/mtdblock2
I looked around for some mtdpart documentation and I didn’t find anything and no examples with explanations anywhere. No troubleshooting sections anywhere.
Looks like the master device is not exposed, and therefore can not be accessed:
$ grep CONFIG_MTD_PARTITIONED_MASTER /boot/config-5.15.0-starfive
# CONFIG_MTD_PARTITIONED_MASTER is not set
ref: https://cateee.net/lkddb/web-lkddb/MTD_PARTITIONED_MASTER.html
I booted from the sdcard.img and ran the commands from there. That seemed to work.
Thanks so it works with sdcard.img but not starfive-jh7110-VF2-SD-wayland.img.
I tried it from the wayland image first, without success. Doing it from sdcard.img worked, and the partition sizes had changed.
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.
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.
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 ?
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
Seems u-boot itself could handle this?
https://lists.denx.de/pipermail/u-boot/2017-May/thread.html#290700
https://lists.denx.de/pipermail/u-boot/2017-May/290702.html
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