Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 3.4.5 visionfive2_fw_payload.img too large? #73

Open
rgadsdon opened this issue Aug 9, 2023 · 6 comments
Open

Version 3.4.5 visionfive2_fw_payload.img too large? #73

rgadsdon opened this issue Aug 9, 2023 · 6 comments

Comments

@rgadsdon
Copy link

rgadsdon commented Aug 9, 2023

Kernel 6.4.0-46, Fedora 38, boot from sdcard.

u-boot-spl.bin.normal.out loads OK, but then:

# flashcp -v visionfive2_fw_payload.img /dev/mtd1
visionfive2_fw_payload.img won't fit into /dev/mtd1!

@ThomasKorimort
Copy link

ThomasKorimort commented Aug 9, 2023

The official boot procedure flow is listed in https://doc-en.rvspace.org/VisionFive2/Boot_UG/JH7110_SDK/boot_flow.html . Maybe it is possible to build a custom OpenSBI and U-Boot bootloader independent of the official StarFive sources. There are also ongoing discussions on the official discussion forum at RVspace, that the JH7110 has a secure boot mode, which is not usable on the Vision Five 2, because its ZSBL BootROM might be compromised for letting the custom kernel believe falsely to run in supervisor mode, whilst it is controlled by a shadow operating system actually using the JH7110's secure boot features (https://forum.rvspace.org/t/is-the-source-code-for-the-boot-rom-for-the-visionfive-2-available/1918/46). Whereas this might be conspiracy stuff and troll activity to be left aside, it might impact the possibility to write a custom open-source and free version of the OpenSBI and U-Boot bootloader software for the Starfive Vision Five 2. On the other side, in the current struggles of the world it seems also quite plausible, that free and open-source computing is sabotaged, restricted and counteracted wherever possible, the world being out for a ramble of self-destruction.

@misuzu
Copy link

misuzu commented Aug 9, 2023

It's a kernel bug, there're no issues when flashing via UART

@ThomasKorimort
Copy link

ThomasKorimort commented Aug 9, 2023

The memory reserved for the SPL on /dev/mtd0 and payload on /dev/mtd1 is quite small. I remember having seen a post, that said, that the payload file was just a KB or so too big to be fitted to its destined partition. Such mishaps do not appear at random. Even if they might not be completely intentional either, they are the result of the hard court battles over copyrights, brand wars and DRM issues currently going on between the major and some minor players in the business, not to speak of the economic war between the USA and China. -> The devil hides in the detail.

@MichaIng
Copy link

MichaIng commented Aug 9, 2023

Linking the related issue at the kernel repo: starfive-tech/linux#81

@misuzu
Copy link

misuzu commented Aug 18, 2023

On the "upstream" kernel the layout looks like this:

% cat /proc/mtd                            
dev:    size   erasesize  name
mtd0: 00080000 00001000 "spl"
mtd1: 00010000 00001000 "uboot-env"
mtd2: 00400000 00001000 "uboot"
mtd3: 00a00000 00001000 "reserved-data"

So the visionfive2_fw_payload.img should be flashed to /dev/mtd2 instead of /dev/mtd1

@grisu48
Copy link

grisu48 commented Jan 2, 2024

I had the same issue on Debian Sid, and #73 (comment) resolved it for me.

You likely also need to use /dev/mtd2 instead of /dev/mtd1. I also needed to update the openSUSE documentation - could this be a issue with one of the Fedora guides?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants