[TOPIC] Add NVMEM bitfield support and reboot‑mode integration by aswinm94 · Pull Request #11 · qualcomm-linux/u-boot

aswinm94 · 2026-04-09T11:28:46Z

This PR introduces bit-level granularity to NVMEM cells and
adds complete reboot-mode support for Qualcomm platforms that store
reboot reasons in PMIC registers.

Qualcomm SoCs rely on PMIC-backed reboot reason storage to implement
features like "reboot bootloader" for entering fastboot mode. However,
these PMIC registers often pack multiple fields into a single byte,
requiring fine-grained bit access that the current NVMEM subsystem does
not support.

In addition, PMIC generations differ in how reboot-related data is
stored: older PMICs use PON (Power On) registers, while newer ones
provide SDAM regions. This series introduces a unified, NVMEM-based
approach that works seamlessly across both architectures.

This also integrates reboot-mode handling into Qualcomm board
initialization, enabling automatic fastboot entry when the reboot reason
indicates bootloader mode.

upstream link: https://lore.kernel.org/u-boot/20260408121841.186410-1-aswin.murugan@oss.qualcomm.com/

NVMEM cells currently only support byte-level access. Many hardware registers pack multiple fields into single bytes, requiring bit-level granularity. For example, Qualcomm PMIC PON registers store a 7-bit reboot reason field within a single byte, with bit 0 reserved for other purposes. Add support for the optional 'bits' property in NVMEM cell device tree bindings. This property specifies <bit_offset num_bits> to define a bit field within the cell's register space. Implement bit‑field handling in the driver to max u32 size Example device tree usage: reboot-reason@48 { reg = <0x48 0x01>; bits = <1 7>; /* 7 bits starting at bit 1 */ }; This reads bits [7:1] from the byte at offset 0x48, leaving bit 0 untouched during write operations. Cells without the 'bits' property continue to work unchanged, ensuring backward compatibility with existing device trees. Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>

Qualcomm PMICs include SDAM (Shared Direct Access Memory) regions which are used to store persistent data like reboot reasons that must survive across reboots. Without this driver, U-Boot cannot access PMIC storage, preventing reboot-to-bootloader functionality and other features that rely on persistent state. Add qcom-spmi-sdam driver that: - Probes SDAM regions from device tree compatible "qcom,spmi-sdam" - Implements NVMEM provider interface for standard cell-based access - Uses SPMI register read/write operations for data access This enables reboot-mode and other subsystems to access PMIC storage through standard NVMEM APIs. Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>

Add reboot-mode detection and automatic fastboot entry to Qualcomm board initialization. This enables 'reboot bootloader' functionality on platforms with reboot-mode device tree configuration. Changes: - Add qcom_handle_reboot_mode() call in board_late_init() - Conditionally compile with CONFIG_DM_REBOOT_MODE - Reorganize header includes Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>

The PM8150 PMIC on this platform uses the older PON (Power On) register architecture rather than dedicated SDAM regions found in newer PMIC generations. To enable reboot-mode functionality with the unified NVMEM-based approach, add a compatibility wrapper that exposes PON registers through the SDAM NVMEM interface. Add device tree configuration: - NVMEM node with compatible "qcom,spmi-sdam" wrapping PON registers - Uses 'ranges' property to map the PON register block at offset 0x800 - NVMEM cell at offset 0x8F (PON_SOFT_RB_SPARE register) - 7-bit field (bits [7:1]) for reboot reason, preserving bit 0 - Mode mappings: bootloader=0x02, recovery=0x01 This wrapper allows the SDAM NVMEM driver to access PON registers transparently, providing a unified interface for both PON-based (older) and SDAM-based (newer) PMIC generations. The PON_SOFT_RB_SPARE register persists across warm resets and is automatically cleared on power cycle. Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>

Enable reboot-mode functionality for all Qualcomm platforms that define reboot-mode device tree nodes. The drivers gracefully handle platforms without reboot-mode configuration, making it safe to enable globally. Add config options: CONFIG_DM_REBOOT_MODE=y - Core reboot-mode framework CONFIG_REBOOT_MODE_NVMEM=y - NVMEM-based storage backend CONFIG_QCOM_SPMI_SDAM=y - Qualcomm PMIC SDAM/PON access Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>

Add a mock I2C EEPROM device (nvmem-test@50) to the sandbox device tree to support NVMEM bit field operation testing. Add test coverage for NVMEM bit field read and write operations to validate the new bit field support in the NVMEM subsystem. Test cases include: - 1-byte cell with 7-bit field (Qualcomm SDAM reboot reason use case) - 4-byte cell with 12-bit field spanning a byte boundary - 4-byte cell without a bit field (legacy byte-level access) - 4-byte cell with a 16-bit field in the upper 2 bytes Error validation tests cover: - Bit field exceeding the cell size - Bit field exceeding the 32-bit maximum - Invalid bit_offset and nbits combinations - Buffer size mismatch in non-bit-field mode The tests verify: - Correct bit extraction during read operations - Read-modify-write behavior preserving unrelated bits - Proper error handling for invalid configurations Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>

