Reset safe registers on Colibri iMX7

I have basically the same question as this one, but I don’t like to mix different Toradex modules. My plan is to implement U-Boot feature * Boot Count Limit* without constantly storing environment variables. Can this be done in Colibri iMX7?

Mentioned SRC_GRP values are only persist during warm boot. Cold boot or power down clear them. So you have to use a flash to store Boot Count .

Hi @cicicok,

Please see if this another reference may help you:

It’s considering the TK1, but may be applicable to the iMX7.

As @alex.tx told you, you’ll have to use a flash to store this kind of information.

Best regards,
André Curvello

If I’m understand this correctly if the system resets itself after for example kernel panic the SRC_GRP register could be used. But if the system completely hangs and the user must power cycled it manually storing bootcount in this register cannot be done.

Yes I know about this solution, because Mender demo (on Colibri iMX7) uses the same technique. But I want to reduce the NAND writes to the absolutely minimum.

Yes, it’s correct.
You need a persistent memory to implement a boot counter. You can connect small external flash or F-RAM chip like this one if you wish not to use embedded NAND flash.

Thank you. Actually we are right now in the phase of redesigning our PCB, so I asked for one F-RAM chip :slight_smile:

But I was also thinking about storing this variable in external RTC (like the on the Iris Carrier Board). What do you think?

An RTC chip we are using (M41T0) has no additional memory. Some other RTC may have it but data will be lost if you power off your device and remove an RTC back up battery.

I agree with @alex.tx.
In your case, @cicicok, I’d suggest the F-RAM usage.

Yesterday while I was playing with Watchdog in iMX7 I got an idea how can be my problem solved without any additional hardware. All you need is just Watchdog and storing the bootcount variable in U-Boot environment.

On iMX7 while in U-Boot one can readout the reboot reason from the watchdog (here is how). We can use this information to assume that something bad is happened during the boot or while running the system. So in the case when the reboot was caused by watchdog, we will activate the bootcount counter using upgrade_available variable. In the case of correct assumption, then by crashing and rebooting will be the bootlimit acceded and altbootcmd from U-Boot called. In the case of wrong assumption nothing unusual happens, because after successful booting in both cases will be the counter deactivated.

To use this method you have to recompile U-Boot in order to activate bootcount function and also activate the watchdog before booting the kernel.

Disclaimer: I know the F-RAM option is better, but sometimes you cannot use extra parts. What do you think about this one? Is it a madman solution?

Hi @cicicok,

If I understood you correct, your plan is to:

  • Enable Watchdog counter from U-boot
  • Activate bootcount function

Then, for your health boot monitoring, you’ll behave in this approach:

  • If Watchdog was not triggered, everything is fine, no writing to U-Boot.
  • If Watchdog was triggered, increase boot count. After watchdog being triggered X times, boot count will reach its limit, partition is not healthy, swap partition by altbootcmd or something like this.

That seems to be a good and reasonable approach.
Using U-Boot environment you’ll be writing to NAND, but less times with this strategy.

Just be aware of a reasonable time for your Watchdog timeout, and also, please take in consideration to have some sort of “service application” to feed the Watchdog in a healthy system operation.

Best regards,
André Curvello

Yes, you summarized it correctly. I hope that somebody sometimes find this solution useful.

Yes. I liked your approach.