You can download a recent build form here…
Ubuntu Kernel 5.7 Firmware package
Thanks, but I get 404 for that URL. I can’t see a “suites” folder under GitHub - ZephyrLabs/fenix: One-stop script set to build Ubuntu/Debian images at all. Possibly a permissions problem?
Oh, I am sorry, It seems to permit people only if they have a Github account, and are logged in…
Do you have one ? or shall I upload to cloud for you to download ?
OK, thanks. I’ve logged into github and it’s now downloading. It will be a few hours or tomorrow before I have time to test it I’m afraid, I’ll try to let you know as soon as I can.
Ok, please take your time to test and tell us the results of this firmware…
Good day!
I reported the same issue here:
I did not find this problem to be kernel-specific, however my board ceased working soon after reporting this issue, ending a few weeks of unreliability and stress with the VIM3L. Note that I’ve still not been contacted or advised about RMA.
@mzb69 I realised we never asked you about the firmware and kernel version you were using…
I can provide you a Up-to date image, are you willing to run it ?
@mzb69 please try these Images, and tell me if it works…
VIM3L_Ubuntu-server-focal_Linux-4.9_arm64_EMMC_V0.9.3-200827
VIM3L_Ubuntu-server-focal_Linux-5.9-rc2_arm64_SD-USB_V0.9.3-200827.img
*please note you need to login to github to be able to download these images, Thank you
also the mainline kernel has been updated from 5.7 to 5.9…
I’ve now tried the image you kindly supplied yesterday. Unfortunately, the HDMI corruption issue still exists.
See https://imgur.com/a/8mWGJ9b for a video of the issue.
Edit: I should add – the display is absolutely stable when there is no SSD write activity. I suspect that the second burst of corruption after the command completes is when OS buffers are flushed to the disk… actually, I can confirm that by adding conv=fsync to the dd command.
i think its power supply problem!!!
plz show power requirement for your ssd
some ssd nvme - need 10W some only 5-7W + sure your VIM device need something 
and sometime its not enough
my recommendation to use ssd from WD blue series which have low power consumption
as @hyphop said, it is highly suspected to be a power issue…
but other than that, is your keyboard and mouse stable ?
i have same issues but in my situation - its was full reset when i try read data in maximal speed from NVME - but this problem disappear on another nvme WD blue series
its same problem for VIM and Edge - need good power supply
Interesting theory… I’m powering the device via a Anker 30W USB-C PD charger and a Nimaso cable that’s rated for 60W. Swapping that for my Dell laptop USB-C PD PSU (rated for 130W), the issue still occurs. If it is power, then I suspect the issue is on the VIM3 not with the PSU.
That said, the drive specification says:
Power Consumption (Active) Avg. read : 2.2W ; Write : 1.7W
…which does lead me to wonder why I see the issue on write, but not read. (I can confirm this with an 8GB file, much larger than RAM, so definitely coming from disk).
Yes, thanks. The USB issue is resolved at least.
That is good to hear…
But regarding the SSD, That is kind of a mixed thing as you have to think of it from an electrical engineering standpoint…
for example…
The VIM3 only sips about 4.5-5W of power in Normal usage… but it won’t boot unless you give it 10W bare minimum…
so you have to be able to provide more that it takes…
also don’t forget to take into account that it creates a huge spike in current when starting up or doing tasks…
But you provide more than ample power to the device… perhaps, if you tried to give power via the VIN port, maybe you could ease the power draw ?
as I think there are limitations to the physical device and how much power it is able to draw maximum…
its just digits ! in real life your equipment can get only 5V + and low power quality - and its will be a problem !
WRITE procedure need every time more power than READ !
The drive is rated at 3.3V 0.9A, so shouldn’t draw more than 3W even at peak. Also, the corruption is sustained for the whole write cycle, not just at the start of the activity. I more suspect EMI arising from PCB layout rather than power supply issues, but I’m not enough of an electronics engineer to dig any further.
I did randomly try dropping the PCIe bus speed to 2.5 GT/s to see if that helped, but made no change to HDMI issue though did have the expected effect on throughput.
I spent excessive amounts of time failing to discover any way to change the framebuffer console HDMI resolution to see if that made a difference. The settings in /boot/env.txt seem to be ignored, as were any uboot variables I tried. I got as far as finding /sys/bus/platform/devices/soc/ff900000.vpu/drm/card0/card0-HDMI-A-1/edid (and /modes in same bit of the tree), but haven’t found anywhere in /sys that will let me write a new mode value to change the HDMI PHY.
Powering via the VIN port was vaguely on my todo list anyway to free up the USB-C port, but I don’t have the Molex crimp tool for building a cable. Is there a better alternative than buying the VIN-to-VIN cable, cutting the wires and soldering to a barrel connector?
Anyway, I think I’ve exhausted most of the effort I have for this, given I don’t actually intend to use HDMI in the day-to-day deployment. Thanks for your help, and hopefully this thread might be of some use to the next person to hit similar issues.
I don’t know about EMF coming through the boards, as I think the M2X board does have copper layers that should hopefully absorb or deflect the incoming interference…
as for the VIN connector, I am afraid there is no other way to add a connector to it…
I too thank you for testing and cooperating in this problem hunting quest…
good day !
Thanks for the info ! at the moment the question remains open…