can't boot from nand flash

Hello Kevin,

what is the Samsung part number? 

You need to make sure you change both the manufacturer ID and the device ID in x-loader.

I am sorry for typing partnumber by mistake, the Samsung nand partnumber is K9F4G08U0A, I remember it is like this. and  it's Samsung NAND 512MiB 3,3V 8-bit.

Yes, I have changed the manufacturer ID to 0xec, and device id to 0xdc.

flash tools works fine, But if I want to use u-boot command instead of flash-tools, what should I do?

simply typing 

mw.b 0x81600000 0xff 0x20000;nand erase 0 20000;mmc init;fatload mmc 0 0x81600000 MLO;nandecc hw; nand write.i 0x81600000 0 20000

doesn't work,

by checking nand page 0x000000 through "nand dump 0x00000000", I find the main areas are the same, spare areas are different,

nand oob of page 0x0 through flash-tools,

OOB:

        ff 83 7c d2 ec ec bb 1c

        1c cc 7e 7e ee 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

nand oob of page 0x0 through u-boot,

OOB:

        ff ff 83 7c d2 ec ec bb

        1c 1c cc 7e 7e ee 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

The first two bytes are different. what is the difference between flash tool and u-boot,

Flash tools seems better than u-boot, How to make u-boot flash x-loader well if I want to?

Kevin:

I found this code in u-boot at ./include/asm-arm/arch-omap3/Omap_gpmc.h :

/* Generic ECC Layouts */
/* Large Page x8 NAND device Layout */
#ifdef GPMC_NAND_ECC_LP_x8_LAYOUT
#define GPMC_NAND_HW_ECC_LAYOUT {\
 .eccbytes = 12,\
 .eccpos = {1, 2, 3, 4, 5, 6, 7, 8,\
  9, 10, 11, 12},\
 .oobfree = {\
  {.offset = 13,\
   .length = 51 } } \
}
#endif

/* Large Page x16 NAND device Layout */
#ifdef GPMC_NAND_ECC_LP_x16_LAYOUT
#define GPMC_NAND_HW_ECC_LAYOUT {\
 .eccbytes = 12,\
 .eccpos = {2, 3, 4, 5, 6, 7, 8, 9,\
  10, 11, 12, 13},\
 .oobfree = {\
  {.offset = 14,\
   .length = 50 } } \
}
#endif

Apparently, u-boot is unaware that you are programming a x8 flash device.

I need to dig more to understand how u-boot determines the NAND width.

Did you have to change u-boot code to support your Samsung NAND?

Regards,

Michael T

Michael T,

    It is not necessary for me to use u-boot to program x-loader to NAND, as the flash tool works fine.

    I am wondering why flash tools can program x-loader to flash, and x-loader works fine; while u-boot can't program x-loader to flash correctly?

    BTW, 

    in previous, you told me to change the parameter in memory specs at top of file from "f 0x0019" to "f 0x0018" for an 8-bit device, what is mean for the parameter 'f', how to know which value I should change to.

Regards,

Kevin Chow

Kevin:

In the Micron NAND spec there is a 2-byte Features Supported code that can be read. 

For these devices it reads 0x0018 for x8 NAND and 0x0019 for x16 NAND.

With Flash Tool we are instead passing this information via the board configuration file

C:\Program Files\Texas Instruments\Flash v1.5\Targets\Configurations\configuration_custom_am35xx.txt

For x8 NAND you need:

f 0x0018

f = Features Supported parameter

0x0018 = parameter value (Bit 0 = 0 for x8, 1 for x16)

Regards,

Michael T

Kevin,

You have to correct the GPMC configuration in u-boot for 8-bit NAND part as mentioned by Michael,the GPMC configuration is defined in "arch/arm/include/asm/arch-omap3/mem.h" and used in "arch/arm/cpu/arm_cortexa8/omap3/mem.c"

Thanks,

Vaibhav

Michael T,

I made some changes to my u-boot source, and it seems that it can program x-loader, and x-loader works well on my Samsung NAND.

What I have done is as follows,

1. 

@include/configs/am3517_evm.h 

@line 302

