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.