Search the Community

Today I flashed the latest version CLI Jammy img instead of my old OS.First system boot,I can get the IP from my router DHCP and I can ping the Board's IP,but SSH connection refused.Now the Latest System won't start SSH service in first boot?I haven't a monitor,so I cant check the system booted or not.

Description outdated PHY driver no longer necessary, incompatible with 5.15. RK3328-roc-pc was not adjusted, no board to test. With it transitioned we can eliminate the phy driver patch entirely. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. Renegade and Rock64 v3 both tested Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

So far no luck. We do have a redundant patch adding the nodes, but that isn't the culprit. The driver complains it doesn't have the host-drv pin defined, but it's shared with the USB2 (same situation between Renegade and Rock64) EDIT: A PHY driver was added back in the dark days before USB3 support by the kernel. It is only used by the Rock64 and Renegade, (and apparently also the RK3328 Station M-whatever). I've removed the entries and USB3 is working again now that mainline supports it without said special case driver. I will open a PR tonight with the fixes.

I'll take a look momentarily, the same patch enabled the usb3 for both the Rock64 and the Renegade, and it looks like mainline has that enabled by default but the patch still exists. May or may not be a cause, I would hope redundant entries simply got ignored...

Since Linux 5.15, the USB3 port on ROCK64 does not work anymore with Armbian. The following kernel errors are shown: usb 5-1: USB disconnect, device number 2 [...] usb usb5-port1: Cannot enable. Maybe the USB cable is bad? This has been reported by multiple users with multiple drives and cables, also disabling UAS does not help. lsusb shows the drive/device, but lsblk does not. I know the ROCK64 is not currently supported by Armbian/has no maintainer, so I'm not expecting anything, just posting this as information and probably someone with more insights into the rockchip64 kernel build has an idea or workaround.

Hi folks, this is my first thread here, I just recently came aboard since I found that Armbian is the better solution for my Odroi-HC4 therefore I won't insist on checking for info and solution on the Odroid Forum. I am not very satisfied with Hardkernel, they produce excellent board with very poor OS support, looks like such critical aspect is left on the shoulder of a couple of great dudes but is not same as having a community behind; also board as the RPI demonstrated that a great OS support is better than having the most powerful hardware, is the same lesson learned by Rock64 even though I won't user Manjaro not even under torture... 😜 Armbian might a great asset for Hardkernel, never understood why they are so reticent... 🤷‍♂️ Thanks! F.

So just to report back for posterity. I've tried the latest 5.18 kernel for the 'rolling' build on https://www.armbian.com/rock64/. No luck with the DAC HAT, audio out the 3.5mm jack no problem. Back to the legacy kernel for me... The list of devices looks promising, but none of them produced sound out the i2s HAT. # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Analog [Analog], device 0: ff010000.i2s-rk3328-hifi ff410000.codec-0 [ff010000.i2s-rk3328-hifi ff410000.codec-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDMI], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [ff000000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 # aplay -L null Discard all samples (playback) or generate zero samples (capture) hw:CARD=Analog,DEV=0 Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0 Direct hardware device without any conversions plughw:CARD=Analog,DEV=0 Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0 Hardware device with all software conversions default:CARD=Analog Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0 Default Audio Device sysdefault:CARD=Analog Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0 Default Audio Device dmix:CARD=Analog,DEV=0 Analog, ff010000.i2s-rk3328-hifi ff410000.codec-0 Direct sample mixing device hw:CARD=HDMI,DEV=0 HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0 Direct hardware device without any conversions plughw:CARD=HDMI,DEV=0 HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0 Hardware device with all software conversions default:CARD=HDMI HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0 Default Audio Device sysdefault:CARD=HDMI HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0 Default Audio Device dmix:CARD=HDMI,DEV=0 HDMI, ff000000.i2s-i2s-hifi i2s-hifi-0 Direct sample mixing device

I don't understand why, but it seems when compression backends are mixed is when the slowness occurs. When trying this on my Rock64, RockPro64 and x86_64 VM with Armbian bullseye it seemed to be fast for a while, and then degrade... disabling the compression made them all similarly quick.

