Cyclone VGT Dev Kit boards - some new boards failing to boot from NOR Flash

Hi, thanks for your comments. 

Some answers
We don't use the EPCQ flash, just the NOR flash.
These are all Rev B with Micron Flash
Yes even the factory image is failing and retrying. On a good board the factory image boot is almost instant. On a bad board it takes seconds to "succeed" but sometimes fails. I ran tests with a modified bootloader and found that it is retrying dozens of times. 
Programming the NOR Flash via JTAG tools works with no errors, including the CRC readback tests, which verifies the data path from the flash to the MaxV pins is ok. 
The error is definitely repeatable across power cycles, and repeatable via pressing the config button. 

One new weird data point - if we load the factory binary maxv.pof image, (and have to switch the factory/user button to user) then 3 of the boards seem to boot ok with our image. The other 2 are still bad. 
I looked at the source, for some reason Altera inverted the factory_user switch signal in the v22 source code. 
BUT if I compile that same factory image from the V22 source, my version of it fails to work. I tried using the exact same Quartus edition - no better. 
All the compilations I make work fine on the good Rev B boards we have. Very mysterious. 

Hi,

Thanks for the detailed update, this is very helpful.

Based on your findings, a few observations:

• Since JTAG programming and CRC verification are clean, the data path from NOR flash to MAX V appears valid.
• The repeated configuration retries (especially dozens of attempts) are not expected and indicate instability during configuration.
• The difference between the factory .pof and self-compiled version may point to differences in fitter/timing results.

There is a related KDB which may be relevant to RevB boards with updated device changes:
https://community.altera.com/kb/knowledge-base/why-cant-i-access-the-epcq-flash-device-on-the-cyclone®-v-gt-fpga-development-ki/344352

Although it refers to EPCQ, it highlights a known incompatibility on RevB (U29), which may also affect configuration robustness.

To help narrow this down further, could you also share the following:

1. For the 3 boards that work with the factory .pof, do they complete configuration in a single attempt or still show retries?
2. For the 2 boards that still fail, is the retry behavior identical across all images?
3. Have you compared settings between your compiled .pof and the factory .pof (e.g. compression, configuration options)?
4. Could you share the serial numbers of the affected boards? There may be a specific affected range for certain revisions.
5. For the silk screen difference, if possible, please share board markings or photos for comparison.

This will help us check if your boards fall within any known affected batch or if this is a new variation.

Thanks again for the detailed debugging effort.

Regards,
Fakhrul