Add Cadence MSPI controller and Infineon S28HX512T driver by natto1784 · Pull Request #102513 · zephyrproject-rtos/zephyr

natto1784 · 2026-01-19T14:11:21Z

This patchset adds Cadence MSPI (OSPI) controller and the Infineon S28HX512T driver as part of the generic MSPI NOR Flash driver.

Please see individual commit descriptions for more information.

Initial MSPI support overlap: #88487

Testing

Tested with following options
west build -b am243x_evm/am2434/r5f0_0 tests/drivers/flash/common -DCONFIG_MAIN_STACK_SIZE=20000 -DCONFIG_FLASH_PAGE_LAYOUT=y -DCONFIG_FLASH_FILL_BUFFER_SIZE=256

Note that the unaligned test WILL fail on 8D-8D-8D configuration since it tries to write odd number of bytes at odd offsets which a DTR configuration like 8D-8D-8D does not support

Pending

Move the CLI options above to Board or SoC defconfigs (need comments)
Decide whether to wait on Add MSPI + flash driver for the TI K3 platform #88487 to get merged or not.
[Offtopic] Fix flash test to not write at odd addresses and odd sizes if in DTR configuration.

swift-tk

The mutex usage in the current controller is not recommended and is technically incorrect. Since the controller is IRQ capable, the controller design should take that into account as invoking k_mutex_unlock from an ISR context is not permitted.

natto1784 · 2026-01-20T09:39:36Z

Hi, the controller is IRQ capable but does not make use of any interrupts, i.e, none of the interrupts are enabled and hence, k_mutex_unlock is not done from an ISR since there is no ISR in the first place.

swift-tk · 2026-01-20T09:43:31Z

Hi, the controller is IRQ capable but does not make use of any interrupts, i.e, none of the interrupts are enabled and hence, k_mutex_unlock is not done from an ISR since there is no ISR in the first place.

I know, but do you not plan to add IRQ support for the controller at all? Normally, the controller access is protected by a mutex and then the transfer(API) context is protected by a semaphore.
With mspi_dev_config and mspi_get_channel_status as acquire/release, all other API calls are made in between. If you need additional protection on other APIs, that's fine too... You may also want to consider whether to support multi-perpherial SW or HW as that would affect the API usage flow.

natto1784 · 2026-04-07T13:12:54Z

Force push change: rename the fixup parts of the SoC quirk to reset for more accurate description

natto1784 · 2026-05-04T12:09:49Z

Hi, I have rebased the patchset against main

A new change

Moved the "boot reset" parts of code to boards from soc directory since it involves external flash. Since this change requires creation of several new files, let me know whether this change is desirable or not.

nordicjm

fix all instances

nordicjm · 2026-05-08T06:30:47Z