--------from----------

 #define GPMC_NAND_ECC_LP_x16_LAYOUT 1

---------to-----------

 #define GPMC_NAND_ECC_LP_x8_LAYOUT 1

2.  

@include/asm/arch-omap3/mem.h

@line 235

--------from---------

#define M_NAND_GPMC_CONFIG1 0x00001800

---------to----------

#ifdef NAND_16BIT

# define M_NAND_GPMC_CONFIG1 0x00001800

#else

# define M_NAND_GPMC_CONFIG1 0x00000800

#endif

3. 

@arch/arm/cpu/arm_cortexa8/omap3/sys_info.c

@line 252

--------from---------

u32 get_gpmc0_width(void)

{

return WIDTH_16BIT;

}

---------to----------

u32 get_gpmc0_width(void)

{

return WIDTH_8BIT;

}

Kevin,

I just ran across this almost-year-old thread.  Thank you for posting your final result.  I had spent the better part of a day searching for a working configuration for our 8-bit NAND on our AM3517EVM derivative board, when I ran across your posting.  I'm sure it saved me a good chunk of time.

If anyone from TI is watching, I hope you'll feed a variation of Kevin's changes into the upstream u-boot sources.  It's almost a year later, but the mainline u-boot source (looking at release 2011.12) still could use improvement in the way one must configure 8-bit NAND.  To select 8-bit vs 16-bit NAND requires mods to files that are not board-specific.  I suggest a variation of Kevin's changes that would require the NAND width to be specified only in one place - namely the board config file.

As a side comment, if the NAND device supports ONFI, then specifying NAND width could potentially be avoided altogether, since the software could dig that out of the ONFI parameters.  I'm pretty sure that can be done even without apriori knowledge of the NAND width.  But, maybe that software work doesn't outweigh the benefit of slightly simplifying the u-boot configuration.

Ron

Hi all;

I have also done all the above changes in u-boot, but still i'm unable to get the nand flash information!

I'm using micron nand flash at gpmc chip select 7, so the manufacture and device id , i need to add in x-loader according to your's posts?

help me?

Regards,

santosh vastrad

This should really be acted on already, it is still broken in the SDK shipped U-Boot for AM3517EVM.

Ron Olson said:

Kevin,

I just ran across this almost-year-old thread.  Thank you for posting your final result.  I had spent the better part of a day searching for a working configuration for our 8-bit NAND on our AM3517EVM derivative board, when I ran across your posting.  I'm sure it saved me a good chunk of time.

If anyone from TI is watching, I hope you'll feed a variation of Kevin's changes into the upstream u-boot sources.  It's almost a year later, but the mainline u-boot source (looking at release 2011.12) still could use improvement in the way one must configure 8-bit NAND.  To select 8-bit vs 16-bit NAND requires mods to files that are not board-specific.  I suggest a variation of Kevin's changes that would require the NAND width to be specified only in one place - namely the board config file.

As a side comment, if the NAND device supports ONFI, then specifying NAND width could potentially be avoided altogether, since the software could dig that out of the ONFI parameters.  I'm pretty sure that can be done even without apriori knowledge of the NAND width.  But, maybe that software work doesn't outweigh the benefit of slightly simplifying the u-boot configuration.

Ron

Joonas:

Please post a link to the old post that you are referring to.

MichaelT

I'm referring to these changes:

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/p/107924/386993.aspx#386993

All in all, the U-Boot (and pretty much kernel too) that is shipped in the latest BSP is practically hardcoded to 16-bit device with 64-bit OOB size, having 8-bit interface and bigger OOB size breaks everything...

Doesn't seem to be working with 8-bit NAND. Didn't change the OOB scheme.

Have done all changes presented in this discussion but only get to this point:

===========

U-Boot SPL 2013.01.01-g8f268d6-dirty (May 10 2013 - 09:54:01)

U-Boot 2013.01.01-g8f268d6-dirty (May 10 2013 - 09:54:01)

AM35XX-GP ES2.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 Mhz
AM3517EVM Board + LPDDR/NAND
I2C: ready
DRAM: 2.7 GiB
NAND:

===========

Regards,

Yakir

NAND detection problem solved. Strange .... probably a build issue.