• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 303 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TDA4VM: Does TDA4 uboot support bootcount?

SK-TDA4VM: Support bootcount feature for J721E

Soumya Kar
Prodigy 130 points
Part Number: SK-TDA4VM

Hi,

Our objective is to enable CONFIG_BOOTCOUNT for our SK-TDA4 J721 board, so that if during bootup the Linux or rootfs does not boot up properly then after a defined number of resets/reboots, we will be switching to a different partition. So in our yocto (Kirkstone) codebase, we found that inside the folder, arago-tmp-default-glibc/work/j721e_evm-oe-linux/u-boot-ti-staging/1_2021.01+gitAUTOINC+78a217ca9e-r33/git, j721e_evm_a72_defconfig has been defined. So we created a bbappend file in our sources folder and added the following properties:

CONFIG_BOOTCOUNT_LIMIT=y
CONFIG_BOOTCOUNT_BOOTLIMIT=4
CONFIG_BOOTCOUNT_ENV=y

Then if the bootlimit has ben reached, then we can try to execute the altbootcmd (not sure how, but we understand from reading several posts and blogs) and switch from the error rootfs partition or the last working rootfs partition.

But while trying to understand more, we came upon this post.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1235518/tda4vm-does-tda4-uboot-support-bootcount

This states that this setup does not support CONFIG_BOOTCOUNT_LIMIT. Is there any other way to enable it? Won't defining the CONFIG_BOOTCOUNT_LIMIT property in defconfig file have any impact? Please requesting for assistance and help.

  • 0
    Prodigy 130 points

    With the above changes inside the u-boot console, I can see the following changes, which can be seen after making the changes in defconfig file.

    bootcount=1
    bootdelay=6
    bootlimit=4

    Now to test, I updated bootpart from 1:2 to 1:3. After this when I am issuing the boot command, it gives the error as:

    Bad Linux ARM64 Image magic!

    This is expected as partition mmcblk0p3 is empty, but I see the bootcount is still staying at 1. Is this expected ?

  • 0
    TI__Guru**** 162990 points

    Hi Soumya,

    Soumya Kar said:
    This states that this setup does not support CONFIG_BOOTCOUNT_LIMIT

    The SDK by default does not enable this config.

    This feature is nothing specific to hardware & it is a generic U-Boot feature. I believe this is a question that can be posted to:

     u-boot@lists.denx.de

    - Keerthy

  • +1
    Prodigy 130 points

    Finally I was able to make it work. Following are the steps that are required to be followed:

    We need to append the following lines for the file (arago-tmp-default-glibc/work/j721e_evm-oe-linux/u-boot-ti-staging/1_2021.01+gitAUTOINC+78a217ca9e-r33/git, j721e_evm_a72_defconfig)

    CONFIG_BOOTCOUNT_LIMIT=y
    CONFIG_BOOTCOUNT_BOOTLIMIT=4
    CONFIG_BOOTCOUNT_ENV=y

    Once done, for the respective header we need to add the option for upgrade_available so that it gets added as part of uboot.env file. The file is j721e_evm.h. Now during the update process, upgrade_available needs to be set to 1.

    Now during reboot/reset, if the linux does not get booted from the new partition (as defined by bootpart) then the bountcount increases and once it becomes greater than bootlimit, altbootcmd get executed. The property altbootcmd can be added in j721e_evm.h too.

  • 0 in reply to Soumya Kar
    TI__Guru**** 162990 points

    Thanks a lot Soumya for sharing this.

    - Keerthy