Hi Brian and Caglar, I finally found the information that I need. I was able to modify the DVFlahser/ubl to write the ubl data to block 1 to block 5.
And, for those who may experience the same scenario that I had, here's what I did. Since, the ubl default block in DVFlasher is block 1, I modified the DVFlasher to write the ubl data onto block 5 . By doing this, I can dump the contents of the failing block since the DVFlasher won't erase it. After making sure that the ubl would be written on block 5, I re-program my device. Then, I modified my kernel to expose the ubl block1 - block5 in linux userspace and from there, I dumped the information of my failing ubl block and compare it to the working copy. I found out that the contents of address 0003900 to 0004000 are entirely different. Thanks for the info. Best Regards, john On Mon, Apr 26, 2010 at 9:56 PM, Brian G Rhodes <[email protected]> wrote: > John Tobias wrote: > >> Hi, >> >> Sorry for the messed up. I was forwarding your email to my co-worker and I >> accidentally send it to you. >> >> Anyway, I have a few questions to follow up with you guys. >> >> 1. What are the possible cause of the "read disturb errors"?. Can you give >> me a bit detail explanation? >> > > You will find information on read disturb in the datasheet for your NAND > part. Here is an excerpt from a Micron appnote. > > *From Micron App note: **_ > http://download.micron.com/pdf/technotes/nand/tn2917.pdf_* > > *Read Disturb:* A read disturb error occurs when one or more bits are > changed from “1” > to “0” during a READ operation. Read disturb errors occur within the block > being read, > but on a page or pages other than the page being read. Performing a high > number > (hundreds of thousands or millions) of READ operations on individual pages > before an > ERASE command for the block containing those pages can exacerbate this > error. > To recover from this type of error, erase the block where the error > occurred and reprogram > the data to that block. > > ------------------------------------------------------------------------------------ > > > Accessing this code repeatedly, without erasing and > reprogramming the data, causes errors to occur over time (see “Temporary > Failures” on > page 2). Many factors influence the point at which errors begin to appear, > including how > often the same physical area of the NAND Flash device is read and the > extent to which > ECC is used to maintain data integrity in the system. > > Also see: > > _http://www.edn.com/blog/980000298/post/1670047767.html_ > > > >> 2. I am using kernel 2.6.10 and the ECC that we are using is >> NAND_ECC_HW3_512. Brian, in your suggestions (reading the failing blocks), >> how I can possible access the nand blocks if am getting a constant "BOOTME >> BOOTME ..." on my serial port?. Do you have any tools that I can use? >> > > You can modify DVFlasher to read blocks from NAND and output over serial. > You are basically adding a command to ubl. Look at DVFlasher.cs and > uartboot.c. It is likely more busywork than not, but it's nice to verify. > There may be better tools than DVFlasher as well out there, but I am not > familiar with any of them. > >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
