Hi Hedley, Please read this threads. I've got the camera from Mexico and I've got the same problem uboot/ubl. I am going to ask the community again to get more information for what they said to me.
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
