[U-Boot-Users] Testing rewrite of NAND code?
Maybe this slipped through unnoticed, so here again:
A rewrite of the NAND flash code by Ladislav Michl is available in the " "testing-NAND" branch of our git repository; you can download it using git or cogito like this:
git clone rsync://source.denx.net/git/u-boot.git#testing-NAND u-boot-testing-NAND resp. cg-clone rsync://source.denx.net/git/u-boot.git#testing-NAND u-boot-testing-NAND
Please help testing this code as thoroughly as possible. I would like to merge this into the main branch ASAP.
Please send your Comments, complaints, bug reports etc. to this mailing list + Ladislav Michl + me.
Thanks.
Best regards,
Wolfgang Denk
I fixed this problem so this is just a comment: (I think I have the latest cmd_nand.c file.) If so, I found no support for the option 'clean' for 'nand erase', which, to my understanding, does a complete erase of the nand device.
Hoda <hskaraki <at> hotmail.com> writes:
I fixed this problem so this is just a comment: (I think I have the latest cmd_nand.c file.) If so, I found no support for the option 'clean' for 'nand erase', which, to my understanding, does a complete erase of the nand device.
I suppose just remove 'clean' from the help and all is fine!
I've made several tests of the new NAND code on a custum board based on mpc8272.
Read worked for me just fine for both "raw data" read and JFFS2 functions (ls and fsload).
When I tried to write data to the NAND flash using the command => nand write.jffs2 400000 200000 400000
the system hanged right after printing: "NAND write: device 0 offset 2097152, size 4194304 ... 4194304 bytes written: OK"
As far as I understood, the "erase" is still not implemented.
-- Sincerely yours, Mike Rapoport.
On Mon, Sep 26, 2005 at 04:52:13PM +0200, Mike Rapoport wrote:
When I tried to write data to the NAND flash using the command => nand write.jffs2 400000 200000 400000
the system hanged right after printing: "NAND write: device 0 offset 2097152, size 4194304 ... 4194304 bytes written: OK"
This is really strange. Code reads:
i = strncmp(cmd, "read", 4) == 0; /* 1 = read, 0 = write */ printf("\nNAND %s: device %d offset %u, size %u ... ", i ? "read" : "write", nand_curr_device, off, size); if (i) ret = nand_read(nand, off, &size, (u_char *)addr); else ret = nand_write(nand, off, &size, (u_char *)addr); printf(" %d bytes %s: %s\n", size, i ? "read" : "written", ret ? "ERROR" : "OK"); return ret == 0 ? 0 : 1;
So it seems nand_write returned sucessfuly. Could you debug it a bit more? Perhaps stack corruption?
Thanks, ladis
On 9/26/05, Ladislav Michl ladis@linux-mips.org wrote:
So it seems nand_write returned sucessfuly. Could you debug it a bit more? Perhaps stack corruption?
I've debugged it a bit more and found out that the crush occurs when hush parser tries to execute the next command (if there is one) and the pointer to the next command seems to be corrupt. So it indeed looks like stack (or maybe heap?) corruption.
Another thing I've noticed, is that NAND CE never goes inactive. As far as I understood the only place where select_chip(mtd, chip) is called with chip=-1 is the "nand_release_device" function, which is #ifdef'ed out (lines 172-194 of nand_base.c).
Yet another thing is that after writing to the NAND the newly written blocks identified as bad on the next boot.
-- Sincerely Yours, Mike.
Hi again:
This more of a note than a question. I have this issue that I also had with the kernel: Yet for me to find out, reading (particularly out of band data) doesn't work properly unless an empty MTD_NAND_READ0 command is sent after the intial one:
this->cmdfunc (mtd, MTD_NAND_READX, column, page); ==> this->cmdfunc (mtd, MTD_NAND_READ0, -1, -1); <==
I've inserted this second line after all the MTD_NAND_READX commands except for MTD_NAND_READID
Without it, what would happen is that it would start reading the ecccode a few bytes before, hence it won't match with the calculated ecccode. Also the blocks, where I wrote to the first page, would be listed as bad when they're not; understandable since again it is reading the wrong bytes. ------------------------------------------------------------------------------- INCA-IP-ROM # nand write 80400000 0 1000
NAND write: device 0 offset 0, size 4096 ... nand_write_ecc: to = 0x00000000, len = 4096 4096 bytes written: OK INCA-IP-ROM # nand read 80800000 0 1000
NAND read: device 0 offset 0, size 4096 ... nand_read_ecc: from = 0x00000000, len = 4096 ECC bytes are: 96 9a 6b 9a 9a 97 66 a6 9b aa 96 97 3c f0 3f f3 3f cf a9 a6 9b 59 59 57 ECC bytes are: ff ff ff ff ff ff ff ff ff ff 33 30 33 f0 cc f3 03 ff ff 03 cf 33 55 65 nand_read_ecc: Failed ECC read, page 0x00000001 nand_read_ecc: Failed ECC read, page 0x00000001 nand_read_ecc: Failed ECC read, page 0x00000001 4096 bytes read: ERROR -------------------------------------------------------------------------------- When I do a nand dump, the oob data looks like this:
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 33 30 33 f0 cc f3 03 ff ff 03 cf 33 55 65 5b 59 5a a7 69 aa 5b 5a aa 6b
I am testing Large page NAND ST 01GW3B on the INCA-IP board.
This extra READ cmd was there in the old cmd_nand.c file in the NanD_ReadBuf function.
participants (4)
-
Hoda -
Ladislav Michl -
Mike Rapoport -
Wolfgang Denk