Forum Discussion
Hi Fakhrul,
Please disregard my earlier comments on the CFM1.rpd range. The combined .rpd shows CFM1 spanning from 0x00008800 to 0x0002B7F0 instead of 0x0002B7FF. My understanding is that this difference is acceptable because it’s just padding, correct?
Also, our current flow generates a .tar file that contains the .pof, and we use that package for performing Remote Upgrade through firmware.
I need to verify whether for the above step #7, if we can take the CFM1‑only .rpd, generate a .pof from it, and still use that for the upgrade process. If you have any additional thoughts or concerns, please let me know.
BR,
-Vishal
Hi Vishal,
Thanks for the update.
The 0x0002B7F0 vs 0x0002B7FF difference is just trailing 0xFF padding. It’s acceptable as long as the flash beyond 0x0002B7F0 remains erased (0xFF). For safety and consistency, extract and program the full CFM1 range per your .map (0x00008800–0x0002B7FF, inclusive).
For firmware‑driven RSU using On‑Chip Flash, please use a CFM1‑only .rpd as the payload (as in step #7). A .pof is a programmer container intended for JTAG/off‑board programming and is not suitable unless your firmware explicitly parses it. Recommended: keep your .tar but include the CFM1‑only .rpd for the RSU path (you may still ship a .pof separately for lab JTAG, if needed).
Please:
- Erase and program exactly 0x00008800–0x0002B7FF.
- Verify after write.
- Set the Remote Update boot address to the Application start page (convert 0x00008800 to page units per the RSU IP guide) before triggering warm reconfig.
Regards,
Fakhrul