[RFC] drivers: Added retention register API

[nvlsianpu]

Added general purpose API for access retention registers.

Work in progress
Not ready for review

Signed-off-by: Andrzej Puzdrowski [email protected]

[henrikbrixandersen]

A few questions/comments prior to todays Architecture WG meeting:

• How common is this hardware feature? How many different SoC families, that we know of, support something like "hardware retention registers"?
• When are the hardware retention registers "cleared"? Are their contents kept through soft resets? Hard resets? Power loss?
• Could an existing API be used for for this? E.g. syscon or EEPROM?
• Is there a Linux kernel equivalent to this functionality?

[carlescufi]

API meeting:

• This API is very close to the existing syscon
• We need however bindings to express which retained register/ram area to use to store the boot information

zephyr,boot-mode-retention-addr = regret1

• Two layers:

  • Devicetrree info about where the actual boot info is stored
  • boot API to store/retrieve that when using Zephyr app/bootloader

• Steps forward:

  • RFC for retention API, including links to multiple SoCs that support them in register form
    • Retention API assumes that locations can be overwritten without page erases, meaning flash is excluded. Open question about atomicity of read/write operations
  • PR for boot API that will, in the future, use the retention API

[bjarki-andreasen]

To expand upon my idea regarding similar DTS approach to partitions:

/ {
    /* Chosen is used to point to actual register on whatever device implements ret_reg API */
    chosen {
        zephyr,boot-mode-ret-reg = <&boot_mode_ret_reg>;
    };

    /* This device would implement syscon API */
    gprt@46020c00 {
        compatible = "st,gprt"
        reg = <0x46020c00 0x40>;

        /* This node implements ret_reg API */
        retained_registers {
            compatible = "retained-registers-syscon";
            #address-cells = <1>;
            #size-cells = <1>;

            /* Retained register used for boot data */
            boot_mode_ret_reg: ret_reg@0 {
                reg = <0x0 0x4>;
            }; 

            /* Retained register used for run counter */
            run_cnt_partition: ret_reg@4 {
                reg = <0x4 0x8>;
            }; 
        };
    };
};

If storing retained registers on EEPROM, this is what that would look like:

/ {
    /* Chosen is used to point to actual register on whatever device implements ret_reg API */
    chosen {
        zephyr,boot-mode-ret-reg = <&boot_mode_ret_reg>;
    };
};

&spi@0x46020000 {
    /* This device would implement EEPROM API */
    eeprom@46020c00 {
        compatible = "st,eeprom"
        reg = <0x46020c00 0x40>;

        /* This node implements ret_reg API */
        retained_registers {
            compatible = "retained-registers-eeprom";
            #address-cells = <1>;
            #size-cells = <1>;

            /* Retained register used for boot data */
            boot_mode_ret_reg: ret_reg@0 {
                reg = <0x0 0x4>;
            }; 

            /* Retained register used for run counter */
            run_cnt_partition: ret_reg@1 {
                reg = <0x4 0x8>;
            }; 
        };
    };
};

The retained_registers compatible property is used to specify what API its parent uses, to translate from the ret_reg API to the parent device appropriate API, be that syscon, EEPROM or other.

Summary

To summarize, we should add some sort of retained register section similar to flash partitions, which have an offset and a size. This sections should be placable inside SOCs which contain retained registers, like nordic and atmel controllers with GPBR and GPRR registers, EEPROMs, some I2C attached ICs, etc.

With this design, we can place and point to retained registers of varying sizes spread around the system, and use chosen nodes to bind a register to a feature, like zephyr,boot-mode-ret-reg.

@galak @carlescufi What do you think?

[nordicjm]

To summarize, we should add some sort of retained register section similar to flash partitions, which have an offset and a size. This sections should be placable inside SOCs which contain retained registers, like nordic and atmel controllers with GPBR and GPRR registers, EEPROMs, some I2C attached ICs, etc.

Would also be good to allow a RAM region to be used too, so that it would be removed from kernel/application usage and placed in a non-initialise area, that way more data than the retention register can hold could be used and it can be used on platforms without a retention register (@gregshue this may be useful for your signing request, as such a request would need a larger storage size).

[nvlsianpu]

This API is very close to the existing syscon

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 - syscon is an interface for manipulate registers for given device driver. In reality we won't (and it is unwanted) 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.

[nvlsianpu]

RFC for consideration on retention registers: #51298

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.