That is possible, but features in mainline kernel are breaking down in regular cycles if not maintained. Most people wrongly assumes works is done when hardware reaches mainline, but that is not the case. When hardware, especially of cheap HW such as Rock64, gets here (never with all functions supported) it starts the journey of breaking its usable features down. We are seeing this everywhere and without our intervention many board would not be usable at all anymore. Those interventions could (are) easily costs somewhere between 5 and 15k euros per board per year. Current cost covering scheme - you as our "clients" are only adding 0.5% of needed. CSC -> Supported didn't fix you the problem. It only helps sharing the non most critical burden: Someone will keep a list of what is not working, but he/she is not obligated to do anything. We also accept people that has no clue about R&D. If this would be a requirement, most likely nobody would show up. But this is again just a wish / theory - in reality - very little of those that joined actually does anything on that list. They report nothing, they don't (all) participate in release process. When there is no help, status is going back again ... If someone pays hours needed to fix the feature / bug, someone will try to fix it. If not, bugs stays. This is not a problem of Armbian since public is not even trying to cover expenses related to keeping the device usable.

Thanks, the tip, i forgot about the 'legacy' kernel images. I've booted the most recent build i could find Armbian_21.02.1_Rock64_focal_legacy_4.4.213 and now have audio working. `aplay -D default:CARD=rki2ssound piano2.wav` will play out of both the onboard 3.5mm headphone jack, and the DAC HAT. I'm sure i had it working before (2+ years) ago using the mainline kernel. Either things have changed since then, or my memory is faulty. I see rock64 has more recently moved from CSC -> WIP and there are some new builds. Will try those out and see if things have changed.

Description Restore Rock64 and RockPi 4A/4B/4C builds. How Has This Been Tested? It hasn't yet. Need to get these changes integrated to the build system so I can test the images on the SBCs :) Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

This issue exists on all RK3399 SBCs indeed, probably even on all SBCs with rockchip64 kernel. We had one report with ROCK64 (RK3328), but to be true the only thing I know in this particular case is that card 0 device 1 didn't exist anymore while we didn't check whether e.g. card 1 or card 0 device 0 works well.

I was actualy looking at modding the neo3 dtb file just the other day. Found it had gone missing from the dts makefile . (arch/arm64/boot/dts/rockchip/Makefile) --- Makefile.orig 2022-03-31 23:09:30.840184181 +0200 +++ Makefile 2022-03-31 23:14:43.734675836 +0200 @@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3326-odroid-go2.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-neo3-rev02.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb

Hi all, I have a Rock64 running on the "official" image (at the time, according to the official Pine64 documentation) "Armbian Ubuntu Bionic XFCE Desktop". Recently I updated it but suddenly it stopped working. After rebooting, all the 3 LEDs were lit, ON all the time and that was about it. I thought it was some kind of SD card corruption because it couldn't load some files from the SD card after the update and before rebooting. The only thing that came to mind to fix this was to restore a backup I had from Dec 2020. So I restored it and it worked again! But guess what... after updating the 280 packages that had an update, it stopped working again. But this time it was different. This time it just didn't find the ethernet card. So I could log in into the board locally, the display worked fine through HDMI but there was no network at all. I tried to show all network devices and the card was nowhere to be found. So I thought there was some kind of problem with the kernel. I flashed my backup again and I kept back around 5 packages, linux-image-current-rockchip64 and linux-dtb-current-rockchip64 among them. After that, it still worked so I knew it was one of those 5. At the end I realised the one that broke it was the linux-image-current-rockchip64 as I suspected and it was going from 21.08.2 to 22.02.1. I think that goes from a 5.10.63 kernel to a 5.15.25. This is the moment when it happened: javi@rock64:~$ sudo apt list -a linux-image-current-rockchip64 [sudo] password for javi: Listing... Done linux-image-current-rockchip64/bionic 22.02.1 arm64 [upgradable from: 21.08.2] linux-image-current-rockchip64/bionic,now 21.08.2 arm64 [installed,upgradable to: 22.02.1] linux-image-current-rockchip64/bionic 21.08.1 arm64 linux-image-current-rockchip64/bionic 21.05.9 arm64 linux-image-current-rockchip64/bionic 21.05.4 arm64 linux-image-current-rockchip64/bionic 21.05.1 arm64 linux-image-current-rockchip64/bionic 21.02.3 arm64 linux-image-current-rockchip64/bionic 21.02.2 arm64 javi@rock64:~$ sudo apt install linux-image-current-rockchip64=22.02.1 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: linux-image-current-rockchip64 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 51.2 MB of archives. After this operation, 123 MB disk space will be freed. Get:1 https://stpete-mirror.armbian.com/apt bionic/main arm64 linux-image-current-rockchip64 arm64 22.02.1 [51.2 MB] Fetched 51.2 MB in 10s (5,066 kB/s) (Reading database ... 109695 files and directories currently installed.) Preparing to unpack .../linux-image-current-rockchip64_22.02.1_arm64.deb ... update-initramfs: Deleting /boot/initrd.img-5.10.63-rockchip64 Removing obsolete file uInitrd-5.10.63-rockchip64 Unpacking linux-image-current-rockchip64 (22.02.1) over (21.08.2) ... Setting up linux-image-current-rockchip64 (22.02.1) ... update-initramfs: Generating /boot/initrd.img-5.15.25-rockchip64 modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/drivers/cdrom/cdrom.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/isofs/isofs.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/jfs/jfs.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/reiserfs/reiserfs.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/udf/udf.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/xfs/xfs.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/netfs/netfs.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/fscache/fscache.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/net/sunrpc/sunrpc.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs_common/grace.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/lockd/lockd.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfs.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfsv2.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs_common/nfs_acl.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfsv3.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfsv4.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nls/nls_iso8859-1.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/lib/842/842_decompress.ko.xz not found. modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/drivers/md/dm-mod.ko.xz not found. update-initramfs: Converting to u-boot format And that's it, after rebooting the network card doesn't work anymore. I've tried to run depmod -a update-initramfs -u before updating that package to no avail, still the same errors. I've tried to have both linux-image-current-rockchip64 and linux-dtb-current-rockchip64 packages on the same 21.08.2 version and update both at the same time but the problem still persists. Other people over the DietPi forums are having other kind of issues, like USB3 or other devices not working. So I think there is some problem with this kernel. I know Armbian doesn't support the rock64 any more officially but I thought it was worth to report the problem. Thank you!

