piknew

Members
  • Content Count

    95
  • Joined

  • Last visited

About piknew

  • Rank
    Advanced Member

Recent Profile Visitors

2683 profile views
  1. Please post dmesg output after changes are committed to emmc (with "w"). I had exactly the same issue - dmesg was reporting a lot of serious write errors. I already assumed that emmc is not usable anymore, however, after couple of weeks... I tried again and everything was OK. I am not sure if this was really hardware issue or software. So, please check dmesg output...
  2. piknew

    piknew

  3. I need to revert statement as above. My OPi+2E has "frozen". So, entry MIN_SPEED=408000 is not valid for my SBCs. Until it is corrected I have added following to /etc/cron.d/cpufrequtils-fix */5 * * * * root /bin/grep 'MIN_SPEED=408000' /etc/default/cpufrequtils 1>/dev/null 2>&1 && /bin/sed --in-place s/MIN_SPEED=408000/MIN_SPEED=480000/ /etc/default/cpufrequtils 1>/dev/null 2>&1 && /bin/systemctl restart cpufrequtils 1>/dev/null 2>&1 Edit. My mistake. It was that I have put my SBC on quite warm router. And during scheduled job (performing backup of my NAS) it was simply shut down: Feb 4 05:11:48 PKBACKUP kernel: thermal thermal_zone0: critical temperature reached (90 C), shutting down Feb 4 05:11:48 PKBACKUP systemd[1]: Stopped target Sound Card. Feb 4 05:11:49 PKBACKUP systemd[1]: Stopping Save/Restore Sound Card State... Feb 4 05:11:49 PKBACKUP systemd[1]: Stopping Initialize i2c hardware RTC device driver... Feb 4 05:11:49 PKBACKUP systemd[1]: Stopped target Timers. Feb 4 05:11:49 PKBACKUP systemd[1]: Stopped Clean PHP session files every 30 mins. Feb 4 05:11:49 PKBACKUP systemd[1]: Stopped Daily Cleanup of Temporary Directories. Feb 4 05:11:49 PKBACKUP systemd[1]: Stopped target Graphical Interface. Feb 4 05:11:49 PKBACKUP systemd[1]: Stopped target Multi-User System. Feb 4 05:11:49 PKBACKUP systemd[1]: Stopped target Login Prompts. Feb 4 05:11:49 PKBACKUP systemd[1]: Stopping Getty on tty1... Feb 4 05:11:49 PKBACKUP systemd[1]: Stopping Serial Getty on ttyS0... ........
  4. It seems that with kernel 4.19.13-sunxi the typo is no longer causing issues (at least on OPi+2, which I've selected to perform test): ___ ____ _ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) _ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | |_| |_ | |_| | | | (_| | | | | (_| | __/ | __/| |_ _| \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| |___/ Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi System load: 2.25 1.43 0.62 Up time: 10 days Memory usage: 4 % of 2014MB IP: 192.168.10.230 CPU temp: 68°C Usage of /: 16% of 15G Last login: Fri Jan 25 08:14:57 2019 from 192.168.10.106 [root@PKHELPER ~]# uptime 08:19:41 up 10 days, 14:22, 2 users, load average: 2.31, 1.46, 0.63 [root@PKHELPER ~]# date Fri Jan 25 08:19:48 CET 2019 [root@PKHELPER ~]# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.04 ms. hardware limits: 120 MHz - 1.37 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 408 MHz and 1.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.10 GHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.00%, 240 MHz:0.00%, 480 MHz:99.18%, 648 MHz:0.00%, 816 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.10 GHz:0.14%, 1.15 GHz:0.00%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:0.68%, 1.34 GHz:0.00%, 1.37 GHz:0.00% (9633) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.04 ms. hardware limits: 120 MHz - 1.37 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 408 MHz and 1.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.10 GHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.00%, 240 MHz:0.00%, 480 MHz:99.18%, 648 MHz:0.00%, 816 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.10 GHz:0.14%, 1.15 GHz:0.00%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:0.68%, 1.34 GHz:0.00%, 1.37 GHz:0.00% (9633) analyzing CPU 2: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.04 ms. hardware limits: 120 MHz - 1.37 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 408 MHz and 1.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.10 GHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.00%, 240 MHz:0.00%, 480 MHz:99.18%, 648 MHz:0.00%, 816 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.10 GHz:0.14%, 1.15 GHz:0.00%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:0.68%, 1.34 GHz:0.00%, 1.37 GHz:0.00% (9633) analyzing CPU 3: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.04 ms. hardware limits: 120 MHz - 1.37 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 408 MHz and 1.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.10 GHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.00%, 240 MHz:0.00%, 480 MHz:99.18%, 648 MHz:0.00%, 816 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.10 GHz:0.14%, 1.15 GHz:0.00%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:0.68%, 1.34 GHz:0.00%, 1.37 GHz:0.00% (9633) [root@PKHELPER ~]#
  5. I will change it on one of my platforms to verify. It will be Orange Pi+ 2 - just a moment ago I have changed it back to original package version (with "408") and rebooted: ___ ____ _ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) _ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | |_| |_ | |_| | | | (_| | | | | (_| | __/ | __/| |_ _| \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| |___/ Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi System load: 1.43 0.34 0.11 Up time: 0 min Memory usage: 3 % of 2014MB IP: 192.168.10.230 CPU temp: 61°C Usage of /: 16% of 15G Last login: Mon Jan 14 17:56:01 2019 from 192.168.10.210 [root@PKHELPER ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1296000 GOVERNOR=ondemand [root@PKHELPER ~]# date && uptime Mon Jan 14 17:58:24 CET 2019 17:58:24 up 0 min, 1 user, load average: 0.73, 0.29, 0.10 [root@PKHELPER ~]# apt list --installed | grep next WARNING: apt does not have a stable CLI interface. Use with caution in scripts. linux-dtb-next-sunxi/stretch,now 5.70 armhf [installed] linux-headers-next-sunxi/stretch,now 5.70 armhf [installed] linux-image-next-sunxi/stretch,now 5.70 armhf [installed] linux-stretch-root-next-orangepiplus/stretch,now 5.70 armhf [installed] linux-u-boot-orangepiplus-next/stretch,now 5.70 armhf [installed] [root@PKHELPER ~]#
  6. @Igor, with latest upgrade the "typo" (408 vs 480) is still in cpufrequtils. Is there a chance (I mean: time to do it) to have it corrected in the source? THe related thread:
  7. Still OK (I can confirm this for all of my "orange" SBCs): [root@PKBACKUP ~]# date Mon Oct 29 20:21:27 CET 2018 [root@PKBACKUP ~]# uptime 20:21:32 up 8 days, 2:32, 1 user, load average: 0.10, 0.03, 0.01 [root@PKBACKUP ~]# ll /etc/default/cpufrequtils -r--r--r-- 1 root root 175 Oct 18 18:01 /etc/default/cpufrequtils [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance [root@PKBACKUP ~]#
  8. After correcting cpufrequtils file - no issues so far: [root@PKBACKUP ~]# date Fri Oct 26 11:03:47 CEST 2018 [root@PKBACKUP ~]# uptime 11:03:53 up 4 days, 16:14, 1 user, load average: 0.00, 0.00, 0.00 [root@PKBACKUP ~]# ll /etc/default/cpufrequtils -r--r--r-- 1 root root 175 Oct 18 18:01 /etc/default/cpufrequtils [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance [root@PKBACKUP ~]# Anybody else (who's SBC was impacted by this issue) can verify the same?
  9. I referred to your post in: I guess the other thread is better to analyze this finding.
  10. For now I have modified cpufrequtils as following for my three boards (orangepipc, orangepiplus 2 GB, orangepiplus2e): [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance For orangepizero as following: [root@PKOTHER ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1200000 GOVERNOR=ondemand #GOVERNOR=performance Only orangepiplus2e is somehow loaded. With my own backup software, which is run twice a day - but in the past it was enough to freeze the board after a few days. I will update if the change helped or not. Question: I have noticed that orangepizero is using lower "MAX" settings. I understand as this device had an issue with overheating. How about other platforms, why lowest frequency settings is 480 MHz, not 240 MHz (which is also supported by H3)? Some results for my platforms (please note that 816 MHz is common lowest choice for H3): orangepiplu2e: [root@PKBACKUP ~]# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:36:53: 1296MHz 0.00 6% 1% 2% 0% 1% 0% 42.5°C 0/9 16:36:58: 816MHz 0.00 0% 0% 0% 0% 0% 0% 43.0°C 0/9 16:37:03: 816MHz 0.00 0% 0% 0% 0% 0% 0% 42.8°C 0/9 16:37:08: 816MHz 0.00 0% 0% 0% 0% 0% 0% 42.8°C 0/9 16:37:14: 816MHz 0.00 0% 0% 0% 0% 0% 0% 40.2°C 0/9 16:37:19: 816MHz 0.00 0% 0% 0% 0% 0% 0% 43.4°C 0/9 16:37:24: 816MHz 0.00 0% 0% 0% 0% 0% 0% 41.7°C 0/9 16:37:29: 816MHz 0.00 0% 0% 0% 0% 0% 0% 41.6°C 0/9 16:37:34: 816MHz 0.00 0% 0% 0% 0% 0% 0% 42.5°C 0/9^C orangepiplus: [root@PKHELPER ~]# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:39:34: 816MHz 0.13 0% 0% 0% 0% 0% 0% 44.2°C 0/9 16:39:39: 1296MHz 0.18 0% 0% 0% 0% 0% 0% 43.8°C 0/9 16:39:44: 816MHz 0.17 0% 0% 0% 0% 0% 0% 43.9°C 0/9 16:39:49: 1296MHz 0.16 0% 0% 0% 0% 0% 0% 43.7°C 0/9 16:39:54: 816MHz 0.14 0% 0% 0% 0% 0% 0% 44.0°C 0/9 16:39:59: 1296MHz 0.13 0% 0% 0% 0% 0% 0% 44.3°C 0/9 16:40:04: 816MHz 0.12 0% 0% 0% 0% 0% 0% 44.3°C 0/9 16:40:09: 816MHz 0.11 0% 0% 0% 0% 0% 0% 43.7°C 0/9 16:40:15: 816MHz 0.10 0% 0% 0% 0% 0% 0% 43.1°C 0/9 16:40:20: 816MHz 0.09 0% 0% 0% 0% 0% 0% 43.7°C 0/9^C orangepipc: [root@PKTEST ~]# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:41:11: 1296MHz 0.07 0% 0% 0% 0% 0% 0% 35.7°C 0/9 16:41:16: 816MHz 0.06 0% 0% 0% 0% 0% 0% 36.7°C 0/9 16:41:21: 816MHz 0.06 0% 0% 0% 0% 0% 0% 36.8°C 0/9 16:41:26: 816MHz 0.05 0% 0% 0% 0% 0% 0% 35.7°C 0/9 16:41:31: 816MHz 0.05 0% 0% 0% 0% 0% 0% 35.9°C 0/9 16:41:37: 816MHz 0.04 0% 0% 0% 0% 0% 0% 36.5°C 0/9 16:41:42: 816MHz 0.04 0% 0% 0% 0% 0% 0% 35.8°C 0/9 16:41:47: 816MHz 0.04 0% 0% 0% 0% 0% 0% 36.4°C 0/9 16:41:52: 816MHz 0.03 0% 0% 0% 0% 0% 0% 36.2°C 0/9^C orangepizero: [root@PKOTHER ~]# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:42:33: 1200MHz 0.00 0% 0% 0% 0% 0% 0% 43.0°C 0/8 16:42:38: 648MHz 0.00 0% 0% 0% 0% 0% 0% 43.1°C 0/8 16:42:43: 648MHz 0.00 0% 0% 0% 0% 0% 0% 43.1°C 0/8 16:42:48: 648MHz 0.00 0% 0% 0% 0% 0% 0% 42.6°C 0/8 16:42:54: 648MHz 0.08 0% 0% 0% 0% 0% 0% 42.5°C 0/8 16:42:59: 648MHz 0.07 0% 0% 0% 0% 0% 0% 43.6°C 0/8 16:43:04: 648MHz 0.06 0% 0% 0% 0% 0% 0% 43.0°C 0/8 16:43:09: 648MHz 0.06 0% 0% 0% 0% 0% 0% 42.6°C 0/8^C
  11. Could you please take a look here: Considering that when running on performance mode - system seems to be stable but once switched to "ondemand" - unstable. May the "mismatch" be the root cause here?
  12. Could you please point out how to achieve this? All my H3 (also H2+) devices suffer from the issue as described. Even with newest kernel. So, after reading I decided to test stability with "constant cpu frequency". EDIT: I've done it by: [root@PKTEST ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1296000 #GOVERNOR=ondemand GOVERNOR=performance [root@PKTEST ~]# Question: would it be possible not to overwrite cpufrequtils file once support package is installed/upgraded?
  13. SUCCESS Story: I have used armbian-config to check Hardware (if my I2C bus is enabled). I have noticed very strange behavior of function: grep was outputted in "usage" mode. I revieved all the scripts and it appeared that line which is searching for "overlays=" is throwing this error. My /boot/armbianEnv.txt didn't have any overlay, especially for I2C, enabled. So, I have added as following (+ overlay prefix): [root@PKTEST ~]# cat /boot/armbianEnv.txt rootdev=UUID=f8301761-6756-4f97-aa80-12c05ea037cf extraargs=pty.legacy_count=2 overlays=i2c0 i2c1 i2c2 user_overlays=ds1307 overlay_prefix=sun8i-h3 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x1058:0x10b8:u [root@PKTEST ~]# Then I have modified my user overlay file to be as following: [root@PKTEST ~]# cat /boot/overlay-user/ds1307.dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; /* * Aliases can be used to set the external RTC as rtc0 * Needs supplying the correct path to the I2C controller RTC is connected to, * this example is for I2C1 on H3 * NOTE: setting time at boot by the kernel * may not work in some cases if the external RTC module is loaded too late */ fragment@0 { target-path = "/aliases"; __overlay__ { rtc0 = "/soc/i2c@1c2ac00/ds1307@68"; }; }; fragment@1 { target = <&i2c0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; ds1307@68 { compatible = "dallas,ds1307"; reg = <0x68>; status = "okay"; }; }; }; }; [root@PKTEST ~]# The address in fragment@0 is determined by looking where system placed i2c0 bus (I am sure that my RTC is connected to bus 0). It is giving /dev/rtc1,m which I have verified as following: [root@PKTEST ~]# ll /dev/rtc* crw------- 1 root root 253, 0 May 22 2016 /dev/rtc0 lrwxrwxrwx 1 root root 4 May 22 2016 /dev/rtc -> rtc0 crw------- 1 root root 253, 1 May 22 2016 /dev/rtc1 [root@PKTEST ~]# hwclock -r -f /dev/rtc0 Sun 22 May 2016 12:38:25 AM CEST -1.593015 seconds [root@PKTEST ~]# hwclock -r -f /dev/rtc1 Fri 05 Oct 2018 11:57:03 AM CEST -0.927469 seconds [root@PKTEST ~]# Unfortunately it seems that line frogment@0 is not making this device available as rtc0 (it is assigning rtc1): [root@PKTEST ~]# dmesg | grep -i rtc [ 3.636229] [drm] Cannot find any crtc or sizes [ 3.756932] sun6i-rtc 1f00000.rtc: rtc core: registered rtc-sun6i as rtc0 [ 3.756939] sun6i-rtc 1f00000.rtc: RTC enabled [ 4.641465] [drm] Cannot find any crtc or sizes [ 9.740172] rtc-ds1307 0-0068: /aliases ID 0 not available [ 9.741555] rtc-ds1307 0-0068: registered as rtc1 [root@PKTEST ~]# Can anybody help and answer if it is possible somehow "override" the device? Of course I have my own systemd script to use it and set correct date at boot time. If "overriding" is not possible then I will use it.
  14. Definitely not (PKTEST is Orange Pi PC) - I also checked on OPI+2 with the same results (FAILED on "dev"). But I will try to downgrade to "next" on OPiPC (PKTEST). I will give an update in matter of minutes. Update: "next" is the same. But then I have downgraded to "Default" and: [root@PKTEST ~]# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- [root@PKTEST ~]# cd /sys/class/i2c-adapter/i2c-0 [root@PKTEST /sys/class/i2c-adapter/i2c-0]# echo ds1307 0x68 >new_device [root@PKTEST /sys/class/i2c-adapter/i2c-0]# ll /dev/rtc* crw------- 1 root root 254, 0 May 22 2016 /dev/rtc0 lrwxrwxrwx 1 root root 4 May 22 2016 /dev/rtc -> rtc0 crw------- 1 root root 254, 1 Oct 4 18:36 /dev/rtc1 [root@PKTEST /sys/class/i2c-adapter/i2c-0]# hwclock -r -f /dev/rtc1 Thu 04 Oct 2018 06:36:46 PM CEST -0.853544 seconds [root@PKTEST /sys/class/i2c-adapter/i2c-0]#
  15. I am not sure if the path is correct - I used the one from dts file (in post above). It seems that "something" is there. However, I2C detect does not see any device under address 0x68. I am also not sure if aliases section of dts file will somehow override visibility of standard rtc0 device from SOC? Below are a few commands. [root@PKTEST /proc/device-tree/soc/i2c@1c2b000]# ll total 0 -r--r--r-- 1 root root 24 Oct 4 17:32 compatible -r--r--r-- 1 root root 8 Oct 4 17:32 clocks -r--r--r-- 1 root root 8 Oct 4 17:32 resets -r--r--r-- 1 root root 9 Oct 4 17:32 status -r--r--r-- 1 root root 4 Oct 4 17:32 #address-cells -r--r--r-- 1 root root 12 Oct 4 17:32 interrupts -r--r--r-- 1 root root 4 Oct 4 17:32 #size-cells drwxr-xr-x 2 root root 0 Oct 4 17:32 ds1307@68 -r--r--r-- 1 root root 4 Oct 4 17:32 phandle -r--r--r-- 1 root root 8 Oct 4 17:32 reg -r--r--r-- 1 root root 4 Oct 4 17:32 pinctrl-0 -r--r--r-- 1 root root 4 Oct 4 17:32 name -r--r--r-- 1 root root 8 Oct 4 17:32 pinctrl-names [root@PKTEST /proc/device-tree/soc/i2c@1c2b000]# cd ds1307@68/ [root@PKTEST /proc/device-tree/soc/i2c@1c2b000/ds1307@68]# ll total 0 -r--r--r-- 1 root root 14 Oct 4 17:32 compatible -r--r--r-- 1 root root 5 Oct 4 17:32 status -r--r--r-- 1 root root 4 Oct 4 17:32 reg -r--r--r-- 1 root root 7 Oct 4 17:32 name [root@PKTEST /proc/device-tree/soc/i2c@1c2b000/ds1307@68]# ll /dev/rtc* crw------- 1 root root 253, 0 May 22 2016 /dev/rtc0 lrwxrwxrwx 1 root root 4 May 22 2016 /dev/rtc -> rtc0 [root@PKTEST /proc/device-tree/soc/i2c@1c2b000/ds1307@68]# dmesg | grep -i ds1307 [root@PKTEST /proc/device-tree/soc/i2c@1c2b000/ds1307@68]# dmesg | grep -i rtc [ 3.625735] [drm] Cannot find any crtc or sizes [ 3.746859] sun6i-rtc 1f00000.rtc: rtc core: registered rtc-sun6i as rtc0 [ 3.746865] sun6i-rtc 1f00000.rtc: RTC enabled [ 4.640512] [drm] Cannot find any crtc or sizes [root@PKTEST /proc/device-tree/soc/i2c@1c2b000/ds1307@68]# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- [root@PKTEST /proc/device-tree/soc/i2c@1c2b000/ds1307@68]# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- [root@PKTEST /proc/device-tree/soc/i2c@1c2b000/ds1307@68]#