WEC7: Mounting TFAT partition on NAND takes a long time RRS feed

  • Question

  • Hello All,

    We are having some issues mounting a TFAT partition on our NAND flash. After each reboot it takes about 4 to 5 minutes before it is mounted succesfully. It seems the OS is scanning all blocks of the NAND Flash which takes a long time.

    We are using the MDD/PDD driver structure together with the flashpart.dll partition driver.

    The hardware we are using:
    - Freescale iMX535 CPU
    - Micron MT29F08G08 Nand (1GB)

    We used the BSP from Adeneo for the iMX535 QSB. (BSP version 1.3.1)

    Our flash layout is as follows:
    - EBOOT       (blocks: 0 - 103)
    - NK          (blocks: 104 - 1006)
    - Free space  (blocks: 1007 - 8192)

    We want to mount a TFAT partition in the remaining free space. EBOOT marks the EBOOT and NK regions as reserved (BLOCK_STATUS_RESERVED) when it writes the NK.bin image.
    Our goal is to have the OS automatically create a single TFAT partition in the free space area. 

    Our register settings are:

        "FriendlyName"="NAND Flash Driver" 

        "Name"="NAND FLASH Storage"


    Our registry is RAM-based, but we want to be able to store registry changes on the NAND eventually.

    I added a output trace of our boot process on pastebin:

    From this trace it appears that after the partition driver is loaded, several things happen which together take quite a long time:
    - looking for transaction log (line 391) ("TransactionLog::RecoverTransactionLog() - looking for the xaction log...")
    - Create MappingTable (line 445) ("MappingTable::MapLogicalSector() - Mapping logical sector .....")
    - Getting blockstatus of remaining blocks.  (line 492) ("FlashPdd::GetBlockStatus - Physical block ...")

    We would think that only the first time the partition is created it would take a long time. 
    Afterwards we would expect that a partition table is stored somewhere in the flash so that the mounting would be a lot quicker on subsequent boots. Unfortunately we are not able to find much information about how the FLASHPART partition driver works and how it stores its partition information.
    Could anyone provide us with further insights about what exactly is happening in the flash partitioning/mounting phase? 

    Thanks in advance for your help,

    Kind regards,

    Tuesday, February 5, 2013 6:38 PM


  • The problem was caused by an incorrect pin setting in BSPNAND_ConfigIOMUX() function in 'nfc_sys.cpp'. The read/busy pin did not have a pull-up specified. The Datasheet of the NAND mentions that a pull-up resistor is required on this signal.
    Without pull-up, the NFC has to wait a long time for the busy signal to become high. This results in much longer access times. By setting a pull-up resistor on the pin, access times are reduced significantly and the partition is mounted much faster.
    • Marked as answer by mfiers Monday, February 18, 2013 8:55 AM
    Monday, February 18, 2013 8:55 AM