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 NAND Support

Hi all,

I am looking at replacing the DM365 DVEVM's obsolete Micron NAND MT29F16G08FAA with an 8Gbit 8 bit MT29F8G08ABABA . I have queried Sprufg5A Rev Aug 2009 Sect 11.2.1.2 which says the RBL supports the following (first column) of Device ID's:

Device ID block extra data) (For address) No. of address cycles
0x43 32 512+16 13 3
0x45 32 512+16 13 3
0x53 32 512+16 13 3
0x55 32 512+16 13 3
0x73 32 512+16 13 3
0x33 32 512+16 13 3
0x75 32 512+16 13 3
0x35 32 512+16 13 3
0x76 32 512+16 13 4
0x36 32 512+16 13 4
0x79 32 512+16 13 4
0x71 32 512+16 13 4
0x46 32 512+16 13 4
0x56 32 512+16 13 4
0x74 32 512+16 13 4
0xF1 64 2048+64 22 4
0xA1 64 2048+64 22 4
0x78 32 512+16 13 4
0x98DA 64 512+16 14 4
0x98DC 64 512+16 14 4

Looking next at the MT29F8G08ABABA's parameter tables, the JEDEC Manufacturer ID is 0x2C which is not listed in the above (Is this Jedec Manu ID the correct "ID" I should be referencing?). I have browsed a number of related NAND links on this forum but unfortunately none have been too helpful in telling either a definite yay or nay regarding support.

I do know that I have Rev 1.2 Silicon (Rev E DVEVM) and would ultimately like to know whether the RBL will be able to boot off a MT29F8G08ABABA NAND & then secondly (& secondary as it should theoretically be posted on the Linux forum), whether this NAND is supported by the Arago DVEVM v3.1 and its packaged kernel (or at least where I can look to see whether it is supported).

It was mentioned in a previouspost that the 4th ID byte information on the NAND might have some relevance? According to my NAND datasheet,the 90h "Read ID" command returns: 0x2C; 0x38; 0x00; 0x26; 0x85 @ address 20h. Further to this, the 90h "Read ID" command returns 0x4F;0x4E;0x46;0x49 @ address 20h. Am I able to use this data somehow to determine support?

I would appreciate any input on the above as to where to turn next.

