I am using a VisionFIve 2 for quite a long time as my desktop experimentation and package building rig for RISC-V.
It is used in the plastic case with active cooler and nothing despite the USB2Serial adapter attached via GPIO. It is equipped with a NVME SSD with debian and archlinux installed in dual-boot via extlinux.conf.
So, on friday I did some updates on some locally built software packages and all was fine. Then, on saturday, I started it again and found everything as expected…on the first glance.
Then, when I tried to update the system, I got a timeout. On my other VF2, which I use as my home server, all was fine. So I tried to ping around a bit and found, that no host was reachable, neither in LAN nor on the net. I checked the network configuration via ifconfig/route commands and everything was configured as it should be. The statistics block, ipconfig shows, there where even packages counted going in and out but as I said, the actual network communication was not established. Dmesg didn’t show errors nor did journalctl.
I then tried to use the other LAN port but there the situation was not different.
So, I then went to boot debian via dual-boot and found the same situation there. So I changed network cables, attached it to a different switch and even changed the power supply…just in case. Again, no network communication. I then created a fresh SD-card with the 2024/03 relase of debian to check it with that. But booting it got stuck in a later stage of loading the kernel. I tried that with two different SD-cards, both working on my PC.
I then thought, perhaps some bits in the QSPL flipped by whatever reason and put the most current firmware files on a SD-card, booted from NVME and tried to copy the files over to my VF2 which failed. Couldn’t ever read the directory. So I transfered the files via serial to the VF2 and flashed the firmware. Booting after that didn’t show any change.
Now, I’m sitting here with a VF2 without network and SD card access. Since I don’t use many of the other features available, I cannot tell what else stopped working.
Any ideas what else I can check or do to get it working again or is the device finally broken?
My goto in troubleshooting is to remove ALL hardware and build it back up from there.
Bare Board (no NVMe, no eMMC, no MicroSD), serial pins and power supply connected only. And I monitor temperature (IR camera) and power usage (Type C USB Voltage Current meter).
And then I add everything back one at a time, until it works again or I have tracked down a part that is the possible cause.
Thank you @mzs ! Sometimes it’s really better to strip everything down to the minimum. I followed your advice and was able to boot from SD card and ping my router. But re-enabling stuff broke things pretty quickly. So I’ll create a very fresh SDcard with the just released 2024/05 release including firmware and then report the results.
Update: added all peripherials again and just left boot mode on SD → works perfectly. So I guess something in QSPL or on boot partition of the NVME-SSD must be corrupted.
Ok, it has been the /boot filesystem the whole time…recreated that one and everything is fine again. Left me speechless, that this was able to produce that kind of issues. I don’t know exactly what was wrong on the filesystem but I suspect that during an update the initrd creation failed and left a broken ramdisk file.
Well…case closed
‘it has been the /boot filesystem the whole time…recreated that one and everything is fine again.’
I seem to have encountered the situation you mentioned before. Multiple boot. After ‘apt upgrade’ a partition system, some files in/boot were modified. (The above content is machine translation)
Just to prevent misunderstandings…I did multiboot for months now but not the way it is done in the 2024-05 release. And the symptoms occuring if the firmware is not up to date are not the same I encountered before. My best bet is still the ramdisk image and it’s creation.
Anyway…problem is solved. Thank you all!
Nobody said it isn’t
But the prerequisite for it to work is, that the paths for the DTBs are correct and they are assembled by different parts (u-boot, uEnv.txt, extlinux.conf). If those are not correct, it still boots but perhaps detects wrong memory sizes or other, hardware related stuff.
Do you actually read, what I write? I just said it is possible and what to look out for.
But “multiboot” can relate to different things. This take from the starfive guys is able to deal with different kernel versions (and OSes). What I did beforehand was just booting Debian and Archlinux from the same SSD using extlinux.conf but with the same kernel versions (compiled differently but the same kernel version using the same DTBs).
