I'm experiencing some difficulties booting on NAND with my Vybrid. I've done my research, of course, and found several threads of interest, including:
I've also stumbled into that document (https://linuxlink.timesys.com/docs/projects/engineering/wiki/NAND_Boot_for_Vybrid_Tower#Generating-the-NAND-U-Boot-Image), which, however full of promises, seems disappoitingly "disabled". (All of its links point to internal as well as absent anchors.)
Last but not least, I've played with 2 different versions of the U-Boot drivers/mtd/nand/fsl_nfc.c driver, found at :
(3) u-boot-timesys/fsl_nfc.c at 2011.12-mvf · Timesys/u-boot-timesys · GitHub (last modified Jun 26 2013, for the 2011.12-pcl052 and 2011.12-pcm052 branches)
(4) Vybrid Manufacturing Tool (last modified Mar 7 2014, with the elsewhere mentioned "nb_update" command split into a "nandinit" and a "nandwrite" ones.)
I can't seem to have either version of these commands work on my TWR, but it so happens that blocks of my NAND at 0x00000000 and 0x00020000 are marked bad (and effetively lost), so this could explain that.
Regarding bad blocks, I read in (1):
- If the first block of a given device could be “theoretically” be BAD, how does the NFC would automatically determine what block read next looking for a HW ECC match?
- The RM says in Section 31.4.4 ‘If there is an ECC failure detected, the process is started again at the next boot block’. Does the NFC use the NAND Boot eFUSES for BOOT SEARCH COUNT (BOOT_CFG[4:3]) to determine how many blocks from the beginning of the device to search? Yes, the ROM uses these fuses to determine the search limit.
I'm a little confused here. Reading section 31.4.4, I have been given the impression that this "next boot block" would be one of those defined just above:
"2. Four boot blocks are identified in the flash at row addresses 0, 256, 512, and 768."
Impression reinforced by the sentence sentence coming just after:
"If the fourth block still has ECC failure, boot is unsuccessful, which means it is not possible to read a reliable boot image from the flash."
But the answer of Daniel Douglass here seems to imply that bad blocks are also skipped, in addition to that process, up to BOOT_SEARCH_COUNT. Since this parameter can take value 8, it seems it's a number of "simple" blocks, rather than of so called "boot blocks". Am I to understand that for each boot block, the ROM code looks for it at BOOT_SEARCH_COUNT successive locations, before switchnig to the next? This would account for the u-boot commands using nand_write_skip_bad() to write the FCB, but not for my failing to boot that way, then. There's also the matter of row addresses 0, 256, 512 and 768 being only 4 pages apart form each other. (Right?)
I have questions also regarding the workings of the NAND boot preparation commands in U-Boot (all versions):
Before the FCB write, the NFC_FLASH_CONFIG (aka NFC_CFG) register is saved, then prv->pg_boot is set. Afterwards this same flag is cleared, and NFC_FLASH_CONFIG is restored to the previously saved value. What is the use of this save/restore scheme, when the NFC_FLASH_CONFIG isn't modified at all? (In fact, apart from the driver's initialisation function, the only places where that register is refered to are the fsl_nfc_command() function, which specifically avoids modifying it when the pg_boot flag is set, and the fs_nfc_addr_cycle() one, which sets the DMA_REQ and PANGE_CNT fields to values from where they never move.)
Actually, I would expect this register to be modified, be it only so that the BTMD bit be set, and NAND writes be altered in the same fashion as NAND reads are altered during boot.
Finally, section 31.4.4 mentions:
"The boot is identical for a 8- and 16-bit wide flash. If a 16-bit flash is connected, the data on the upper lane is discarded. If a 8-bit flash is connected, the upper 1 KB of data is not
So what can be the use of PTE9/RCON2 specifying the NAND data width in BOOT_CFG?
Thanks a lot.