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

DM8168 NAND Boot issues

James Long
Prodigy 150 points

Hi

We’re having trouble getting our DM8168s to boot from NAND flash. The hardware platform is of our own design and it uses a rev 2.0 silicon DM8168 (DM8168BCYG2) and connects to an 8-bit ONFI-compliant 2Gbit SLC NAND Flash (Micron MT29F2G08ABAEAH4:E). The connection is very similar to the one shown in the SPRUGX8 reference guide, page 858 (figure 9-4) and we are using nCS0 for our chip select.

If we boot the board from UART then we can talk to the NAND flash just fine from uboot, we can write to and read from the flash and the data persists over power cycles without issue.

However, when we set the board to boot from NAND flash first (BTMODE[4:0] = “10010”) then we can’t seem to pull any boot code from the NAND and keep cycling through the boot options. The date code of the chip is 21AH9NW and the ROM code version is 0x00002101 with ROM code CRC of 0xD4D669FB as per page 2340/section 25.3.1.2 of the SPRUGX8 guide.

On closer inspection of exactly what is happening with the NAND interface on boot, we should expect the memory controller to first send a ‘reset’ command and then wait for the NAND flash to release the Ready/Busy line, indicating that it is ready for more commands. The reset command consists of sending the following: CS low, CLE high, ALE low, RE high, WE low and data bus value of “FF”. Wait for the setup time of the flash and then drive WE high to load in the command followed by CS high to deselect the flash.

What we actually see is CS going low with RE and CLE going high then some 80ns later, WE goes low. 280ns after that, WE goes high, then RE goes high after another 30ns. Finally CS and CLE go high after another 100ns. All this time, ALE and WP and all data bits are low and Ready/Busy is high. This doesn’t correspond to any valid NAND flash command or address transaction and since it’s not a reset command, the NAND doesn’t reset and the ready/busy line doesn’t change. It looks like the DM8168 gives up and moves on to the next boot mode which is NAND again. We don’t have an I2C EEPROM containing NAND data, so it tries the same thing again then moves onto SPI (not fitted) and then UART which works if we send it data.

 

Could you please confirm if there are any known issues with NAND boot on DM8168 Rev 2.0 devices which might cause this behaviour?

Any ideas on what to try in order to make this work?

 

Thanks

James.

6607.NAND Timing.pdf