+	flash0: flash@0 {
+		compatible = "infineon,s28hx512t", "jedec,mspi-nor";
+		status = "okay";
+		reg = <0>;


missing ranges

The reason ranges wouldn't work is FLASH_SIZE and FLASH_BASE_ADDRESS are selected based on zephyr,flash node. However MSPI controller's does not allow setting size as part of

zephyr/dts/bindings/mspi/mspi-controller.yaml

Line 17 in 60aaf22

const: 1

The flash itself is at 0x6000000 hence, a separate flash0_memory nodes is added as well

nordicjm · 2026-05-08T06:30:52Z

+		flash0_memory: flash@60000000 {
+			compatible = "soc-nv-flash";
+			reg = <0x60000000 DT_SIZE_M(128)>;
+		};


missing ranges

sonarqubecloud · 2026-05-08T06:56:21Z

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

swift-tk · 2026-05-08T08:10:17Z

+
+		flash0_memory: flash@60000000 {
+			compatible = "soc-nv-flash";
+			reg = <0x60000000 DT_SIZE_M(128)>;


This should not be needed. See #108100

Don't think I can use ranges to configure size due to this

zephyr/dts/bindings/mspi/mspi-controller.yaml

Lines 18 to 20 in 60aaf22

"#size-cells":

required: true

const: 0

and ranges will mess this up if I map it, right?

zephyr/include/zephyr/drivers/mspi/devicetree.h

Line 163 in 60aaf22

.dev_idx = DT_REG_ADDR(mspi_dev), \

You are right. the address and size cell const value were copied from SPI. It will prevent defining a size cell in child's reg property.

Even if we set size-cell to 1 and add the ranges, the REG_IDX_0_VAL_ADDRESS of the child will have changed to the mapping address and no longer represent index or CE number.
It looks like we need to move away from SPI DT anyways in order to use ranges. @JarmouniA @nordicjm

I think this edge case is just how it will have to be, there would be a similar thing with i2c, so the SPI device will need to not have ranges then, but the flash node (and below) which is a child of it will need ranges which is the best that can be made of the situation

Alright, added ranges to the flash0 node to map the memory region to zephyr,flash

swift-tk · 2026-05-08T08:13:56Z

Sorry, I'm forgetting things. Is this PR waiting on the other draft PR or is it ready yet?

natto1784 · 2026-05-08T08:25:32Z

Sorry, I'm forgetting things. Is this PR waiting on the other draft PR or is it ready yet?

It is ready, CI test failure is unrelated. Thanks for reviewing

swift-tk

Great! I see no other issues at this point. Sorry for not looking at this sooner.

swift-tk · 2026-05-09T07:32:58Z

+	# GPIO is required for ce_gpios despite the field being ignored
+	select GPIO
+	select PINCTRL
+	select MSPI_TIMING


Suggested change

select MSPI_TIMING

imply MSPI_TIMING

CC: @m-braunschweig, thanks!

Updated my branch

cherrypicked and rebased

Add a Cadence MSPI peripheral driver, used in the TI K3 platform. The driver was tested in 1S-1S-1S and 4S-4S-4S mode with the onboard infineon s25h flash of the am243x launchpad and a custom driver for the flash using this interface. The command and dummy cycles are always taken from the xfer request and never from the devicetree since different commands might have different latencies. The driver is somewhat basic for now and lacks e.g. callback implementation. This is something that can be added in the future. If a non-supported / invalid request is detected a error code is returned. Signed-off-by: Mika Braunschweig <mika.braunschweig@siemens.com>

Cadence OSPI/QSPI controller allows peripherals on its bus to have configurations like 8D-8D-8D or 4S-4D-4D which require DTR configuration for dual transfer rate. Hence, allow having DTR configuration in the driver. Signed-off-by: Amneesh Singh <amneesh@ti.com>

Cadence OSPI controller allows dual byte opcodes which are used by the flash on the bus for modes such as Octal SDR/DDR. Hence, allow configuration for dual byte opcodes. Signed-off-by: Amneesh Singh <amneesh@ti.com>

We configure address length as 'length - 1' in the controller. This currently does not check if the length is 0, in which case it causes unsigned integer underflow, so add a check for that. Signed-off-by: Amneesh Singh <amneesh@ti.com>

Add a mechanism to configure the CS timing based on the configured clock frequency for the peripheral (SCLK) in reference clock cycles for the controller (RCLK). Signed-off-by: Amneesh Singh <amneesh@ti.com>

Add the read delay field in the timing configuration to allow configuring delay for read data capture. This is supposed to be set either by the peripheral using this controller at runtime or the user. Additionally, also make the related struct and parameters public by separating out the header. Signed-off-by: Amneesh Singh <amneesh@ti.com>

Reset the STIG register configuration in case it was set before initializing the driver. Signed-off-by: Amneesh Singh <amneesh@ti.com>

Cadence MSPI controller uses a FIFO for indirect access operations on the device on bus. Right now we directly use the physical address provided via DT. This does not work on cores with MMU like A53; hence, map the FIFO address the same way base contrller register space is mapped. Signed-off-by: Amneesh Singh <amneesh@ti.com>

DDR Octal SPI configurations require reading an even number of bytes at a time. This includes commands such as RDSR (Status Register) and RDID (JEDEC ID). Currently this can cause timing issues, hence use an even number of bytes for the both aforementioned commands if the data rate is dual. Signed-off-by: Amneesh Singh <amneesh@ti.com>

1. Remove endianness configuraton, since some MSPI controllers may return -ENOSYS if they are configured as big or small endian. 2. Set default command (opcode) length to 1 byte for 1S-1S-1S (SPI) mode. Signed-off-by: Amneesh Singh <amneesh@ti.com>

- Add support for Infineon Semper S28HX512T NOR flash. This supports SPI mode (1S-1S-1S), 8S-8S-8S and 8D-8D-8D. - Expose set_up_xfer_with_addr, read_jedec_id and soft_reset_66_99 function declarations to the vendor specific quirks. - Add more macros to the spi_nor_s28hx512t.h header that can be used in addition to the already present macros. - Add a specific quirk that is only used when the parent controller for this flash is Cadence MSPI (OSPI). This involves calibrating a delay for capturing data on the controller by reading JEDEC IDs on different configurations. - Add DT binding for the flash to allow convenient Kconfig symbols that depend on the presence of the compatible flash node in the DT. - Add Kconfig option FLASH_MSPI_INFINEON_S28HX512T_TI_EARLY_FIXUP_RESET for TI K3 SoCs. This is required as the ROM bootloader on the SoCs may leave the flash in 8D-8D-8D state depending on what bootmode is set. This requires resetting the board beforehand in this very specific configuration. - Move FLASH_MSPI_QUIRKS_GET to the bottom of file in flash_mspi_nor_quirks.h header. Signed-off-by: Amneesh Singh <amneesh@ti.com>

Add boot-time reset for TI MSPI flash devices left in 8D-8D-8D mode by ROM bootloader. Issues reset commands to restore 1S-1S-1S mode before normal flash driver initialization. The priority is set to default flash priority minus one. The priority is a non-issue as long as MSPI bus (flash controller) is initialized before this. Signed-off-by: Amneesh Singh <amneesh@ti.com>

Add Cadence MSPI controller and the S28HX512T NOR flash on its bus. Signed-off-by: Amneesh Singh <amneesh@ti.com>

sonarqubecloud · 2026-05-11T12:30:52Z

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

natto1784 force-pushed the mspi_s28hx512t branch from a557064 to 335024e Compare January 20, 2026 07:40

natto1784 marked this pull request as ready for review January 20, 2026 07:40

zephyrbot added area: Boards/SoCs area: MSPI area: Flash platform: TI K3 Texas Instruments Keystone 3 Processors area: Devicetree Binding PR modifies or adds a Device Tree binding platform: Infineon Infineon Technologies AG labels Jan 20, 2026

zephyrbot requested review from JarmouniA, billwatersiii, de-nordic, dnltz, glneo, gramsay0, jsbatch, mcatee-infineon, rghaddab, sreeramIfx, swift-tk, talih0, teburd and vaishnavachath January 20, 2026 07:42

zephyrbot assigned swift-tk Jan 20, 2026

swift-tk requested a review from anangl January 20, 2026 08:52

swift-tk reviewed Jan 20, 2026

View reviewed changes

Comment thread include/zephyr/drivers/mspi.h Outdated

swift-tk requested changes Jan 20, 2026

View reviewed changes

natto1784 force-pushed the mspi_s28hx512t branch from 335024e to 35b285d Compare January 20, 2026 09:30

zephyrbot requested a review from swift-tk January 20, 2026 09:32

JarmouniA previously approved these changes Apr 2, 2026

View reviewed changes

natto1784 dismissed JarmouniA’s stale review via 2adbdaa April 7, 2026 13:12

natto1784 force-pushed the mspi_s28hx512t branch from c08c84e to 2adbdaa Compare April 7, 2026 13:12

natto1784 requested a review from JarmouniA April 7, 2026 13:13

natto1784 force-pushed the mspi_s28hx512t branch from 2adbdaa to d6868c7 Compare April 8, 2026 08:54

natto1784 force-pushed the mspi_s28hx512t branch from d6868c7 to 3be4f22 Compare May 4, 2026 12:07

nordicjm requested changes May 8, 2026

View reviewed changes

swift-tk reviewed May 8, 2026

View reviewed changes

swift-tk mentioned this pull request May 8, 2026

Add XIP aperture start address to xip-config in mspi-device binding #108100

Closed

swift-tk previously approved these changes May 9, 2026

View reviewed changes

m-braunschweig and others added 14 commits May 11, 2026 17:22

mspi: cadence: allow dual byte opcodes

33a94e5

Cadence OSPI controller allows dual byte opcodes which are used by the flash on the bus for modes such as Octal SDR/DDR. Hence, allow configuration for dual byte opcodes. Signed-off-by: Amneesh Singh <amneesh@ti.com>

mspi: cadence: check for address length

06d068d

We configure address length as 'length - 1' in the controller. This currently does not check if the length is 0, in which case it causes unsigned integer underflow, so add a check for that. Signed-off-by: Amneesh Singh <amneesh@ti.com>

mspi: cadence: change CS timing configuration

68a1b27

Add a mechanism to configure the CS timing based on the configured clock frequency for the peripheral (SCLK) in reference clock cycles for the controller (RCLK). Signed-off-by: Amneesh Singh <amneesh@ti.com>

mspi: cadence: reset the STIG register during init

bdaf5e7

Reset the STIG register configuration in case it was set before initializing the driver. Signed-off-by: Amneesh Singh <amneesh@ti.com>

boards: am243x_evm: add nodes for OSPI and nor flash

dfc4940

Add Cadence MSPI controller and the S28HX512T NOR flash on its bus. Signed-off-by: Amneesh Singh <amneesh@ti.com>

boards: am62l_evm: add nodes for OSPI and nor flash

6cfeadd

Add Cadence MSPI controller and the S28HX512T NOR flash on its bus. Signed-off-by: Amneesh Singh <amneesh@ti.com>

Conversation

natto1784 commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing

Pending

Uh oh!

Uh oh!

swift-tk left a comment

Choose a reason for hiding this comment

Uh oh!

natto1784 commented Jan 20, 2026

Uh oh!

swift-tk commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

natto1784 commented Apr 7, 2026

Uh oh!

natto1784 commented May 4, 2026

Uh oh!

nordicjm left a comment

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!

sonarqubecloud Bot commented May 8, 2026

Quality Gate passed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

natto1784 May 8, 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!

swift-tk commented May 8, 2026

Uh oh!

natto1784 commented May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

swift-tk left a comment • 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!

sonarqubecloud Bot commented May 11, 2026

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

natto1784 commented Jan 19, 2026 •

edited

Loading

swift-tk commented Jan 20, 2026 •

edited

Loading

natto1784 May 8, 2026 •

edited

Loading

natto1784 commented May 8, 2026 •

edited

Loading

swift-tk left a comment •

edited

Loading