Search the Community

Hi there! I just got my hands on a brand new Odroid C4. I flashed Armbian Bullseye (tried Buster too as Bullseye is marked unstable) onto an SD card. The Issue I'm now facing is, after any sort of kernel update the board will not properly soft reboot anymore. I can restart the freshly installed system (which I generated the ix link with) as many times as I want using /sbin/reboot, but one apt upgrade later the board hangs in limbo when I issue a soft reboot. I can see the system itself shutting down, the blue light stopping to heartbeat, and then nothing happens anymore, until I replug power, then the board boots up fine. I have tried to run nand-sata-install as described on the C4's board page (If you face issues with rebooting run this as root) but it does not help, and I'm not even sure whether it even flashes a new U-Boot at all. Obviously, I have trouble using the board as a server like this, as I'd have to come home and replug it if I ever need to reboot so hopefully this can get fixed Should anyone require further data, I can always provide that.

Hi there, I have an overlay available for Odroid C4 (Kernel 6.6.51), which needs some testing in the field. It supports 12MHz operation max on the pins 19, 21, 23 and 24 on the GPIO header. In case you have a test case for that, let me know, and I can provide things to you. Michael

Hi, after a long time I started up my C4 and tried both the standard download kernel as well as a home compiled one. I need SPI on the C4, so I changed the device tree to meson-sm1-odroid-c4-spidev.dtb, and see spidev kernel modul loaded, but no driver, and I don't get any signals on the corresponding pins. Any help is appreciated - would be great to have SPI working again... See you, Michael

Is there some instructions on how to get opencl with gpu working on the C4 with armbian ? I found https://wiki.odroid.com/odroid-c4/os_images/ubuntu/minimal/20200526#opencl_configuration but the package mali-fbdev isn't available on armbian. Closest I've got is : $ curl -L http://deb.odroid.in/c4/pool/main/m/mali-midgard-driver/mali-fbdev_0.1-2ubuntu4_arm64.deb -o mali-fbdev_0.1-2ubuntu4_arm64.deb $ ar -xv mali-fbdev_* $ tar --use-compress-program=unzstd -xvf data.tar.zst $ sudo cp -r usr/* /usr/ $ mkdir -p /etc/OpenCL/vendors/ $ echo /usr/share/mali-odroid-c4/libmali.so | sudo tee /etc/OpenCL/vendors/mali.icd But then clinfo fails with : $ clinfo Number of platforms 1 Platform Name ARM Platform Platform Vendor ARM Platform Version OpenCL 2.0 git.c8adbf9.ad00b04c1b60847de257177231dc1a53 Platform Profile FULL_PROFILE Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory Platform Extensions function suffix ARM Platform Name ARM Platform Number of devices 1 Failed creating base context during opening of kernel driver. So, presumably, there is a kernel module to be installed as well. I also found https://developer.arm.com/downloads/-/mali-drivers/user-space ... but doesn't indicate support for the C4. Any hints to get further ? Thanks.

Hello I'm running debian bullseye on an Odroid C4 since quite some time now and decided it was a good time to upgrade to bookworm. When I first installed armbian on this board, I remember that I had to install the Odroid HC4 image. If I'm not mistaking, there were no C4 image at the time. After upgrading my current bullseye firmware with armbian-config ( and by passing the SSD issue described in this armbian forum post by hot plugging it ), I noticed that /boot/armbianEnv.txt had this line: fdtfile=amlogic/meson-sm1-odroid-hc4.dtb whereas the amlogic/meson-sm1-odroid-c4.dtb file exists in the /boot/dtb directory. Despite having read that HC4 and C4 were the same board with few differences, dtdiff shows a lot of settings differ between the dtb of the two boards. Similarly, I notice that a bunch of *odroidc4 packages are now present in the repository that I don't remember having seen when I first installed armbian. So before upgrading to bookworm, I was wondering if it would be a good or bad idea to modify the armbianEnv.txt in order to use the C4 dtb, and replace the *odroidhc4 packages by their *odroidc4 equivalents. Did someone already try these changes ? Does someone see any issue with applying this changes ? Will there be other changes to apply in order to fully migrate from the initial HC4 configuration to a possibly more appropriate C4 configuration ? Thanks for your time and answers.

Please move this message to correct folder, if I used the wrong one. There is a grave bug in the ext4 FS, which was introduced in kernel around 6.1.55 and is fixed in kernel 6.1.66. The bug is causing data coruption and data loss, like new packages aren't installed properly. A fix was introduced today into kernel, in version 6.1.66 Armbian Bookworm 23.11.1 (Debian) comes with 6.1.63 and, according to my knowledge, is affected. When will new kernel packages from armbian be available? References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 https://fulda.social/@Ganneff/111551628003050712

