• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 2545 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.

U-Boot: Problem with Redundant NAND partitions for U-Boot Environment

anthony barrera
Intellectual 430 points


Hello,


I am having issue with my system and I am not sure what is my best solution.


I am running an custom board based on the BeagleBone Black, using NAND instead of eMMC. U-Boot version is u-boot-2013.10-ti2013.12.01.

Our system has 2 partitions for storing U-Boot environment variables, mtd6 (primary) and mtd7 (redundant). Initially, when executing saveenv, I thought U-Boot wrote the environment variables to both mtd6 and mtd7. Apparently, every time a saveenv is executed, U-Boot only writes to one of them and alternates between them for every saveenv.


My issue is that once linux kernel starts, my application needs to access the U-Boot parameters, which I accomplish using nanddump. The problem is I dont know which U-Boot partition is active, so I dont know whether to read from mtd6 or mtd7. A couple questions:

1. What is the philosophy behind alternating between the primary and backup partitions?

2. From Linux, is there a way to determine the active partition? Our current workaround is to always execute saveenv twice so that the current environment is always saved to both partitions, then we always read mtd6.

Thanks in advance for any help! - Anthony

  • 0
    TI__Guru** 116100 points
    Hi Anthony,


    Our system has 2 partitions for storing U-Boot environment variables, mtd6 (primary) and mtd7 (redundant). Initially, when executing saveenv, I thought U-Boot wrote the environment variables to both mtd6 and mtd7. Apparently, every time a saveenv is executed, U-Boot only writes to one of them and alternates between them for every saveenv.


    Have you seen this behavior BBB when it boots from eMMC ?
    Try to add some debug prints in the following file (for NAND) to identify , why & which is causing the problem.

    u-boot-2013.10-ti2013.12.01/common/env_nand.c
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 430 points
    Hi Titus, thank you for your reply. I have studied the U-Boot code already, and this alternation between saving to primary or redundant NAND partition is by design, so its not necessarily a problem or a bug... but it is causing me problems when reading the U-Boot environment from the Kernel since I dont know which partition U-Boot used as its active partition.

    I was debating hacking the U-Boot code to just always write to both environment partitions every time a saveenv is executed... but wanted to ask here first to see if anyone knew the reasoning behind this alternation. Perhaps hacking the code is not the best option?
  • 0
    Guru 11260 points

    Hi,

    My issue is that once linux kernel starts, my application needs to access the U-Boot parameters, which I accomplish using nanddump. The problem is I dont know which U-Boot partition is active, so I dont know whether to read from mtd6 or mtd7. A couple questions:

    1. What is the philosophy behind alternating between the primary and backup partitions?

    When it comes to NAND, there will be 'NAND Bad Blocks', so since your uboot environment is important the uboot provides an option to have your environment variables in different location aswel using CONFIG_ENV_OFFSET_REDUND, so what it does it when you do saveenv it will automatically alter between its partitions.

    2. From Linux, is there a way to determine the active partition? Our current workaround is to always execute saveenv twice so that the current environment is always saved to both partitions, then we always read mtd6.

    Uboot provides a tool to be used from linux fw_printenv & fw_setenv dig up through it (I am running out of time or would have explained), that will solve your problem if you still face any issues using fw_printenv ping me.

    Thanks,

    --Prabhakar Lad