[RFC] API: Retention register API

[nvlsianpu]

Is your feature request related to a problem? Please describe.
This ticket is one of results of discussions on #50105

Retention registers are registers which are able to retains values between system reboots or other events which causes system RAM invalidation. Usually there are just a few retention register in a SoC if any.

Retention registers are not a backup-RAM. Better to access the backup-RAM like the rest of system memory, which is most efective.

Retention API assumes that locations can be overwritten without page erases, meaning flash is excluded. Open question about atomicity of read/write operations.

Example of retention registers are:
Nordic Semiconductor SoCs nRF GPREGRET register,
STM (for instance STM32L412RBT6) backup-register

Also worth to make some investigation on idea how to describe retention register like device in DTS: #50105 (comment)

Describe the solution you'd like
It might be worth to introduce an API which is dedicated for retention register like entities.
A try for that was made her #50105

Describe alternatives you've considered

There was also idea of using syscon API for that.

After Looking at the syscon API I see one problem with that - It is too low level. I'm expecting that we are using vendor provided hardware abstraction layer for manipulate peripherals MIMO register- syscon is an interface for manipulate registers for given device driver. In reality we won't (and it is unwanted IMO) give any possibility for manipulation on register level of all the peripheral - instead just a few like retention registers. Creating a fake syscon like register device might be an option, but real addressing isn't required for that. I'm doubting in that It will be proper solution.

With solution like that
We need however to express which retained register area to use to store expected information

zephyr,SOMETHIN-retention-addr = regret1

2. Do nothing

Internal SoC retention register can be accessed using SoC proletary callback/s. Such callbacks can be even standardize among SoCs (using a global weak callback, and SoC dependent overriding callbacks, example of this approach is sys_arch_reboot() ).

Additional context
Retention values might be use as a way because on which system initializes differently, switches to different boot mode or store any other useful in next run-time value.

[bjarki-andreasen]

I will argue that we should make a high level abstraction, and then concider how to implement it low level:
Specifically, i would like an abstraction for retained memory, be it retained registeres, backup RAM (SRAM), EEPROM etc.
The rules for the high level API:

• Memory accessed with API must be reserved and exclusively accessed through API
• Memory accessed with API must survive a system reset, with no exceptions
• Memory must be modifiable without page erase, like SRAM, registeres, EEPROM etc.
• Memory must be partition able, it must be possible to describe partitions within the retained memory
• Memory partitions must be able to be sized dynamically pr byte with no alignment rules.
• It must be possible to describe retained memory partitions in devicetree as nodes

An API that follows these rules should be able to implement the logic of retained memory, the low level APIs used to fulfil the high level APIs like EEPROM, ret_reg, Syscon etc. can then be designed seperately.

[nvlsianpu]

@bjarki-trackunit I have nothing against high level abstraction. I think need to considered this having in mind that solution should give possibility for access given register (maybe only these within SoCs) without much overhead.

[bjarki-andreasen]

@nvlsianpu The reason for a higher level abstraction is that the single API may be able to cover multiple methods of retaining memory. With the retention registers, it is literally just writing/reading from memory mapped registers, it is too simple to warrant its own API IMO.

Syscon is about as low as we get for general purpose APIs, but note that that API covers writing/reading to all registers, not just retained registers for example, and the reason for its existence is that reading/writing to registers on some architectures is not as simple as memory mapped registers.

We don't need a way to read/write to retention registers, we need a way to partition and interact with them and other retained memory in a generic way.

[nordicjm]

@bjarki-trackunit Have a look at main...nordicjm:zephyr:retention and see what you think, I've currently got 2 backends implemented, I have been trying to implement a noload RAM one but struggling on how to get it implemented in the linker, somehow it'd need to have memory at specific regions (for specific lengths) reserved and not sure how to go about that. I think I might have to have it whereby it goes as a separate dts node and the existing sram region and Kconfig is reduced properly. actually there is a node you can use already which adds a NOLOAD section, we're in business! 3 (basic) backends implemented, need to tidy it up, add prefix/checksum support, create some tests then should be good

[nordicjm]

Fixed with #55125