Cyclone V GT Dev Kit - new units fail to boot from FPP

We have been using this development kit internally for many years, and on our last order 2 out of 3 units fail to boot using the Fast Passive Parallel (FPP) configuration scheme through the MAX V.

We normally use our own custom MAX V bitstream, but the issue is present even with the factory MAX V image and the factory FPGA image/flash content. The MAX V appears to try loading the image (LED D6 flashing or statically lit, depending on the MAX V firmware version) for about 6 seconds before giving up and signaling an error (LED D5).

On reception, one of the two faulty boards seemed to work, it was just taking a bit longer to boot than usual (presumably it took a few retries). It then got progressively worse: the boot started failing intermittently, and now it is almost impossible to get it to boot through FPP. The boards can still boot through Active Serial (AS), and the FPGA can properly read and write the main flash, so the issue seems to affect only the MAX V flash access / FPGA configuration.

Following this thread, which reports the same issue: Cyclone VGT Dev Kit boards - some new boards failing to boot from NOR Flash | Altera Community - 353984 we tried reducing the MAX V utilization to improve timing. With this change one of the boards managed to boot a few times, but very rarely and not reliably.

The affected boards are all rev. B and have serials:
- 5CPCIE00100214
- 5CPCIE00100263

While debugging, I also noticed that the timing constraints do not follow the Parallel Flash Loader IP User Guide. For example, fpga_dclk should be a generated clock and used as the reference for the other constraints, and the set_output_delay on fpga_data does not respect the tDSU from the Cyclone V datasheet. That said, correcting these constraints did not improve the boot behavior.

We are now stuck with two boards that can only boot from AS, which is a concern for future orders. Between this and the flash revision change to rev. B (where the PCB is actually labelled rev. A and the example designs are mixed and not clearly labelled), these boards are becoming difficult to work with.

Since there is at least one other thread reporting the same behavior it looks less like an isolated fault and more like a recurring issue on recent production. Could someone from Intel confirm whether this is being tracked, and what the recommended action is for affected boards?