I should mention that I’m using firmware v2.8.0 instead of latest v2.11.5, because v2.8.0 is the last version that can still fit into old MTD layout.
Not sure if this is a factor or not.
Interestingly, with the new kernel, /proc/mtd is not showing up any partitions. Is this expected?
The firmware shouldn’t be relevant; I have used all versions without issue. The setting of the machine type only takes effect once you
upgrade the kernel via. @agreenbhm’s repo.
If you did do that and it didn’t work then I don’t know why.
I assume you updated that file after installing the kernel? If so you will need to reinstall the kernel in order to have the post-install scripts (which read that file) process the correct DTB.
I updated the file before I installed your kernel, because that was the part of the step of setting up the initial ubuntu. In any case, I just re-installed the kernel page and it seems I still have the similar issue.
BTW, I notice /etc/flash-kernel/dtbs/ directory is empty. Is this expected? If we think we are using the wrong dtbs, are there other ways to confirm this?
jsun@vf2:~$ ls /etc/flash-kernel/dtbs/
README.dtbs
That directory isn’t used from what I’ve observed. Mine is empty except for the README also. You can manually install the correct DTB and then see what happens when you re-install the kernel, whether or not the correct one gets installed or not.
You’ll want to check your Grub config to see what DTB is being called by the bootloader. You can either look at the grub.cfg file (/boot/grub/grub.cfg), about halfway down the file, at the entry, which starts with “menuentry” and then see what is set for the “devicetree” parameter. Or, you can just press “e” when the Grub menu loads on boot to view/edit the parameters of the default entry.
I’m assuming that it’s set to “dtb-6.4.0-rc1+”, which is a symlink to “/boot/dtbs/6.4.0-rc1+/starfive/jh7110-starfive-visionfive-2-v1.3b.dtb” (if indeed the wrong DTB is being loaded). To manually set it to the right DTB, just overwrite the actual file (not the symlink) with “/usr/lib/linux-image-6.4.0-rc1+/starfive/jh7110-starfive-visionfive-2-v1.2a.dtb”. Check your logic that Grub is pointing to the symlink, and then the symlink is pointing to the newly copied DTB. Once that’s checked you can reboot. If everything is working fine at that point then the DTB is definitely the issue and we’ll need to figure out why the wrong one is being installed. If not, we’ll need to look elsewhere.
I’m excited about this development, but can’t get started. My board is a 1.3B, I updated the two firmware files (current as of May 11, 2023), and it boots the VisionFive2 202303 Debian just fine (including the Pink HDMI), but when I try to boot the ubuntu-23.04-preinstalled-server-riscv64+visionfive2.img image, I get nothing on the UART. Have tried on multiple microSD cards, including ones that boot the Debian image fine. If I press and hold reset, the UART does report dwmci_s: Response Timeout but that’s about it.
Thanks for your help. The dtb file was fine and not the issue. The seems to be related to an old 10/100mbps switch which connects the board to the WiFi router. When I connect the board directly to the WiFi router’s Ethernet port, both vf2 ether ports would work.
I’m getting a new gigabit switch and will update here tomorrow.
Not quite sure where to start if the known-good Ubuntu image isn’t booting in default config. I suppose you could always trying to manually install my kernel to the SD card while it’s offline and try booting that, but no guarantees that would yield any different results. The Ubuntu image from Canonical has worked for basic boot for me since release day of 23.04.
Glad you got your networking issue resolved and that it wasn’t some edgecase DTB issue.
It’s working now. With your words, I decided to eliminate all remaining variables, and found the embarrassing/confusing cause: when I was first trying to get things working I was messing around with the boot mode switches. For some reason, the Debian image (and sdcard.img) boots from microSD with them set in SDIO mode (right/left from top to bottom) (!), but switching them to QSPI mode (right/right) got Ubuntu working. Yay! Now to upgrade to your kernel - thanks!
Glad you’ve got it working. I’m guessing it’s due to the Debian image having U-boot included, allowing you to boot directly from the SD card, whereas the Ubuntu image is only the OS, so U-boot from SPI is needed to load Grub from the SD card.
That’s exactly right. The folks for whom sdcard.img boots, but nothing else does…that’s 99% likely the cause (and right/right QSPI boot mode is the solution!). Following your instructions in the OP, I’m now running kernel 6.4.0-rc1+ - thanks!
So you need to update the SPI to use this?
Not sure you need to update the SPI; the default firmware it comes with might be fine. But you do need to boot from SPI if using the Ubuntu image.
any tutorial to install U-boot on the FLASH to load the ubuntu oficial image?
pd: the ubuntu oficial image can be loaded via SDIO config?
This site looks like it has pretty extensive instructions for updating SPI. StarFive VisionFive 2 Firmware / Bootloader Update Guide. I know Starfive had published instructions too in multiple places. A quick Google should find them. The Ubuntu image cannot use sdio by default since it does not include U-boot in the image.
The only thing missing from the StarFive VisionFive 2 wiki instructions is the boot mode switch settings, which should be set to QSPI mode (right/right). Other than that, the instructions there are very good (IMO).
Has anyone seen problems getting these kernel builds to do clean shutdowns or reboots? When trying a reboot via “shutdown -r”, I see the reboot process get partway through shutting services down, and then it just stops partway through a line. I’ve got a 1.3b board with the 2.10.4 firmware, if that matters.
For me reboot never worked until
the latest firmware. Did you flash that?
Reboot is inconsistent for me. Sometimes it hangs after a few lines of output, other times it’s fine. Not sure if I’m on the latest firmware but can check tomorrow.