Many thanks,
NicKA

  • NicKA,

     

    Some information is missing from Sprufg5A Section 11.2.1.1 (http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf). After the 4th bullet (Read the device Id of NAND and get the parameters for NAND from a table in ROM), the following information needs to be added.

     

    If the NAND device is not found in this table, then the RBL will read the fourth byte of the NAND ID (stored on the actual device) and attempt to decode this to obtain the necessary parameters.

    For the purpose of determining NAND block size and page size the information from the fourth byte is considered as follows:

    • Bits 5 and 4 determine the block size

    – Bits 5,4 = 00: 64KB

    – Bits 5,4 = 01: 128KB

    – Bits 5,4 = 10: 256KB

    – Bits 5,4 = 11: 512 KB

    • Bits 1 and 0 determine the page size

    – Bits 1,0 = 00: 1KB

    – Bits 1,0 = 01: 2KB

    – Bits 1,0 = 10: 4KB

    – Bits 1,0 = 11: 8KB

     

    We are in the process of updating the document.

     

    For any NAND device on DM365, the following steps are followed by RBL to determine the NAND geometry:

    1. Look up for device ID (and manufacturing ID) in the look up table. This information is read from the NAND device using 0x90 “Read ID” command at address 0x0. As per your post, for MT29F8G08ABABA is 0x2C (manufacture ID); 0x38 (Device ID); 0x00; 0x26 (4th byte ID, 1 based).

    As 0x38 (or 0x2C38) is not in the first column, the device is not supported by table look up.

    2. The next option is 4th byte ID. Based on the explanation above, the value of 0x26 represents the following:

    Block size:  128 KB

    Page size: 2KB

    If this matches with the actual NAND geometry, then the NAND is supported.

     

    If the actual page size is a multiple of the page size determined, there is a possibility that the NAND will be supported by RBL (it will read the UBL successfully). However the only way to check that is to try the NAND.

     

    Please post the question for Linux (Arago) support in the Linux forum. Hope this helps.

     

    Regards,

    Gaurav

  • As Gaurav pointed out, this NAND is likely supported. Just a couple of more points -

     

    a) DM365 EVM has NAND socket where you should be able to quickly try loading UBL, uboot and see if you can get to uboot prompt. Instructions to do this can be found at - 

    http://processors.wiki.ti.com/index.php/GSG:_DM365_DVEVM_Additional_Procedures#Restoring_the_NAND_Flash

     

    b) In addition, please look at the HW ECC requirements for NAND. DM365 EMIF HW can only support upto 4-bit HW ECC. If the NAND ECC requirement is more than 4-bit ECC, you would need to add support of ECC in software. 

     

    Regards,

    Prateek

     

     

  • Hi Gaurav,

    Thank you for the response! I unfortunately do not quite understand.

    First Query:

    According to your table:

    • Bits 5 and 4 determine the block size

    – Bits 5,4 = 00: 64KB

    – Bits 5,4 = 01: 128KB

    – Bits 5,4 = 10: 256KB

    – Bits 5,4 = 11: 512 KB

    • Bits 1 and 0 determine the page size

    – Bits 1,0 = 00: 1KB

    – Bits 1,0 = 01: 2KB

    – Bits 1,0 = 10: 4KB

    – Bits 1,0 = 11: 8KB

     

    the value 0x26 (or 0b0010 0110) should represent:

     

    – Bits 5,4 = xx10: 256KB

    – Bits 1,0 = xx10: 4KB          (I am truncating the upper half of the lower nibble?)

     

    My second attempt: You mentioned Base 1. If 26 is base 1 and converted into base 8 =>  0b00011010 then:

     

    – Bits 5,4 = xx01: 128KB

    – Bits 1,0 = xx10: 4KB          (I am truncating the upper half of the lower nibble?)

     

    Neither of these give me the outcomes you got (128Kb, 2Kb). What am I doing wrong?

    Second Query:

    "If this matches with the actual NAND geometry, then the NAND is supported. If the actual page size is a multiple of the page size determined, there is a possibility that the NAND will be supported by RBL (it will read the UBL successfully)." Do you mind elaborating? I am a lost here.Where can I find these 'actual' values (which I assume refer to what is DM365 supported) for NAND geometry & page size?

     

    Sincerely,

    NickA

  • Hi Prateek,

    Thanks for the response.

    a) Yes I have seen this socket thank you! I have actually gone ahead and ordered some samples of the MT29F8G08ABABA to give them a shot as suggested. I am not a fan of guesswork though (it tends to bite me in the ass) and would like to understand what is going on here.  Thanks for the link!

    b) This Micron part uses 4bit ECC so we should be good! Thanks again.

    Sincerely,
    NickA

  • NickA,

    You are right. The correct values are:

     "

    the value 0x26 (or 0b0010 0110, 0 based here) should represent:

     

    – Bits 5,4 = xx10: 256KB

    – Bits 1,0 = xx10: 4KB          (I am truncating the upper half of the lower nibble?)

    "

    The correct/actual value can be found in the NAND datasheet. If the datasheet says that the Block size is 256KB and Page size is 4KB then it matches what RBL interprets and the NAND is supported.
    Second Query: Suppose the NAND datasheet says that the Block size is 512KB. In this case the NAND might be supported (as the RBL reads multiple blocks). RBL will find UBL descriptor in the 2nd block as per RBL which is actually block 1 in NAND. The same applies for Page size also. In these cases, UBL might have to be modified to identify the correct NAND geometry.

    But to make sure that the NAND is indeed supported in these cases, please make sure that a complete boot (UBL, u-boot, Kernel) is successful. 

    Thanks,

    Gaurav

  • Hi Gaurav,

    Ok its making sense! So based on the 4th byte, the DM365 RBL will configure itself for 4K pages & 256K Blocks (ie 64 pages / block) but from the datasheet my actual NAND configuration is 4K pages & 512K blocks (ie 128pages / block which is exactly as per your subsequent example). Its not identical but it is a multiple so there is that possibility of the DM365 successuflly reading it. Awesome! I have one small concern  - this NAND datasheet stipulates page size of 4096 + 224bytes (4320bytes). Is this still in fact a 4K page size? Are the extra 224bytes allocated to highlghting bad cells?

    I am also not quite understanding  "RBL will find UBL descriptor in the 2nd block as per RBL which is actually block 1 in NAND"?

    Sincerely,
    NickA

  • NickA,

    224 bytes is for ECC. The data page size is 4096 bytes.

    Using 256 K block size, RBL will find UBL at location what it thinks is block 2 (after 512 K bytes, assuming block 0 is the first block). But this in NAND would be block 1.

    Hope this helps.

    Thanks,
    Gaurav

  • Hi Gaurav,

    Ok, those both make sense! Thanks a mill for your input. I have no doubt I will be harassing this forum again very soon. Apologies in advance :)

    Sincerely,
    NickA

  • NickA,

    I am glad we could help. Please feel free to contact us through forums if you have any questions.

    Thanks,
    Gaurav

  • Update: We have received today the NAND samples (MT29F8G08ABABA) which we have used to replace the existing NAND in the DM365 EVM. So far everything has gone ok in that we have been able to successfully erase and flash the NAND with UBL & uBoot using the UART bootmode ie for the benefit of people reading this in future:


    http://processors.wiki.ti.com/index.php/RBL_UBL_and_host_program

    http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility

    http://processors.wiki.ti.com/index.php/UG:_DaVinci_PSP_Installation_on_DM365_EVM#Flashing_DM365_EVM_.28PG_1.2_Silicon_or_newer.29_using_Serial_flash_utilities


    We were ecstatic to see the board come to life (once DIP switches were returned to NAND boot mode) and pass control from RBL to UBL to uBoot. We now however have have an issue in which uBoot seems to fail to identify the NAND device and returns "No NAND device found" with our MT29F8G08ABABA instead of the previous "Manufacturer ID: 0x2c Chip ID: 0xd3 (Micron NAND 1GiB 3.3V 8-bit)" which was output when using the the original DVEVM packaged (but obsolete) MT29F16G08FAA.

    We are using uBoot 2009.03 as available from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_3_10/latest/index_FDS.html . Any ideas? There is a newer 2009.08 uBoot available from the u-boot-ti GIT. Is this our best bet? Is it just that this NAND is not supported yet in this uBoot release?


    I also received some advice re editting a " nand_ids.c" which I am rather vague about & will look into but I wanted to put my feelers out in the meantime regardless.


    Many thanks!

    NickA

  • NickA,

    Glad to know that your NAND worled with RBL and UBL. For uboot related issues, please post your queries in the related forum.

    Thanks,
    Gaurav

  • NickAllen said:
    Update: We have received today the NAND samples (MT29F8G08ABABA) which we have used to replace the existing NAND in the DM365 EVM. So far everything has gone ok in that we have been able to successfully erase and flash the NAND with UBL & uBoot using the UART bootmode ie for the benefit of people reading this in future:

    Nick, How did you erase and flash the NAND?  Are you using the stock utilities?

    I'm trying to use the SD utilites because our revision 1.1 chip has a boot in the UART boot.  The SD utilities fail to talk to the NAND.  I'm working on modifying the NAND code, but if someone is doing this without modifying code I'm afraid I may be on the wrong track.

    Thanks John

  • Hi John or Nick,

    I am looking for some help to replace my NAND chip on my evmdm365 board.  I has been problematic and after the forst time came right again but now the second time I have decided to go through the exercise to replace it.  Could you help with a couple of high level points what I need to do to get the board going again with the virgin chip in.  All the different TI documentation and guides is just confusing me where the thing really boots from and what I need to get to the point that I sit in the u-boot envrionment again and can write my kernel image and filesystem to NAND and be going again.

    Thanks, Hijn.

  • Jihn,

    Then first thing you should do is determine if your board can be updated through the serial port.  If you set the configuration switches to UART boot, you should see the message BOOTME over and over.  If you see this then you can is the serial flash utilities to write UBL and u-boot to the flash.  If you don;t see it check the version of your chip and compare against the errata to see if you chip has the serial bug.  If it does then you are in for some work.

    JohnA

  • Thanks John,

    I get the BOOTME's by the dozen when switching to UART boot mode - after fisrt having to figure out that TI documentation logic is reversed for SW4 in the Tech Manual for Spectrum Digital board evmdm365.  I have in the mean time tackled the SD-card boot guide and am figuring out what exactly is going on there after I only got the first part going on my previous endevour.  All my functionality issues are sorted out and I need to make my application usable now so all those things I skipped over when the going got tough are being sorted out now.  My linux skill has also improved a bit so I am much more comfortable doing stuff.  Thanks for your pointer, I feel there's hope again and will post again if I get stuck. Jinh T.

  • Hi John, I got the SD card boot flash going and could put  ubl on the NAND and was able to boot up this way and put my kernel uImage and ramdisk.gz on the flashand it would run again as normal from the newHynix NAND.  Problem occurred then again that actualy got me down this path and it is the following:  when the board is running in this auto boot mode - done guided by the wiki on how to create a ramdisk with auto-run demo - it can boot up again from flash every time I press the reset button on the evmdm365 but when I cycle power I have to every time write ramdisk onto NAND for it to work, else it ends up with a kernel panic.  this was what I was seeing beginning of the week on the board with the suspect flash which does not want to be r-flashed even now so it's running on the replacement flash.  Any idea what could cause the corruption of my zipped ramdisk on flash as I assumed the bootloader would just load it up into RAM and work from there but it seems like powering down goes screws it up.

    Thanks, Jinh T.

  • Jinh,

    - Is it possible for you to compare the Flash content before power up (ie after you burned the flash with uImage and file system) and after a new power up?
    This way you would see if the NAND content is kept.

    - Also usually the UBL, U-boot and uImage should come from the same DVSDK package. Have you updated UBL and U-boot with the one coming from the DVSDK package you got Linux and FS from?
    Only the UBL, U-boot and uImage/FS coming from the same DVSDK are being tested/validated on the DM365 EVM.

    Best regards,

    Anthony

  • I don't have any easy way to compare the nand contents.

    I am using the kernel from 4.0.0.22 and the ubl and u-boot from the latest.  I had to make a lot of changes to the kernel and some drivers, so I didn't want to change to the latest kernel.

    JohnA

  • I have resolved the problem of not being able to power up from NAND where something wrote an extra directory into my filesystem going into ramdisk and it pushed it just over the range that is programmed into NAND.  I compared the filesystem I had with a backup of the one from my ubuntu 9.04 server and first though it was file permissions until I saw it was a bit bigger and discovered the stray modules/ directory wriiten into my /lib directory.  It is working again and now I am still eager to get my board booting from SD completely as well.  If I stumble on issues there I will ask for some help again.

    Thanks, Jinh T.

  • Hi, NickA,

     

    Would please tell me where can download the original DVEVM packaged (but obsolete) MT29F16G08FAA?

    Many thanks,

     

    David D.

    e-mail: ddiao@cantronics.com