On 07/09/2012 11:12, Stefano Babic wrote:
On 07/09/2012 01:19, Scott Wood wrote:
On 09/06/2012 03:04 AM, Stefano Babic wrote:
Signed-off-by: Stefano Babic sbabic@denx.de
Hi Scott,
drivers/mtd/nand/nand_ids.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c index 3953549..fe75686 100644 --- a/drivers/mtd/nand/nand_ids.c +++ b/drivers/mtd/nand/nand_ids.c @@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = { /* 128 Gigabit */ {"NAND 16GiB 1,8V 8-bit", 0x1A, 0, 16384, 0, LP_OPTIONS}, {"NAND 16GiB 3,3V 8-bit", 0x3A, 0, 16384, 0, LP_OPTIONS},
- {"NAND 16GiB 3,3V 8-bit", 0x48, 4096, 16384, 0x100000,
LP_OPTIONS},Why does this NAND chip need things specified that are zeroes for other chips?
At least on this board with MX35, the chip cannot be recognized. Manufacturer ID and device ID are read flawlessly, but then u-boot fails to get the correct geometry. Setting explicitely the values, I can then read / write into the NAND without any problem. It can be more a problem related to the specific MXC NAND driver (mxc_nand.c).
It seems to me that the values returned by this flash cannot be interpreted in nand_get_flash_type().
The values returned from a READ-ID command with address 0x00 are:
0x2C 0x48 0x04 0x4A 0xA5,
I can really get these values from the flash, so the MXC controller gets the correct data.
However, the code in nand_base.c (lines from 2718, so not-Samsung case) parses the answer setting the NAND as a 16-bit device, but this is really a 8bit device. I do not know the meaning of the answer, it is not described in the datasheet.
Cheers, Stefano