Compilation of u-boot with CONFIG_BOOTCOUNT_LIMIT

When I tried to build u-boot with CONFIG_BOOTCOUNT_LIMIT enabled in include/configs/apalis-tk1.h I got an error output like described here. In the u-boot docs it is stated that “At the moment, the Boot Count Limit feature is available only for MPC8xx, MPC82xx and MPC5200 Power Architecture® processors.” ( ubootBootcountAccess.c ). Does the TK1 support this feature? If yes: What additional configuration needs to be considered? If no: Can I use some workaround instead?

The following hardly documented configurations need to be considered when one wants to enable bootcount limit support (info from here):

  • CONFIG_BOOTCOUNT_LIMIT (enables the bootcount limit functionality)
  • CONFIG_SYS_BOOTCOUNT_ADDR (address where boot count is stored)
  • CONFIG_BOOTCOUNT_MAGIC (just 1 google hit, right now I don’t know what it is dooing…)
  • CONFIG_BOOTCOUNT_RAM (to store it in RAM?)
  • CONFIG_BOOTCOUNT_I2C (to store it in I2C device?)
  • CONFIG_BOOTCOUNT_ENV (to store it in u-boot environment?)

The following environment variables need to be considered:

  • bootlimit: needs to be set to a value >=1
  • bootcount<=bootlimit: boots with bootcmd
  • bootcount>=bootlimit: boots with altbootcmd or enters u-boot interactive mode (if altbootcmd not defined)

Does someone know if my assumptions are correct and what needs to be considered when I want to store the bootcount in the eMMC?

It seems like that other boards like the BeagleBone Black need to have #define CONFIG_BOOTCOUNT_LIMIT and #define CONFIG_BOOTCOUNT_ENV configured in its board specific u-boot configuration file /include/configs/am335x_evm.h in u-boot-toradex.git - U-Boot bootloader for Apalis and Colibri modules when not using RTC but the u-boot environment to store it

@@ -208,7 +207,7 @@
 /* Bootcount using the RTC block */

 /* USB gadget RNDIS */
@@ -396,11 +395,6 @@
 #elif defined(CONFIG_EMMC_BOOT)
-#define CONFIG_ENV_OFFSET		0x0
 #elif defined(CONFIG_NOR_BOOT)
 #define CONFIG_ENV_SECT_SIZE		(128 << 10)	/* 128 KiB */
@@ -417,11 +411,7 @@
 #define CONFIG_ENV_OFFSET_REDUND	0x001e0000
 #elif !defined(CONFIG_ENV_IS_NOWHERE)
-/* Not NAND, SPI, NOR or eMMC env, so put ENV in a file on FAT */
-#define FAT_ENV_INTERFACE		"mmc"
-#define FAT_ENV_DEVICE_AND_PART		"0:1"
-#define FAT_ENV_FILE			"uboot.env"

I enabled in /include/configs/apalis-tk1.h:


I disabled in /include/configs/apalis-tk1.h:


However I get still compilation errors when trying to compile u-boot using make distclean, make apalis-tk1_defconfig and make -j3 2>&1 | tee build.log due to some misconfiguration:

scripts/kconfig/conf  --silentoldconfig Kconfig
/bin/sh: 1: Syntax error: end of file unexpected (expecting ")")
make[1]: *** [include/config.h] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by `include/config/uboot.release'.  Stop.

I would not recommend storing the boot count in the U-Boot environment as this will cause excessive writing to this otherwise vital configuration data area.

I know just about this possibility. What approach for storing of the boot count would you suggest?

I guess APBDEV_PMC_SCRATCH or the iRAM would be much better suited. However we have not tried messing with any of that as of yet. To be honest a boot count is not a feature we officially support on any of our modules so far.

What about loading the u-boot environment explicitly from a file in the boot partition like done for the BeagleBone Black (lines 70-89)?

I would not recommend doing this other than maybe for some initial pre-setting as part of an update script.

With relation to write-cycle limitations this should be uncritical as long as there is shuffling of the memory written to, right? Why wouldn’t you recommend that?

Increased write-cycles are not the sole issue here. Any such cross bootloader/kernel dependency increases complexity and therefore is ultimately prone to errors. This was e.g. the reason we separated device tree and kernel from the regular rootfs partition into its separate one. Especially on the raw NAND based modules running UBIFS based rootfs’ doing this tremendously decreased failure rate during our regular validation & verification runs in the climate chamber.

Ultimately this all depends on your requirements and you are very welcome to change whatever you desire just don’t blame us if the final result does not quite perform as expected.

Ok thanks, I understand.

A further question related to the overall topic:
Needs the wear leveling of the eMMC to be activated or is it activated by default? (I did not find something about that in the datasheets of the THGBMHG7C1LBAIL

An eMMC is a managed flash just like e.g. MMC/SD cards, SSDs or USB sticks and it’s self-contained controller/firmware should take care of all this.

We are actually about to publish some more information about this topic on our developer website including how one can find out about bad blocks, wear and expected remaining lifetime of eMMCs.

The compilation error was due to a typo in scripts/Makefile.autoconf. It compiles.

CONFIG_ENV_OFFSET_REDUND is disabled in my current configuration in addition and #define CONFIG_SYS_BOOTCOUNT_BE seems to be not required as well.

Hi is this problem fixed before.

@Florian_K could you fixed this problem with your Toradex board? I need same solution, what steps should be followed from my side.

Can you please help me at this point.

Best regards,

Hi is this problem fixed before.

@Florian_K could you fixed this problem with your Toradex board? I need same solution, what steps should be followed from my side.

Can you please help me at this point.

Best regards,