• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 98 subscribers
  • Views 3612 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.

Bad block in uboot environment

Arno Steffens
Intellectual 930 points


In one of my devices, uboot-environment is located at a bad block.
"save
Saving Environment to NAND...
Erasing Nand...
Skipping bad block at  0x000c0000

Writing to Nand... FAILED!"

In my memory mapping I have already reseverd 2blocks.
How can I setup uboot in a way, that it will look at c0000 or (in case
of bad block) at the next block e0000?

In my configs file I found somewhat like:
#define CONFIG_ENV_SIZE                 (128 << 10)     /* 128 KiB */
#define SMNAND_ENV_OFFSET               0xC0000 /* environment starts here */
#define CONFIG_SYS_ENV_SECT_SIZE        boot_flash_sec

in mem.c of my processor I found:
      f_sec = (128 << 10);    /* 128 KiB */
      /* env setup */
      boot_flash_base = base;
      boot_flash_off = f_off;
      boot_flash_sec = f_sec;

uboot is based on 2010.03 release.

Maybe someone can give me an advice?
Thanks
- Arno

PS:
Move the base address of environment is not an option, as in next
device the bad block might be on exact this location.
Environment itself is just 2kB, but a block is 128k.  Can I decrease
the environment to that size and still use access from linux (via
fw_printenv)?

  • 0
    Prodigy 220 points

    Hi Arno!

    Do you solved this problem?

  • 0 in reply to Oleg Loginov
    Intellectual 930 points

    No, couldn't find a solution right now. Maybe this is the way:

    In tools/env/readme I found something that might help

    #define HAVE_REDUND    /* For systems with 2 env sectors */

    DEVICEx_ENVSECTORS defines the number of sectors that may be used for
    this environment instance. On NAND this is used to limit the range
    within which bad blocks are skipped, on NOR it is not used.

    But I am not sure whether it is automatically switching to this 2nd environment, if CRC fails or BAD block is in 1st one.

     

     

     

     

     

  • 0 in reply to Arno Steffens
    Prodigy 220 points

    Thanks Arno!

    What version PSP do you use?

     

  • 0 in reply to Oleg Loginov
    Intellectual 930 points

    Current 4.2.0.6 from git tree. Do you have same trouble with bad block in environment? Let me know if (and how) you can solve this.

    Actually I have a problem to get 2.6.37 from git running with SW-ECC. That drives me crazy...

  • 0 in reply to Arno Steffens
    Prodigy 220 points

    Hi, Arno!
    Yes, I have same problem whith bab block in enviroment. I necessarily write to you, if solved this trouble. I have board DM365 and use PSP_02_10_00_08 (uboot 1.3.4) release. I will think how to avoid write to bad blocks. I want rebuild uboot, maybe this is help.

    sory for bad english)

  • 0 in reply to Arno Steffens
    Prodigy 220 points

    Hi Arno!

    I used U-Boot 2010.12-rc2 (Mar 24 2011) include DVSDK 4_02_00_01 and problem solved. How i undestand u-boot 2010.12 have skip bad blocks at read/write.

    After install u-boot  2010.12 necessarily do command  #nand scrub  for full erase flash and clear OOB(out of band) area in NAND. Next install u-boot afresh and u-boot must create own bad blocks table.

    My log:

    U-Boot 2010.12-rc2 (Mar 24 2011 - 19:27:17)

    Cores: ARM 297 MHz
    DDR:   243 MHz
    I2C:   ready
    DRAM:  128 MiB
    NAND:  2048 MiB
    MMC:   davinci: 0, davinci: 1
    Bad block table found at page 524224, version 0x01
    Bad block table found at page 1048512, version 0x01
    Bad block table found at page 524160, version 0x01
    Bad block table found at page 1048448, version 0x01

    Net:   Ethernet PHY: GENERIC @ 0x00
    DaVinci-EMAC
    Hit any key
    to stop autoboot:  3

    DM36x EVM #
    saveenv
    Saving Environment to NAND...
    Erasing Nand...

    Erasing at 0x3c0000 --  50% complete.

    Erasing at 0x3e0000 -- 100% complete.
    Writing to Nand... done
    DM36x EVM #

    DM36x EVM # nand bad

    Device 0 bad blocks:
      3ff80000
      3ffa0000
      3ffc0000
      3ffe0000
      7ff80000
      7ffa0000
      7ffc0000
      7ffe0000
    DM36x EVM #

    I hope this help.

    Regards, Oleg

  • 0 in reply to Oleg Loginov
    Intellectual 930 points

    Hi Oleg,

    sorry, but I don't understand. Do you mean, it is all automatically handled in 2010.12-rc2 ?

    From what I see in your log: your environment is in 3c0000, but there is no bad block there. So of course you don't have a problem there ... What are your configurations about the environent ( start, size ?)

    Regards

    Arno

  • 0 in reply to Arno Steffens
    Intellectual 930 points

    I could manage bad block handling (with help from u-boot mailing list). The missing setting was just this line:

    #define CONFIG_ENV_RANGE        (CONFIG_SYS_ENV_SECT_SIZE * 2)    /* for bad block handling */

    CONFIG_SYS_ENV_SECT_SIZE is for me 1 sector, so I have one sector to handle a bad block.

    Additionally I added redundancy with this:

    #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
    #define CONFIG_ENV_OFFSET_REDUND    0x100000 /* no bracets! */
    #define CONFIG_ENV_SIZE_REDUND        (CONFIG_ENV_SIZE)

    The behaviour of this is not completly clear to me. There is a question left for redundancy, which is imho a bug (or maybe
    I don't get the design concept of redundancy):
     If I have an empty environment (both standard and redund - env1 and env2 ) and boot, it recognizes CRC error (which is ok).
    A "save" write it to redundand environment (0x10.0000). This is probably as it recognice an CRCerror in env1 and doesn't check this for env2

    If I add some settings ("set test true") and do "save" a second time - it writes ONLY to default env1 (0xc.0000) ?!?
    What happens, that it will change location? Or shouldn't it write to both locations ?

    Regards

    Arno

  • 0 in reply to Arno Steffens
    Prodigy 220 points

    Hi, Arno

    I did  # mark mark bad 0x3c0000. Next:

    #nand bad

    Device 0 bad blocks:

    Device 0 bad blocks:
      003c0000
      3ff80000
      3ffa0000
      3ffc0000
      3ffe0000
      7ff80000
      7ffa0000
      7ffc0000
      7ffe0000

    After did command #saveenv and was disappointed:

    Saving Environment to NAND...
    Erasing NAND...
    Skipping bad block at  0x003c0000
    Erasing at 0x3e0000 -- 100% complete.
    Writing to NAND... FAILED!

    I thought, if u-boot finds bad block, then go at next good block and write environments. It is not so.......

    my config davinci_dm365evm.h:

    #ifdef CONFIG_NAND_DAVINCI
    #define CONFIG_ENV_SIZE        (256 << 10)    /* 256 KiB */
    #define CONFIG_ENV_IS_IN_NAND
    #define CONFIG_ENV_OFFSET    0x3C0000

    nand block size 128 Kbyte (0x20000), nand page 2KByte (0x800)

    How do you write and probably need to do CONFIG_ENV_OFFSET_REDUND (optional): uboot/git/readme:

          This setting describes a second storage area of CONFIG_ENV_SIZE
          size used to hold a redundant copy of the environment data, so
          that there is a valid backup copy in case there is a power failure
          during a "saveenv" operation.  CONFIG_ENV_OFFSET_RENDUND must be
          aligned to an erase block boundary.

     


     

     

     

     

  • 0 in reply to Arno Steffens
    Prodigy 220 points

    Hi, Arno

    I have not had to deal with REDUNDAND_ENVIRONMENT.

    To test, I try to create CONFIG_ENV_OFFSET_RENDUND, ie

    CONFIG_ENV_OFFSET 0x3C0000
    CONFIG_ENV_OFFSET_REDUND 0x400000
    CONFIG_ENV_SIZE (256 <<10) / * 256 KiB * /
    CONFIG_ENV_RANGE (2 * CONFIG_ENV_SIZE)

    1 env (0x3C0000 + CONFIG_ENV_RANGE (512KiB)) (0x3C0000 - 0x440000)
    2 env (0x44000 - 0x48000) (rendund)

    Then do the command # mark bad 0x3C0000 and see what happens when  use commands #saveenv))

    Tired of this u-boot))
    If you have already done so, please let us know

    Regards, Oleg

  • 0 in reply to Oleg Loginov
    Intellectual 930 points

    I do have a board with bad block in environment area. It is handled now. Also redundancy works - I am happy. I recommend to reduce the environment size, to get it more reliable.

    So I have two envirenments, each is 2 sectors wide (one for use, one spare for bad block). This is same like you, if I see this right. And I use just 8k in the 128k sector size. So you have to shrink down ENV_SIZE to 8<<10. If you use 256<<10 you have no free space for bad block handling. It should be max as big as one sector!

    Hope I could help

    Regards, Arno

  • 0 in reply to Arno Steffens
    Prodigy 220 points

    Hi Arno!

    I'm glad you got it! Thanks for the advice. Now I know how to bypass the record in bad blocks!

     

    Regard, Oleg