Add QSPI NOR flash driver for SF32LB #96085

gmarull · 2025-09-16T13:21:09Z

Add flash (QSPI NOR) driver for SF32LB

gmarull · 2025-10-01T12:14:06Z

Questions for @rabbitsaviola

Please review the driver in general
DMA code is not placed in RAM, but it's called from flash_sf32lb_mpi_qspi_nor_write, is it okay?
Clarify in general what is strictly needed to be placed in RAM
Clarify why using write chunk lengths > FIFO size does not work (L324); use, e.g., teslabs@43a7ae6 to check

rabbitsaviola · 2025-10-02T14:37:25Z

DMA code is not placed in RAM, but it's called from flash_sf32lb_mpi_qspi_nor_write, is it okay?

it's ok that DMA code is not placed in RAM as sequence command mode used.

Clarify why using write chunk lengths > FIFO size does not work (L324); use, e.g., teslabs@43a7ae6 to check

write doesn't work when chunk_len > FIFO size is because RBSIZE is set to 3 by L535. If RBSIZE is 0, chunk_len=128byte works well.

gmarull · 2025-10-14T12:43:04Z

last push: dropped row boundary config as it's not needed

JarmouniA · 2025-10-14T13:59:17Z

boards/sifli/sf32lb52_devkit_lcd/sf32lb52_devkit_lcd.dts

+
 	chosen {
-		zephyr,flash = &py25q128ha;
+		zephyr,flash = &nor;


zephyr,flash chosen is usually a node with nv-soc-flash compatible, and it is what's expected by several DT macros and MCUboot.

zephyr/include/zephyr/devicetree/fixed-partitions.h

Line 87 in fb7a74e

COND_CODE_1(DT_NODE_HAS_COMPAT(DT_GPARENT(node_id), soc_nv_flash), (DT_GPARENT(node_id)), \

zephyr/cmake/mcuboot.cmake

Line 144 in 4b3cb73

dt_prop(write_block_size PATH "${flash_node}" PROPERTY "write-block-size")

This soc has no "nv-soc-flash", it can only XIP from an external QSPI NOR. We may have to adjust these macros/cmake utils when needed I guess.

The difficulty here is keeping the QSPI NOR description aligned with what one would find in Linux (I think it is, except for the extra binding I had to create due to QSPI controllers not owning a proper device class) and making Zephyr happy at the same time if we use that same QSPI NOR for XIP. I'm open to better suggestions, but I think it's yet another case of Zephyr going on its own, making things just difficult.

You can have a look at

zephyr/boards/st/stm32h750b_dk/stm32h750b_dk-common.dtsi

Line 176 in 2e24a6f

ext_flash_ctrl: qspi-flash-controller@0 {

for an example of how this should be done in my opinion to work properly with what Zephyr MCUboot and DT Macros expect.

You can have a look at

zephyr/boards/st/stm32h750b_dk/stm32h750b_dk-common.dtsi

Line 176 in 2e24a6f

ext_flash_ctrl: qspi-flash-controller@0 {

for an example of how this should be done in my opinion to work properly with what Zephyr MCUboot and DT Macros except.

IMHO this is not a good devicetree description. You have 3 levels just to make Zephyr happy (quadspi, ext_flash_ctrl and then ext_flash). I doubt you would find this in parts with such capability in Linux (like ST MP1/2)

I doubt you would find this in parts with such capability in Linux (like ST MP1/2)

Yes, Linux is simpler indeed
https://github.com/STMicroelectronics/linux/blob/f01241fbba4d879fa770685629b49d42e904e43c/arch/arm/boot/dts/st/stm32h750i-art-pi.dts#L188

https://github.com/STMicroelectronics/linux/blob/f01241fbba4d879fa770685629b49d42e904e43c/arch/arm/boot/dts/st/stm32mp157d-ev1.dts#L587

I doubt you would find this in parts with such capability in Linux (like ST MP1/2)

Yes, Linux is simpler indeed https://github.com/STMicroelectronics/linux/blob/f01241fbba4d879fa770685629b49d42e904e43c/arch/arm/boot/dts/st/stm32h750i-art-pi.dts#L188

https://github.com/STMicroelectronics/linux/blob/f01241fbba4d879fa770685629b49d42e904e43c/arch/arm/boot/dts/st/stm32mp157d-ev1.dts#L587

The problem in Zephyr is that QSPI controllers have no proper driver class, so we currently have 1) a mess in drivers/flash and 2) devicetree zephyrisms to make things "work". To keep the controller/flash aligned with what one usually finds in Linux, I had to create the extra "memory" type node where you specify the memory-mapped absolute address.

I had to create the extra "memory" type node where you specify the memory-mapped absolute address.

You can probably use ranges for that as suggested here
#97413 (comment)

I had to create the extra "memory" type node where you specify the memory-mapped absolute address.

You can probably use ranges for that as suggested here #97413 (comment)

will give it a shot, thanks for the suggestion

ranges does not work as expected because

config FLASH_BASE_ADDRESS hex "Flash Base Address" default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_FLASH)) if (XIP && (ARM || ARM64)) || !ARM

