Recommended Posts

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

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

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

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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 by @lex
info
Link to post
Share on other sites
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!

Link to post
Share on other sites

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?

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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 by Curmudgeon
Link to post
Share on other sites
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: 

 

4 hours ago, Curmudgeon said:

could not sync Chromium to my Google account

 

 

Link to post
Share on other sites

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.

Link to post
Share on other sites

 

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.

Link to post
Share on other sites
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"

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
  • Igor pinned this topic

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...