That timing is really up to Imagination Technologies and not StarFive.
Ref:
And:
5 Likes
Alright I see thanks. I asked because I was looking to buy another VF2 but it still not opensourced gpu.
Does this mean we wont have SSH connectivity to headless installs?
Hmmm
Just took another VF2 board, flashed an SD card with the new image, use RS232 to update OpenSBI and uboot, and I’m greated with that:
## Warning: defaulting to text format
Can't set block device
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Retrieving file: /boot/extlinux/extlinux.conf
Can't set block device
Error reading config file
u-boot is not latest it could be, but is fairly recent:
StarFive # version
U-Boot 2021.10 (Jan 19 2023 - 04:09:41 +0800), Build: jenkins-github_visionfive2-6
riscv64-buildroot-linux-gnu-gcc.br_real (Buildroot VF2_v2.8.0) 10.3.0
GNU ld (GNU Binutils) 2.36.1
StarFive #
I suspect that this new image come with a new but incompatible version of uboot?
You should really put both u-boot-spl.bin.normal.out and visionfive2_fw_payload.img along the image download with a big warning that these probably be needed to be updated before the image will work.
And updated OpenSBI & Uboot with the versions from Release VisionFive2 Software v2.10.4 · starfive-tech/VisionFive2 · GitHub
And it is now booting 
2 Likes
Did you change the boot switches to the SDIO3.0 position. Because then it should read the latest u-boot-spl.bin.normal.out (SPL) and the fw_payload.img (OpenSBI + U-Boot) directly from the SD card if you are using the starfive-jh7110-202302-SD-minimal-desktop.img.
1 Like
Oh, so the switch work now? I’m using the recommended setting from the last time I setup a board with when looking at the board with the USB port in front, both switches on the right side
Will change the SD setting once I finished setup the rootfs
1 Like
Yup sounds sensible
Confirmed - this works. Thank you.
2 Likes
Gents,
If the switch is working now could you please check if it is now possible to from nvme ssd?
By boot from nvme ssd I mean boot from SPI Flash that will look for OS image at nvme ssd.
Thanks
Kernel needs to be somewhere not nvme, as u-boot still does not have pci-e support.
For now, I load kernel from sd with root= pointing to nvme. It’s not a terrible solution.
I could put the kernel at the end of the SPI, where there is enough storage, but I would still need the sd, as u-boot configuration is held there. There’s space reserved in SPI for u-boot env, but it is not being used currently.
Using the sd as a clutch until pci-e support is in place seems to be the better solution for now.
2 Likes
That is something WIP by the engineering team, some codes are in place, but we don’t have a commit date internally yet.
1 Like
@kira
I think you are missing the point if you think my problem with this is not knowing how to use apt install.
Still ancient 5.15? I guess I’ll give this a pass then. Is the intent to stay at 5.15 until everything is upstreamed?
1 Like
5.15 ancient?
This is the second Longterm version of the kernel on the list. it’s not that old in reality.
It’s not beause the first LTS is 6.1 that all 5.x kernel are “ancient” & “deprecated”. 5.15 is still maintained, latest release 5.15.96 was a couple of days ago.
4 Likes
@kira
Thank you for the link, i’m sure some people will find that useful, and I’m sorry for not properly explaining myself in my original post.
I think this change badly impacts people doing headless installs (or installs with non-working monitor combos.) since it puts you in a chicken-in-egg situation. Effectively mandating people to use a UART/FTDI connection to get access to a shell in order to install openssl. uurgh.
It sort of worries me that StarFive have done this, it’s not an improvement, it’s a regression.
2 Likes
I appreciate the releases of
- the new image:
https://drive.google.com/drive/folders/1fBNI8kKIpwBfET1tCkfWgqsP0DM8X_yy
- the new firmware:
But I believe the community would be better served if we could just do the usual apt-get update/upgrade to get the goodness rather than having to flash new firmware and flash a new sdcard.
Honestly this is very cumbersome and wastes much time for the users. Please consider finding another method where the apt-get update/upgrade actually take care of upgrading the firmware and respective packages.
I recall the Radxa Rock board being able to upgrade its firmware with special hooks to do that.
Then they provided their own repo which was set in the /etc/apt/sources.list holding their radxa specific packages.
I was hoping starfive were going to follow a similar pattern when delivering their firmware and packages.
2 Likes