I have seen some kernel errors w.r.t. trim on Silicon Power 16GB SD-card, was in ROCK3A. But no other errors. Kernel is unspecified, although I might be able to figure out which/what, you can even search this forum, then you know yourself. This errors do not occur on a RPi4 v1.1 (with RPL OS and kernel). So if you want to know, dig more into logs, doe specialistic blocklevel error checking. In general: welcome to SD-card magic!. See also this:

I flashed a home built nanpim4v2 image to two brand new Silicon Power 32GB sdcards and they wont boot whereas SanDisk 32GB boot OK can anyone explain why ?

Why repair the filesystem first while you anyway overwrite the whole storage device then? /dev/sdb1 suggests an USB SD-card adaptor is used. Both the adaptor, which translates USB protocol into MMC commands, and the SD-card itself, which also does internal block managing, can mess up the filesystem. Not as long as this is plugged into the computer where the imager (or dd) is running, but once removed and put into the SBC, power is lost and re-applied. The USB + SD-card hardware (and also OS driver in the computer) might have flaws in its implementation. It could easily be that SD-card signals 'ready' to OS, so you then take out USB + SD-card, but that actually not all is committed to the actual flash and still some is in buffers or the SD-card is still doing wear-leveling and doesn't do that in a correct way. And worse, if fake sized counterfeit, the firmware might be busy doing its 'magic tricks' to fake hundreds of GB size while only 8 or 32 GB is actual flash chip. So unfortunately, even if using a verify step in writing an image, the actual content on the SD-card might be different from the image file once the SD-card is put in the SBC. I remember such a case on this forum where someone did manual block-level compare of storage device and image. I also have had such issue at least once. It is the situation where you just re-do / re-write again without knowing what is wrong. And/or use other SD-card, other USB-adaptor, other computer, etc. To prevent such issues, I tend to use (the) SBC itself to write SD-cards. My RPI4 runs from USB-SSD, so SD-card slot is free. I trust RPL HW more than various USB SD-card adaptors. Earlier test I mentioned using the the Armbian-imager was on NanoPi-R6C running from eMMC+NVME, so same story, free SD-card slot. It ran Armbian Trixie KDE6 and 7.0-rc rockchip64 kernel. I was also forced to more or less, because on my Tumbleweed N100 box the Armbian Imager only stayed white (some EGL error). That was with x86-64 AppImage. I thought it would be better to install from a .deb hence walked to my powered-on ARM64 running Debian. Anyway I do normally not use images. I would rather use ddrescue (enable mapfile option) to check and make sure image is same as on storage device. That helped also in the past for 4TB HDD's (when risk of bit-rot). It is CLI based and allows to re-do check after power-cycle.

moved

It is not working with this patch because offcially AIC8800 is not supported in kernel > 7.0-rc6 plus in my image Wifi was initially disabled With new image it is better: I made a small fix to make it running with some commands as root: ``` # unzip AIC_FIX.zip # mkdir -p /lib/modules/$(uname -r)/kernel/drivers/net/wireless/aic8800 # cp aic_btusb.ko aic_load_fw.ko aic8800_fdrv.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/aic8800/ # depmod -a # cat /etc/modules-load.d/aic8800.conf aic_load_fw aic8800_fdrv aic_btusb # cp -r aic8800_fw /lib/firmware/ # cp -pr aic8800_fw/USB/aic8800D80/ /lib/firmware/ # modprobe aic_load_fw # modprobe aic8800_fdrv # modprobe aic_btusb # lsmod |grep -i aic aic_btusb 57344 0 aic8800_fdrv 626688 0 cfg80211 1200128 1 aic8800_fdrv aic_load_fw 86016 1 aic8800_fdrv ``` Please also remember as it is experimental and all you do it is on your own risk HDMI is not working and we need some code first, I guess for this part: CONFIG_PHY_ROCKCHIP_INNO_HDMI_QP