Hello,
I’m trying to display in my application the reset reason.
I don’t think the following guide Watchdog (Linux) | Toradex Developer Center applies to PCA9450 or verdin mini, as from the the PCA9450 datasheet https://www.nxp.com/docs/en/data-sheet/PCA9450.pdf register 0xA is configuration register.
it does seem that the info I’m looking for is in register 0x5:
I can access this register with command:
cat /sys/bus/i2c/devices/0-0025/pca9450-pmic/registers | grep 0x05
my problem is, I have tried to read this register in different scenarios and the values I read are consistent (same value repeating the same pattern) but they don’t match the values reported in the datasheet.
if I issue a software reboot with “sudo reboot” command:
cat /sys/bus/i2c/devices/0-0025/pca9450-pmic/registers | grep 0x05
[0x05] = 40
If I unplug and plug back the power cable:
cat /sys/bus/i2c/devices/0-0025/pca9450-pmic/registers | grep 0x05
[0x05] = 80
If I force the hardware watchdog:
cat /sys/bus/i2c/devices/0-0025/pca9450-pmic/registers | grep 0x05
[0x05] = 50
can anyone explain the discrepancy with the datasheet?
Regards,
Rocco
Greetings @RoccoBr,
I don’t think it’s a discrepancy. The values in Linux seem to be in hexadecimal, while the datasheet shows the information in binary/bits.
With that 0x40 would mean bit 6 is set. Which looking at the datasheet corresponds to a WDOG reset. This makes sense since software reboots are done in a similar fashion to watchdog resets.
0x80 means bit 7 is set, so PWRON reset which makes sense for a full power-cycle.
0x50 means bit 6 and 4 are set. So WDOG and PMIC_RST, which seems to make sense as well.
Did that help clear things up?
Best Regards,
Jeremias
hi @jeremias.tx ,
well, I would expect bit 5 to be set in case of reboot from command line and only bit 6 in case of watchdog, but at the end of the way, the most important thing is that I get always the same value in a specific situation
Regards,
Rocco
well, I would expect bit 5 to be set in case of reboot from command line and only bit 6 in case of watchdog,
I’ve seen other customers gets similar values when doing a software reboot via the reboot command. Seems like that’s just how the driver here interprets things.
but at the end of the way, the most important thing is that I get always the same value in a specific situation
Just to confirm as you said previously the values are consistent in each situation, correct?
Best Regards,
Jeremias
Hi @jeremias.tx ,
yes I always get the same value in the same situation
Okay well, as you said what matters the most here is the consistency of the values so it’s good to see that. Do you have any other questions on this topic then?
Best Regards,
Jeremias
Glad we were able to help clarify!
hi @jeremias.tx ,
I am reopening this issue as I have switched to BSP 6.7.0 and I can’t access the reset register anymore.
On BSP5 I could access registers as /sys/bus/i2c/devices/0-0025/pca9450-pmic/registers
but not on BSP6:
/sys/bus/i2c/devices/0-0025$ ls -lh
total 0
lrwxrwxrwx 1 root root 0 Aug 9 10:35 consumer:platform:usbphynop1 -> ../../../../../../virtual/devlink/i2c:0-0025--platform:usbphynop1
lrwxrwxrwx 1 root root 0 Aug 9 10:35 consumer:platform:usbphynop2 -> ../../../../../../virtual/devlink/i2c:0-0025--platform:usbphynop2
lrwxrwxrwx 1 root root 0 Aug 9 09:40 driver -> ../../../../../../../bus/i2c/drivers/nxp-pca9450
-r--r--r-- 1 root root 4.0K Aug 9 10:35 modalias
-r--r--r-- 1 root root 4.0K Aug 9 09:40 name
lrwxrwxrwx 1 root root 0 Aug 9 10:35 of_node -> ../../../../../../../firmware/devicetree/base/soc@0/bus@30800000/i2c@30a20000/pmic@25
drwxr-xr-x 2 root root 0 Aug 9 10:35 power
drwxr-xr-x 13 root root 0 Aug 9 09:40 regulator
lrwxrwxrwx 1 root root 0 Aug 9 09:40 subsystem -> ../../../../../../../bus/i2c
lrwxrwxrwx 1 root root 0 Aug 9 10:35 supplier:platform:30200000.gpio -> ../../../../../../virtual/devlink/platform:30200000.gpio--i2c:0-0025
lrwxrwxrwx 1 root root 0 Aug 9 10:35 supplier:platform:30330000.pinctrl -> ../../../../../../virtual/devlink/platform:30330000.pinctrl--i2c:0-0025
-rw-r--r-- 1 root root 4.0K Aug 9 09:40 uevent
do you know how to access register 0x5 on BSP6?
Reagrds,
Rocco
Drew has found the same info here:
/sys/kernel/debug/regmap/0-0025/registers
Hi @RoccoBr !
Please keep in mind that /sys/kernel/debug/regmap/0-0025/registers is a kernel debug feature.
This is part of the DebugFS and one should carefully consider if it is desirable to have it enabled in production. Having it enabled also affects the overall performance of the system.
So please keep in mind the tradeoff of having DebugFS enabled in production.
Best regards,
hi @henrique.tx thanks for the clarification
how can I get the same info without using debugFS?
by the way I haven’t enabled it manually, it seems to be enabled by default in BSP6 for yocto
Regrads,
Rocco
Hi @RoccoBr !
Sorry for the delay.
After some internal discussion, there is a bit more information about this topic.
Indeed from kernel used in BSP 5 to kernel used in BSP 6, what PCA9450’s driver exposes to userspace and how it is exposed to userspace simply changed.
On BSP 5 it is possible to access the register through sysfs.
On BSP 6 it is not exposed on sysfs, but on debugfs.
The thing is: as of now debugfs has “no stability constraints placed on files exported there” [1]. Which means: things might simply change on a newer kernel version, therefore the way you are using to access it might simply break on an upcoming version of the kernel.
So, you can:
- Simply keep using debugfs as it is right now keeping in mind that upon a new kernel version you will need to check the debugfs file(s) you are accessing, or
- Customize the driver for your use case, which means building Torizon OS from Yocto to apply your customization (since the PCA9450’s driver is builtin - you can check using
sudo zcat /proc/config.gz | grep PCA9450)
[1] DebugFS — The Linux Kernel documentation
Best regards,
