Search the Community
Showing results for tags 'odroidc2'.
-
Hi guys, i have a question regarding the installation method of the two operating systems. On my OrangePI3 I booted the operating system from micro sd card and told armbian bionic that the eMMC memory will only be used as a boot loader while the rootfs of the actual operating system is installed on a connected USB stick. Is it the same with the Armbian Bionic for the Odroid C2 version? Or is it the case that the future operating system is written directly to the eMMC memory and booted from there? And then there was the reminder that Odroid C2 does not boot from USB. . . Can I use it as described for OrangePI3?
-
I am trying to connect a PPS source to an ODROID-C2 board using GPIO. I am running Armbian 19.11.3 Buster, with kernel 5.3.11-meson64. I downloaded the Armbian kernel source for this kernel, added the following to meson-gxbb-odroidc2.dts, and compiled and installed it: pps { compatible = "pps-gpio"; gpios = <&gpio GPIOY_3 GPIO_ACTIVE_HIGH>; status = "okay"; interrupt-parent = <&gpio_intc>; interrupts = <26 IRQ_TYPE_LEVEL_LOW>; }; When I boot and load the pps-gpio module, I get the following error: pps-gpio pps: failed to map GPIO to IRQ: -6 pps-gpio: probe of pps failed with error -22 Could anyone help me understand what I'm getting wrong that's causing this error? Am I misunderstanding how to assign IRQs to GPIOs?
-
Hi all, preparing an image for our next deployment (10 Odroid C2), I found that somehow the MAC address visible in Uboot doesn't make it into Armbian system. On the first copied system (I use odroidbackup.pl), in Uboot "Printenv" I get ethaddr=00:1e:06:36:58:63 Original system gives me: ethaddr=00:1e:06:34:fa:1a Both systems report to our DHCP server with the latter MAC, which will lead to troubles when both boards will be in the same network Any hints how to get the (apparently eFuse stored) MAC into the Armbian system? Thanks in advance, Michael
-
Hello, After upgrade Armbian (4.19.69-meson64) to Armbian Buster with Linux 5.3.11-meson64 warning messages shows up on boot in dmesg: ... [ 1.973932] Key type encrypted registered [ 1.985109] dwc2 c9000000.usb: c9000000.usb supply vusb_d not found, using dummy regulator [ 1.985153] dwc2 c9000000.usb: c9000000.usb supply vusb_a not found, using dummy regulator [ 1.986616] phy phy-c0000000.phy.0: USB ID detect failed! [ 1.986623] phy phy-c0000000.phy.0: phy poweron failed --> -22 [ 1.986643] ------------[ cut here ]------------ [ 1.986700] WARNING: CPU: 3 PID: 68 at drivers/regulator/core.c:2036 _regulator_put+0x34/0xd8 [ 1.986702] Modules linked in: [ 1.986709] CPU: 3 PID: 68 Comm: kworker/3:1 Not tainted 5.3.11-meson64 #19.11.3 [ 1.986711] Hardware name: Hardkernel ODROID-C2 (DT) [ 1.986719] Workqueue: events deferred_probe_work_func [ 1.986724] pstate: 60000005 (nZCv daif -PAN -UAO) [ 1.986728] pc : _regulator_put+0x34/0xd8 [ 1.986732] lr : _regulator_put+0x34/0xd8 [ 1.986733] sp : ffff000011683af0 [ 1.986735] x29: ffff000011683af0 x28: 0000000000000000 [ 1.986739] x27: ffff80007f2ac6b8 x26: ffff000011106530 [ 1.986743] x25: 0000000000000000 x24: 0000000000000009 [ 1.986746] x23: ffff000011683bb8 x22: ffff80006a1c2b00 [ 1.986750] x21: ffff0000113916c8 x20: ffff80006a1c2d00 [ 1.986753] x19: ffff80006a1c2d00 x18: ffff0000113ae000 [ 1.986756] x17: 000000003ae42590 x16: 00000000ed672116 [ 1.986760] x15: 00000000fffffff0 x14: ffff0000114be0fa [ 1.986763] x13: 0000000000000000 x12: ffff0000114bd000 [ 1.986767] x11: ffff0000113ae000 x10: ffff0000114bd748 [ 1.986770] x9 : 0000000000000000 x8 : 0000000000000001 [ 1.986774] x7 : 00000000000000eb x6 : ffff0000114bd000 [ 1.986777] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.986780] x3 : 00000000ffffffff x2 : 3c797d94ab3f0f00 [ 1.986783] x1 : 0000000000000000 x0 : 0000000000000024 [ 1.986787] Call trace: [ 1.986792] _regulator_put+0x34/0xd8 [ 1.986796] regulator_put+0x2c/0x40 [ 1.986800] regulator_bulk_free+0x30/0x50 [ 1.986805] devm_regulator_bulk_release+0x18/0x20 [ 1.986810] release_nodes+0x1b0/0x220 [ 1.986814] devres_release_all+0x34/0x58 [ 1.986818] really_probe+0x1b8/0x3d0 [ 1.986822] driver_probe_device+0xdc/0x130 [ 1.986825] __device_attach_driver+0x88/0x108 [ 1.986828] bus_for_each_drv+0x78/0xc8 [ 1.986831] __device_attach+0xd4/0x158 [ 1.986834] device_initial_probe+0x10/0x18 [ 1.986837] bus_probe_device+0x90/0x98 [ 1.986840] deferred_probe_work_func+0x88/0xd8 [ 1.986846] process_one_work+0x1e0/0x338 [ 1.986850] worker_thread+0x240/0x440 [ 1.986854] kthread+0x120/0x128 [ 1.986859] ret_from_fork+0x10/0x18 [ 1.986861] ---[ end trace 629d4ecc13425951 ]--- [ 1.986907] ------------[ cut here ]------------ [ 1.986942] WARNING: CPU: 3 PID: 68 at drivers/regulator/core.c:2036 _regulator_put+0x34/0xd8 [ 1.986943] Modules linked in: [ 1.986948] CPU: 3 PID: 68 Comm: kworker/3:1 Tainted: G W 5.3.11-meson64 #19.11.3 [ 1.986950] Hardware name: Hardkernel ODROID-C2 (DT) [ 1.986954] Workqueue: events deferred_probe_work_func [ 1.986958] pstate: 60000005 (nZCv daif -PAN -UAO) [ 1.986962] pc : _regulator_put+0x34/0xd8 [ 1.986965] lr : _regulator_put+0x34/0xd8 [ 1.986967] sp : ffff000011683af0 [ 1.986969] x29: ffff000011683af0 x28: 0000000000000000 [ 1.986972] x27: ffff80007f2ac6b8 x26: ffff000011106530 [ 1.986976] x25: 0000000000000000 x24: 0000000000000009 [ 1.986979] x23: ffff000011683bb8 x22: ffff80006a1c2b00 [ 1.986983] x21: ffff0000113916c8 x20: ffff80006a1c2e00 [ 1.986986] x19: ffff80006a1c2e00 x18: ffff0000113ae000 [ 1.986989] x17: 000000003ae42590 x16: 00000000ed672116 [ 1.986993] x15: 00000000fffffff0 x14: ffff0000114be0fa [ 1.986996] x13: 0000000000000000 x12: ffff0000114bd000 [ 1.987000] x11: ffff0000113ae000 x10: ffff0000114bd748 [ 1.987003] x9 : 0000000000000000 x8 : 0000000000000001 [ 1.987006] x7 : 0000000000000118 x6 : ffff0000114bd000 [ 1.987010] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.987013] x3 : 00000000ffffffff x2 : 3c797d94ab3f0f00 [ 1.987016] x1 : 0000000000000000 x0 : 0000000000000024 [ 1.987019] Call trace: [ 1.987023] _regulator_put+0x34/0xd8 [ 1.987027] regulator_put+0x2c/0x40 [ 1.987030] regulator_bulk_free+0x30/0x50 [ 1.987034] devm_regulator_bulk_release+0x18/0x20 [ 1.987038] release_nodes+0x1b0/0x220 [ 1.987041] devres_release_all+0x34/0x58 [ 1.987044] really_probe+0x1b8/0x3d0 [ 1.987048] driver_probe_device+0xdc/0x130 [ 1.987051] __device_attach_driver+0x88/0x108 [ 1.987053] bus_for_each_drv+0x78/0xc8 [ 1.987056] __device_attach+0xd4/0x158 [ 1.987059] device_initial_probe+0x10/0x18 [ 1.987062] bus_probe_device+0x90/0x98 [ 1.987065] deferred_probe_work_func+0x88/0xd8 [ 1.987069] process_one_work+0x1e0/0x338 [ 1.987072] worker_thread+0x240/0x440 [ 1.987075] kthread+0x120/0x128 [ 1.987078] ret_from_fork+0x10/0x18 [ 1.987081] ---[ end trace 629d4ecc13425952 ]--- [ 1.987135] dwc2: probe of c9000000.usb failed with error -22 [ 1.987536] dwc2 c9100000.usb: c9100000.usb supply vusb_d not found, using dummy regulator [ 1.987581] dwc2 c9100000.usb: c9100000.usb supply vusb_a not found, using dummy regulator [ 2.024002] mmc0: new HS200 MMC card at address 0001 ... I haven't had any system hangups yet but I am worried.
-
Hello, I am using up to date Armbian - Debian Buster with Armbian Linux 4.19.69-meson64 Linux version 4.19.69-meson64 (root@builder) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.95 SMP PREEMPT Mon Sep 2 01:21:39 CEST 2019. I have encountered Ethernet interface lockup on medium traffic (after 30s-120s when copying big files from external usb disk by sshfs - 240Mb/s). At high/medium Ethernet traffic the issue always occurs. It is most likely caused by some kernel update because I didn't have such problem before. Similar issue: https://github.com/rockchip-linux/kernel/issues/27 [ 1584.165514] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: discard [ 1689.827553] ------------[ cut here ]------------ [ 1689.827600] NETDEV WATCHDOG: eth0 (meson8b-dwmac): transmit queue 0 timed out [ 1689.827721] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x2b4/0x2c0 [ 1689.827736] Modules linked in: uas nf_log_ipv4 nf_log_common nft_limit xt_tcpudp xt_multiport xt_LOG xt_limit xt_conntrack nft_counter nft_chain_nat_ipv4 ipt_MASQUERADE nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink meson_rng rng_core scpi_hwmon meson_gxbb_wdt ip_tables x_tables realtek [ 1689.827866] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.69-meson64 #5.95 [ 1689.827871] Hardware name: Hardkernel ODROID-C2 (DT) [ 1689.827881] pstate: 20000005 (nzCv daif -PAN -UAO) [ 1689.827892] pc : dev_watchdog+0x2b4/0x2c0 [ 1689.827901] lr : dev_watchdog+0x2b4/0x2c0 [ 1689.827906] sp : ffff000008003da0 [ 1689.827912] x29: ffff000008003da0 x28: 0000000000000005 [ 1689.827926] x27: 0000000000000020 x26: 00000000ffffffff [ 1689.827939] x25: 0000000000000140 x24: ffff800071250480 [ 1689.827952] x23: ffff80007125045c x22: ffff800070ca5940 [ 1689.827965] x21: ffff000008e77000 x20: ffff800071250000 [ 1689.827978] x19: 0000000000000000 x18: ffffffffffffffff [ 1689.827991] x17: 0000000000000000 x16: 0000000000000000 [ 1689.828004] x15: ffff000008e93000 x14: 00000000fffffff0 [ 1689.828017] x13: ffff000008f2786a x12: ffff000008e93000 [ 1689.828030] x11: 0000000000000000 x10: ffff000008f26000 [ 1689.828043] x9 : 0000000000000000 x8 : 0000000000000001 [ 1689.828055] x7 : 0000000000000000 x6 : 0000000000000123 [ 1689.828068] x5 : 0000000000000000 x4 : 0000000000000001 [ 1689.828080] x3 : 0000000000000000 x2 : ffff000008e7c358 [ 1689.828093] x1 : 2481295eb9750900 x0 : 0000000000000000 [ 1689.828105] Call trace: [ 1689.828117] dev_watchdog+0x2b4/0x2c0 [ 1689.828131] call_timer_fn+0x20/0x78 [ 1689.828143] expire_timers+0xa4/0xb0 [ 1689.828154] run_timer_softirq+0xe4/0x1a0 [ 1689.828164] __do_softirq+0x10c/0x200 [ 1689.828174] irq_exit+0xac/0xc0 [ 1689.828186] __handle_domain_irq+0x60/0xb0 [ 1689.828194] gic_handle_irq+0x58/0xa8 [ 1689.828201] el1_irq+0xb0/0x128 [ 1689.828212] arch_cpu_idle+0x10/0x18 [ 1689.828220] do_idle+0x1d4/0x298 [ 1689.828229] cpu_startup_entry+0x20/0x28 [ 1689.828243] rest_init+0xcc/0xd8 [ 1689.828256] start_kernel+0x3d4/0x400 [ 1689.828269] ---[ end trace b79bbf67547ae10f ]--- [ 1689.828334] meson8b-dwmac c9410000.ethernet eth0: Reset adapter. [ 1689.909766] RTL8211F Gigabit Ethernet stmmac-0:00: attached PHY driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:00, irq=37) [ 1689.922902] meson8b-dwmac c9410000.ethernet eth0: No Safety Features support found [ 1689.922925] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW [ 1693.046757] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 1737.955616] meson8b-dwmac c9410000.ethernet eth0: Reset adapter. [ 1738.037764] RTL8211F Gigabit Ethernet stmmac-0:00: attached PHY driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:00, irq=37) [ 1738.050715] meson8b-dwmac c9410000.ethernet eth0: No Safety Features support found [ 1738.050737] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW [ 1741.822114] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
-
Hi there, after updating the kernel to the latest version, the odroid-c2 only boots if a keyboard is present. If I disconnect the keyboard (which is and was the normal situation), on next reboot, I get a message "Enter root password for maintenance or press CONTROL-D to continue". Obviously, I'd greatly appreciate being able to boot my Odroid without having to connect a keyboard all the time. Best, Bastian
-
Hi, after a very successful deployment last year we will start a new sub sea C2 deployment next year (next to the old installation, in Northern Pacific, down at 2600m). Things work out nicely, but now we reached a state where some help from experts is welcome. I need to include some changes into the filesystem generated by Armbian build system, and hope someone can give me a hint on how to do it best way: - include some packages into the image (list available) - add some files to /etc/udev/rules.d/ - add some lines to /etc/rc.local - have a preinstalled user plus home directory (optional) Any help is appreciated, and sorry for my dumb questions Michael
-
Greetings. I'm running a headless cluster of Odroid C2's (eMMC) using the latest Armbian buster minimal image with kernel 4.19.69-meson64. I'm encountering an issue where it takes a long time for SSH connection to be accepted (initially up to 30 min consistently). I get a connection refused. The issue seems to be due to the entropy pool becoming depleted during the early boot process which blocks SSH from starting while it refills the pool. The problem seems to be known and documented well here: https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html As suggested I have installed installed haveged which brings the SSH startup from 30 mins to 10 mins after boot, which is an improvement, but still not good. Has anyone else experienced this issue? Any ideas?
-
After some hours of compiling I got OpenCV 4.1.1 running on Armbian Buster 64-bit. The SBC is an Odroid-C2. Thank you for this great OS-image.
-
Using a cable such as this one, can we expect Armbian on the C2 to consistently assign the same serial designation to each cable port? It would be nice but probably not? I found this question and this one but I'm not sure what would be the best approach for my application. I'd like to do it 'The Armbian Way' if there is one. How would you ensure that each hardware device is assigned the same port each time? Thanks .
-
Hi everyone, I'm trying to use the serial port on pins 8+10 on an ODroid C2. My understanding is that this maps to /dev/ttyS1 by default, but whenever I try to use this serial port, or any of ttyS0, S1, S2, S3, I get the error "Input/output error". root@odroidc2:~# stty raw -crtscts 9600 < /dev/ttyS1 stty: 'standard input': Input/output error root@odroidc2:~# cat /dev/ttyS1 cat: /dev/ttyS1: Input/output error I have done a lot of searching on this forum and others, and it sounds like this could be something I need to enable in my device tree config, or some kind of overlay, but I'm very new to this and couldn't find anything specific on what to do. I had a look around in the /boot directory but couldn't find anything that might indicate that the UART was disabled. I would have thought this /dev/ttyS1 would be enabled by default, while /dev/ttyS2 is optional since it collides with some GPIO pins. I'm using the latest Armbian_5.75_Odroidc2_Debian_stretch_next_4.19.20 and have also had the same problem with the latest Ubuntu as well. Is there a trick to enabling the default UART included with the ODroid C2? Thanks!
-
configuring gpio pin for pps-gpio on odroid c2 running 4.19.y
aegiap posted a topic in Amlogic meson
Hello, A GPS module ublox is connected to a odroid c2 board on GPIOX.12 and GPIOX.13 for the RX and TX and GPIOX.10 for the PPS. The board is running the stable kernel 4.19.42-meson64 from Armbian based on Debian stretch which was dist-upgraded to Debian buster. I am trying to get the /dev/pps0 entry using GPIOX.10 to finish the chrony setup but I cannot find the correct syntax in the DTS file. Any pointer or idea ? I try either of the gpios line below, none of them seems to be correct. pps { gpios = "< 0x1e 0x66 0x0 >"; #gpios = "<&gpiox 10 GPIO_ACTIVE_HIGH>"; #gpios = "< 0x66 >"; assert-falling-edge; compatible = "pps-gpio"; }; The file include/dt-bindings/gpio/gxbb.h#L122 in the Linux kernel tree show the value of GPIOX.10 is set to 102 (aka 0x66 in hexa). After reboot, the pps-gpio module is loaded and cannot find the GPS connected. # dmesg | grep -i pps [ 1.414780] pps_core: LinuxPPS API ver. 1 registered [ 1.414783] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 5.460824] OF: /pps: could not find phandle [ 5.460835] pps-gpio pps: failed to get GPIO from device tree [ 5.460849] pps-gpio: probe of pps failed with error -22 The previous pps-gpio kernel module had the option for the gpio_pin which seems a bit easier to use :-/ Thank you. -
Hello, Recently I have discovered bug in kernel or maybe iptables with using Huawei E3372h LTE Hi-Link USB dongle (or maybe other devices which exposes HTTP interfaces over cdc_ether). Odroid enters into kernel panic and reboot. I am using ARMBIAN 5.85 stable Debian GNU/Linux 9 (stretch) 4.19.42-meson64. kernel:[ 60.801868] Internal error: Oops: 96000004 [#1] PREEMPT SMP The steps to recreate the bug: 1) disable or remove NetworkManager, use only IPv4, 2) set network interfaces in /etc/network/interfaces source /etc/network/interfaces.d/* auto lo iface lo inet loopback auto eth0 allow-hotplug eth0 iface eth0 inet static address 10.0.0.1 netmask 255.255.255.0 allow-hotplug enxXXX iface enxXXX inet dhcp enxXXX - is example name of your E3372h (virtual?) ethernet interface. 3) check settings in /etc/sysctl.conf - you need have some routing capabilites on - mine is: kernel.printk = 3 4 1 3 net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.tcp_syncookies=1 net.ipv4.ip_forward=1 net.ipv4.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.all.disable_ipv6=1 net.ipv4.icmp_echo_ignore_broadcasts=1 net.ipv4.icmp_echo_ignore_all=1 vm.swappiness=100 4) set iptables rules to forward packets between local eth0 and usb dongle ethernet: *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o enxXXX -j MASQUERADE COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :interfaces - [0:0] :open - [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT -A INPUT -j interfaces -A INPUT -j open -A INPUT -j DROP -A FORWARD -i enxXXX -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o enxXXX -p tcp -m multiport --dports 80,443,9001,9111,3690 -j ACCEPT -A FORWARD -i eth0 -o enxXXX -p icmp -m icmp --icmp-type 8 -j ACCEPT -A FORWARD -j DROP -A OUTPUT -j ACCEPT -A interfaces -i lo -j ACCEPT COMMIT 5) connect to local eth0 other computer (set static IP to eg. 10.0.0.2, netmask 255.255.255.0 and gateway 10.0.0.1), 6) from other computer you should be able to ping E3372h eth interface: 192.168.8.1, 7) open web browser (I have Firefox) - enter address: http://192.168.8.1 8) after 5-10 seconds kernel panic occurs 9) after reboot there is a green background on screen via HDMI (need to hard power off and on to start without green screen). I have attached two fotos: 1 - kernel oops messages; 2 - green screen. Has anyone had a similar problem?
-
Hi, I compiled some images for C2 yesterday (mainline 5.77, jessie), and had a nice console as usual. Today, the new images still have u-boot console, and give some information about kernel starting, but no login by console (USB serial) is possible. I tried to set "console=serial" in /boot/armbianEnv.txt, but that gives me an endless reboot loop. Were there some changes? Maybe in baudrate? I get u-boot messages at 115200 8N1 as expected.. Michael
-
Hello, I using up to date Armbian Stretch with kernel 4.19.41-meson64 #5.85 SMP PREEMPT Wed May 8 12:40:37 CEST 2019 aarch64 GNU/Linux. Today about 2 minutes after system boot I have found this warning in kernel log: May 12 07:51:48 xxx kernel: WARNING: CPU: 1 PID: 0 at kernel/time/hrtimer.c:917 hrtimer_forward+0x88/0xd0 May 12 07:51:48 xxx kernel: Modules linked in: cdc_ether usbnet uas xt_tcpudp nf_log_ipv4 nf_log_common xt_LOG xt_multiport xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_connt May 12 07:51:48 xxx kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.41-meson64 #5.85 May 12 07:51:48 xxx kernel: Hardware name: Hardkernel ODROID-C2 (DT) May 12 07:51:48 xxx kernel: pstate: 20000085 (nzCv daIf -PAN -UAO) May 12 07:51:48 xxx kernel: pc : hrtimer_forward+0x88/0xd0 May 12 07:51:48 xxx kernel: lr : txdone_hrtimer+0xd0/0x108 May 12 07:51:48 xxx kernel: sp : ffff00000800be20 May 12 07:51:48 xxx kernel: x29: ffff00000800be20 x28: ffff80007ff8a580 May 12 07:51:48 xxx kernel: x27: ffff00000891a6d8 x26: 0000000000000001 May 12 07:51:48 xxx kernel: x25: 0000000000000000 x24: 0000000000000001 May 12 07:51:48 xxx kernel: x23: ffff8000710c4be8 x22: 00000000000000f8 May 12 07:51:48 xxx kernel: x21: ffff8000710c4bb8 x20: ffff8000710c4ac0 May 12 07:51:48 xxx kernel: x19: 00000000000f4240 x18: 0000000000000000 May 12 07:51:48 xxx kernel: x17: 0000000000000000 x16: 0000000000000000 May 12 07:51:48 xxx kernel: x15: 000000000000029a x14: 0000000000000400 May 12 07:51:48 xxx kernel: x13: 0000000000000001 x12: 0000000000000001 May 12 07:51:48 xxx kernel: x11: 0000000000ad3d80 x10: 0000000000000040 May 12 07:51:48 xxx kernel: x9 : ffff000008e93418 x8 : ffff800071400248 May 12 07:51:48 xxx kernel: x7 : ffff800071400288 x6 : 00000000d138f0b4 May 12 07:51:48 xxx kernel: x5 : 0000000000000001 x4 : ffff8000710c4be8 May 12 07:51:48 xxx kernel: x3 : 0000002116b3f554 x2 : 00000000000f4240 May 12 07:51:48 xxx kernel: x1 : 0000002116b3f76a x0 : 0000000000000216 May 12 07:51:48 xxx kernel: Call trace: May 12 07:51:48 xxx kernel: hrtimer_forward+0x88/0xd0 May 12 07:51:48 xxx kernel: __hrtimer_run_queues+0x120/0x1b8 May 12 07:51:48 xxx kernel: hrtimer_interrupt+0xd4/0x250 May 12 07:51:48 xxx kernel: arch_timer_handler_phys+0x28/0x40 May 12 07:51:48 xxx kernel: handle_percpu_devid_irq+0x80/0x138 May 12 07:51:48 xxx kernel: generic_handle_irq+0x24/0x38 May 12 07:51:48 xxx kernel: __handle_domain_irq+0x5c/0xb0 May 12 07:51:48 xxx kernel: gic_handle_irq+0x58/0xa8 May 12 07:51:48 xxx kernel: el1_irq+0xb0/0x128 May 12 07:51:48 xxx kernel: arch_cpu_idle+0x10/0x18 May 12 07:51:48 xxx kernel: do_idle+0x1d4/0x298 May 12 07:51:48 xxx kernel: cpu_startup_entry+0x20/0x28 May 12 07:51:48 xxx kernel: secondary_start_kernel+0x194/0x1d0 May 12 07:51:48 xxx kernel: ---[ end trace dcd1d1f08e0ad792 ]--- When it happened I had one USB device connected to ODROID - E3372h LTE modem (and it was online). But system working normally after that. I've never had such warning before (with previous kernel - 4.19.20). Maybe it has something to do with the last Armbian kernel update?
-
Hello, I using up to date Armbian Stretch with kernel 4.19.41-meson64 #5.85 SMP PREEMPT Wed May 8 12:40:37 CEST 2019 aarch64 GNU/Linux. I started using TP-Link TL-WN722N V1 USB WiFi dongle recently. Unfortunately Armbian has crashed and rebooted once during I using such USB dongle. I tried to reproduce this bug once more but I can't. I have installed firmware-atheros package for this USB dongle. Should I install armbian-firmware-full package instead of firmware-atheros? It could help? Log:
-
2 changes are in queue on my workstation, one is u-boot 2018.11, the other is updating the Dev patchset and beginning to iron out 4.19 Kernel. The first I honestly don't see any issues with moving forward, but want people to know about it, the second is a bit of a hairball and I'll need some help with debugging, and in fixing. Detail of changes: U-boot: Currently Meson64 and Odroid C2 are using 2018.05 and 2018.07, respectively. I will be moving all to 2018.11, and eliminating the "specialness" of the Odroid C2 in our build system, so Meson64 will be inheriting the C2 boot script under the "Meson64 name, it will no longer have its own u-boot patch folder/etc. The board will finally be fully integrated into the Meson64 configuration, although it will still have the special Odroid firmware blob (all Amlogic SoC's have their own blobs, so no special changes need made to allow for the C2 to have a different one than the K2) Current Concerns: packaging scripts on 4.14 kernel are not creating a symlinked named "Image" for the updated boot script. I didn't consider that and only caught it today. U-boot is obviously unimpressed. Kernel 4.19: This will eventually become the "Default" kernel, once it has been debugged and proven out, as Amlogic Mainline kernels can now be easily patched with full video decoder support (already done), and Mali support is available (I need to finish integrating that, later date) Current concerns: -HDMI displays seem to be a sore spot, I have 1 that works flawlessly (hilariously a 7" waveshare-like HDMI), while the other needs to be plugged in after boot to work, and an HDMI-DVI adapter one is nonfunctional. (it seems to think it's attached, but no image) - I am getting a million "failed to change cpu frequency: -5" errors again. The clock marked as critical fix is in there, needs verified as it looks different than the old one. - I had to disable CEC entirely to get the system to boot with a display attached, it would fault, reboot, fault, etc. Plugging in a display after boot yielded an oops. No CEC = that problem is gone. Tagging @Neil Armstrong, for tracking if interested/have ideas. I'm using Neil's always helpful meta-meson patchset, these were squirreled away in "next" so I assume they are not complete/some WIP, so this can be some good feedback/etc. No one can break things like an end user.
-
lm-sensors can read temps fine - $ uname -a Linux Odroid-C2 4.19.20-meson64 #5.75 SMP PREEMPT Fri Feb 8 10:08:40 CET 2019 aarch64 GNU/Linux $ sensors -u scpi_sensors-isa-0000 Adapter: ISA adapter aml_thermal: temp1_input: 39.000 But htop displays 0 C -
-
Hi, I use the new kernel with I2CA being used for controlling some U/I meters and sensors. There are three 1Wire masters included by overlay (and they work ): > ls /sys/bus/w1/devices/ > 22-000000214032 28-00000a09aa8d w1_bus_master2 > 28-00000a089919 w1_bus_master1 w1_bus_master3 I2C works also fine, all devices mounted so far are answering: > i2cdetect -y 0 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- 0c -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 40: 40 41 -- -- -- 45 -- 47 48 -- 4a -- -- 4d -- -- > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- -- -- -- -- 6c -- -- -- > 70: -- -- -- -- -- -- 76 -- Then I access the GPIO subsystem to initialize one pin for power control: #! /bin/sh echo 475 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio475/direction echo 0 > /sys/class/gpio/gpio475/value After that, I2C access is screwed up, and no normal access possible: > i2cdetect -y 0 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f > 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f > 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f > 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f > 70: 70 71 72 73 74 75 76 77 This is kind of a showstopper - anyone can help here? Seems that activating the GPIO subsystem is touching the I2C pins on J2, too. Michael
-
Hi, I´d like to use the GPIO PINs on my Odriod C2 with the mainline kernel 4.18. I tried to install the User Space IO, which seems to be the right tool to help me with the task. Unfortunately I had no luck trying to install it on my own. Hopefully we can install it together and get the GPIOs to do their job. It says "User space devices are exposed through /dev or /sys. Verify the device is showing up prior to trying demo programs." That is what is shown in this directory's: Picture, are devices installed properly or do I have to configure the C2 to start with User Space IO? That happens if I try to run the example code to access the GPIO or the SPI interface: Picture2 Can someone help me with that? Thank you! Nik
-
Hi, I use the C2 connector J2 signals to control power distribution for several attaches devices. A n-channel MOSFET is driven by a GPIO signal, with pulldown (3k3) to ensure that the n-channel MOSFET is off, - as long as the GPIO pin is in tristate or input state. I considered this to be the case for all "normal" GPIO lines (except I2C and SPI). I see now that after powerup, at least GPIOX_5 is active and switches on my load until I can export the GPIOX_5 and drive it low. Does anyone know if the GPIO lines are driven actively after powerup / reset? And if so, can this behaviour be changed in U-boot or kernel environment? The philosophy of the whole business is to keep everything shutdown except the C2 and the fiber media converter, so in case of bad things happening we can start without being disturbed by some external hardware. Another issue seems to happen with the new kernel: I power the C2 by the J2 pins (+5V), with J1 removed. Old kernel was off after a "shutdown -h now", the current one is rebooting after this command. This happens only if powered by J2 pins, not when powered by the small power connector - tested with two C2 boards now. Any ideas on that? Thanks in advance, Michael
-
Now checked on Odroid C2 an image 5.76 with MALI and a media script, by a technique with replacement of u-boot, as for K2. Everything works fine. After installing the script, the standard browser began to play video 1080 full screen without brakes. MPV is just as easy to handle any full-screen video. Bonus has an in-house sound via HDMI. There is one caveat when configuring - it is necessary to specify the correct DTB option in the file for Odroid C2 "/extlinux/extlinux conf". 1. Copy of the standard u-boot from the working SD card. dd if=/dev/mmcblkXXX of=u-boot_odroid_c2.img bs=1M count=4 2. Burn the image Armbian for TV Boxing on the SD card. 3. Replace u-boot on the recorded SD card dd if=u-boot_odroid_c2.img of=/dev/mmcblk0 conv=fsync bs=1 count=442 dd if=u-boot_odroid_c2.img of=/dev/mmcblk0 conv=fsync bs=512 skip=1 seek=1 4. edit "/extlinux/extlinux conf" p.s. By the way, LibreELEC with the new 5.1 kernel works just as well on Odroid C2.
-
Hi, On an Odroid C2, I used to read IP camera stream with ffmpeg without HW decoding, as it was not available yet. After reading many threads on this forum, regarding hw decoding through ffmpeg, I decided to give a try....but without any success. First of all, I tried to decode the Sintel.2010.720p.mkv file, and it worked well. This is the command I used: ffmpeg -c:v h264_v4l2m2m -i Sintel.2010.720p.mkv -an -vf fps=1 -f image2 -strftime 1 "/dev/shm/cam1_%S.jpg" (This takes a snapshot every second from the video file) And I got this output: [h264_v4l2m2m @ 0xaaaab68e84f0] driver 'meson-vdec' on card 'Amlogic Video Decoder' [h264_v4l2m2m @ 0xaaaab68e84f0] Using device /dev/video0 [h264_v4l2m2m @ 0xaaaab68e84f0] driver 'meson-vdec' on card 'Amlogic Video Decoder' Stream mapping: Stream #0:0 -> #0:0 (h264 (h264_v4l2m2m) -> mjpeg (native)) Press [q] to stop, [?] for help [h264_v4l2m2m @ 0xaaaab68e84f0] output POLLERR [swscaler @ 0xaaaab691f000] deprecated pixel format used, make sure you did set range correctly Output #0, image2, to '/dev/shm/cam1_%S.jpg': Metadata: encoder : Lavf57.83.100 Chapter #0:0: start 0.000000, end 103.125000 Metadata: title : Chapter 01 Chapter #0:1: start 103.125000, end 148.667000 Metadata: title : Chapter 02 Chapter #0:2: start 148.667000, end 349.792000 Metadata: title : Chapter 03 Chapter #0:3: start 349.792000, end 437.208000 Metadata: title : Chapter 04 Chapter #0:4: start 437.208000, end 472.075000 Metadata: title : Chapter 05 Chapter #0:5: start 472.075000, end 678.833000 Metadata: title : Chapter 06 Chapter #0:6: start 678.833000, end 744.083000 Metadata: title : Chapter 07 Chapter #0:7: start 744.083000, end 888.032000 Metadata: title : Chapter 08 Stream #0:0(eng): Video: mjpeg, yuvj420p(pc), 1280x544 [SAR 1:1 DAR 40:17], q=2-31, 200 kb/s, 1 fps, 1 tbn, 1 tbc Metadata: encoder : Lavc57.107.100 mjpeg Side data: cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1 frame= 53 fps=3.4 q=4.8 Lsize=N/A time=00:00:53.00 bitrate=N/A speed=3.44x After that successfull test, I tried this from a CCTV RTSP stream : ffmpeg -stimeout 5000000 -c:v h264_v4l2m2m -i rtsp://192.168.1.31/11 -an -vf fps=1 -f image2 -strftime 1 "/dev/shm/cam1_%S.jpg" and I got this output: [h264 @ 0xaaaadbc04330] corrupted macroblock 16 36 (total_coeff=-1) [h264 @ 0xaaaadbc04330] error while decoding MB 16 36 [h264 @ 0xaaaadbc04330] concealing 753 DC, 753 AC, 753 MV errors in I frame Guessed Channel Layout for Input Stream #0.1 : mono Input #0, rtsp, from 'rtsp://192.168.1.31/11': Metadata: title : 10 Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: h264 (Baseline), yuvj420p(pc, bt709, progressive), 1280x720, 2.08 tbr, 90k tbn, 180k tbc Stream #0:1: Audio: pcm_alaw, 8000 Hz, mono, s16, 64 kb/s [h264_v4l2m2m @ 0xaaaadbd68c70] driver 'meson-vdec' on card 'Amlogic Video Decoder' [h264_v4l2m2m @ 0xaaaadbd68c70] Using device /dev/video0 [h264_v4l2m2m @ 0xaaaadbd68c70] driver 'meson-vdec' on card 'Amlogic Video Decoder' Stream mapping: Stream #0:0 -> #0:0 (h264 (h264_v4l2m2m) -> mjpeg (native)) Press [q] to stop, [?] for help [h264_v4l2m2m @ 0xaaaadbd68c70] output POLLERR [swscaler @ 0xaaaadbc47f60] deprecated pixel format used, make sure you did set range correctly [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. Output #0, image2, to '/dev/shm/cam1_%S.jpg': Metadata: title : 10 encoder : Lavf57.83.100 Stream #0:0: Video: mjpeg, yuvj420p(pc), 1280x720, q=2-31, 200 kb/s, 1 fps, 1 tbn, 1 tbc Metadata: encoder : Lavc57.107.100 mjpeg Side data: cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1 [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. [Parsed_fps_0 @ 0xaaaadbc668a0] Discarding initial frame(s) with no timestamp. Last message repeated 1 times frame= 0 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= 0x video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) I am using the regular ffmpeg, installed through apt install. (No compilation from source). I am using the latest armbian ubuntu stable version: 4.19.20-meson64 #5.75 SMP PREEMPT Fri Feb 8 10:08:40 CET 2019 aarch64 aarch64 aarch64 GNU/Linux Any sugestions for using HW decoding over a RTSP stream? Thx Fabian
-
I have a 4-port USB 2.0 hub powered by a 5V 3.1A power supply that does not show up on my C2, with or without devices connected to it. I have the C2's USB OTG port disabled as I use a DC power supply. $ sudo lsusb Bus 001 Device 004: ID 1df7:3010 Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub dmesg does not log the hub connecting/disconnecting. How do I troubleshoot this? armbianmonitor -u: http://ix.io/1DzS
-
Hello, I have 16GB orange eMMC v0.4 module for Odroid C2. I have installed on it Armbian Debian Stretch Next (mainline kernel). When I run iozone I got read results that is slower than eMMC Hardkernel specs. root@odroidc2:~# iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Sun Feb 10 03:49:18 2019 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 32953 36184 23772 23774 23679 25934 102400 16 39075 44064 42145 42258 41967 43945 102400 512 40897 41149 80160 80028 79930 41461 102400 1024 41512 41928 82305 82300 82167 42205 102400 16384 41108 43502 86202 86228 86214 43877 On Hardkernel Ubuntu when I run iozone I have max ~50 MB/s write and ~133MB/s read, but on Armbian only max ~86 MB/s read. Why is that?