We've designed and build (mostly successfully - everything but the 8-bit NAND works) an OMAP-L138 embedded system, whose processor kernel (CPU, RAM, Flash and Power manager) is an exact hardware copy of the LCDEVKIT-AE7 evaluation board. This board uses a MICRON 16-Bit 512MB NAND Flash MT29F4G16ABADAH4 as mass storage device and works pretty well.
Compiling, building and running our linux system and application software, loaded from the Flash and copied to RAM by u-boot, works perfectly, when the image has been prepared and flashed using the TI OMAP-L138_FlashAndBootUtils_2_40 package. We compiled and build that package from sources sucessfully, in order to add some debugging outputs into the sft part, running on the ARM.
Caused by current market shortage of those 3.3V / 16/Bit Flash chips, we decided to switch to its 1.8V / 8-Bit sibling MT29F4G08ABBDAH4-ITX of the same manufacturer.
We changed power supply of the Flash and interfacing of all power-group B GPIOs of the OMAP to 1.8V and the board works pretty well in all functions, executing its programm from RAM. The only thing that doesn't work are any accesses to the new 8-bit Flash.
By debugging the sfh / stf parts of the AIS tool package mentioned above, we were able so isolate the problem a bit, as follows:
The first read access to the physical Flash chip (after successfully download the BOOTUBL parts and our flash image file to RAM by FTP) is reading out two 4-byte-strings at chip offsets 0x00 an 0x20, yielding the ONFI signature and the manufacturer device ID string. These two strings contain nearly exact what we expect (from the MICRON data sheet), but in each string the first byte is missing, so that the second byte to be expected is in the first place (array index 0), the third byte is in array index 1 and the fourth byte in array index 2. Array index 3, the fourth byte, contains an additional value, not described in the data sheet. This is true for both strings read out in those two first accesses.
Shifting the bytes in those two arrays satisfies the program expections, so that the subsequent flashing starts, but the verify step for all blocks fails - naturally. It looks like as every first byte in any multi byte read access is missing and all subsequent bytes are shifted in time by one place.
Has anyone reading this, ever observed that kind of fault and can give us any hint, which parameter of setup, either of the EMIFA unit, or clocks or anything else may be wrong? The funny thing ist, that the 16-bit version of the Flash works seamlessly, with the original AIS binary tools and drivers from the TI SDK, as well as with the version 2.40, downloaded, compiled and build from sources. It must be something wrong with the board, the flash chip of (most probably) with our software setup, but we have no idea what.
Thank you in advance for any hints
Horst
