hi just for my information: How do you debug uboot ?? Albert On Mon, Apr 26, 2010 at 9:40 PM, John Tobias <[email protected]> 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? > > 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? > > Thanks, > > John > > > > > > > On Fri, Apr 23, 2010 at 11:43 PM, Brian G Rhodes <[email protected]>wrote: > >> Caglar Akyuz wrote: >> >>> On Friday 23 April 2010 11:09:51 pm John Tobias wrote: >>> >>> >>>> Hello Guys, >>>> >>>> I would like to know what are the possible chances that u-boot/ubl >>>> crashes?. I am looking for some theory/scenario that I can possibly >>>> connect/apply the scenario to what happened to my device based on >>>> dm6446. >>>> >>>> The device has been running for a year now and for some reason it never >>>> come back anymore. I connect through the serial port of the device and >>>> check if there's something different. The device was in the state where >>>> the bootloader is missing. I re-program the u-boot and the device boot >>>> it >>>> again as I expected. >>>> The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to >>>> screwed up the uboot. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> >>>> >>> >>> Hi, >>> >>> Since you are looking for theories, here is mine... >>> >>> Assuming that you are using a NAND flash, I think it can be because of >>> read disturb in NAND array. I know that it's a very long shot but its the >>> first explanation coming to my ming. >>> >>> >>> >> >> If it is caused by read disturb errors, the number of bits of ECC you are >> using would be useful to know. If you are using 1 bit ECC, then I wouldn't >> say that it is entirely unlikely. The UBL is setup to read from 5 >> consecutive blocks for the bootloader, so you can always program multiple >> backups, and use a similar strategy for Linux if you put the kernel in NAND >> as well. So, I would second Caglar's theory, also assuming you are using a >> NAND device. >> >> If you can recreate the failure, I would suggest reading the data off >> first before reprogramming again. Then you can compare it to a good image >> and see how many bits are incorrect in the failing block(s), accounting for >> the number of bits which can be corrected by ECC or reading without ECC. >> > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
