Noinit section in LIM

[aScurtu86]

Hello Guys,

I'm trying to define a NoInit section in the linker script of my app running on U54_1 in order to save some variables through reset cycles. At this point I'm not able to do so and as I'm not that familiar with the linker script syntax I'm not sure if the problem is the way I defined the section or the fact that at reboot the HSS is doing an initialization of its own and I should also define this area into its linker file.

This is how I've defined the section in the linker script:
/* NOINIT section for data */
.noinit (NOLOAD) : ALIGN(0x10)
{
__noinit_start = .;
*(.noinit)
(.noinit.)
. = ALIGN(0x10);
__noinit_end = .;
} > l2lim

And this is how I defined a test variable in that section:

int32_t NoinitNumber attribute ((section (".noinit")));

Unfortunatelly the value in the NoInitNumber variable is set to 0 at each reboot and I can't figure out why.

Any feedback is welcome.

[hughbreslin]

Hi @aScurtu86 when you say the variables are resetting to 0 on reboots, is this a power cycle or starting a new debug session? Just checking as the LIM is RAM it will be in an unknown state after a power cycle.

[aScurtu86]

Hi Hugh.
I'm seeig the variable set to 0 after rebooting the MSS by writing SYSREG->MSS_RESET_CR = (uint16_t)0xDEAD.
As my experience is limited with both linker scripts and the Polarfire architecture I'm not sure if my linker script syntax is the problem or there is something in the poalrfire way of doing things I'm not taking into consideration.

[hughbreslin]

ahhh ok, this register will cause a reboot of the MSS itself which will clear the LIM contents - could you give me a bit more of an idea of what you're trying to do? Is it debugging a bare metal application that will be used as a HSS payload?

[aScurtu86]

The function I need is having a variable that preserves over reset cycles, but not power cycles. On other architectures where the RAM memory handling was very basic definying the variable in a NoInit section of the RAM was suficient. Also most of the times the NoInit section was already defined in the lynker and I just used it without the need to explicetely define it. It also helped that I was in control of the bootloader and it's memory footprint did not overlap the NoInit section.

As now the application is loaded by the HSS, I'm not sure if I'm not correctly defining the section (wrong/incomplete syntax) or the HSS is also using the same area and regardless of my NoInit linker settings for the application, at startup the area is initialised for the HSS.

[hughbreslin]

Hmm ok - so the issue I think will be that once you reset you will loose your LIM contents, the reset propagates to the L2 cache controller. You could try the following:

1. Use the HSS to train the DDR / bring up the system but not boot any payload and then load your application via the debugger. You could use the steps in this document as a guide where you just launch new debug sessions without a reset or restart. This will only work reliably if your application hasn't crashed. I.e turn on the system one and start multiple iterative debug sessions without a reboot or soft reset to try out application changes. When you start the debug session it will point the CPUs to the start of your application code.
2. Use some FPGA memory which is not reset with / by the MSS to store your application code. You would need to modify your design to add a fabric RAM connected up to one of the FICs with a reset that is independent of the MSS, this is definitely doable and would be more reliable if you had to reset the MSS for any reason. Obviously the content will be lost between power cycles.

There are definitely more ways to do what you're looking for, if none of these are suitable let me know :) A third option in my head is writing / reading your values from a non-volatile memory like MMC or sNVM but this would require drivers and functions to work instead of just a pointer to memory so they're more complex. Using the sNVM would definitely do what you need and the values would be persistent across resets,

[aScurtu86]

Thanks for the sugestions. As you said, the easiest path looks to be adding a small FPGA memory and I will do it.
That way I will stay clear of doing custom changes to the HSS, and keeping it stock should make life easier on the long run.