8168.DM8168_NAND.pdf

  • 0
    TI__Intellectual 1645 points

    James,

    Can you verify the value of CONTROL_STATUS (0x48140040) through CCS or u-boot and make sure the boot mode is what you expect?

    Also i assume that when flashing 'u-boot-min' at the beginning of flash you are following the U-boot user guide and setting the ECC scheme appropriately for it (i.e. HW 2/BCH8 for u-boot-min and HW 0/HammingCode for u-boot.

  • 0 in reply to Benoit Parrot
    Prodigy 150 points

    Hi Benoit

    We have verified the contents of that register and it looks like the processor has correctly sampled the boot mode pins and it is in the mode we expect, i.e. MBOOT="10010" - NAND, NANDI2C, SPI, UART.

    As for the contents of the NAND, at this stage there it doesn't really matter as the boot process hasn't even gotten far enough to read the NAND device parameters, let alone the contents of the bootloader.

    James.

  • 0 in reply to James Long
    TI__Intellectual 1645 points

    James,

    Can you give the value read from that register? I would like to check the bus width and mux bits.
    Also would it possible to try one of these NAND device on the EVM just to see if there is any difference in behavior?

  • 0 in reply to Benoit Parrot
    Prodigy 150 points

    We've fitted these boards with SPI flash parts in addition to the NAND flash and they are loaded with boot code. As such, once the board fails to boot from NAND, it boots from SPI and the control status register 0x48140040 reads as 0x00060312.

    It's tricky to fit the exact same flash part to the EVM as we're using a BGA package on our boards, whereas the EVM uses a TSSOP pagkage. However the part is very similar, the only differences should be the x8 vs x16 data bus width and the package type. I will try to get hold of some of the x8 part we use in the TSSOP package to we can try this, but I should mention that the EVM boards we have are fitted with Rev 1.1 DM8168 silicon and our boards have the rev 2.0 part instead.

    I've probed the signals on the EVM and the interface looks good. The timings are the same, but read enable (REn) is high throughout and the lower 8 data bits (D7:0) are all high. This corresponds to the command "Reset" and as expected, the ready/busy line transitions low shortly after the rising edge of write enable (WEn).

    Can you confirm if you have seen Rev 2.0 DM8168 parts booting from NAND flash on more recent EVMs?

    If so, what revision of ROM code do they have?

    James.

  • 0 in reply to James Long
    TI__Intellectual 1645 points

    Yes we are actually booting a Rev 2.0 DM8168 part from NAND flash (16bit).
    Just to be clear the ROM is part of the device itself and is not board dependent.
    So all Rev2.0 devices have the exact same ROM image.

    The CONTROL_STATUS register value you gave (0x00060312) does not exactly match what you are describing in the '8168.DM8168_NAND.pdf' file.
    For Device control the text says: Wait enabled, 8-bit data, A/A/D muxed.

    However the current value shows: Wait enabled, 8-bit data, A/D muxed.
    In other word the CS0MUX[1,0] is set to 01b you  might have intended 10b...

    I am not sure if that would a difference as far as the NAND reset sequence goes, but you might want to double check it anyway.

  • 0 in reply to Benoit Parrot
    Prodigy 150 points

    Hi.

    We have the CS0MUX[1:0] pins set to "01". Accordig to the datasheet page 57, that corresponds to A/A/D mode. The definition of the CONTROL_STATUS register in the reference guide page 305 and the value we have does, as you say suggest that we're reading this as A/D mode instead. It is interesting that the A/D and A/A/D entries in this table are switched compared to those in the table in the datasheet, could you confirm that these are correct?

    It is possible that our boards have an assembly error which means those nets have the wrong values. I will check them when I get chance and also check what happens on our EVM if they are set to the other setting.

    I'm glad to hear that there are other boards which boot fine from NAND, that's a relief!

    Do these boards still use the same NAND as the Rev 1.1 EVM from Spectrum digital?

    Regarding the ROM code, I was wondering if there might be different ROM programs for different variants of the chip or where extra features have been added. The fact that it has a version number would suggest that there might be more varieties of this than there are silicon revisions! 

    Are all such variations (e.g. special secure parts or whatever there might be) indicated in eFuse and read by the standard ROM code?

    James.

  • 0 in reply to James Long
    TI__Intellectual 1645 points

    James,

    I had not noticed the inconsistency between the data sheet and the TRM regarding the CS0MUX values, I will have to track this down and get back to you.

    Yes the Rev 2.0 evm are using the same NAND part as the Rev1.1 evm.

    The ROM code version does not vary with selected feature in eFUSE, it only varies with actual silicon revision.
    The ROM does look at a subset of the eFUSE feature for booting purpose, like General Purpose vs Secure Device, etc...

  • 0 in reply to Benoit Parrot
    Prodigy 150 points

    Hi

    We have managed to get NAND boot working on our boards. 

    The trick seemed to be setting the CS0MUX values to "00" - Non-multiplexed mode. We've confirmed this setting both a the pins and in the Control_Status register.

    When we set the part to A/D multiplexed we saw similar results to A/A/D, but the DM8168 drive the command "3F" instead of "00". This is a valid command for the NAND, but makes no sense at that time.

    Do you see any side effects of running our boards with the non-multiplexed setting from now on?

    Thanks

    James.

  • 0
    Prodigy 160 points

    Hi

    it may be an ECC issue.

    Correctable errors are counted, but are not corrected by the driver.

    I know that two years ago the TI driver for uboot was updated for this issue, but don't ask me about version numbers.

    good luck

    tsahi