stm32H7 external NOR ospi flash in memorymapped mode #62349

FRASTM · 2023-09-06T14:09:41Z

This PR completes the #61082

to make the stm32h7 or stm32u5 with octo-NOR flash tested when the external NOR octoFlash is configured in MemoryMapped mode.

CONFIG_STM32_MEMMAP is enabling the external NOR flash MemoryMapped mode.

CONFIG_STM32_MEMMAP_EXT_FLASH_BASE_ADDRESS is defining the external nor flash base address

FRASTM · 2023-09-06T14:10:08Z

Tested with stm32h7b3i_dk in MemoryMapped mode
requires mpu region definition
Writing few bytes in memorymapped mode is still possible

GeorgeCGV · 2023-09-08T06:38:08Z

@FRASTM, when used with a bootloader (i.e. MCU-Boot) shouldn't init be skipped?

If I understand it correctly:

bootloader inits devices
performs copy/move operations
maps the memory
jumps into it

The FW starts after the jump. There, the init sequence is going to be performed for all device and sys nodes (happens twice if the device is used in the FW and bootloader).
In that case, the map shall be already enabled (in the bootloader, as we "run" from it) and not interrupted (i.e. via a clock re-init #57337 (if using it), xSPI re-init (as happens here)).

Or did I miss something?

FRASTM · 2023-09-08T07:51:34Z

Or did I miss something?

No, as you say I could face a pb of clocking.
However in the sample application (a simple "hello world") in the external NOR flash, there is no xSPI node.
What I see is :

the boot loader is correctly going to do_boot() in ..//bootloader/mcuboot/boot/zephyr/main.c
the reset vector is correctly going to the external NOR,
the PC is correctly executing the application which is downloaded (with STM32CubeProgrammer) in the external NOR flash but nothing on the output console. I am expecting "hello world from NOR flash"

*** Booting Zephyr OS build zephyr-v3.4.0-3121-g4df7ebf34d86 ***
I: Starting Direct-XIP bootloader
I: Image 0 Primary slot: Image not found
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x0
I: Jumping to the image slot

GeorgeCGV · 2023-09-08T11:00:26Z

there is no xSPI node.

By xSPI I meant OSPI/QSPI.

I am saying that the flash is currently re-initialized after the jump. It shouldn't happen when we are executing from it. Similarly to what is done here .

Also, #57337 kills the PLL1 clock during clock initialization (after jump). That affects XIP if the flash is clocked using it (default).

FRASTM · 2023-09-11T12:54:09Z

In the sample application which is compiled linked and written for the external NOR flash, there is no oSPI flash driver (no oSPI peripheral) This is just a hello_word or a basic/blinky. About PLL and system clock I cannot tell. Once jumped to the NOR I cannot debug anymore after instruction
((void (*)(void))vt->reset)();
with vt = {msp = 0x24001100, reset = 0x9000173f}

   0x9000173e:	movs	r0, #16
   0x90001740:	msr	BASEPRI, r0
   0x90001744:	ldr	r0, [pc, #36]	; (0x9000176c)
   0x90001746:	mov.w	r1, #2112	; 0x840
   0x9000174a:	adds	r0, r0, r1
   0x9000174c:	msr	PSP, r0
   0x90001750:	mrs	r0, CONTROL
   0x90001754:	movs	r1, #2

ajhemphill91 · 2023-09-14T21:28:16Z

I was able to adapt samples/application_development/code_relocation_nocopy to work with the stm32h7b3i_dk based on this.

Created a stm32h7b3i_dk.conf in the boards dir there, containing:

CONFIG_FLASH=y
CONFIG_HAVE_CUSTOM_LINKER_SCRIPT=n
CONFIG_SPI=n

Our use-case was to load image data into the external flash and have it accessible to the user application. For this any external flash destined data is defined const inside of a file to be targeted by code relocation.

Then modify CMakeLists.txt to point the code relocation to the appropriate memory regions:

# Previously was EXTFLASH_TEXT, due to the linkerfile being used in this sample for nrf5340
zephyr_code_relocate(FILES src/ext_code.c LOCATION QSPI_TEXT NOCOPY)

# Also move .rodata section (const-defined image data)
zephyr_code_relocate(FILES src/ext_code.c LOCATION QSPI_RODATA NOCOPY)

Finally for any code/rodata relocated to external flash, you need a external loader configured appropriately to flash it. I was able to use the default MX25LM51245G_STM32H7B3I-DISCO.stldr provided with STM32CubeProgrammer. After the above changes, flashing the zephyr.hex with STM32CubeProgrammer properly uploads to the external flash.

erwango · 2023-09-15T07:05:00Z

I was able to adapt samples/application_development/code_relocation_nocopy to work with the stm32h7b3i_dk based on this.

Quite interesting! Thanks @ajhemphill91 for sharing this work.
Would you be able to open an issue (or share a pull request) to discuss this more in details?

FRASTM · 2023-09-15T10:45:18Z

My test is to build the mcuboot in the internal flash (0x8000000) and a sample application for the NOR flash
west build -p auto -b stm32h735g_disco samples/basic/blinky --sysbuild -- -DCONFIG_XIP=y -DCONFIG_FLASH_BASE_ADDRESS=0x90000000 -DSB_CONFIG_BOOTLOADER_MCUBOOT=y
I have to set CONFIG_BOOT_DIRECT_XIP=y in the ../bootloader/mcuboot/boot/zephyr/boards/stm32h735g_disco.conf
(or stm32h7b3i_dk as well)

I am using the STM32CubeProgrammer to flash the mcuboot @0x8000000 and the zephyr.signed.bin @ 0x90000000

*** Booting Zephyr OS build zephyr-v3.4.0-3599-g09ce3a6b8e3e ***
I: Starting Direct-XIP bootloader
I: Image 0 Primary slot: Image not found
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x0
I: Jumping to the image slot

Code is running in the external NOR flash but fails at 0x90000f74 in arm_core_mpu_enable
--> disabling the MPU for stm32h7

diff --git a/soc/arm/st_stm32/stm32h7/Kconfig.series b/soc/arm/st_stm32/stm32h7/Kconfig.series
index 061a23856c..ddf7a77075 100644
--- a/soc/arm/st_stm32/stm32h7/Kconfig.series
+++ b/soc/arm/st_stm32/stm32h7/Kconfig.series
@@ -10,9 +10,7 @@ config SOC_SERIES_STM32H7X
 	select CPU_HAS_FPU
 	select SOC_FAMILY_STM32
 	select HAS_STM32CUBE
-	select CPU_HAS_ARM_MPU
 	select HAS_SWO
 	select USE_STM32_HAL_CORTEX
-	select CPU_HAS_CUSTOM_FIXED_SOC_MPU_REGIONS
 	help
 	  Enable support for STM32H7 MCU series

PLL1 is not re started after the jump to the external NOR, reset bu t keep the clock scheme.
(the octospi controller is also clocked by the PLL1)

diff --git a/drivers/clock_control/clock_stm32_ll_h7.c b/drivers/clock_control/clock_stm32_ll_h7.c
index c95d8ab129..d20ff56efc 100644
--- a/drivers/clock_control/clock_stm32_ll_h7.c
+++ b/drivers/clock_control/clock_stm32_ll_h7.c
@@ -660,6 +660,12 @@ __unused
 static int set_up_plls(void)
 {
 #if defined(STM32_PLL_ENABLED) || defined(STM32_PLL2_ENABLED) || defined(STM32_PLL3_ENABLED)
+
+	/* Skip if PLL1 is already configured */
+	if (LL_RCC_PLL1_IsReady() && LL_RCC_PLL1_IsEnabled()) {
+		return 0;
+	}
+
 	int r;
 	uint32_t vco_input_range;
 	uint32_t vco_output_range;

and application is executed from the external NOR :

*** Booting Zephyr OS build zephyr-v3.4.0-3601-g703daf557a5d ***
I: Starting Direct-XIP bootloader
I: Image 0 Primary slot: Image not found
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x0
�*** Booting Zephyr OS build zephyr-v3.4.0-3601-g703daf557a5d ***
Hello World! from external flash  stm32h735g_disco

GeorgeCGV · 2023-11-27T08:57:20Z

drivers/flash/flash_stm32_ospi.c

+		s_command.Instruction = (dev_cfg->data_mode == OSPI_SPI_MODE)
+					? ((stm32_ospi_hal_address_size(dev) ==
+					HAL_OSPI_ADDRESS_24_BITS)
+						? SPI_NOR_CMD_PP
+						: SPI_NOR_CMD_PP_4B)
+					: SPI_NOR_OCMD_PAGE_PRG;


Why not using the write_opcode and base lines configuration on the opcode?

do you suggest

if (dev_cfg->data_rate == OSPI_STR_TRANSFER) { s_command.Instruction = (dev_cfg->data_mode == OSPI_SPI_MODE) ? ((stm32_ospi_hal_address_size(dev) == HAL_OSPI_ADDRESS_24_BITS) ? SPI_NOR_CMD_PP : SPI_NOR_CMD_PP_4B) : SPI_NOR_OCMD_PAGE_PRG; } else { s_command.Instruction = write_opcode;

if (dev_cfg->data_rate == OSPI_STR_TRANSFER) { s_command.Instruction = (dev_cfg->data_mode == OSPI_SPI_MODE) ? dev_data->write_opcode : SPI_NOR_OCMD_PAGE_PRG; } else { s_command.Instruction = SPI_NOR_OCMD_PAGE_PRG;

The spi_nor_process_bfp sets write_opcode accounting to mode if it is not set from DT. The address width is taken into consideration as well.

Also for write and read the lines might need adaptation not only based on mode, but also on the opcode. Something like:

write

if (dev_cfg->data_mode == OSPI_OPI_MODE) { cmd->AddressSize = HAL_OSPI_ADDRESS_32_BITS; cmd->InstructionSize = HAL_OSPI_INSTRUCTION_16_BITS; cmd->InstructionMode = HAL_OSPI_INSTRUCTION_8_LINES; cmd->AddressMode = HAL_OSPI_ADDRESS_8_LINES; cmd->DataMode = HAL_OSPI_DATA_8_LINES; } else { cmd->AddressSize = stm32_ospi_hal_address_size(dev); cmd->InstructionSize = HAL_OSPI_INSTRUCTION_8_BITS; switch (cmd->Instruction) { case SPI_NOR_CMD_PP_4B: __fallthrough; case SPI_NOR_CMD_PP: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE; cmd->AddressMode = HAL_OSPI_ADDRESS_1_LINE; cmd->DataMode = HAL_OSPI_DATA_1_LINE; break; case SPI_NOR_CMD_PP_1_1_4_4B: __fallthrough; case SPI_NOR_CMD_PP_1_1_4: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE; cmd->AddressMode = HAL_OSPI_ADDRESS_1_LINE; cmd->DataMode = HAL_OSPI_DATA_4_LINES; break; case SPI_NOR_CMD_PP_1_4_4_4B: __fallthrough; case SPI_NOR_CMD_PP_1_4_4: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE; cmd->AddressMode = HAL_OSPI_ADDRESS_4_LINES; cmd->DataMode = HAL_OSPI_DATA_4_LINES; break; default: return -ENOTSUP; } }

read

/* initially set lines by mode */ switch (dev_cfg->data_mode) { case OSPI_QUAD_MODE: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_4_LINES; cmd->AddressMode = HAL_OSPI_ADDRESS_4_LINES; cmd->DataMode = HAL_OSPI_DATA_4_LINES; break; case OSPI_DUAL_MODE: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_2_LINES; cmd->AddressMode = HAL_OSPI_ADDRESS_2_LINES; cmd->DataMode = HAL_OSPI_DATA_2_LINES; break; default: return -ENOTSUP; } /* adapt by read mode */ switch (dev_data->read_mode) { case JESD216_MODE_112: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE; cmd->AddressMode = HAL_OSPI_ADDRESS_1_LINE; cmd->DataMode = HAL_OSPI_DATA_2_LINES; break; case JESD216_MODE_122: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE; cmd->AddressMode = HAL_OSPI_ADDRESS_2_LINES; cmd->DataMode = HAL_OSPI_DATA_2_LINES; break; case JESD216_MODE_114: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE; cmd->AddressMode = HAL_OSPI_ADDRESS_1_LINE; cmd->DataMode = HAL_OSPI_DATA_4_LINES; break; case JESD216_MODE_144: cmd->InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE; cmd->AddressMode = HAL_OSPI_ADDRESS_4_LINES; cmd->DataMode = HAL_OSPI_DATA_4_LINES; break; default: return -ENOTSUP; }

Similar is done for normal operations. Therefore, some driver refactoring could be beneficial.

GeorgeCGV · 2023-11-27T09:00:12Z

drivers/flash/flash_stm32_ospi.c

+	s_command.Instruction = (dev_cfg->data_rate == OSPI_STR_TRANSFER)
+				? ((dev_cfg->data_mode == OSPI_SPI_MODE)
+					? ((stm32_ospi_hal_address_size(dev) ==
+					HAL_OSPI_ADDRESS_24_BITS)
+						? SPI_NOR_CMD_READ_FAST
+						: SPI_NOR_CMD_READ_FAST_4B)
+					: SPI_NOR_OCMD_RD)
+				: SPI_NOR_OCMD_DTR_RD;


Why not using read_opcode and base other configuration on available read_mode, data_mode, data_rate?

Why not using read_opcode and base other configuration on available read_mode, data_mode, data_rate?

do you suggest :

s_command.Instruction = (dev_cfg->data_rate == OSPI_STR_TRANSFER) ? ((dev_cfg->data_mode == OSPI_SPI_MODE) ? ((stm32_ospi_hal_address_size(dev) == HAL_OSPI_ADDRESS_24_BITS) ? SPI_NOR_CMD_READ_FAST : SPI_NOR_CMD_READ_FAST_4B) : dev_data->read_opcode) : SPI_NOR_OCMD_DTR_RD;

Something like

if (dev_cfg->data_rate == OSPI_DTR_TRANSFER) { /* DTR transfer rate (==> Octal mode) */ cmd->Instruction = SPI_NOR_OCMD_DTR_RD; cmd->DummyCycles = SPI_NOR_DUMMY_RD_OCTAL_DTR; } else { /* STR transfer rate */ if (dev_cfg->data_mode == OSPI_OPI_MODE) { /* OPI and STR */ cmd->Instruction = SPI_NOR_OCMD_RD; cmd->DummyCycles = SPI_NOR_DUMMY_RD_OCTAL; } else { /* use SFDP:BFP read instruction */ cmd->Instruction = dev_data->read_opcode; cmd->DummyCycles = dev_data->read_dummy_cycles; } }

At init stage the read opcode, dummy cycles, write opcode are supposed to be set. Some from SFDP:BFP and/or DT.

FRASTM · 2024-01-23T14:11:15Z

rebasing on d7873e2
there is a pb with MPU on the stm32h7 : when the memmap mode of the external octo-flash is enabled, the read operation performed by a memcpy results in a z_arm_usage_fault.
However reading the content of the flash @0x90000000 is correct
0x90000000: 0x96f3b83d 0x00000000 0x00000400 0x00005808

--> requires a new MPU region to be specified for the ext mem flash

ext_flash: ext_flash@90000000 {
		compatible = "zephyr,memory-region";
		device_type = "memory";
		reg = <0x90000000 DT_SIZE_M(64)>;
		zephyr,memory-region = "EXTFLASH";
		zephyr,memory-attr = <( DT_MEM_ARM(ATTR_MPU_IO) )>;
};

FRASTM · 2024-01-23T15:04:21Z

rebase on d7873e2
requires #61082

Define the lfs1 partition in the mcu internal flash
west build -p always -b stm32h7b3i_dk samples/subsys/fs/littlefs/ --sysbuild -- -DCONFIG_FLASH_BASE_ADDRESS=0x90000000 -DSB_CONFIG_BOOTLOADER_MCUBOOT=y
Build/link the samples/subsys/fs/littlefs/ application for the external octo flash memory for its slot1 partition
sign the application
west sign -t imgtool -- --key ../bootloader/mcuboot/root-rsa-2048.pem
Flash the mcu_boot build/mcuboot/zephyr/zephyr.bin at boot partition
Flash the application build/littlefs/zephyr/zephyr.signed.bin at slot1 partition (in external octo-flash)

FRASTM · 2024-01-23T15:04:58Z

*** Booting Zephyr OS build zephyr-v3.5.0-3960-gf6dfcb10c7df ***
I: Starting Direct-XIP bootloader
I: Image 0 Primary slot: Image not found
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x0
I: Jumping to the image slot
I: NOR init'd in MemMapped mode

I: littlefs partition at /lfs1
I: LittleFS version 2.5, disk version 2.0
I: FS at flash-controller@52002000:0xe0000 is 8 0x2000-byte blocks with 512 cyce
I: sizes: rd 256 ; pr 256 ; ca 4096 ; la 256
I: Automount /lfs1 succeeded
*** Booting Zephyr OS build zephyr-v3.5.0-3960-gf6dfcb10c7df ***
Sample program to r/w files on littlefs
Area 0 at 0xe0000 on flash-controller@52002000 for 65536 bytes
/lfs1 automounted
/lfs1: bsize = 256 ; frsize = 8192 ; blocks = 8 ; bfree = 6

Listing dir /lfs1 ...
[FILE] boot_count (size = 1)
[FILE] pattern.bin (size = 547)
/lfs1/boot_count read count:11 (bytes: 1)
/lfs1/boot_count write new boot count 12: [wr:1]
------ FILE: /lfs1/pattern.bin ------
...
I: /lfs1 unmounted
/lfs1 unmount: 0

drivers/flash/flash_stm32.c

For the flash driver, the base address is the MCU internal flash address (usualyy 0x8000000). This PR gets the that address from the device tree node "st,stm32-nv-flash" instead of relying on the CONFIG_FLASH_BASE_ADDRESS which might differ when building for another flash memory. Signed-off-by: Francois Ramu <[email protected]>

This CONFIG_STM32_MEMMAP is for enabling the MemoryMapped mode on external octo or quad spi memory. In this case, the flash_stm32_read is done in mem map mode the flash_stm32_erase is not available. Signed-off-by: Francois Ramu <[email protected]>

Enable the MemoryMapped Mode for the stm32 octoFlash driver Configure the Flash in MemoryMapped to use in XiP mode. With this mode the erase and write are not supported. Address and size are given by the DTS register property. Signed-off-by: Francois Ramu <[email protected]>

This change is aborting the memoryMapped mode of the octo-flash before erasing or writing the NOR. Operations are performed in command mode. Reading is always performed in MemoryMapped mode (memcopy) Signed-off-by: Francois Ramu <[email protected]>

Enable the DCACHE1 in INCR burt mode to allow writing to the external NOR octoFlash when in MemoryMapped mode Signed-off-by: Francois Ramu <[email protected]>

Define the Device tree of the b_u585i_iot02a disco kit to access the external NOR octo-flash in MemoryMapped mode for XiP Signed-off-by: Francois Ramu <[email protected]>

Gives a sample to execute the little fs on external memory map (XiP) where the lfs1 partition is in internal mcu flash The application is built/linked/stored in the external NOR flash on slot1 partition. Signed-off-by: Francois Ramu <[email protected]>

Skip the PLL1 init if it is already running, this will avoid disabling the PLL when running after a jump from mcuboot Signed-off-by: Francois Ramu <[email protected]>

Define the MPU attribute to be ATTR_MPU_IO for the qspi region, starting at 0x90000000 of the stm32h7 serie. Signed-off-by: Francois Ramu <[email protected]>

Define the Device tree of the stm32h7b3i_dk disco board to access the external NOR octo-flash in MemoryMapped mode for XiP Set openocd runner for debugging. Signed-off-by: Francois Ramu <[email protected]>

Gives a sample to execute the little fs on external memory map (XiP) where the lfs1 partition is in internal mcu flash Signed-off-by: Francois Ramu <[email protected]>

GeorgeCGV · 2024-01-31T17:20:08Z

drivers/flash/flash_stm32_ospi.c

+	if (stm32_ospi_is_memorymap(dev)) {
+		/* If the Flash is in MemoryMapped mode, abort it and continue */
+		LOG_INF("MemoryMap : disable before write");
+		if (stm32_ospi_abort_memmap(dev) != 0) {
+			LOG_ERR("MemoryMap not aborted correctly");
+			return -EIO;
+		}
+	}


It would be fatal when accidently writing while running in XIP.

I guess the idea here is to allow bootloader to exit memory map mode that is entered in OSPI init to allow erase & write operations.

In that case, the CONFIG_MCUBOOT is going to be set to y for the mcuboot while the app won't have it. Extra macro could be used to prevent memory map mode exit in the application code.

An alternative, protect write abortion with extra Kconfig option that the application can set.

Another alternative is to run flash driver from RAM. Not proposed today as not yet fully functional on our side, but this is an option used by others.

I am not sure what is the footprint on RAM in that case. But having flash driver in ram might not be required for all applications. After switching to the slot in o/qSPI. I assume it is rare when writing and erasing are required outside of the bootloader (unless update slot is there as well).

erwango · 2024-01-22T13:07:10Z

drivers/flash/flash_stm32_ospi.c

@@ -989,6 +1127,19 @@ static int flash_stm32_ospi_erase(const struct device *dev, off_t addr,
 		return -ENOTSUP;
 	}

+#ifdef CONFIG_STM32_MEMMAP


Requires relocation

drivers/flash/flash_stm32_ospi.c

erwango · 2024-02-01T08:01:09Z

drivers/flash/flash_stm32_ospi.c

+	if (stm32_ospi_is_memorymap(dev)) {
+		/* If the Flash is in MemoryMapped mode, abort it and continue */
+		LOG_INF("MemoryMap : disable before write");
+		if (stm32_ospi_abort_memmap(dev) != 0) {
+			LOG_ERR("MemoryMap not aborted correctly");
+			return -EIO;
+		}
+	}


Another alternative is to run flash driver from RAM. Not proposed today as not yet fully functional on our side, but this is an option used by others.

FRASTM · 2024-02-20T08:31:01Z

see #68607

FRASTM requested review from erwango, nashif, de-nordic, MaureenHelm and galak as code owners September 6, 2023 14:09

zephyrbot added area: Devicetree Binding PR modifies or adds a Device Tree binding platform: STM32 ST Micro STM32 area: Flash labels Sep 6, 2023

zephyrbot requested review from ABOSTM, Desvauxm-st, gautierg-st and GeorgeCGV September 6, 2023 14:10

zephyrbot assigned erwango Sep 6, 2023

FRASTM added Release Notes Required Release notes required for this change area: OSPI Octo SPI DNM This PR should not be merged (Do Not Merge) and removed area: Flash area: Devicetree Binding PR modifies or adds a Device Tree binding labels Sep 6, 2023

FRASTM force-pushed the stm32h7_ospi_memmap branch from dbe0a43 to 3f1c537 Compare September 15, 2023 14:16

zephyrbot added area: Devicetree Binding PR modifies or adds a Device Tree binding area: Flash labels Sep 15, 2023

FRASTM mentioned this pull request Sep 15, 2023

drivers: stm32 qspi flash driver enables the MemoryMapped mode #61122

Closed

FRASTM force-pushed the stm32h7_ospi_memmap branch from dd54d1c to 5a91280 Compare November 6, 2023 16:14

GeorgeCGV reviewed Nov 27, 2023

View reviewed changes

FRASTM force-pushed the stm32h7_ospi_memmap branch from 5a91280 to 045dbbb Compare December 12, 2023 14:58

FRASTM force-pushed the stm32h7_ospi_memmap branch from 045dbbb to f6dfcb1 Compare January 23, 2024 14:57

FRASTM force-pushed the stm32h7_ospi_memmap branch 3 times, most recently from 588b336 to 61e3968 Compare January 24, 2024 12:00

GeorgeCGV reviewed Jan 29, 2024

View reviewed changes

drivers/flash/flash_stm32.c Outdated Show resolved Hide resolved

FRASTM force-pushed the stm32h7_ospi_memmap branch from 61e3968 to 00ca393 Compare January 29, 2024 15:48

FRASTM added 11 commits January 29, 2024 17:10

soc: arm: stm32u5 device with DCACHE for writing to NOR flash

5e10f8a

Enable the DCACHE1 in INCR burt mode to allow writing to the external NOR octoFlash when in MemoryMapped mode Signed-off-by: Francois Ramu <[email protected]>

boards: arm: stm32u585 disco kit for XiP on external octoflash

84aca6d

Define the Device tree of the b_u585i_iot02a disco kit to access the external NOR octo-flash in MemoryMapped mode for XiP Signed-off-by: Francois Ramu <[email protected]>

drivers: clock control of the stm32h7 skips pll1 re-init

8b6b9ab

Skip the PLL1 init if it is already running, this will avoid disabling the PLL when running after a jump from mcuboot Signed-off-by: Francois Ramu <[email protected]>

dts: arm: stm32h7 MPU attribute for the external Memory

1b1e047

Define the MPU attribute to be ATTR_MPU_IO for the qspi region, starting at 0x90000000 of the stm32h7 serie. Signed-off-by: Francois Ramu <[email protected]>

boards: arm: stm32h7b3 disco kit for XiP on external octoflash

d9a03a8

Define the Device tree of the stm32h7b3i_dk disco board to access the external NOR octo-flash in MemoryMapped mode for XiP Set openocd runner for debugging. Signed-off-by: Francois Ramu <[email protected]>

samples: subsys: fs_little fs on stm32h7b3 disco in xip

c54eca3

Gives a sample to execute the little fs on external memory map (XiP) where the lfs1 partition is in internal mcu flash Signed-off-by: Francois Ramu <[email protected]>

FRASTM force-pushed the stm32h7_ospi_memmap branch from 00ca393 to c54eca3 Compare January 29, 2024 16:12

GeorgeCGV reviewed Jan 31, 2024

View reviewed changes

erwango reviewed Feb 1, 2024

View reviewed changes

FRASTM closed this Feb 20, 2024

GeorgeCGV mentioned this pull request Jul 9, 2024

drivers: clock_control: stm32h7: disabling PLL when executing in memory map mode leads to a stall #75653

Closed

stm32H7 external NOR ospi flash in memorymapped mode #62349

stm32H7 external NOR ospi flash in memorymapped mode #62349

Uh oh!

Conversation

FRASTM commented Sep 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FRASTM commented Sep 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GeorgeCGV commented Sep 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FRASTM commented Sep 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GeorgeCGV commented Sep 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FRASTM commented Sep 11, 2023

Uh oh!

ajhemphill91 commented Sep 14, 2023

Uh oh!

erwango commented Sep 15, 2023

Uh oh!

FRASTM commented Sep 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GeorgeCGV Jan 31, 2024 • 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!

FRASTM commented Jan 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FRASTM commented Jan 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FRASTM commented Jan 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GeorgeCGV Feb 1, 2024 • 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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FRASTM commented Feb 20, 2024

Uh oh!

Uh oh!

FRASTM commented Sep 6, 2023 •

edited

Loading

FRASTM commented Sep 6, 2023 •

edited

Loading

GeorgeCGV commented Sep 8, 2023 •

edited

Loading

FRASTM commented Sep 8, 2023 •

edited

Loading

GeorgeCGV commented Sep 8, 2023 •

edited

Loading

FRASTM commented Sep 15, 2023 •

edited

Loading

GeorgeCGV Jan 31, 2024 •

edited

Loading

FRASTM commented Jan 23, 2024 •

edited

Loading

FRASTM commented Jan 23, 2024 •

edited

Loading

FRASTM commented Jan 23, 2024 •

edited

Loading

GeorgeCGV Feb 1, 2024 •

edited

Loading