• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 101 subscribers
  • Views 1679 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.

DM365 EVM nand flash memory map: overlapping spaces?

Marco Braga
Expert 1780 points

Hello,

while writing a memory map of the default NAND flash on DM365 EVM, I've noticed a potential problem and I'd like to have confirm of it. My EVM uses a Micron MT29F16G08FAA flash chip, with this configuration:

Page size: 2048 + 64 bytes

Block size: 64 pages, 128KB (0x20000) bytes of data

Device size: 16Gbit, 16384 blocks

The default system configuration is this:

RBL searches for UBL in blocks 1-24, skipping bad blocks. UBL fits into 1 block, so addresses from 0x20000 to 0x31FFFF are reserved for UBL.

UBL searches for the main bootloader (U-Boot) in blocks 25-50. This means that addresses from 0x320000 to 0x65FFFF are reserved for U-Boot.

Checking the U-Boot source code, it seems to me that on DM365 its configuration is stored at fixed address 0x3C0000 up to 0x3FFFFF. This is defined in U-Boot source code's DM365 config and in the Linux kernel itself (partition sizes are hard coded). Notice that with 128KB blocks, address 0x3C0000 is block 30, well within the range 25-50.

Then the Linux kernel is commonly stored at address 0x400000, that is block 32, again in the range 25-50. Notice that this is defined in the linux Kernel (again hard coded) and also documented in a lot of readme and wiki pages for DM365.

Also NANDWriter addresses the flash using block numbers (i.e. 1-24, 25-50) while U-Boot and the linux Kernel use hard addresses. This means that the addresses can easily get wrong if the actual block size of the flash is not correcly accounted for. Perhaps this already happened.

One last point I still have to check is what happens if all blocks in the range 25-49 are bad. My U-Boot binary is over 128KB, so it uses at least 2 blocks and another block is required for the header (what a waste!). Probably it is better not to write the config before block 54 and the kernel starting from block 56 (just to be safe).

What happens when using NAND with block size of 4K or 8K? If I am correct the problem can even get worse.

Please tell me I am wrong...

 

  • 0
    TI__Mastermind 37340 points

    you are correct on your analysis.  It is unfeasible for us to support all NAND devices available and to come; therefore much of our software (flash writter tools, u-boot, linux kernel) are developed for our hardware EVM; these software components do support other NAND parts as well, but are not guarantted to support all NAND devices.  Therefore, when developing your own board with a different NAND device than what is on our EVM, some adjustments to all three of the software components mentioned above may be necessary; this is partly why we provide the source code for all three of these.

  • 0 in reply to Juan Gonzales
    Expert 1780 points

    Hi Juan,

    I see you point and agree with you. Still, I've found the problem in the actual Spectrum Digital DM36X EVM rev. D, with its supplied NAND flash. I worte my observations to point out to other users that simple "cut and paste" of what's provided by TI can sometimes cause problems in actual projects (even if a remote event, like in this case). Perhaps a "readme" from TI on this point could be useful.

    Regards,

    Marco

  • 0 in reply to Marco Braga
    TI__Mastermind 37340 points

    Marco,

    Thank you for your feedback.  For the benefit of others, I want to mention that RBL block search (or UBL) is the only hardware dependant block access and is normally defined in our data-sheets.  Everything else, such as where UBL looks for u-boot, or u-boot and kernel offsets re software controlled block or address offsets.  As you probrably know, we try to document some of these in our wiki articles (http://wiki.davincidsp.com/index.php?title=Main_Page) but certainly appreciate the consturctive feedback here in ways we can improve some of these articles or perhaps create new ones that help address customer needs. 

  • 0 in reply to Juan Gonzales
    Prodigy 40 points

    Hello,

    I have a question about RBL loads UBL on DM365. As i understand, the RBL searchs UBL descriptor(margic), then loads UBL to IRAM according UBL descriptor(margic), but if the starting block position of UBL in nand flash is bad block, and the valid UBL is stored at the next block, in this case, it seems RBL can't skip the bad block and loads the next valid block, just skip the current block of UBL description and re-search UBL descriptor again up to 24 blocks.  Right?

    So when building total firmeware (including UBL descriptor, UBL, u-boot, kernel, filesystem) for flash programming in mass production, we will define the start block of UBL for UBL description, but after flash programming, the start block position of UBL  in flash may be bad block, and the valid UBL is stored at the next block, in this case, it seems RBL can't loads UBL. How to deal this issue for mass production? Thanks for any advice.

    The Nand Boot Mode Flow Chart got from TI is attached for your information.

    Best Regard

  • 0 in reply to feng xiao47153
    TI__Expert 5955 points

    My recommendation is to place multiple copies of the descriptor and UBL in various blocks of the NAND (the descriptor goes in page 0 of a block and the actual UBL data would go into the remaining pages of a block).  Each descriptor must be different to correspond to its copy of the UBL.  If during programming a block is found to be bad, you should not try to move the content you were going to write to the next available block, rather you should just skip writing that copy of the UBL.  Otherwise, the descriptor will be wrong and will be pointing back to a bad block.

    Best Regards.

  • 0 in reply to Tai Nguyen
    Prodigy 40 points

    Thanks, Tai.

    But in this way, it seems hard to program NAND flash with the whole FW(including UBL,u-boot,kernel,filesystem,...) for mass production.  Any other way?

  • 0 in reply to feng xiao47153
    TI__Expert 5955 points

    Sorry Feng. I don't see any other way to get around the problem.

  • 0
    Expert 2150 points

    so addresses from 0x20000 to 0x31FFFF are reserved for UBL.

     

     

    i doubt that the end address must be 0x3FFFF  ??right ???

  • 0
    Expert 2150 points

    what's the best  suggestions for this situation,say use one nand flash to stored all stuff(ubl uboot.kernel , rootfs) ??

     

    should us just make back blocks for the ubl/uboot at the same time ?if so, how about this:

    block 0:  nothing

    block 1:

    page 0 : ubl discription for block 1

    page 1 : data of ubl

     

    block 2:

    page 0 : ubl discription for block 2

    page 1 : data of ubl

    etc...