Re: [PATCH] AT91RM9200 NAND support

Savin Zlobec
2006-06-20T12:18:57Z

Thomas Gleixner wrote:

>On Tue, 2006-06-20 at 13:42 +0200, Savin Zlobec wrote:
>
>
>>>Well, we read the manufacturer ID. When we get 98H, how should we know
>>>that this is a Samsung part ? And I doubt that this is a quad bit flip.
>>>
>>>
>>>
>>What bothers me is that MTD from 2.6.17 reads manufacturer ID = 0xec, and
>>the latest git MTD reads 0x98. The chip on my board is Samsung.
>>
>>
>
>Thats indeed strange. Whats the exact part number ?
>
>
>
>>>Can you please remove the nand_wait_ready() call in nand_command() and
>>>test the following patch ? It disables the ready busy pin and uses the
>>>chip_delay. Please check, whether the 20us are correct. You can safely
>>>set it to 50 without breaking stuff.
>>>
>>>
>>>
>>It doesn't work with 20us nor with 50us.
>>
>>
>
>Ok, revert the patch. I really need to know which code path triggers
>this behaviour. Can you apply the patch below and compile the kernel
>with CONFIG_DEBUG_INFO.
>
>When the chip is not in READY state on entry of nand_command() debug
>info is printed. Please decode the kernel addresses of "Last caller" and
>"Current caller" with
>
>addr2line -e vmlinux 0xNNNNNNNNN
>
>
Here it is.
savin

Chip not ready in nand_command():
Last caller: c012aa04 (nand_base.c:389)
Last command: 0x70
Current caller: c012c0e8 (nand_base.c:1720)
Current command: 0x60

384 static int nand_check_wp(struct mtd_info *mtd)
385 {
386 struct nand_chip *chip = mtd->priv;
387 /* Check the WP bit */
388 chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
389 return (chip->read_byte(mtd) & NAND_STATUS_WP) ? 0 : 1;
390 }

1715 static void single_erase_cmd(struct mtd_info *mtd, int page)
1716 {
1717 struct nand_chip *chip = mtd->priv;
1718 /* Send commands to erase a block */
1719 chip->cmdfunc(mtd, NAND_CMD_ERASE1, -1, page);
1720 chip->cmdfunc(mtd, NAND_CMD_ERASE2, -1, -1);
1721 }