Odroid C4

[xorinox]

Hello, I have just installed Armbian_20.05.4_Odroidc4_focal_current_5.6.18.img on my Odroid-C4, and encounter the same issue. The board doesn't come back up after rebooting. The ethernet controller is blinking in an interesting way. The right orange NIC LED blink about 5 times, then green and orange LED blink once together. This continues this way. The screen is not enabled after the reboot. Unpowering the board helps to reboot. The last thing you read from the screen before it turns black was: Reached target Reboot.

 

I am using a micro SD card, Samsung Pro 32G. Let me know what information you might want to have posted here.   I do not have the same issue with Odroid's default image, but I prefer your tidy distro

dmesg.log kern.log

[xorinox]

Update: reboot issue on SD card using Armbian_20.05.4_Odroidc4_focal_legacy_4.9.224.img    cannot be reproduced

[xorinox]

Right after booting Armbian_20.05.4_Odroidc4_focal_legacy_4.9.224.img    on a SD card and then running apt update && apt upgrade -y leads to this "Operation not permitted" error message. Not sure if that's important. After the upgrade the board still reboots and comes back online.

 

Processing triggers for systemd (245.4-4ubuntu3.1) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for libc-bin (2.31-0ubuntu9) ...
Processing triggers for ca-certificates (20190110ubuntu1.1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for initramfs-tools (0.136ubuntu6.2) ...
ln: failed to create hard link '/boot/initrd.img-4.9.224-odroidc4.dpkg-bak' => '/boot/initrd.img-4.9.224-odroidc4': Operation not permitted
update-initramfs: Generating /boot/initrd.img-4.9.224-odroidc4
update-initramfs: Converting to u-boot format
Reading package lists... Done
Building dependency tree
Reading state information... Done

[Werner]

9 hours ago, xorinox said:

Right after booting Armbian_20.05.4_Odroidc4_focal_legacy_4.9.224.img    on a SD card and then running apt update && apt upgrade -y leads to this "Operation not permitted" error message. Not sure if that's important. After the upgrade the board still reboots and comes back online.

 

 

Did you check the boot log as well as uname -a? If there are no additional errors and the loaded kernel is the one that is to be expected that you should be just fine.

[Curmudgeon]

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.

[@lex]

12 hours ago, Curmudgeon said:

I've been disappointed with instability (crashes)

 

12 hours ago, Curmudgeon said:

I can enjoy stability for hours on end so long as I don't run htop

I would like to know how htop can crash your system or make crashes. Please provide all information, screenshot when it crashes if you can't access the board. If you are using Desktop, connect also via ssh to grab all armbian info.

 

*edited*

I don't have the board,  maybe you create a new thread related to the problem, i can follow that and share some thoughts. I can test the this Armbian version on another board.

Edited August 21, 2020 by @lex
info

[Technicavolous]

On 8/21/2020 at 5:30 AM, Curmudgeon said:

so long as I don't run htop

I am not able to reproduce this issue. I downloaded all the current images, none can I reproduce this error. Can you give a more detailed description of the session?

 

Reboot appears to be working on SD however. This past two weeks I've been away from the bench. Nice to see!

[Technicavolous]

On 7/15/2020 at 4:45 PM, xorinox said:

apt upgrade -y leads to this "Operation not permitted" error message.

I saw this but the error displayed on the uart terminal before handing off to hdmi.  Haven't seen any operational difference. 

[legogris]

bullseye works all right for me when built from master from Aug 6  (b0331a80c97a2f4072229a8c5fad1cac345d4a24). Have not tried other releases. Booting from MMC. A couple of oddities I noticed:

 

• No video output on HDMI on boot. This isn't an issue for me as I run them headless so I haven't looked more into it. I have not tried desktop.
• The boot partition is too small (this is with cryptroot enabled, though). Adding `BOOTSIZE=400` build parameter fixes that. You can probably get away fine with half of that, but I like to have some headroom in case I need to backup images etc in case of future troubleshooting.
• The hw MAC address gets overridden with a hardcoded one, which is annoying.

 

No stability or performance issues so far. Reboots work fine.

 

For the person(s) with htop issues: Can you run a parallell session with: `sudo dmesg > kernel.log` and post it here after a reboot when htop hangs it?

[Curmudgeon]

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).

[Curmudgeon]

On 8/23/2020 at 2:34 PM, Technicavolous said:

I am not able to reproduce this issue. I downloaded all the current images, none can I reproduce this error. Can you give a more detailed description of the session?

 

Reboot appears to be working on SD however. This past two weeks I've been away from the bench. Nice to see!

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.

[@lex]

