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.

66AK2H12 NAND boot (RBL)

Other Parts Discussed in Thread: 66AK2H12

We have a custom board design that has a 66AK2H12 with the EMIF connected to a Micron MT29F8G16ADBDAH4 NAND flash.  This is a 16-bit wide, ONFI-compliant flash with all 16 bits connected to the EMIF.  If I boot the Keystone 2 from the UART, U-Boot sees the NAND, reads it, writes it, loves it, wants to get married to it, everything is groovy.  But if I put the U-Boot image itself in the NAND flash and configure the BOOTMODE pins so that the RBL will try to boot from flash, nothing works.

The ARM Bootloader documentation (spruhj3, p. 3-7) says

The RBL uses has several methods of determining the NAND device geometry. The
first method is to ask the device if it is ONFI-compliant. To determine if the device is
ONFI compliant, a standard read ID command is issued to device address 0x20 and
four bytes read. If the four bytes contain 0x49464E4F (ASCII for ONFI), the RBL knows
the device is ONFI-compliant. It will then read the ONFI parameter table from the
device that contains the geometry information.


The manufacturer and device ID will always be read from the device by issuing a read
ID command to device address 0x00 and four bytes read. The first byte is the
manufacturer ID. The second byte is the device ID. The third and fourth bytes imply
information about the device geometry.


If the device was found to not be ONFI-compliant, the RBL will compare the
manufacturer and device ID to a table of known devices stored in the RBL. This table
includes geometry information for each device listed in the table.


So, in desperation I probed the EMFI and saw the following transactions on my oscilloscope:

1. RBL resets NAND

Next, RBL issues a READID command (0x90) to address 0x20:

NAND replies with the four-byte magic number 0x49464E4F (ASCII for ONFI):

RBL issues another reset, then a READID (0x90) to address 0x00:

The NAND replies with its device ID

And, after that, as far as I can tell, there are no more transactions on the EMIF.

So what's going on?  Is there an erratum in the RBL?  Is there a problem booting from a 16-bit NAND?

