alchemist

oh, thanks! I will take a look on this release of Armbian :-)

Hi! seems the udev rule needs to be rewritten too. I will look at that later... EDIT: @BipBip1981 do you really run kernel 5.15 or is your workaround for 5.10?

Hi, I thought this forum did support on the Helios{4,64} regardless of the OS since Kobol is now closed. More, the issues I encounter testing the Armbian patches can be helpful for the future Armbian releases (I had the eMMC issues long time before many Armbian users were impacted with the Buster update). I did tried to apply the Armbian patches for kernel 5.15, but they fail because Helios4 and 64 are now mainlined. But not problem, I will try to fix it by myself, and report back the solution here. I have the skills to do it. BTW I have the same issue with vanilla kernel 5.15 and Helios4. I will test it first on the helios4 because it's not used anymore. Kind regards, Xavier Miller

Hi! I am trying the vanilla 5.15 kernel which has support for helios64. The system is booting, disks, MMC and network are working. But fancontrol fails. It seems the /sys entries have changed and the udev rules are not working. I've tried to understand the wiki page in order to adapt the udev rules and fancontrol config file but I am a little bit lost. Is there updated versions of those config files? Kind regards, Xavier Miller.

YEAH ! I can compile and boot linux-5.10.63, I only had to disable the rk3328 patches because some patches were rejected. I booted from sdcard, updated the /boot folder, then rebooted from eMMC and I can again run and write on the eMMC :-) EDIT: and upgraded to 5.10.64 this weekend without any issue

Hi! If I remove the patches that don't compile and adapt the other ones, the resulting kernel is having issues with eMMC or unbootable kernel (u-boot does bootloops). I even tried some older versions that did work (i.e. recompile one of my ancient kernels with vanilla sources + gentoo patches + armbian patches) and it fails. But I didn't do it with method, I wanted to have a stable kernel to have back my "production" home server. The kernel I run is now " 5.10.34-gentoo #1 SMP Mon May 3 10:47:06 CEST 2021 aarch64 GNU/Linux", the version I had in one backup. After May 3 2021 I had issues with u-boot (kernel did not boot) or not compiling patches. I can help you (armbian poeple) to point the problems. In fact, I would like to rebuild all the provides binaries (u-boot, kernel) myself in order to understand how they are working and configured.

I am talking about patches provided by armbian. They still continue to support our Helios64 :-)

Thank you, but I will wait until it is documented.

ok, but is kernel 5.13 useable? what are the known issues? the features matrix is not updated accordingly on the wiki...

Hi! In the Kobol wiki, there are 2 supported kernels : 4.4 and 5.10 In the armbian-build GIT repo, I see also patches for 5.13. What is the status of the 5.13 patches for the Helios64? Kind regards, Xavier Miller

