MAX 10 Execute in Place Dual Image RSU CFM Issue

[n-slipstream]

I have setup a MAX10 08 with dual image design and implemented a software stack to update the CFM1 with a new image.

When dual image is enabled memory initiation becomes disabled, so the NIOS II software must be placed in UFM0 and alt_boot copier enabled in the BSP. This is called execute in place. The system is working an boots fine.

My issue is that for a dual image design the flash is NEVER in an IDLE state.

alt_u32 status = IORD(ONCHIP_FLASH_0_CSR_BASE, 0);

2'b11 BUSY_READ always set so I cannot erase a region/sector and then write a new image.

ug_m10_ufm_User_Flash_Memory.pdf

The NIOS is running from UFM and I need to update CFM1, different flash sectors but part of the same on chip flash device.

For a single image design with memory initiation enabled I can successfully write to flash and update the bitstream.

Is there a way to update the flash when using execute in place?

[Farabi]

Hello,

Please refer to link : https://cdrdv2.intel.com/v1/dl/getContent/666980?fileName=edh_ed_handbook-683689-666980.pdf

Figure 82, step 5, there is setting for initialize flash content.

regards,

Farabi

[n-slipstreem]

@Farabi 

Thank you for your message but I think there has been a misunderstanding.

I have already successfully created a .pof file and successfully booted the NIOS from UFM.

UFM              CFM0         CFM1

NIOS II code     Image 1      Image 2

I have a SPI slave peripheral that receives an .rpd file and the NIOS II must write it to CFM1 to update image 2.

This is to implement an in the field upgrade without the USB Blaster.

The NIOS II cannot erase any sectors or pages.

https://www.intel.com/content/www/us/en/docs/programmable/683180/18-0/on-chip-flash-core-registers.html

Every time the on-chip-flash IP Core Status Register is read the busy field is set to 2'b11 BUSY_READ.

While busy any command to the Control register to erase is ignored, write protection can be removed but new data cannot be written unless and erase has completed.

Is there a way to for execute in place NIOS II to write to on-chip flash?

My theory as to why:

When building the code for NIOS II the .text region must be placed on the on chip flash, rather than alt_load copy to on-chip memory. If not then mem_init_generate fails.See part 6.

https://www.intel.com/content/www/us/en/docs/programmable/683689/current/application-21528.html

Just by having the NIOS II running will cause read operations for program content from .text.

Not sure of a good way round this.

[Farabi]

Hello,

I am consulting NIOS expert on this request. I will get back to you once I have the answer for your question.

regards,

Farabi

[Farabi]

Hello,

I am sorry to keep you waiting. I have consulted this case with engineering, MAX10 RSU + NIOS II XIP from on-chip flash is still under investigation. There will be a fix in future release, but it is not stated which version. So the functionality of this feature is not guaranteed to work for now.

It is recommended to boot NIOS II from boot copier where the .text is in the on-chip memory, you will be able to update the application image in CFM1 and CFM2 and trigger reconfiguration after the image update.

If you boot NIOS II with XIP where the .text file is pointed to the QSPI controller, you will be able to update the CFM1 and CFM2, but the program will hang after last HEX data is being written to CFM.

regards,

Farabi

[Farabi]

Hello,

There is note to mention that NIOS II can't erase or write UFM when boot NIOS II with XIP.

link : https://www.intel.com/content/www/us/en/docs/programmable/683689/current/fpga-on-chip-flash-description.html

see Table 28 : "Note: You can not erase or write UFM while XiP in the Intel® MAX® 10."

regards,

Farabi

[Farabi]

Hello,

Do you have further question?

regards,

Farabi

[Farabi]

We do not receive any response from you to the previous question/reply/answer that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.