IMX95 bootcount managment

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX95 bootcount managment

65 Views
Abder
Contributor II

Hi,

I've been working recently on the imx95 19x19 EVK board and i'm interested in implementing a bootcount management mechanism for our distro update/recovery. 

Looking in the TRM, i found out that the GPRs (General Purpose Registers) are in the BBNSM and are accessible via the SCMI protocol (requests to the SM running on the M33). In u-boot, scmi_get_bbnsm_gpr() and scmi_set_bbnsm_gpr() APIs are kindly provided (in arch/arm/mach-imx/imx9/scmi/soc.c) and i was able to implement my bootcount_store()/_load() without issues.

However, in the kernel, no such APIs exist ! (I would want to reset the bootcount from Linux user-space after a successful boot.)

Additionally, i came across the Cyber Resilient Recovery Module (CRRM) in your documentation, and now i'm questioning even if there is the need at all to self-manage a bootcount for distro updates.

So I have the following questions for you:

  • Why there is no support for SCMI APIs for GPR access in the kernel ? is it because the CRRM uses one of the GPRs ?
  • With CRRM, does it make sense to have a bootcount for managing distro updates ? if yes, where do you recommend storing the bootcount other than GPR ? (or what other ways are available to access the GPRs)

Any answer, is very well appreciated.

SoC: i.MX 95 (19x19 LPDDR5 EVK)
BSP: LF6.18.20_2.0.0

Thank you,

Abder

Tags (1)
0 Kudos
Reply
2 Replies

33 Views
Chavira
NXP TechSupport
NXP TechSupport

HI @Abder,

Thank you for the detailed investigation.

In simple terms, CRRM and ROM recovery do not replace a bootcount mechanism. They help recover from corrupted or invalid boot images, but they cannot determine whether Linux or your application has booted successfully. For OTA update solutions, a bootcount is still recommended to detect failed updates and perform automatic rollback.

Regarding the BBNSM GPRs, U-Boot provides access through NXP-specific SCMI functions, but Linux currently does not expose an equivalent interface. If you need Linux access to these registers, a custom kernel driver or SCMI vendor extension would likely be required.

For your use case, our recommendation is to continue using BBNSM GPRs for bootcount storage if they are already working in U-Boot. CRRM recovery and bootcount management serve different purposes and should be considered complementary mechanisms rather than alternatives.

Best regards,
Chavira

0 Kudos
Reply

16 Views
Abder
Contributor II

Hi @Chavira 

Thank you for the valuable clarifications.

Ok for using GPRs then, but will be there any official driver from NXP on the kernel side to add GPR access ?

I can see in the kernel source under drivers/firmware/arm_scmi/vendors/imx that imx-sm-bbm.c defines the GPR commands but doesn't implement them !!

enum scmi_imx_bbm_protocol_cmd {
IMX_BBM_GPR_SET = 0x3,
IMX_BBM_GPR_GET = 0x4,
IMX_BBM_RTC_ATTRIBUTES = 0x5,
IMX_BBM_RTC_TIME_SET = 0x6,
IMX_BBM_RTC_TIME_GET = 0x7,
IMX_BBM_RTC_ALARM_SET = 0x8,
IMX_BBM_BUTTON_GET = 0x9,
IMX_BBM_RTC_NOTIFY = 0xA,
IMX_BBM_BUTTON_NOTIFY = 0xB,
};
 
Is there any reason behind this decision i.e., implementing all the listed cmds but the GPR ones ? I prefer to align with NXP's intended approach here before relying on any custom implementation.
 

Best regards,

Abder

0 Kudos
Reply