And since the flash@0 parent node has #size-cells set to 0, range translation will not happen, keeping FLASH_BASE_ADDRESS set to 0. Instead, I've now changed the flash base address in the SoC defconfig, so it points to the memory-mapped address. This way we keep aligned with Linux (where the '0' means SPI slave 0, as it's a child of an SPI bus) and we can skip devicetree zephyrisms.

dts/bindings/mtd/jedec,qspi-nor.yaml

JarmouniA · 2025-10-14T14:04:39Z

drivers/flash/flash_sf32lb_mpi_qspi_nor.c

+	static const struct flash_sf32lb_mpi_qspi_nor_config config##n = {                         \
+		.params =                                                                          \
+			{                                                                          \
+				.write_block_size = 4U,                                            \


Should be set in flash device node via nv-soc-flash compatible's write-block-size property.

Related discussion #95152 (comment)

As mentioned above, this is already known because we always execute from a QSPI NOR (not an internal NV flash where these values may differ depending on SoC)

But the driver can be used with different NOR chips, isn't write-block-size a NOR chip property?

I think it should actually be set to 1 (as in spi_nor.c driver, which deals with jedec compliant devices), are there any SPI NORs requiring something else?

I think it should actually be set to 1

Ok, but let's set it via DT instead of hardcoding it in the driver.

are there any SPI NORs requiring something else?

I can't say

I think it should actually be set to 1

Ok, but let's set it via DT instead of hardcoding it in the driver.

I don't think this is a variable attribute in JEDEC compliant SPI NORs (as you can see as well in spi_nor.c), it could actually be made a driver-level static variable.

JarmouniA · 2025-10-14T14:08:37Z

drivers/flash/flash_sf32lb_mpi_qspi_nor.c

+		.params =                                                                          \
+			{                                                                          \
+				.write_block_size = 4U,                                            \
+				.erase_value = 0xFFU,                                              \


Ditto, with erase-block-size

Related discussion #96443 (comment)

On SPI NOR devices, erase size is not strictly fixed, you can erase per sector, block or entire chip.

gmarull · 2025-10-14T15:27:52Z

last push: moved flash nor parameters to module-level variable, same as in spi_nor.c (and fixed write block size).

soc/sifli/sf32/sf32lb52x/Kconfig.defconfig

Add compatible for SiFli SF32LB MPI operating as QSPI NOR controller. Signed-off-by: Gerard Marull-Paretas <[email protected]>

Compatible should be set at board level, depending on how MPI IP is used (e.g. NOR, NAND, PSRAM). Signed-off-by: Gerard Marull-Paretas <[email protected]>

No longer used. Signed-off-by: Gerard Marull-Paretas <[email protected]>

Ideally we should be able to just use jedec,spi-nor (to keep Linux compatibility), but, QSPI controllers live in a limbo in Zephyr. Adding this binding won't make things worse than they are. Signed-off-by: Gerard Marull-Paretas <[email protected]>

Command was missing. Signed-off-by: Gerard Marull-Paretas <[email protected]>

So we can obtain a register address (as hex) given its name. Signed-off-by: Gerard Marull-Paretas <[email protected]>

Take it from the chosen flash node parent (MPI controller) 'nor' register, which contains the memory mapped address for the NOR flash. Signed-off-by: Gerard Marull-Paretas <[email protected]>

Initial driver for the SF32LB MPI accessing QSPI NOR flash devices. Signed-off-by: Gerard Marull-Paretas <[email protected]>

So that flash driver can be used (MPI2 works in QSPI mode). Signed-off-by: Gerard Marull-Paretas <[email protected]>

Allow obtaining SFDP parameters using SF32LB driver. Signed-off-by: Gerard Marull-Paretas <[email protected]>

sonarqubecloud · 2025-10-14T20:30:47Z

Quality Gate passed

Issues
0 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

gmarull requested a review from cameled September 16, 2025 13:21

github-actions bot added manifest manifest-hal_sifli DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Sep 16, 2025

gmarull force-pushed the sf32lb52x-flash branch 3 times, most recently from ce5be5e to 7335cff Compare September 17, 2025 19:05

gmarull force-pushed the sf32lb52x-flash branch from 7335cff to 9c0f2b4 Compare October 1, 2025 08:35

zephyrproject-rtos deleted a comment from github-actions bot Oct 1, 2025

gmarull force-pushed the sf32lb52x-flash branch from 9c0f2b4 to 488686a Compare October 1, 2025 08:46

gmarull removed the DNM (manifest) This PR should not be merged (controlled by action-manifest) label Oct 1, 2025

gmarull force-pushed the sf32lb52x-flash branch 3 times, most recently from 5218a60 to 003a034 Compare October 1, 2025 12:10

gmarull marked this pull request as ready for review October 1, 2025 12:10

zephyrbot added area: MEMC area: Boards/SoCs platform: SF32LB area: Samples Samples area: Flash area: Devicetree Bindings labels Oct 1, 2025

zephyrbot requested review from JarmouniA, de-nordic, kartben, nashif and rghaddab October 1, 2025 12:12

zephyrbot assigned de-nordic Oct 1, 2025

gmarull added the DNM This PR should not be merged (Do Not Merge) label Oct 1, 2025

gmarull requested a review from fabiobaltieri October 14, 2025 12:43

fabiobaltieri previously approved these changes Oct 14, 2025

View reviewed changes

JarmouniA reviewed Oct 14, 2025

View reviewed changes

gmarull dismissed fabiobaltieri’s stale review via f8292de October 14, 2025 15:27

gmarull force-pushed the sf32lb52x-flash branch from ba3f8e5 to f8292de Compare October 14, 2025 15:27

gmarull requested a review from fabiobaltieri October 14, 2025 15:28

gmarull force-pushed the sf32lb52x-flash branch 2 times, most recently from 178403c to 8274aca Compare October 14, 2025 18:59

JarmouniA reviewed Oct 14, 2025

View reviewed changes

soc/sifli/sf32/sf32lb52x/Kconfig.defconfig Outdated Show resolved Hide resolved

gmarull added 10 commits October 14, 2025 22:02

dts: bindings: mtd: add sifli,sf32lb-mpi-qspi-nor

f0fe7b9

Add compatible for SiFli SF32LB MPI operating as QSPI NOR controller. Signed-off-by: Gerard Marull-Paretas <[email protected]>

dts: arm: sifli: sf32lb52x: adjust mpi1/2 defaults

1c2ac80

Compatible should be set at board level, depending on how MPI IP is used (e.g. NOR, NAND, PSRAM). Signed-off-by: Gerard Marull-Paretas <[email protected]>

dts: bindings: memory-controllers: drop sifli,sf32lb-mpi

9826ac6

No longer used. Signed-off-by: Gerard Marull-Paretas <[email protected]>

dts: bindings: mtd: add jedec,qspi-nor

f4c3a72

Ideally we should be able to just use jedec,spi-nor (to keep Linux compatibility), but, QSPI controllers live in a limbo in Zephyr. Adding this binding won't make things worse than they are. Signed-off-by: Gerard Marull-Paretas <[email protected]>

drivers: flash: spi_nor: add SPI_NOR_CMD_BE_32K_4B

51d7401

Command was missing. Signed-off-by: Gerard Marull-Paretas <[email protected]>

scripts: kconfig: kconfigfunctions: add dt_node_reg_addr_by_name_hex

a11603c

So we can obtain a register address (as hex) given its name. Signed-off-by: Gerard Marull-Paretas <[email protected]>

soc: sifli: sf32: sf32lb52x: configure flash base address

b545af0

Take it from the chosen flash node parent (MPI controller) 'nor' register, which contains the memory mapped address for the NOR flash. Signed-off-by: Gerard Marull-Paretas <[email protected]>

drivers: flash: sf32lb_mpi_qspi_nor: add initial driver

014a0d5

Initial driver for the SF32LB MPI accessing QSPI NOR flash devices. Signed-off-by: Gerard Marull-Paretas <[email protected]>

boards: sf32lb52_devkit_lcd: adjust memory and QSPI NOR parameters

933c0d1

So that flash driver can be used (MPI2 works in QSPI mode). Signed-off-by: Gerard Marull-Paretas <[email protected]>

samples: drivers: jesd216: add support for SF32LB

e601bd6

Allow obtaining SFDP parameters using SF32LB driver. Signed-off-by: Gerard Marull-Paretas <[email protected]>

gmarull force-pushed the sf32lb52x-flash branch from 8274aca to e601bd6 Compare October 14, 2025 20:04

gmarull requested a review from JarmouniA October 14, 2025 20:04

zephyrbot added area: Kconfig area: Devicetree labels Oct 14, 2025

zephyrbot requested review from decsny, mbolivar, rruuaanng and tejlmand October 14, 2025 20:06

Add QSPI NOR flash driver for SF32LB #96085

Are you sure you want to change the base?

Add QSPI NOR flash driver for SF32LB #96085

Uh oh!

Conversation

gmarull commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gmarull commented Oct 1, 2025

Uh oh!

rabbitsaviola commented Oct 2, 2025

Uh oh!

gmarull commented Oct 14, 2025

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!

JarmouniA Oct 14, 2025 • 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!

JarmouniA Oct 14, 2025 • 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!

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!

gmarull Oct 14, 2025 • 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!

gmarull commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

sonarqubecloud bot commented Oct 14, 2025

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

gmarull commented Sep 16, 2025 •

edited

Loading

JarmouniA Oct 14, 2025 •

edited

Loading

JarmouniA Oct 14, 2025 •

edited

Loading

gmarull Oct 14, 2025 •

edited

Loading

gmarull commented Oct 14, 2025 •

edited

Loading