This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I know it's not a specific DM365 issue, but i have some understanding problems about the NAND Flash and i thought maybe someone can help me out:
The typical use case of our dm365 custom board will be:
* about 20 years of steady use aka "always on",
* reboots at least a 100 times in this 30 years
* very hard to access or maintain
* operation conditions not really friendly...outside ...-10 to 70°C possible...but at least no increased radiation ;)
So my concern now is how the NAND behaves over time.
What i "think" would be a good idea:
* Store UBL and Uboot redundant, since RBL and UBL check only on ECC. So if a block is bad, it will not be used from the beginning(initial or later re-/programming). If a block becomes bad during operation, we have at least n-1 copies. I assume that a block becomes bad or looses its data is very unlikely if you do not write/erase and only read!???
* With the Kernel and Filesystem I'm not sure: UBoot reads it from Block X with bad block management -> means it skips every block marked as bad and keeps on reading. So as long as no block gets bad during operation I'm fine because production-bad-blocks are also skipped at initial flash programming. Same question here: Can a block become bad or loose its data during operation if you only read from time to time? And here i can not store the Kernel and FS redundant, because there is no support in uboot for that, right?
In the data sheets they say the data retention they guarantee is about 10 years. So what does this mean? 10 years without or with power? operating conditions? What is a guarantee? I really do not find anything from the manufacturer that would answer this questions...
Would be great if someone could help me out here!
Valentin Ecker
Valentin,
The questions you have asked are regarding NAND performance over time. It depends on the NAND used. NAND datasheet and manufacturer should provide the exact details.
Regarding RBL, as you mentioned if 1 copy goes bad, there are still n-1 copies of UBL and the boot should be successful.
Usually u-boot and kernel have bad block management but for specific details please refer to u-boot/kernel documentation.
Thanks,
Gaurav
Hello.
After several months of work, we received yesterday the unit with DM365 and Micron 256MB NAND flashes, which Linux does not boot:
NAND read from offset 700000 failed -117
** Read error
The flashes are "electrically" locked, the customer does not report any special occurrences....
Now I am very very concerned about this issue - is it possible that flashes elaborated some error with the time (2 months!!)?
I shall be very thankful for any consideration...
Hi Leon,
-117 is EUCLEAN, which will happen if the flash chip reports that it corrected an error using ECC during the read. There is a patch for U-BOOT that will stop U-BOOT from reporting an error when it encounters this:
http://www.mail-archive.com/u-boot@lists.denx.de/msg17826.html
Hello, Chris.
You now totally confused me. I was sure, that the issue I have is this:
http://e2e.ti.com/support/embedded/linux/f/354/t/73788.aspx
Will yo be so kind to read this through and comment here?
It is VERY important for me, as upgrading to the last DVSDK is really heavy operation - we are struggling for the last 3 days and have made only about 20-30% of the way.
Really thank you for your help.
Hi Leon,
Apologies for confusing the issue further, that was not my intention. If you are seeing bit flip errors then indeed you may have to update your version of U-BOOT to support the full ECC, as indicated by that thread. However, from your previous posts it did not appear that you were seeing bit flipping errors happening during a successful read, but were rather seeing an incorrectly reported read error when the read was corrected using the ECC.
Chris