Can you show the output of the file log.txt from the command below after the board freeze?

 

* fire htop

* type in the shell:

 

watch -n 10 "dmesg|tail>>log.txt&&echo ----->>log.txt&&sync"

 

 

[Curmudgeon]

@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
-----

[Curmudgeon]

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.

[Technicavolous]

I got a new monitor, basically a monitor and a half - 2560 x 1080. 

 

With image

Armbian_20.08.1_Odroidc4_bionic_current_5.8.5_desktop.img

On boot ("Armbian" with circles going in circles) it is detected as 3840x2160 and when entering the desktop is sets it to 1152x864.

 

I've only tested this image so far.

It seems to identify the monitor by name and size correctly, but can't seem to set that resolution.

 

http://ix.io/2wSV

 

Armbian_20.08.1_Odroidc4_buster_current_5.8.5_desktop.img

also sets the resolution to the above values, but doesn't let me select 1080p (or any other value) and does not detect that it is an LG 35".

[Curmudgeon]

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

[Technicavolous]

What kind of 'support' do you need? If I understand correctly 'support' is being determined now. There are a couple desktop versions on the bottom of the download page. Give them a try. It's still a work in progress, your contributions may assist in the effort.

 

[Curmudgeon]

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.

Edited September 15, 2020 by Curmudgeon

[Igor]

5 hours ago, Curmudgeon said:

any other image would be unwelcome

We have too small resources (we can't pay, you don't see this as a cost) to deal more with this hw and its users so its more or less down to "community support only".
 

5 hours ago, Curmudgeon said:

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

 

Probably armbian-config bug, related to:
https://armbian.atlassian.net/browse/AR-396

Check if speeds are correct with:

cpufreq-info

 

4 hours ago, Curmudgeon said:

Both of the above are "must-haves" for me.

 

Modern kernel with full blown support that will satisfy all of your needs will exists when greater Linux community develops / port feature (very late, often never) or if you pay that features are ported / developed. We can only invest 30-50 of our private hours per day. For more: 

• https://github.com/armbian/build#support
• https://github.com/armbian/build#contribute
• https://www.armbian.com/donate/

 

4 hours ago, Curmudgeon said:

could not sync Chromium to my Google account

 

 

[Curmudgeon]

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.

[Igor]

6 hours ago, Curmudgeon said:

There is an error in boot.ini file which assigns a value

Can you perhaps try to correct this error?

https://github.com/armbian/build/blob/master/config/bootscripts/boot-odroid-c4.ini
https://docs.armbian.com/Process_Contribute/

[Curmudgeon]

 

Quote

Can you perhaps try to correct this error?

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.

[Igor]

10 hours ago, Curmudgeon said:

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.

 

You mean a clean image has that problem?

[Curmudgeon]

2 hours ago, Igor said:

 

You mean a clean image has that problem?

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"

[Igor]

3 minutes ago, Curmudgeon said:

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

I see, then this is a bug. Thanks.

[Curmudgeon]

On 9/24/2020 at 8:18 AM, Igor said:

I see, then this is a bug. 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.

[Igor]

We are moving away from old and smelly legacy u-boot on Odroid C4/HC4 which we used to boot legacy kernel. I made few tests and it seems alright:

C4
https://users.armbian.com/igorp/images/odroidc4/archive/

HC4

https://users.armbian.com/igorp/images/odroidhc4/archive/

Welcome to test and report if some odd bugs might show up.

[mboehmer]

Hi,

 

have been off for a few days, too many ongoing projects.

I'm really happy to see that C4 is now "supported", and want to express my thanks to all people involved!

Aynway, a small issue: the download image is reporting to be officially supported, while both selfcompiled images (buster/focal) report themselfs as "trunk" images without official support.
 

Welcome to Armbian 20.11.0-trunk Buster with Linux 5.9.9-meson64

No end-user support: built from trunk

I used a freshly installed build system from yesterday night.

Is this expected behaviour?

The network controller problem (dwmac reset issue) of previous builts is gone, btw. uSD card issues have not been verified, I'm using eMMC on my systems.

So far, Michael

[Werner]

12 minutes ago, mboehmer said:

Is this expected behaviour?

Yes. Only images from the download page itself receive support.

[mboehmer]

Small update on the official image (Armbian 20.08.22 Focal with Linux 5.9.6-meson64): when I boot from eMMC, everything is fine. Inserting a Samsung uSD card leads to repeated "mmc1: error -84 whilst initialization".

Trying to boot from uSD card (same image, working on eMMC) fails. System is stuck with"Starting kernel..." on console.

Attaching the same uSD card by USB card reader works.

So in case you find troubles with uSD card, check brand and product.