• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 365 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.

UBL/U-Boot/Kernel memory layout in big block NAND

J.C. Wren
Prodigy 140 points

I'm bringing up a DM6446 board with a 4GB BBN.  While I have it basically working, I'm puzzled by where things are getting put.  I'm using sfh_DM6446 to load the UBL and U-Boot.  It appears to be loading the UBL to blocks 1 though 5, which is consistent with the having 5 copies of the UBL.  U-Boot is going into blocks 6 through 49.  But with a blocksize of 128K, when loading the kernel to 0x40000, this winds up in the middle of space sfh used to store U-Boot.  U-Boot is only 140K or so, so why is sfh using so many blocks?  In addition, U-Boot is saving the environment at 0x40000 (256K), which is where the #2 UBL backup resides.

To get U-Boot to work, I had to adjust the CFG_ENV_SECT_SIZE and CFG_ENV_SIZE in include/configs/davinci.h to 0x20000.  Leaving CFG_ENV_SIZE unchanged results in a 'Length not block aligned' error when erasing the configuration space.

Unfortunately, the 'nand dump' command has such painful output, it's difficult to figure out what's where by comparing bytes from the NAND against bytes of the UBL and U-Boot binaries.  And the comparing I did didn't have results I expected (but I'm attributing that to me, at the moment).

Ultimately, this is important because I need to adjust the mtd_partition table so the mtdblocks are correctly aligned.

Thanks,

--jc

  • 0
    Intellectual 760 points

    Juan, is there someone there that could help with this also?  It is not impeedding us at the momment, but it will soon. ... gary

  • 0
    TI__Mastermind 37340 points

    jc,

    Some of what you have said makes sense and some other stuff does not.  I am not sure what NAND device you are using, but assuming that your NAND device is supported by RBL in DM6446 (not sure if DM6446 supports 4GB BBN), then we should be focusing on block size, which according to your comments above is 128k or (0x20000).  This is likely why you had to change CFG_ENV_XXX values; if you choose a different NAND part, you need to add support for your NAND device which implies changing some of the variables in u-boot.

    That said, I find it very hard to believe that sfh_dm6446 places u-boot in blocks 6 thru 49; as you noted u-boot is not that big.  That said, you have the source code thus you can change block offsets if you wish.  From a hardware point of view, the only restriction is UBL is stored starting at block 1.  The address offset for u-boot can be anywhere in NAND you wish, so long as the address offset is built into UBL so it knows where to find it.  Likewise for uImage (linux kernel), you can stored it whereever you wish, so long as you configure u-boot so that it knows where to look for it (typically specified in bootcmd). 

     

  • 0 in reply to Juan Gonzales
    Prodigy 140 points

    Juan,

    The RBL supports the 4GB NAND we're using (MT29F4G08ABC, 4GB, x8, 1.8V, 0xAC indentifier).  Changing U-Boot is not necessary.  Relocating blocks is not necessary nor desirable.

    The question is why does sfh_dm6446 correctly program a small part and incorrectly programs a large part.  It would appear to be a problem with sfh_dm6446 and not the RBL.  Possibly the UBL, but other than how it might relate to sfh_dm6446 programming the flash, there are no problems that are affecting U-Boot or anything else.

    --jc

  • 0 in reply to J.C. Wren
    Prodigy 10 points

    JC,

    did you use the U-Boot and the UBL that comes with the DVSDK 2.0 for accessing the NAND? We are currently using this version of the DVSDK for out board with a DM6443. We would like to switch to a BBN (Samsung K9F4G08U0A, 4GB, x8, 3.3V, 0xDC Device Code) and try to estimate the software effort involved.

    Thanks,
    Patrick