[U-Boot-Users] Testing rewrite of NAND code?

[U-Boot-Users] Testing rewrite of NAND code?

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hello! I'm from outer space,  and I've made myself look like a signa-
ture.  While  you  are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
                              Sincerely, A Stranger in a Strange Land

[U-Boot-Users] Re: Testing rewrite of NAND code?

[Hoda]

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. 

[U-Boot-Users] Re: Testing rewrite of NAND code?

[Hoda]

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!

[U-Boot-Users] Testing rewrite of NAND code?

[Mike Rapoport]

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.

[U-Boot-Users] Testing rewrite of NAND code?

[Ladislav Michl]

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

[U-Boot-Users] Re: Testing rewrite of NAND code?

[Hoda]

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.

[U-Boot-Users] Testing rewrite of NAND code?

[Mike Rapoport]

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.