Curmudgeon

Maybe same problem with my Odroid-N2. Blue LED is on and not blinking. Upgraded to kernel 5.9.10 this morning. Curiously, there is a zero length file in /boot named .next that may have diagnostic significance. Added later: Another anomaly - in /boot there is a symbolic link uInitrd -> uInitrd-5.9.6-meson64 but the target file does not exist.

Noted, thanks.

There seems to be a design problem. Armbian_20.08.1_Odroidn2_focal_legacy_4.9.232_desktop.img was working well for my use cases. It could be booted directly from the uSD card or via the SPI program (PetitBoot) in a multi-boot situation. Sadly a recent upgrade has made a significant change to the Armbian booting architecture. Instead of the boot.ini file declaring which partition holds the root file system, this is now done by an entry in /boot/armbianEnv.txt. I don't know what this change was intended to achieve but, for me the consequence is that the Armbian image is no longer compatible with PetitBoot. I now have to decide whether I want to use only Armbian or to have a choice of several bootable images via PetitBoot.

I got the kernel from users.armbian.com/balbes150/arm-64 via forum.armbian.com/topic/12162-single-armbian-image-for-rk-aml-aw-aarch64-armv8 but I am currently reconsidering whether to continue using this kernel or not because balbes150 seems to have taken on an unfavourable, possibly even malevolent attitude towards AMlogic SoC's.

I'm running the balbes150 Armbian_20.10_Arm-64_focal_current_5.9.0-rc7_desktop and I'm very happy with it. Using the performance governor and highest selectable CPU frequency (1992 MHz by Armbian-config), CPU temperature is normally below 40C and CPU frequencies are 1.91/1.99 GHz for big/LITTLE cores respectively. However, htop reports 1.99 GHz for all cores. If I execute cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq the values 1992000 and 1908000 are returned.

Yes. If I do a clean install to uSD card of Armbian_20.08.1_Odroidc4_focal_legacy_4.9.232_desktop.img, the boot.ini file will be as it was before my recent changes relating to CPU frequencies. If I then do sudo apt update, sudo apt upgrade, the boot.ini file is replaced by the one I submitted with my CPU frequency changes but there is another change that I did not make. Line 3 now is: setenv rootdev "/dev/mmcblk0p1" and the image will not boot unless I manually restore line 3 to: setenv rootdev "/dev/mmcblk1p1". Alternatively, I can manually restore line 3 to its original state: setenv rootdev "UUID=d3dbee0b-9c4d-424b-9eb3-e91a2b1a250b"

Yes, I tried but now a new error has appeared in boot.ini line 3 which I am unable to fix. The declaration of rootfs should be UUID driven but the new boot.ini file specifies a fixed location that will only work if the installation is on the eMMC device.

I've investigated the problem regarding CPU frequencies with Armbian_20.08.1_Odroidc4_focal_legacy_4.9.232_desktop. There is an error in boot.ini file which assigns a value (initially 1908) to the environment variable, max_freq_a55 but then fails to include this in the list of bootargs for passing to the kernel. Consequently the kernel imposes an alternative maximum (1800) when developing its list of available frequencies that are acted on by armbian-config.

My reading of the armbian.com/odroid-c4 page was that the only supported image is Armbian_20.08.1_Odroidc4_focal_current_5.8.5 and I presumed that bug reports for any other image would be unwelcome. The image I have been using is Armbian_20.08.1_Odroidc4_focal_legacy_4.9.232_desktop and I've found it generally satisfactory but with a couple of annoying issues, the main one being that Armbian config does not allow any CPU clock frequencies of > 1.8 GHz, regardless of the maximum declared in boot.ini . I'm accustomed to being able to operate overclocked at 2.1 GHz using HardKernel's Mate Desktop with 4.9.230 kernel. I tried out Armbian_20.08.1_Odroidc4_buster_current_5.8.5_desktop.img but: a) could not sync Chromium to my Google account, and b) sound was not available Both of the above are "must-haves" for me.

Is there any desktop version of Armbian for Odroid-C4 planned to be supported in the near future?

I am now running a test of htop (2.2.0-5~armbian20.08.1+1) and it has so far run for uptime of 01:37:51 without incident. I expect that I will adopt Armbian 20.08.1 now and, accordingly I see no good reason to pursue this issue further. Thank you @lex and Technicavolous for your assistance.

@lex, log.txt file from start to finish was unchanging and ended as follows: ----- [ 17.642229] meson6-dwmac ff3f0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 17.642258] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 20.628273] asoc-aml-card odroid_hdmi: S/PDIF Playback disable [ 20.628399] spdif_a keep clk continuous [ 20.628405] aml_spdif_close [ 20.628510] audio_ddr_mngr: frddrs[0] released by device ff660000.audiobus:spdif@0 [ 62.472149] fb: mem_free_work, free memory: addr:800000 [ 239.265897] usb 2-1.3: USB disconnect, device number 3 [ 239.279241] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 239.279335] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK -----

The htop problem is quite repeatable for me using the following procedure: 1. Make a fresh install of Armbian_20.08_Odroidc4_focal_legacy_4.9.232_desktop on uSD 2. Boot from the newly installed image and complete the installation with sudo apt update, sudo apt upgrade, sudo reboot. 3. Activate htop and wait for 10 minutes or so til the blue heartbeat LED stops flashing.

I'm away from home at present and can't investigate htop issue further til next week. I shall try to shed some more light then. Thanks for you response(s).

In recent weeks I've been trialling Armbian on an Odroid-C4 as a general purpose desktop computer. I've been disappointed with instability (crashes) but put it down to the immaturity of Armbian support for Odriod-C4. However, today I have realised that I can enjoy stability for hours on end so long as I don't run htop . This behaviour relates to Armbian_20.08_Odroidc4_focal_legacy_4.9.232_desktop (and possibly Armbian 20.05.4_focal_legacy_4.9.224_desktop) and htop (2.2.0-3~armbian19.11.9+1). I apologise if this is not the right place to report such a problem.