I try to profiler the system, but could not find vmlinux binary and kernel debug symbol. The board is Odroid C4, SD card Image is download from armbian website Ubuntu 22.04.3 kernel 6.1.50-current-meson64 Thank you for help

Hello. I am wondering if anyone here has Xenomai working for Amlogic platforms? I'm particularly interested in applying Xenomai to Le Potato/Sweat Potato. According to them, Xenomai is current and working for the Amlogic S905X3 (Odroid C4), though I have failed to find any source, patches, or images for that board. As far as I can tell, aside from some minor performance improvements here and there, the Odroid C4's SoC layout is very comparable to what the Potato boards have. So I only expect minor changes, if anything, to go from that SoC to the Potato's SoC. Xenomai's own guide to porting the dovetail interface is pretty good; I'll do that if I have too. I'm just not trying to reinvent 80% of the wheel if I don't have to either. Not trying to get out of doing work, just doing it twice would be silly. Constructive comments most appreciated! 😄 (FYI, I'm not new to GNU/Linux, the cli, gcc, make, compiling in general, etc. etc. In fact, I have had a build system for Armbian up and running for months now, and can build functional images with it. I've even marginally contributed to Armbian. TL;DR: I won't need much hand holding, just help over one or two obstacles.)

Hi, I have a broken Odroid C2 from a customer. I've never used Odroid so I was wondering if I bought a Odroid C4 and insert the card will it run ok ? Don't know any info about what's in the sd card. The customer bought from a supplier he no long intends to work with ever again. Can anyone help me in any way ?

Hi, I would like to run a 32 bits (armhf) Debian or Ubuntu image on an Odroid C4. Do you know if this is possible, and if it is, can you point me to the right image ? Cheers, jf

Hello, I have trouble activating i2c on odroid c4. There's a pcf8563 module connected to the board. Also, /dev/i2c-0 /dev/i2c-1 exist. But pcf8563 does not show up when I run i2cdetect. I can rule out hardware issue because both i2c and pcf8563 work well with Hardkernel's Ubuntu image. So far, I've tried the followings but they don't work: Adding overlay="i2cA i2cB" to /boot/armbianEnv.txt and reboot. Manually editing device tree by changing status under "i2c@1d000" to "okay" and reboot. Also, I remember that i2c used to work on older versions of Armbian, which come with older version of kernels. But since linux 5.19, i2c no longer works. So I suspect that some changes in kernel may break the i2c functionality. I've uploaded diagnose info to https://paste.armbian.com/pevijojiwa Please advise. Thank you.

As it just happened, na OK, a few hours earlier, rhe name of an networkcard was changed. Why? How? By doing nothing special a real time consumpting work i had to get out what to change now, changing all the scripts and hoping nothing ist lost. what did build all the link local addresses?

I'm running Armbian Cli 23.02.2 Jammy with Linux 6.1.11-meson64 on my OdroidC4, I'd like to be able to boot from a USB3.0 SSD, (I'm aware that this board doesn't have SPI flash memory, so you should sacrifice a micro SD to host the system boot) When I run armbian-config and go to the option to "boot from SD - systemd on SATA, USB or NVMe" the process seems to complete all the steps without difficulty, at the end the process asks to reboot, the problem starts here, at perform the reboot the system never boots, it stays in a loop, the SSD flashes led light as if it had activity, the same my odroid c4 flashes blue led light in a loop, but the system never appears by ssh. I hope someone can help me. Excuse my English, I'm using a translator.

Armbian Armbian 22.11.4 Jammy on Odroid C4 boot from SD card system on an ext4 SSD. First of all - everything I need works correctly... However, I have a question about the SD card. During the first installation on the SSD disk, the system hung on the first reboot and you could see from the console that the SD card with UUID=61748c7e-b234-40e8-b6b6-592f845c3699 was being waited for. After the timeout, the only way to fix the "error" was to log into the system via terminal. Long story - only after commenting out the SD card in the fstab on the SSD: UUID=61748c7e-b234-40e8-b6b6-592f845c3699 /media/mmcboot ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 0 /media/mmcboot/boot /boot none bind 0 0 the system booted from the SSD as requested. Since then, the SD card is not mounted and just shows up as: Disk /dev/mmcblk0: 30.61 MiB, 32096256 bytes, 62688 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes at fdisk -l. No UUID etc nothing... The SD-Card is 32G and is readable on other systems... Question now - is this normal? Can I live with that? Can it be fixed? A "curiosity" - after booting from the SSD and updating the kernel to 6.0.13, the update ended up on both the SSD and the unmounted SD card. How - is a mystery to me (;-)