HELP!

  • Hi Charles,

    I've forwarded this to the support team. Their feedback will be posted directly here.

    Best Regards,
    Yordan
  • Charles,

    Can you please confirm that when you flashed the NAND, you are setting ECC layout as recommended here:

    The reason you need to do it is the the RBL expects the ECC data in the NAND spare are to be in a different format as compared to u-boot and Linux. Hence the initial image needs to be written to NAND page using ECClayout 1 which is as shown below:

    Hope this helps. Let us know if the issue is not resolved even with this chnage.

    Regards,

    Rahul

  • The wiki page you referred to has this:

    • under u-boot prompt, do
    > setenv serverip <tftp-server-ip-address>
    > setenv bootfile '/tftp/server/path/to/u-boot-nand.gph'
    > dhcp ${fileaddr}
    > nand ecclayout set 1
    > nand erase.part bootloader
    > # For K2HK EVM
    > nand write ${fileaddr} bootloader ${filesize}
    > # For K2E or K2L EVM
    > nand write ${fileaddr} <offset> ${filesize}
    > nand ecclayout set 0

    but when I try it on my U-Boot (checked out from the TI git repository), this command is not supported:


    U-Boot# nand ecclayout set 1
    nand - NAND sub-system

    Usage:
    nand info - show available NAND devices
    nand device [dev] - show or set current device
    nand read - addr off|partition size
    nand write - addr off|partition size
    read/write 'size' bytes starting at offset 'off'
    to/from memory address 'addr', skipping bad blocks.
    nand read.raw - addr off|partition [count]
    nand write.raw - addr off|partition [count]
    Use read.raw/write.raw to avoid ECC and access the flash as-is.
    nand erase[.spread] [clean] off size - erase 'size' bytes from offset 'off'
    With '.spread', erase enough for given file size, otherwise,
    'size' includes skipped bad blocks.
    nand erase.part [clean] partition - erase entire mtd partition'
    nand erase.chip [clean] - erase entire chip'
    nand bad - show bad blocks
    nand dump[.oob] off - dump page
    nand scrub [-y] off size | scrub.part partition | scrub.chip
    really clean NAND erasing bad blocks (UNSAFE)
    nand markbad off [...] - mark bad block(s) at offset (UNSAFE)
    nand biterr off - make a bit error at offset (UNSAFE)
    U-Boot#

  • I did notice that there is a CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC preprocessor symbol in the U-boot sources. I'll try setting that in my config and see what happens.
  • Yes, the way the ECC layout is handled seems to have changed in the u-boot code to handle the variation in ECC layout, the new code seems to require users to build the NAND uboot image in MLO format as described in u-boot/board/ti/ks2_evm/README.

    Can you also confirm which branch of uboot did you get from the TI GIT repo.

    Regards,
    Rahul
  • The code I'm working on is my own branch forked from the 'master' branch cloned from

    git://git.ti.com/ti-u-boot/ti-u-boot.git

    I've had to make some changes due to hardware differences between my board and the EVM.

    I tried compiling u-boot with CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC.  The OOB bytes now appear to have the pattern shown upthread.  After erasing the NAND:

    U-Boot# nand dump 0
    Page 00000000 dump:
    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    [... etc ... ]
    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    OOB:
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff
    ff ff ff ff ff ff ff ff

    and then

    U-Boot# nand write ${fileaddr} bootloader ${filesize}

    NAND write: device 0 offset 0x0, size 0x5cad4
    379604 bytes written: OK
    U-Boot# nand dump 0
    Page 00000000 dump:
    00 05 ca c4 0c 00 00 00 be 00 00 ea 14 f0 9f e5
    14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5
    14 f0 9f e5 14 f0 9f e5 60 00 00 0c c0 00 00 0c
    20 01 00 0c 80 01 00 0c e0 01 00 0c 40 02 00 0c
    [ ... etc ... ]
    10 f4 80 77 03 d0 18 46 ff f7 7a ff 12 e0 10 f4
    c0 65 05 d0 01 46 18 46 ff f7 26 ff 3d 46 09 e0
    18 46 ff f7 6d ff 21 46 30 46 ff f7 1d ff 01 e0
    4f f0 ff 35 28 46 f8 bd 10 b5 0a 4b 44 6a 9c 42
    OOB:
    ff ff ff ff ff ff 5d 9f
    51 01 75 70 97 da 19 02
    ff ff ff ff ff ff f2 94
    99 d6 15 cb 3b 05 96 dc
    ff ff ff ff ff ff 9e 2e
    5b 02 25 ec b6 27 30 fa
    ff ff ff ff ff ff 30 0b
    51 e1 85 f4 c2 17 9a 49
    U-Boot#

    So you can see the first six of every sixteen OOB bytes remain in their reset (all 1s) state after the write.

    This did not seem to solve the problem; the part still won't boot from NAND.

  • So the ECC layout may have been a problem (which now appears to be fixed), but I think a more fundamental problem exists. It really looks like the RBL isn't even reading out the OOB/ECC. When I probe the EMIF with my oscilloscope, there are no transactions after the RBL reads out the the ONFI code and the manufacturer and product IDs. So, in effect, fixing the ECC layout was fixing a problem I hadn't encountered yet, because I haven't been able to get the RBL to transfer any data from the NAND, much less to verify the ECC.
  • Charles,

    We have added some additional instructions to address flashing of the NAND using uboot. It appears the newer releases require you to use the MLO file created in the u-boot build instead of the .gph image.
    processors.wiki.ti.com/.../Linux_Core_U-Boot_User's_Guide

    Can you try to see if these steps helps resolve your issues.

    Regards,
    Rahul
  • I have been using the MLO file created during the u-boot build.

  •  

    Part Number

    FBGA Code

    Original

    MT29F8G16ADBDAH4-IT:D

    NW238

    EVM, respin

    MT29F4G08ABBDAH4-IT:D

    NW190

    So, replacing the 16-bit NAND with a pin-compatible 8-bit NAND solved the problem.  The replacement is the same NAND part used by the TI EVM.

    I will say that nowhere in the supplied documentation could I find any mention that the RBL will not boot from a 16-bit part.  In particular, section 3.6 of spruhj3 "KeyStone II Architecture ARM Bootloader" on NAND boot seems to imply that an ONFI-compliant 16-bit NAND (such as the one we tried in the original version of our board) should work.  Experience showed otherwise.