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.

OMAP-L137 Nand Flash support.

Other Parts Discussed in Thread: OMAP-L137, OMAP3525

1) SPRUFL6C - External Memory Interface A, 2.5.6.4, specifies that as CE_ will not be asserted during the tr time of a page read, so that only

CE don't care Nand Flash are natively supported.

Is this true even for ROM bootloader ?

SPRAB04B - Using the D800K001 Bootloader does not mention this constraint in accessing Nand devices.

2) Any news about recent "true" CE don't care Nand devices supported by OMAP-L137 ?

It is common that devices claiming to be CE don't care, actually do require CE low during the tr time when carefully inspecting the datasheet.

Thank you for your attention.

 

  • Hi Misha,

    Misha said:

    1) SPRUFL6C - External Memory Interface A, 2.5.6.4, specifies that as CE_ will not be asserted during the tr time of a page read, so that only

    CE don't care Nand Flash are natively supported.

    Is this true even for ROM bootloader ?

    SPRAB04B - Using the D800K001 Bootloader does not mention this constraint in accessing Nand devices.

    The document includes a workaround for that at section 2.5.6.8. I will have to search a little more to confirm if the bootloader supports it or not.

    Misha said:

    2) Any news about recent "true" CE don't care Nand devices supported by OMAP-L137 ?

    It is common that devices claiming to be CE don't care, actually do require CE low during the tr time when carefully inspecting the datasheet.

    Even though the LCD daughter card is not available for OMAP-L137, it contains a NAND flash that works with the boot loader.  You can find the schematics at:

      http://support.spectrumdigital.com/boards/dskda830 under DSKDA830 User Interface Board

     

     

  • Misha, Mariana,

    The boot loader does not implement using a GPIO as the CE for the NAND, and therefore booting from NAND devices that require the CE to be low during the entire tR time is not supported.

    Regards,

    Daniel

  • I could test the OMAP-L137 EVM interfacing to Nand Flash Micron MT29F4G08AAC: this chip was suggested as it is "CE don't care" ,and is part of DSK DA830 BOM.

    I installed Linux PSP 02_020_00_07, upgraded xdais,armubl,u.boot in the EVM spi Flash used for target boot, then configured Linux kernel for Nand Flash support as described in PsP User's guide.

    1)The Nand chip is not properly identified by MTD driver.

    I noted that the hw inteface timing is not complaint with Nand device Read Id command(see inserted picture): infact CE_ should be kept permanenltly active during all the the write and read bus cycles. Instead, CS_ is simply pulsed in occurrence with WE_ or CE_ pulses...

    I wonder how this can be granted as spufl6c EMIF A  User's guide states (2.5.6.4):

     

    Since NAND operations are divided into single asynchronous access cycles, the chip select signal will not remain activated for the duration of the NAND operation. Instead, the chip select signal will deactivate between each asynchronous access cycle.

    I grounded permanently CS3_ on the chip side, and the chip was regularly identified.

     

     

    QUESTION: how the proper CS_ management can be supplied for Nand devices ?
    Apart Linux MTD, how Boot Loader handles the CS_ line ?

    2)Even if the chip is permanently selected (no conflict arise on the EMIFA with other devices)

    the YAFFS file system is not functional: booting EVM...

    ..nand_davinci nand_davinci.0: Using 4-bit hardware ECC
    NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)
    Bad block table not found for chip 0
    Bad block table not found for chip 0
    Scanning device for bad blocks
    Creating 4 MTD partitions on "nand_davinci.0":
    0x00000000-0x00020000 : "bootloader"
    mtd: Giving out device 0 to bootloader
    0x00020000-0x00040000 : "params"
    mtd: Giving out device 1 to params
    0x00040000-0x00240000 : "kernel"
    mtd: Giving out device 2 to kernel
    0x00240000-0x20000000 : "filesystem"
    mtd: Giving out device 3 to filesystem
    nand_davinci nand_davinci.0: hardware revision: 2.5
    Creating 3 MTD partitions on "Windbond spi nand flash":
    0x00000000-0x00040000 : "U-Boot"
    mtd: Giving out device 4 to U-Boot
    0x00040000-0x00044000 : "U-Boot Environment"
    mtd: Giving out device 5 to U-Boot Environment
    0x00044000-0x00400000 : "Linux"
    mtd: Giving out device 6 to Linux

    # cat /proc/mtd
    dev:    size   erasesize  name
    mtd0: 00020000 00020000 "bootloader"
    mtd1: 00020000 00020000 "params"
    mtd2: 00200000 00020000 "kernel"
    mtd3: 1fdc0000 00020000 "filesystem"
    mtd4: 00040000 00001000 "U-Boot"
    mtd5: 00004000 00001000 "U-Boot Environment"
    mtd6: 003bc000 00001000 "Linux"

    #flash_eraseall /dev/mtd3:

    Erasing 128 Kibyte @ 1fd20000 -- 99 % complete.
    Skipping bad block at 0x1fd40000
    Skipping bad block at 0x1fd60000
    Skipping bad block at 0x1fd80000
    Skipping bad block at 0x1fda0000

    # flash_info /dev/mtd3
    MTD_open
    MTD_ioctl
    MTD_close
    Device /dev/mtd3 has 0 erase regions

    # mount -t yaffs2 /dev/mtdblock3 /mnt/nand
    yaffs: dev is 32505859 name is "mtdblock3"
    yaffs: Attempting MTD mount on 31.3, "mtdblock3"
    block 4075 is bad
    block 4076 is bad
    block 4077 is bad
    block 4078 is bad

    # cd /mnt/nand
    # ls
    lost+found

    However when adding a directory :
    # mkdir testdir

    the opertaion fails....reporting many warnings

    **>> yaffs chunk nnnnn was not erased
    nand_davinci_4bit_compare_ecc Too many errors to be corrected!
    nand_davinci_4bit_compare_ecc Too many errors to be corrected!

    QUESTION: any suggestions ? Where can I found additional information for Linux Nand Flash support ?

    Thank you for your attention.

  • Here I attach the oscilloscope printout.
    The RED rectangle shows the NOT complaint Read ID operation performed by OMAP-L137.
    CS3_ should be kept low during the whole operation.

     

  • For the sake of clarity here I attach the required standard timings for Read ID command for Nand Flash.

     

     Later investigations showed that the CE3_ bad management I found with Linux MTD drivers is the same when trying to program the device through JTAG by means of nand_writer_ccsv3.out according to :
    3.4 Flashing Boot Images to NAND Flash di OMAP-L137 EVM PSP User's Guide (SPRUGi8).

    Is it possible that some glue logic is always required for OMAP-L137 ? in other words, that the
    direct hardware interface to Nand devices (albeit CE don't care) is not supported ?

    According to OMAP-L137 External memory interface A(sprufl6c).pdf:

    2.5.6.4 NAND Read and Program Operations

    A NAND Flash access cycle is composed of a command, address, and data phase. The EMIFA will not
    automatically generate these three phases to complete a NAND access with one transfer request. To
    complete a NAND access cycle, multiple single asynchronous access cycles must be completed by the
    EMIFA. Software must be used to request the appropriate asynchronous accesses to complete a NAND
    Flash access cycle. This software must be developed to the specification of the chosen NAND Flash
    device.
    Since NAND operations are divided into single asynchronous access cycles, the chip select signal will not
    remain activated for the duration of the NAND operation. Instead, the chip select signal will deactivate
    between each asynchronous access cycle.
    For this reason, the EMIFA does not support NAND Flash
    devices that require the chip select signal to remain low during the tR time for a read. See Section 2.5.6.8
    for workaround.

    In other words, the tR time issue is only one of the constraints involved.

    Is it possible that the suggested interfacing is not functional ?

     

    Please help me to solve this doubts.

    Thank you for your attention.

  • Hi folks,

    is there any progress in using NAND flash with the L137?

    I'm about to start a new project with the L137 and after reading this thread I know why they use SPI flash on the Eval Board to boot from [:O]. Unfortunately SPI-flash is usually small and expensive so I'd prefer NAND flash.

    As I understand Misha's findings it would be possible to boot from NAND flash by grounding its CS, but is it possible to write a new firmware too? Is there already a version of UBoot that supports booting from NAND?

    I would have to reuse some of the NAND flash pins after booting to connect to a SD/MMC card. Disabling the NAND's CS should be sufficient to stop it from interfering with the card, but vice versa it seems I'll need a driver to isolate the card (which doesn't have a CS) from the flash? Anybody who has experience with this?

    Greets from Berlin, Germany,
    Stefan

  • Hi Stefan,

    wsw said:
    As I understand Misha's findings it would be possible to boot from NAND flash by grounding its CS, but is it possible to write a new firmware too? Is there already a version of UBoot that supports booting from NAND?

    The UBL supports NAND flash. (See restrictions described by Daniel). I was able to boot from NAND flash using the memory in the daughter card from spectrum. The daughter card is not for sale, but you can find the it's schematic at:

    http://support.spectrumdigital.com/boards/dskda830/revc/

    under DSKDA830 User Interface Board. It contains a NAND flash.

    wsw said:
    I would have to reuse some of the NAND flash pins after booting to connect to a SD/MMC card. Disabling the NAND's CS should be sufficient to stop it from interfering with the card, but vice versa it seems I'll need a driver to isolate the card (which doesn't have a CS) from the flash? Anybody who has experience with this?

    I have not done that. But, if you are not interfacing with the NAND flash after the boot, you can reuse the pins for other purposes, just change the pinmux registers if needed.

  • Mariana said:

    The UBL supports NAND flash. (See restrictions described by Daniel). I was able to boot from NAND flash using the memory in the daughter card from spectrum. The daughter card is not for sale, but you can find the it's schematic at:

    http://support.spectrumdigital.com/boards/dskda830/revc/

    under DSKDA830 User Interface Board. It contains a NAND flash.


    Yes, I've seen this. If you switch NAND flash boot on (SW1-2), all they do is setting CE of the Flash to low (ANDing it with EMIFA_CS3 in order to have access to the flash for programming or other reads when NANDboot is set to high as I think).

    BTW: Their different boot options (NAND/NOR) can be activated simultaneously - I don't think that would be a good idea!

    Maybe I don't even need to set CE low permanently because the NAND flash I plan to use (we already have it in stock for our OMAP3525 project) seems to support "CE don't-care" for both read and program:

     

    Mariana said:
    I would have to reuse some of the NAND flash pins after booting to connect to a SD/MMC card. Disabling the NAND's CS should be sufficient to stop it from interfering with the card, but vice versa it seems I'll need a driver to isolate the card (which doesn't have a CS) from the flash? Anybody who has experience with this?

    I have not done that. But, if you are not interfacing with the NAND flash after the boot, you can reuse the pins for other purposes, just change the pinmux registers if needed.[/quote]
    That's how I read the datasheet too.
    I hope the LINUX driver for the SD/MMC  (which is part of the kernel IIRC) has no problem when  - in case of a firmware update - it gets its pins temporarily 'stolen' while writing to the NAND flash. At least we'll have to synchronize the update daemon (-> NAND flash) and the application (-> SD/MMC) accordingly.

  • the gate is a single 2-input positive-OR gate.so that it is low when a and b is low.

    i can't boot form nand8 too.how it's gone?anyone can help me?