Vybrid NAND Boot with insidious bad blocks

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Vybrid NAND Boot with insidious bad blocks

Jump to solution
1,546 Views
aurélienmartin
Contributor I

Hello there,

  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:

(1) Understanding VYBRID NAND Boot

(2) Re: Vybrid NAND boot

  I've also stumbled into that document (https://linuxlink.timesys.com/docs/projects/engineering/wiki/NAND_Boot_for_Vybrid_Tower#Generating-t...​), 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):

  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?
    1. 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

read."
So what can be the use of PTE9/RCON2 specifying the NAND data width in BOOT_CFG?

Thanks a lot.

Labels (2)
Tags (1)
0 Kudos
1 Solution
1,189 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
3 Replies
1,190 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!
0 Kudos
1,192 Views
timesyssupport
Senior Contributor II

Hi,

You will need to be logged in to the LinuxLink website in order to fully view the document. If you do not yet have a login, it is free to create an account with a Vybrid subscription:

Activate Your LinuxLink Support Edition Subscription for Freescale Vybrid Controller Solutions | Tim...

You will then be able to view the Nand Boot for Vybrid doc, which explains how to boot from NAND with U-Boot v2013.07 and v2011.12. I would recommend using U-Boot v2013.07, because this has support for Linux v3.13+. Also, it should be ok if blocks 0x0 and 0x20000 are marked bad, I believe this is where the BBT is stored and U-Boot will skip over these blocks. If you have any issues while following the steps in the doc, please let me know and I will assist.

Thanks,

Timesys Support

1,192 Views
karina_valencia
NXP Apps Support
NXP Apps Support

timesyssupport​ can yo help to review this case?

0 Kudos