I've installed Armbian on a Odroid C4 board (running with emmc storage & connected to the orginal power supply). After a few hours or days, the board crashes & throws an error unable to handle kernel paging request at virtual address 000000000002e82e2... See https://pasteboard.co/NjIo5L6UR0Px.jpg for the complete error message System diagnosis information is uploaded to https://paste.armbian.com/aqahepelav

Hi everyone! I've just got a new odroid c4 and am trying to hook it up to a small i2c oled display. I've wired it up to the I2C A SCA and SCL pins with 3.3V and GND as needed, and enabled both I2C A and B in armbian-config. However, when I run i2cdetect -y 0 I get the device grid with a 30 in position 30 and nothing else, both with the display hooked up or not, nothing changes. Is there anything obvious I might have missed to get I2C running? Thanks in advance for your help!

Dear all, I have a strage problem here with handling large files and I ran out of ideas. System: Odroid C4 (running from SD-card) OS: 5.7.15-meson64 #20.08 SMP PREEMPT PRETTY_NAME="Debian GNU/Linux 10 (buster)" Attached to the system are a few USB disks: 3x 8TB, 1x 4TB, 1x 3TB, 1x 2TB All filesystems: ext4 (except the remote NAS filesystem, which is ZFS - see below) 3 of these disks are encrypted via truecrypt 7.1 On the 3 TB disk (ext4, unencrypted) there is a zipped dd-image of a harddisk. That file has about 760 GB size Now I tried to copy this file to a different location. 1st try: rsync to a NAS filer (ZFS, OmniOS, NFSv4) -> The rsync process goes to "D" state after a couple of GB 2nd try: scp to the same NAS -> same result. Copies a couple of gigabytes and then freezes 3rd to 5th try: mounted the NAS via NFSv4 and used rsync, scp and cp to the mountpoint -> same result 6th and 7th try: Tried to copy to a local (truecrypted) 8TB disk using rsync and cp -> same result All these attemts stopped after transferring a couple of gigabytes and then the involved processes showed "defunct" state. The transferred size is different every time and is between 40 an 200 GBytes. What I tried to pinpoint the problem: Tried to read the big file: - md5sum <big_imagefile> -> works! - dd if=<file> of=/dev/null bs=100M -> works! Tried to write a big file: - dd if=/dev/zero of=<file_on_8TB_truecrypted_disk> bs=100M count=10000 -> works! Tried to copy using dd: - dd if=<the_image_file> of=<file_on_truecrypted_disk> bs=100M -> works! Checksum is ok. So I finally managed to copy the file to a different location using dd. But why is cp, scp and rsync failing? Additional information: During the process I did several experiments with the swapspace (disabled, used swapfile on SD-card, etc) nothing helped. In the logfiles there is not the smallest hint to a problem. Also observing the memory during copy using "free" command did not show any unusual state. Systemlimits: root@odroidc4:/var# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 11363 max locked memory (kbytes, -l) 65536 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 11363 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited No overclocking or something. Just a plain Armbian installation. No funny "tuning". I also have the same problem with some other applications. For example rmlint, for eliminating duplicates, runs for a while (30 minutes?) and then freezes. After that I connected the USB disk to a different Linux system and rmlint worked fine. Fun fact: I'm pretty sure I originally copied the long file from a "full size" Linux system via rsync to the Odroid a couple of months ago. Any ideas what the problem could be? Thank you! Lothar

Hi guys, I have issues with audio - only dummy interface shown - after the system update of ~2year old armbian. I did not find any solution, so I decided to go for latest build - so I flashed latest image Armbian 23.02 Jammy XFCE to the emmc drive of my odroid C4. System started ok, but unfortunately no HDMI audio device shown anyway. I have no idea what to do, my dmesq is full of these lines: [ 13.936415] fe.dai-link-0: ASoC: no backend DAIs enabled for fe.dai-link-0 [ 13.937748] fe.dai-link-0: ASoC: error at dpcm_fe_dai_prepare on fe.dai-link-0: -22 ... [ 935.795034] fe.dai-link-0: ASoC: no backend DAIs enabled for fe.dai-link-0 [ 935.801472] fe.dai-link-0: ASoC: error at dpcm_fe_dai_prepare on fe.dai-link-0: -22 I believe it is connected - there are some similar issues reported on various distros. Only solution, which seems to me would work, was reinstall odroid-base and odroid-alsa packages, however these are not in the armbian repositories. Would you please help what should I do to resolve such challenge? Or at least where are these packages, please?