A lot. Just out of my head what I'm willing to part with. What I can miss. KM6 TVbox, OrangePi3, RPiZeroW, Tinker Board, Rock64, Atomic Pi. Only for a good price the Khadas VIM2 and Jetson Nano. RPi2B very maybe. I love that one too much, so only +50 euro for that one. I'll have to take a lok at what else I've got.

https://imola.armbian.com/archive/rock64/ ???

For anyone reading this in the future, https://imola.armbian.com/dl/archive/rock64/ is the url. Everything up to and including the version I had was also added to https://armbian.hosthatch.com/archive/rock64/archive/. But the new place even has Armbian_21.08.1_Rock64_bullseye_current_5.10.60 !!! Truly we are living in the blessedest of times!

First, thanks for the tips. It's good to have someone to boune ideas off of. The extcon is the physical port (re: "external connection"), in this case a Typc-C connector on our board. It notifies the phy core that then initiates the callback to the workqueue in the dwc3-rockchip driver. At least that's my understanding. You have to reference the extcon in the usbdrd3 proprerty, which is the rockchip dwc3 driver (the dwc3-simple driver doesn't directly reference an extcon), so it can attach the extcon to the phy. But apparently you also need to attach it to the tcphy0 property, or so it seems based on some other DTS examples. It's very confusing. The extcon driver in this case is fusb302. There is one of those under drivers/usb/typec/tcpm that comes from Google. But that doesn't seem to work no matter what I do with its dts config. So I forward ported the fusb302 driver from the BSP, which comes from rockchip. With some added debug I can see connection events and the callback to the workqueue function. Turns out my version of that patch came later and does not have the call to dwc3_phy_setup() - which is why my port compiled without the core.c/h patch. Of course, that may also be the reason it doesn't work. I ported it from a 4.4 kernel. The ayufan-rock64 kernel is not something I can drop on this device. We're bumped to 5.15.14 (upstream release + custom patches, most if not all are from the net) at the moment and it's tied to the specific u-boot we have. It also probably wouldn't support our display, though I have a serial console so maybe that doesn't matter. My changes are simple, really. They consist of choosing a fusb302 driver: Google's (CONFIG_TYPEC_FUSB302, plus some other typec drivers which I think are required) or Rockchips (CONFIG_FUSB_30X, which is part of my port and is standalone) a dwc3-* driver: dwc3-of-simple (aka CONFIG_USB_DWC3_OF_SIMPLE) or dwc3-rockchip (CONFIG_USB_DWC3_ROCKCHIP, which I've added to the Kconfig). We run as an embedded board so nearly everything is statically compiled, but I make the fusb driver a module and manually load it after boot. This way if any of the drivers lock up it won't happen until the fusb is loaded and I plug something in (or left something plugged in from the last test). Then the DTS is updated to match those selections. There are a few places that this matters. Note that what follows is what I have, but it obviously isn't working. When using the stock drivers (Google fusb302, dwc3-of-simple), it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { // Google fusb compatible = "fcs,fusb302"; fcs,int_n = <&gpio1 2 GPIO_ACTIVE_HIGH>; interrupt-parent = <&gpio1>; interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; vbus-supply = <&vcc5v0_typec0>; status = "okay"; connector { compatible = "usb-c-connector"; data-role = "dual"; label = "USB-C"; op-sink-microwatt = <1000000>; power-role = "dual"; sink-pdos = <PDO_FIXED(5000, 2500, PDO_FIXED_USB_COMM)>; source-pdos = <PDO_FIXED(5000, 1400, PDO_FIXED_USB_COMM)>; try-power-role = "sink"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; usbc_hs: endpoint { remote-endpoint = <&u2phy0_typec_hs>; }; }; port@1 { reg = <1>; usbc_ss: endpoint { remote-endpoint = <&tcphy0_typec_ss>; }; }; }; }; }; }; &u2phy0 { status = "okay"; extcon = <&fusb0>; // otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { // phy-supply = <&vcc5v0_typec0>; status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "okay"; }; port { u2phy0_typec_hs: endpoint { remote-endpoint = <&usbc_hs>; }; }; }; &usbdrd3_0 { status = "okay"; }; &usbdrd_dwc3_0 { status = "okay"; dr_mode = "peripheral"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; }; &tcphy0_usb3 { status = "okay"; extcon = <&fusb0>; port { tcphy0_typec_ss: endpoint { remote-endpoint = <&usbc_ss>; }; }; }; When using the Rockchip fusb302 and dwc3 driver it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { compatible = "fairchild,fusb302"; vbus-5v-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>; int-n-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; fusb302,role = "ROLE_MODE_DRP"; fusb302,try_role = "ROLE_MODE_DRP"; reg = <0x22>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; status = "okay"; }; }; &u2phy0 { status = "okay"; otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "disabled"; }; }; &usbdrd3_0 { status = "okay"; extcon = <&fusb0>; }; &usbdrd_dwc3_0 { status = "okay"; extcon = <&fusb0>; dr_mode = "otg"; /* USB 3.0 */ maximum-speed = "super-speed"; phys = <&tcphy0_usb3>; phy-names = "usb3-phy"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; resets = <&cru SRST_UPHY0>, <&cru SRST_UPHY0_PIPE_L00>, <&cru SRST_P_UPHY0_TCPHY>, <&cru SRST_A_USB3_OTG0>; reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg"; }; &tcphy0_usb3 { status = "okay"; }; I'll try adding that dwc3_phy_setup() call just for grins to see what happens. But I'm not sure it matters if I try to boot in peripheral mode to start with. I think it only matters if I'm trying to use OTG. I'm trying to use peripheral mode only right now just to get device mode working in any way possible (but preferrably at least at HS).

Thanks for sharing the link, that was an interesting read. Seeing the patches jogged my memory a bit. The 'dwc3_rockchip_otg_extcon_evt_work' function is what handles the actual mode switching. Its execution is scheduled using a work queue via the dwc3_rockchip_*_notifier functions which are based on some extcon notifier. I have almost no understanding of what extcon is nor how the notifiers work and how they are ultimately connected to the physical switch. It is possible the physical switch manipulates a basic resistance circuit to force the CC pin resistance to the required amount to force UFP/DFP modes. Once the resistance is forced the dwc3 controller generates IRQs that inform the driver via notifiers? I am guessing here, but it makes sense because the OTG port is wired to a type-A connector which means the physical switch could control the CC pin resistances without interfering since CC pin can't be wired to a type-A connector. You are right about the dwc3 controller needing to be reset at the same time, the patch thread discusses this requirement. In fact, I think it was this very requirement that led to them stripping the 'static' keyword from the 'dwc3_phy_setup' function in dwc3/core.c so it could be called from their new dwc3/dwc3-rockchip.c driver. It was this change in particular that caused the immediate NAK for upstream. I presume that if your port attempts lack the required logic to reset the dwc3 controller managed in core.c that is likely why the work queue item is hanging or locking up the system? What kernel version and from what source did you port the driver? If it isn't from the 'legacy' branch repo used by Armbian it might be worth trying again with the following version which I can confirm has functioning mode switch logic: https://github.com/ayufan-rock64/linux-kernel tag:4.4.202-1237-rockchip-ayufan Are you possibly running into issues getting back to USB2 HS peripheral mode because you still have ported code compiled in? I ask because I took Terry's DTS patch from above and integrated it into the Armbian build for a linux-5.10.y 'current' branch kernel (specifically 5.10.92-rockchip64) and have the peripheral mode operational as long as 'dr_mode = "peripheral"' is set in the built DTB as shown in the patch. I have tested it with mass storage, hid and ncm gadgets, all working as expected.

hello were you able to solve it somehow? I have the same problems on the desktop , with buster and a rock64 , i have black horizontal lightning bolts every x seconds

This message is on-topic, but for an unknown reason, it is not possible for me to create a message in Help wanted. So I post here. I have used Armbian for two years, I think, on several devices, and I have given some money to support it. Thanks for the job. I recently upgraded to the last version with Debian 11. Everything fine but one point which is probably not a bug, that's why I don't post in "bugs". I use Unbound which is the heart of my soft. And I use a python script which is loaded by Unbound. Until now, there was no problem. With the last version, I ran in several read problems. The first reason I found is apparmor, which prevented the script to open a module in /usr/local/lib. I removed apparmor and this solved this problem and another one. But when the scripts must open (read) /home/rock64/unbound.conf, I get a permission denied, even if the file and the directory has 777 permission. I made a lot of tests. I can read the file if copied on some directories, and not in others. I don't understand the logic. I suppose there is another program like apparmor, but I cannot find it. What can prevent Unbound from reading a 777 file ? Thanks if you have an idea.

No, they are here: https://imola.armbian.com/dl/rock64/archive/ All changes regarding new support rules are WIP since we lack people, time and better organisation. There are mistakes here and there. Also we haven't been able to speak with all people that want to help. And after they join, we need to work overtime on overtime to support them. Even we try to keep this project under control its still huge. And expensive - end users wishes and demands (which creates stress and just more damages with negative effect on help) never stops If you can't find image you need - build one. https://docs.armbian.com/Developer-Guide_Build-Preparation/ @kehrnal Maintainer is not a technical demanding role:

One thing I found particularly concerning is that https://armbian.hosthatch.com/archive/rock64/archive/ goes up to `Armbian_21.02.3_Rock64_buster_current_5.10.21.i..> 09-Mar-2021 11:32` while I previously, on `26-Aug-2021` downloaded `Armbian_21.08.1_Rock64_buster_current_5.10.60.img.xz` Are the newer images gone?

hello I have installed rock64 armbian debian bullseye, on the emmc card and I have an ssd disk by usb3, the disk is mounted in /etc/fstab, but every day approx it gives me an error blk_update_request: critical target error, dev sda, sector 250069504 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [18241.624593] Buffer I/O error on dev sda, logical block 31258688, async page read I have tried several discs and it happens to all of them Is there something to be able to install so that I don't get that error

looking at https://github.com/150balbes/build/blob/station-x2/config/sources/families/rockchip64.conf if [[ $BOARD == station-p2 || $BOARD == station-m2 ]]; then BOOTSOURCE='https://github.com/150balbes/u-boot-rk' BOOTBRANCH='branch:rk356x' BOOTPATCHDIR="u-boot-station-p2" KERNELSOURCE='https://github.com/150balbes/rockchip-kernel' KERNELBRANCH='branch:rk35xx' KERNELPATCHDIR='station-p2-'$BRANCH LINUXCONFIG='linux-station-p2-'$BRANCH LINUXFAMILY=station-p2 else KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan' KERNELPATCHDIR='rockchip64-'$BRANCH fi can anyone tell me where this "station-m2" board name comes from? looking at this file https://github.com/150balbes/build/blob/station-x2/config/boards/station-m2.wip # Rockchip RK3566 BOARD_NAME="Station M2" BOARDFAMILY="rockchip64" BOOTCONFIG="firefly-rk3568_defconfig" KERNEL_TARGET="legacy,current,edge" FULL_DESKTOP="yes" BOOT_LOGO="desktop" BOOT_FDT_FILE="rockchip/rk3566-firefly-roc-pc.dtb" SRC_EXTLINUX="yes" SRC_CMDLINE="console=uart8250,mmio32,0xfe660000 console=tty0" ASOUND_STATE="asound.state.station-m2" IMAGE_PARTITION_TABLE="gpt" the string "station-m2" only appears in the filename "station-m2.wip". Is it the filename itself that gets converted into $BOARD or does it get populated some other way?