External RTC wakealarm, permission denied

Hi, I have an external RTC on my custom carrier board, a DS3231. to use it, I’ve created my own DTS file (in my custom Yocto layer for this target). What I want to achieve is that the alarm feature of this RTC is enabled, and that the INT pin of this RTC will trigger when the alarm goes off.

The DTS entry:

&i2c1 {
	status = "okay";

	/* DS3231 real time clock on carrier board */
    	ds3231: ds3231@68 {
		compatible = "maxim,ds3231";
		reg = <0x68>;
		status = "okay";
		wakeup-source;
	};
};

The external RTC seems to be working:

dmesg |grep rtc
[    1.833129] rtc-ds1307 0-0068: registered as rtc0
[    1.843403] snvs_rtc 20cc000.snvs:snvs-rtc-lp: registered as rtc1
[    3.436208] rtc-ds1307 0-0068: setting system clock to 2020-12-16T08:37:49 UTC (1608107869)

But, the alarm feature does not:

echo +10 > /sys/class/rtc/rtc0/wakealarm
-sh: /sys/class/rtc/rtc0/wakealarm: Permission denied

some further info:

 cat /proc/driver/rtc
rtc_time        : 09:01:47
rtc_date        : 2020-12-16
alrm_time       : 00:00:00
alrm_date       : 1970-01-01
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1
max user IRQ frequency  : 64
24hr            : yes

What am I doing wrong?

@DBakker,

When installing your image with the Toradex Easy Installer, the image.json configuration file determines which dtb is going to be written to NAND. You can try modifying your image.json changing the default dtbs to yours, since it should already be on the image package.

That’s interesting: my DTB file is not in the image package! In the meantime, I’ve discovered that my custum kernel configuration is also being ignored by OE, it seems as if all custom changes that I made to the kernel and boot configuration in my custom layer are ignored. But, the additional packages I enabled in my layer, and some other customisation (adding a user for example) are implemented in my custom build.

Is there something I’m missing here?

Okay, I solved the issue with the custom kernel configuration that was ignored: I followed these steps here, using colibri-imx6ull as folder name. That does mean however that the section on custom kernel configs on the Toradex wiki is wrong: here.

What remains is that my custom device tree still isn’t being built.

@DBakker,

Thanks for your feedback. I’ll check with the BSP team about your custom device tree not being built and fix the article. I’ll get back to you as soon as I have more info on this.

@DBakker you missed one important thing in your device-tree…
You need an interrupt line to get alarm feature working(this feature isn’t well described)

Lets say your RTC INT line is connected to GPIO1_IO08
It should look like:

&iomuxc {
	pinctrl_rtc_int: rtc-int-grp {
		fsl,pins = <
			MX6UL_PAD_GPIO1_IO08__GPIO1_IO08  0x14
		>;
	};
};

&i2c1 {
	status = "okay";

	/* DS3231 real time clock on carrier board */
	ds3231: ds3231@68 {
		compatible = "maxim,ds3231";
		reg = <0x68>;
		/* setup pinctrl for IRQ line */
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_rtc_int>;
		/* setup interrupt parent and IRQ type - in this example GPIO1(irq parent) IO08(IRQ num) */
		interrupt-parent = <&gpio1>;
		interrupts = <8 IRQ_TYPE_EDGE_RISING>;
		wakeup-source;
		status = "okay";
	};
};

Some further info, another change that I made to the device tree also wasn’t working, so I checked

cat /proc/device-tree/model

and the response is the default model description for the Colibri evaluation board, not the model text in my own DTS file. Am I correct in assuming that the default DTB is still being used, not my own?

I followed the steps here: Custom meta layers, recipes and images in Yocto Project (hello-world examples) | Toradex Developer Center
I’ve got a file linux-toradex_%.bbappend in recipes-kernel/linux:

FILESEXTRAPATHS_prepend := "${THISDIR}/linux-toradex:"
 
CUSTOM_DEVICETREE = "dc-devicetree.dts"
 
SRC_URI += "\ 
	file://${CUSTOM_DEVICETREE} \
	"
 
do_configure_append() {
	# For arm32 bit devices
	cp ${WORKDIR}/${CUSTOM_DEVICETREE} ${S}/arch/arm/boot/dts
	# For arm64 bit freescale/NXP devices
	# cp ${WORKDIR}/${CUSTOM_DEVICETREE} ${S}/arch/arm64/boot/dts/freescale
}

in conf/machine I have colibri-imx6ull-extra.conf:

KERNEL_DEVICETREE_append = " dc-devicetree.dtb"

in layer.conf I added:

include conf/machine/colibri-imx6ull-extra.conf

and finally, in recipes-bsp/u-boot, the file u-boot-toradex_%.bbappend:

do_configure_append() {
	sed -i 's/#define FDT_FILE.*/#define FDT_FILE "dc-devicetree.dtb"/' ${S}/include/configs/colibri-imx6ull.h
}

compilation doesn’t give any warnings (it did give a warning when I wrote colibri_imx6ull.h in the last file instead of colibri-imx6ull.h, though). Did I miss something?

@gustavo.tx Nope, it’s not there. Only

  • imx6ull-colibri-eval-v3.dtb
  • imx6ull-colibri-wifi-eval-v3
  • imx6ull-colibri-eval-v3-colibri-imx6ull.dtb
  • imx6ull-colibri-wifi-eval-v3-colibri-imx6ull.dtb
  • imx6ull-colibri-eval-v3–5.4.47+git0+9e7307657f+git0+9e7307657f-r0-colibri-imx6ull-20201217131613.dtb
  • imx6ull-colibri-wifi-eval-v3–5.4.47+git0+9e7307657f+git0+9e7307657f-r0-colibri-imx6ull-20201217131613.dtb

The machine configuration defines what device trees get built and deployed.

The steps in the Toradex custom image guide implement that with KERNEL_DEVICETREE_append, right? that’s what I used as well, my second response contains the details

@DBakker,

In the meantime, can you please check if your .dtb is present on deploy/images/colibri-imx6ull? It is possible that your device tree was in fact built but not properly packaged.

Good catch @qba.

Can you confirm if this solves your issue, @DBakker?

Best regards,
André Curvello

Hi Andre, no, the issue was that my custom device tree was not being built at all using the instructions on the Toradex wiki. I reverse-engineered how to get a custom device tree in my layer by looking at how that was done in the Toradex layers and copying that. Once that was working my device tree was loaded correctly and the external RTC is now working.

Oh, good to know.

So, in another words, the root-cause of the issue was more “Yocto-related” than device-tree related, right?

Thanks for the feedback.

Best regards,
André Curvello