I cannot find the serial number with Armbian 23.02.2 on ODroid C4. On ODroid C2 with Armbian 22.11.2 and older versions it was readable on /sys/firmware/devicetree/base/serial-number. This does not exist anymore on C4. I do not know if it depends on Armbian version or board type.

How to run Armbian on Odroid C4? I followed official guide (https://docs.armbian.com/User-Guide_Getting-Started), but I always ends up with following: Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! UUID=e614931e-7b37-40f0-8d34-c3ca836004e8 does not exist. Dropping to a shell! SD-Card is working fine when other OS is used (such as Ubuntu provided by Hardkernel) Am I missing something?

The proposed solution here (https://github.com/armbian/build/pull/4824) basically performs a power-reset of the SDCARD in the final moments in order to prepare for the bootloader's (Uboot) restart. What puzzles me is that the kernel has a Watchdog feature which seems to operating fine as witnessed by the console log "watchdog: watchdog0: watchdog did not stop!" meaning that the watchdog driver has been told to disregard attempts to disable it (which is fine in the context that the watchdog is being used to reset the cpu). The problem is, the watchdog never times-out because, i presume, something is still "kicking the dog" (there seems to be a worker thread tasked for this purpose). As a test I "brutally" caused a watchdog timeout (watchdog_dev.c: watchdog_release()) by: 1) disabling interrupts 2) setting watchdog timeout to 2 secs 3) going into infinite loop The board now reboots fine and reliably but clearly i've skipped the notification handler mechanism that is meant to be used in the "odroid-reboot.c" solution. So I guess my question is, are reboots meant to be an elegant hand-off from kernel to uboot, or is the watchdog supposed to be the means to get all registers/pin to their POR state ready for a cold boot? I'm new here so didn't know where to post, let me know the preferred place or whether it's not appropriate.

ODROID C4 : How can I configure SDIO bus on GPIO 40 pins ? I beleave that ODROID-C4 GPIO 40pins supports SDIO bus by SoC GPIO pin configuration. How can I get such pin configuration, that enables SDIO bus on GPIO 40 pins? Are there someone who got such configuration? Thank you .

My buddy gave me his Odroid C4 when he bought a Raspberry and it has been reset for me to use. I plugged it into my new fibre modem. It has access to the internet. I have my PC upstairs with lots of videos I have downloaded. I used to use a WD box to watch my movies. I can't seem to get the new Odroid to connect to the network. I use windows 10 and didn't have a problem sharing files before. Does anyone have idea on how to hock the systems so they will share files??? Rod

Hello to all, I have an OdroidC4 with a Hardkernel HDMI Display VU7Aplus. I installed latest image 22.11 XFCE. I think the display size via display data channel is not properly handled. If a lot of text is to be displayed (see pic with the setting of the locale after first login), the lowest lines disappear. So you have to type in the language/continent/country settings blind, because there is no input prompt to be seen. Even when the GUI desktop starts, there is the same issue. When you open a terminal window, the lower border of the window disappears (see pic). Is there a way to configure the display size manually? I also did a complete new build (Armbian_23.02.0-trunk_Odroidc4_jammy_current_6.1.11_xfce_desktop) , there is the same problem, as with the stable image from the download area. Thanks for any help in advance Andy

Hi, just returned to start working on a FLIR Lepton camera, with Odroid C4, hooked up to SPI (faster than the C2). WIth the official image from download page (Armbian 22.08 Jammy, kernel 5.10.144) I get the following message on console as soon as I try any access to spidev: [ 77.660325] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 77.666930] Mem abort info: [ 77.670400] ESR = 0x86000004 [ 77.673801] EC = 0x21: IABT (current EL), IL = 32 bits [ 77.677915] SET = 0, FnV = 0 [ 77.681367] EA = 0, S1PTW = 0 [ 77.684796] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000f26b000 [ 77.690454] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 77.697196] Internal error: Oops: 86000004 [#1] PREEMPT SMP [ 77.702645] Modules linked in: spidev rfkill cpufreq_powersave cpufreq_conservative lz4hc lz4hc_compress lz4 snd_soc_hdmi_codec snd_soc_meson_axg_tdmout snd_soc_meson_axg_sound_card snd_soc_meson_g12a_tohdmitx panfrost snd_soc_meson_card_utils gpu_sched snd_soc_meson_codec_glue snd_soc_meson_axg_frddr snd_soc_meson_axg_fifo meson_gxbb_wdt meson_vdec(C) v4l2_mem2mem ir_nec_decoder videobuf2_dma_contig meson_rng dw_hdmi_i2s_audio videobuf2_memops videobuf2_v4l2 videobuf2_common meson_saradc videodev rc_odroid mc meson_ir rc_core snd_soc_meson_axg_tdm_interface snd_soc_meson_axg_tdm_formatter snd_soc_core ac97_bus snd_pcm_dmaengine snd_pcm snd_timer snd soundcore display_connector zram sch_fq_codel ramoops reed_solomon nfsd efi_pstore auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 meson_gxl reset_meson_audio_arb rtc_meson_vrtc axg_audio sclk_div clk_phase dwmac_generic realtek dwmac_meson8b [ 77.810859] CPU: 2 PID: 3156 Comm: spidev_test Tainted: G C 5.10.144-meson64 #22.08.2 [ 77.819904] Hardware name: Hardkernel ODROID-C4 (DT) [ 77.824823] pstate: a0400009 (NzCv daif +PAN -UAO -TCO BTYPE=--) [ 77.830777] pc : 0x0 [ 77.835509] lr : meson_spicc_pow2_determine_rate+0x2c/0x40 [ 77.840340] sp : ffff800012eb3920 [ 77.845116] x29: ffff800012eb3920 x28: 0000000000000000 [ 77.849906] x27: ffff000001170800 x26: 0000000000000000 [ 77.854808] x25: 0000000000000000 x24: ffff80001134cdf8 [ 77.860069] x23: 0000000000000002 x22: 0000000000000000 [ 77.865331] x21: ffff800012eb3a70 x20: ffff000000d75f00 [ 77.870594] x19: 0000000000000000 x18: 0000000000000000 [ 77.875854] x17: 0000000000000000 x16: 0000000000000000 [ 77.881115] x15: 0000aaaaaf3a3018 x14: 0000000000000000 [ 77.886376] x13: 0000000000000000 x12: 0000000000000000 [ 77.891637] x11: 0000000000000000 x10: 0000000000000054 [ 77.896898] x9 : 0000000000000001 x8 : 0000000000000001 [ 77.902159] x7 : 00000000ffffffbf x6 : 0000000000000000 [ 77.907421] x5 : 0000000000000000 x4 : ffff800012eb39c0 [ 77.912682] x3 : ffff800012eb3d30 x2 : 0000000000000000 [ 77.917943] x1 : ffff800012eb39c0 x0 : ffff00003f9c9e28 [ 77.923206] Call trace: [ 77.927258] 0x0 [ 77.931291] clk_core_determine_round_nolock.part.30+0x20/0x88 [ 77.935568] clk_core_round_rate_nolock+0x80/0x90 [ 77.940226] clk_mux_determine_rate_flags+0xdc/0x208 [ 77.945145] clk_mux_determine_rate+0x14/0x20 [ 77.949456] clk_core_determine_round_nolock.part.30+0x20/0x88 [ 77.955234] clk_core_round_rate_nolock+0x80/0x90 [ 77.959889] clk_core_set_rate_nolock+0x5c/0x1f0 [ 77.964460] clk_set_rate+0x38/0xa8 [ 77.968504] meson_spicc_transfer_one+0x88/0x300 [ 77.972483] spi_transfer_one_message+0x258/0x4c0 [ 77.977139] __spi_pump_messages+0x34c/0x570 [ 77.981366] __spi_sync+0x1e8/0x220 [ 77.985297] spi_sync+0x30/0x58 [ 77.989235] spidev_sync+0x48/0x80 [spidev] [ 77.993146] spidev_message+0x2e0/0x400 [spidev] [ 77.997026] spidev_ioctl+0x41c/0x848 [spidev] [ 78.001033] __arm64_sys_ioctl+0xa8/0xe8 [ 78.004914] el0_svc_common.constprop.4+0x8c/0x180 [ 78.009656] do_el0_svc+0x24/0x90 [ 78.013090] el0_svc+0x14/0x20 [ 78.016370] el0_sync_handler+0x90/0xb8 [ 78.019747] el0_sync+0x160/0x180 [ 78.023032] Code: bad PC value [ 78.026046] ---[ end trace b73c9916d0bfd2d6 ]--- This behaviour affects also simple programs like spidev_test from kernel archive. I checked the hardkernel image (kernel 4.9) and there the problem is not existing. Any ideas on that? Thanks in advance, Michael