Update the nvmem_cell_read() and nvmem_cell_write() documentation to describe the new bit field operation mode. The documentation now clearly explains: For bit field mode (nbits > 0): - Read: extracts the bit field from raw hardware bytes - Write: performs read-modify-write to preserve other bits - Requirements: buffer size must be sizeof(u32), cell size <= 4 bytes For non-bit-field mode (nbits == 0): - Read/Write: direct byte-level access - Requirements: buffer size must equal the cell size This helps developers understand when to use each mode and the associated buffer size requirements. Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>

varada-qcom · 2026-04-10T04:14:50Z

arch/arm/dts/qcs615-ride-u-boot.dtsi

+	/* Virtual NVMEM node for PON-based reboot reason storage */
+	nvram@800 {
+		compatible = "qcom,spmi-sdam";
+		reg = <0x800>;


Generally address values are expected to be spelled out in full. i.e. 0x00000800

@varada-qcom , It was referred from other soc dts in kernel, they didn't spelled out fully so I did the same to maintain the uniformity
https://source.denx.de/u-boot/u-boot/-/blob/master/dts/upstream/src/arm64/qcom/lemans-pmics.dtsi#L154
Do we need to change it?

varada-qcom · 2026-04-10T04:14:57Z

arch/arm/dts/qcs615-ride-u-boot.dtsi

+		reg = <0x800>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x00 0x800 0x100>;


varada-qcom · 2026-04-10T04:17:24Z

arch/arm/mach-snapdragon/board.c

+	reboot_mode = env_get("reboot-mode");
+	if (reboot_mode && !strcmp(reboot_mode, "bootloader")) {
+		log_info("Entering fastboot mode due to reboot reason...\n");
+		ret = run_command("run fastboot", 0);


Is 'fastboot' a variable? Why run within run_command()

yes, it is a variable

varada-qcom · 2026-04-10T04:17:50Z

arch/arm/mach-snapdragon/board.c


 	qcom_show_boot_source();
+
+	/* Handle reboot-mode detection and fastboot entry */


varada-qcom · 2026-04-10T04:18:15Z

arch/sandbox/dts/test.dts

 				sandbox,filename = "i2c.bin";
 				sandbox,size = <256>;
 			};
+			emul_nvmem_test: emul-nvmem-test {


blank line before and after nodes

varada-qcom · 2026-04-10T04:23:18Z

test/dm/nvmem.c

+/*
+ * Test for NVMEM bit field support
+ */


varada-qcom · 2026-04-10T04:24:03Z

test/dm/nvmem.c

+	return i2c_eeprom_read(dev, offset, buf, size);
+}
+
+/* Test NVMEM bit field operations */


remove. Looks like AI generated. Remove all obvious, no value add comments like this

varada-qcom

Lot of code seems to have been added. Please ensure you are withing the available flash size

aswinm94 added 7 commits April 9, 2026 16:49

varada-qcom reviewed Apr 10, 2026

View reviewed changes

arch/arm/mach-snapdragon/board.c

qcom_show_boot_source();

/* Handle reboot-mode detection and fastboot entry */

Copy link
Copy Markdown

varada-qcom Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

varada-qcom reviewed Apr 10, 2026

View reviewed changes

test/dm/nvmem.c

Comment on lines +2 to +4

/*

* Test for NVMEM bit field support

*/

Copy link
Copy Markdown

varada-qcom Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

varada-qcom reviewed Apr 10, 2026

View reviewed changes

b49020 mentioned this pull request Apr 10, 2026

Add support for fastboot reboot reason detection #5

Closed

b49020 changed the title ~~Add NVMEM bitfield support and reboot‑mode integration~~ [TOPIC] Add NVMEM bitfield support and reboot‑mode integration Apr 10, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[TOPIC] Add NVMEM bitfield support and reboot‑mode integration#11

[TOPIC] Add NVMEM bitfield support and reboot‑mode integration#11
aswinm94 wants to merge 7 commits intoqualcomm-linux:u-boot-mainline-1.0from
aswinm94:nvmem

aswinm94 commented Apr 9, 2026

Uh oh!

varada-qcom Apr 10, 2026

Uh oh!

aswinm94 Apr 10, 2026 •

edited

Loading

Uh oh!

varada-qcom Apr 10, 2026

Uh oh!

varada-qcom Apr 10, 2026

Uh oh!

aswinm94 Apr 10, 2026

Uh oh!

varada-qcom Apr 10, 2026

Uh oh!

varada-qcom Apr 10, 2026

Uh oh!

varada-qcom Apr 10, 2026

Uh oh!

varada-qcom Apr 10, 2026

Uh oh!

varada-qcom left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants


		qcom_show_boot_source();

		/* Handle reboot-mode detection and fastboot entry */

Conversation

aswinm94 commented Apr 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aswinm94 Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

varada-qcom left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

aswinm94 Apr 10, 2026 •

edited

Loading