FYI, I am running a custom kernel based on chosen armbian patches. Seems I need to add some more... Re-patching and re-compiling until I get the kernel running (some arbmian patches don't compile on 5.10.55) EDIT: reverted to an older kernel (5.10.34) and eMMC is operational :-)

Hi, I got write errors on the eMMC, and the filesystem becomes read-only. Dmesg shows that: [ 304.982737] mmc2: running CQE recovery [ 304.987677] mmc2: running CQE recovery [ 304.989762] blk_update_request: I/O error, dev mmcblk2, sector 26826008 op 0x1:(WRITE) flags 0x4000 phys_seg 127 prio class 0 [ 304.989791] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789645 starting block 3353569) [ 305.021383] mmc2: running CQE recovery [ 305.026213] mmc2: running CQE recovery [ 305.030808] mmc2: running CQE recovery [ 305.032702] blk_update_request: I/O error, dev mmcblk2, sector 26265544 op 0x1:(WRITE) flags 0x4000 phys_seg 111 prio class 0 [ 305.033382] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 793979 starting block 3283345) [ 305.109165] mmc2: running CQE recovery [ 305.114772] mmc2: running CQE recovery [ 305.120284] mmc2: running CQE recovery [ 305.125405] mmc2: running CQE recovery [ 305.126960] blk_update_request: I/O error, dev mmcblk2, sector 25560376 op 0x1:(WRITE) flags 0x0 phys_seg 15 prio class 0 [ 305.126976] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789517 starting block 3195094) [ 305.128183] mmc2: running CQE recovery [ 305.132052] mmc2: running CQE recovery [ 305.138255] mmc2: running CQE recovery [ 305.143172] mmc2: running CQE recovery [ 305.143705] blk_update_request: I/O error, dev mmcblk2, sector 25568256 op 0x1:(WRITE) flags 0x0 phys_seg 11 prio class 0 [ 305.143719] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789519 starting block 3196066) [ 305.146059] mmc2: running CQE recovery [ 305.150856] mmc2: running CQE recovery [ 305.153652] blk_update_request: I/O error, dev mmcblk2, sector 25566136 op 0x1:(WRITE) flags 0x0 phys_seg 14 prio class 0 [ 305.153674] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789524 starting block 3195813) [ 305.156107] mmc2: running CQE recovery [ 305.161761] mmc2: running CQE recovery [ 305.166281] mmc2: running CQE recovery [ 305.173900] mmc2: running CQE recovery [ 305.179678] mmc2: running CQE recovery [ 305.184108] mmc2: running CQE recovery [ 305.189973] mmc2: running CQE recovery [ 305.192654] blk_update_request: I/O error, dev mmcblk2, sector 25550264 op 0x1:(WRITE) flags 0x0 phys_seg 6 prio class 0 [ 305.192674] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789534 starting block 3193811) [ 305.195645] mmc2: running CQE recovery [ 305.201382] mmc2: running CQE recovery [ 305.206397] mmc2: running CQE recovery [ 305.209876] mmc2: running CQE recovery [ 305.212505] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789547 starting block 3194323) [ 305.215282] mmc2: running CQE recovery [ 305.267254] mmc2: running CQE recovery [ 305.272126] mmc2: running CQE recovery [ 305.276368] mmc2: running CQE recovery [ 305.282479] mmc2: running CQE recovery [ 305.287200] mmc2: running CQE recovery [ 305.291543] mmc2: running CQE recovery [ 305.315011] JBD2: Detected IO errors while flushing file data on mmcblk2p1-8 [ 305.317983] mmc2: running CQE recovery [ 305.322443] mmc2: running CQE recovery [ 305.329227] mmc2: running CQE recovery [ 305.330168] Aborting journal on device mmcblk2p1-8. [ 305.332721] mmc2: running CQE recovery [ 305.333640] EXT4-fs error (device mmcblk2p1): ext4_journal_check_start:83: Detected aborted journal [ 305.334031] EXT4-fs (mmcblk2p1): Remounting filesystem read-only [ 305.334048] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794035, error -30) [ 305.334380] EXT4-fs error (device mmcblk2p1): ext4_journal_check_start:83: Detected aborted journal [ 305.335183] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794033, error -30) [ 305.336335] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794038, error -30) [ 305.337472] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794037, error -30) [ 305.337497] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794036, error -30) [ 305.339676] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794039, error -30) I did a fsck, and rebooted, but it gives the same kind of errors after that, It seems I cannot write on eMMC anymore. I use eMMC to store the boot script + a rescue subsystem (I boot it by renaming /boot.rescue to /boot). It is formatted as a ext4 partition. What can I do to get back to a sane state ? Kind regards, Xavier Miller.

Mine is rock solid too, running nextcloud on nginx, nfs, samba, mysql. I have a custom system.

yeah, but the feeling is less than 2 seconds. Can it because the flashing starts after the message (no lit, then lit)? Meanwhile, I have my custom kernel and OS (Gentoo Linux), they run fine :-)

Hi!, I am playing around with customizing my boot script (to install later my custom distro), and I am fighting with the Recovery. I took a long time to understand I have to press the recovery button during a "long time", then release it very quickly to get the UMS mode and not falling into the Maskrom mode. Indeed, when U-Boot detects the recovery button keypress, it proposes UMS, then very shortly after the Maskrom mode. Is it possible to configure U-Boot to wait longer on the UMS mode, let's say 5 seconds, and after that delay switch to Maskrom mode as latest failover? For info: I have Armbian running on EMMC, and I play within the /boot folder, then roll-back my trials in Recovery/UMS mode. Kind regards, Xavier Miller.