![]() Time-sync.target (for early-boot clock-dependant services). Systemd-timedated, of which only systemd-timesyncd starts early on boot, beforeĪll other services, including systemd-timedated, sysinit.target and "userspace daemons" in question on a basic Arch are systemd-timesyncd and To order userspace daemons depending on that symlink to start strictly after Unit (auto-generated, see vice(5) for more info), which is useful Node name from "les", which has link_priority=-100.Īlso, TAG+="systemd" makes systemd track device with its "vice" This sets "link_priority" to 10 to override SYMLINK directive for same "rtc" dev SUBSYSTEM="rtc", KERNEL="rtc1", SYMLINK+="rtc", OPTIONS+="link_priority=10", TAG+="systemd" "/usr/lib/udev/rules.d/les", and can be overidden byĮ.g. "/dev/rtc" symlink for userspace gets created by udev, according to Using wrong RTC, which is default in both cases. So two issues are with "system clock" that kernel keeps and userspace daemons Points to rtc0 as well, and rtc1 - no matter how early it appears - gets Symlink (and can't be configured to use other devs), which by default udev RTC via systemd-timedated and systemd-timesyncd, which both use "/dev/rtc" One and kernel will already pick up time from internal rtc0 by the time this oneįurthermore, systemd-enabled userspace (as in e.g. Internal one) on system startup, but unfortunately it still won't be the first ![]() That should ensure that this second RTC appears as "/dev/rtc1" (rtc0 is the Tree, where it's currently the latest supported release. Workaround is to downgrade kernel to 4.9, e.g. Kernel BUG instead of loading any overlays - be sure to try loading that dtboĪt runtime (checking dmesg) before putting it into cmdline, as that might make Included and loaded there, strictly before rtc overlay.īone_capemgr seem to be broken in linux-am33x packages past 4.9, and produces i2c-1 instead (with &bb_i2c1_pins), BB-I2C1 should also be FILES="/lib/firmware/BB-RTC-02-00A0.dtbo" -Īnd re-running the usual mkinitcpio -g /boot/initramfs-linux.img command. With Arch-default mkinitcpio, it's easy to do via FILES= in Via bone_capemgr.enable_partno= must be included there. Where kernel will look up stuff in /lib/firmware, so all *.dtbo files loaded Modern ArchLinuxARM always uses initramfs image, which is starting rootfs, bone_capemgr.enable_partno=BB-RTC-02"ĭocs in bb.org-overlays repository have more details and examples on how to ![]() To something like "/boot/uEnv.txt", for example (with dtb path from command above): Mounted) with "bone_capemgr.enable_partno=" cmdline addition, and should be put Update : This will always produce a warning for each "fragment"Īnd then loaded on early boot (as soon as rootfs with "/lib/firmware" gets Package on ArchLinuxARM) to the destination with:ĭtc -O dtb -o /lib/firmware/BB-RTC-02-00A0.dtbo -b0 i2c2-rtc-ds3231.dts * bone_capemgr.enable_partno=BB-RTC-02 */Ĭompatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green" Īs per comment in the overlay file, can be compiled ("dtc" comes from same-name I2c2 bus and "ds3231" kernel module (alias for "ds1307", but more appropriate Tree Overlays (usually "/lib/firmware/*.dtbo" files, compiled by "dtc" from dtsįiles), which is kinda like patching Device Tree, only done at runtime.Ĭode for such patch in my case ("i2c2-rtc-ds3231.dts"), with 0圆8 address on 3.18.x kernels it had to be done by patching and re-compiling platform dtbīut since 3.19.x kernels (and before 3.9.x), easier way seem to be to use Device ![]() Usually accomplished by adding the thing to Device Tree, and earlier withĮ.g. This obviously doesn't enable device straight from the boot though, which is Numbers on BBB headers, and how to check/detect/enumerate connected devices Ways to tell reliably which i2c device in /dev corresponds to which bus and pin (see this post on Fortune Datko blog and/or this one on minix-i2c blog for ICs like DS1307 or DS3231 (a better one of the line) with I2C interface, whichĪre all supported by Linux "ds1307" module.Įnabling connected chip at runtime can be easily done with a command like this:Įcho ds1307 0圆8 >/sys/bus/i2c/devices/i2c-2/new_device Of cheap chips with various precision available, most common being Dallas/Maxim Network access (or a patchy one) to sync this internal RTC when board boots up.Įasy solution to that, of course, is plugging external RTC device, with plenty This represents a problem if keeping track of time is necessary and there's no The SoC, which isn't battery-backed, so looses track of time each time device BeagleBone Black (BBB) boards have - and use - RTC ( Real-Time Clock -ĭevice that tracks wall-clock time, including calendar date and time of day) in ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |