• Announcements

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

How install RTC schield by Hardkernell in Odroid c2 with OMV Erasmus 3.0.92?
0

43 posts in this topic

Recommended Posts

6 minutes ago, marcellom said:

Good morning Zador :)

this is the output

/dev/rtc  /dev/rtc0

 

 

maybe is needed do this as follow?

To change the default RTC as e.g. used by hwclock create a file called /etc/udev/rules.d/99-rtc1.rules with e.g. the following contents:

KERNEL=="rtc1", SUBSYSTEM=="rtc", DRIVER=="", ATTR{name}=="m41t00", SYMLINK="rtc", MODE="0666"

Share this post


Link to post
Share on other sites
4 minutes ago, zador.blood.stained said:

.. and output of "udevadm info /dev/rtc0 --attribute-walk" ?

this

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/i2c-1/1-0051/rtc/rtc0':
    KERNEL=="rtc0"
    SUBSYSTEM=="rtc"
    DRIVER==""
    ATTR{date}=="2017-11-18"
    ATTR{name}=="rtc-pcf8563"
    ATTR{time}=="08:39:22"
    ATTR{since_epoch}=="1510994362"
    ATTR{hctosys}=="0"
    ATTR{max_user_freq}=="64"

  looking at parent device '/devices/i2c-1/1-0051':
    KERNELS=="1-0051"
    SUBSYSTEMS=="i2c"
    DRIVERS=="rtc-pcf8563"
    ATTRS{name}=="pcf8563"

  looking at parent device '/devices/i2c-1':
    KERNELS=="i2c-1"
    SUBSYSTEMS=="i2c"
    DRIVERS==""
    ATTRS{name}=="aml_i2c_adap1"

Share this post


Link to post
Share on other sites
13 minutes ago, zador.blood.stained said:

Looks like RTC is configured correctly but nothing reads the time from it.

The kernel should do it automatically if it's configured correctly, please also check the output of "grep RTC_HCTOSYS /boot/config-$(uname -r)"

 

Edit: and "dmesg | grep -i rtc"

 

et voilà

root@openmediavault:~# grep RTC_HCTOSYS /boot/config-$(uname -r)
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"


root@openmediavault:~# dmesg | grep -i rtc
[    3.073994] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[   12.946414] rtc-pcf8563 1-0051: chip found, driver version 0.4.3
[   12.947104] rtc-pcf8563 1-0051: rtc core: registered rtc-pcf8563 as rtc0

Share this post


Link to post
Share on other sites

I can trust my eyes..

I have disconnected router from internet...

After that i have shutdown my odroid.

At reboot (without internet ndp server cant' update the time, right?) time and date is correct...

:)

Do you think we can close the case with a "solved"?

If is ok, ill write all in a post with entire procedure.

and change the 3d objet with [solved].

Tell me that I'm not deluding.....

Share this post


Link to post
Share on other sites
31 minutes ago, marcellom said:

At reboot (without internet ndp server cant' update the time, right?) time and date is correct...

 

As it's on almostall systems with a working network connection since on Armbian NTP is active by default. Please update the first post with this important piece of information for others trying to solve the same problem that is only one for stand-alone systems without any network connection these days :) 

Share this post


Link to post
Share on other sites

Yes dear Tkaiser.

What i want to do is start with a fresh and updated img and repeat the entire "procedure".

After that, ill write a clean post with all steps, to post here and in OMV forum.

Now i add Solved in the object EDIT BY ME: Is better wait after update try in the (now) updated OMV...

Could I thanks everyone to help?

Without you do not know how I would have done it!

 

 

 

 

Share this post


Link to post
Share on other sites

Strange: sometime on reboot time and date is right, sometime is reset to 1970.

RTC is brand new... but im thinking the battery is dead.

Ok people... i need to understand.

Ill write after battery. change.......

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

0

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.