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.
AM1705 Boot from NAND Flash
Part Number: AM1705
We have recently updated our boot process via NAND on the Am1705 so that we have redundant boot images to use if we get damaged NAND areas. To this end, we now have 2 copies each of the initial User bootloader (UBL) stored at blocks 1 & 2 of the NAND chip in AIS format. Our UBL has some useful low-level diagnostics, but in normal boot it simply loads one of 2 U-Boot copies from either the primary or secondary area of NAND, then we use some U-Boot scripting to do the same for the 2 Linux kernel image copies, which, once running the OS, uses a UBIFS NAND partition.
We chose this route due to a couple of field failures (in the U-Boot image's ECC); the idea being that UBIFS can maintain itself pretty well once the board is fully up and running, but we don't really have the same option for the boot-level binaries. We have a Linux script that checks the redundant images against each other, plus it looks at any creeping ECC failures over time. If any discrepancies are found, it re-programs the affected image using the data from the good copy.
I noticed relatively early that there was a potential weakness in this scheme relating to the on-chip ROM bootloader (RBL); namely, that if we found a damaged Block 1 and happened to lose power after erasing it prior to refreshing with a good copy (from Block 2), then the RBL seemed to abort boot when it encountered a blank Block 1, rather than trying to load data from successive blocks, as I had assumed. Further testing has shown that RBL will only check Block 2 for our 2nd UBL copy if Block 1 is marked bad. I have tried introducing errors in the AIS image's CRC, ECC errors and simply damaging the magic word at the start of the block - all of these result in a non-bootable board, even though there is a perfectly good UBL image stored at Block 2.
Is my understanding of the RBL 'abort boot' conditions correct? I realise that we can't change the RBL behaviour, but we may have to look more carefully in how we deal with Block 1 with our NAND checking script if there's a limited number of options that lead to Block 2 being checked if Block 1 contains errors.
Is there source code for the RBL available to check my suspicions?
Please make sure you read the forum guidelines first.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Yordan Kovachev:
We used 03.20.00.14 to get the project going back in the day, although it doesn't come up in day-to-day use.
In reply to Jeremy Evans:
In reply to JJD:
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.