stm32h7rs run application in external flash memory XIP #88052
Conversation
|
Run the samples/application_development/code_relocation_nocopy/ (Be sure to erase internal and external memory partitions and to download the zephyr.hex file) |
|
With the samples/boards/st/hello_world_xip/ the goal is to place the mcuboot in the internalm flash memory and to jump to a zephyr application executed in the external flash
|
FRASTM
force-pushed
the
stm32h7rs_xip
branch
4 times, most recently
from
c96a37b to
576fead
Compare
|
|
||
| status = "okay"; | ||
|
|
||
| mx25uw25645: xspi-nor-flash@70000000 { |
There was a problem hiding this comment.
Minor naming issue, but on the STM32H7S78-DK, it's actually a mx66uw1g45g
You had this in the first place, but then changed it in 94d4c78 ?
FRASTM
force-pushed
the
stm32h7rs_xip
branch
12 times, most recently
from
00e30e7 to
bcc9c4c
Compare
|
Hello @FRASTM I just tested this PR with the STM32H7S78-DK. First of all, I had to make these changes to have something that builds & flash properly: diff --git a/samples/boards/st/hello_world_xip/boards/stm32h7s78_dk.overlay b/samples/boards/st/hello_world_xip/boards/stm32h7s78_dk.overlay
index 700cb5f56d5..5357426313d 100644
--- a/samples/boards/st/hello_world_xip/boards/stm32h7s78_dk.overlay
+++ b/samples/boards/st/hello_world_xip/boards/stm32h7s78_dk.overlay
@@ -13,6 +13,11 @@
zephyr,flash = &mx66uw1g45;
zephyr,code-partition = &slot0_partition;
};
+
+ aliases {
+ led1 = &green_led;
+ led2 = &orange_led;
+ };
};
&mx66uw1g45 {I am building with the following command: west build -b stm32h7s78_dk zephyr/samples/boards/st/hello_world_xip/ --sysbuild -- \
-DSB_CONFIG_BOOTLOADER_MCUBOOT=y \
-Dhello_world_xip_CONFIG_FLASH=y -Dhello_world_xip_CONFIG_STM32_MEMMAP=y \
-Dmcuboot_CONFIG_LOG=y -Dmcuboot_CONFIG_LOG_DEFAULT_LEVEL=3I am getting this log on the console: From what I understand, the message |
|
I've added the following pll2 configuration (same as the pll1 above): diff --git a/boards/st/stm32h7s78_dk/stm32h7s78_dk.dts b/boards/st/stm32h7s78_dk/stm32h7s78_dk.dts
index d42b89d1629..b51d53e2ed2 100644
--- a/boards/st/stm32h7s78_dk/stm32h7s78_dk.dts
+++ b/boards/st/stm32h7s78_dk/stm32h7s78_dk.dts
@@ -88,6 +90,19 @@
status = "okay";
};
+/* PLL2 for clocking the xspi peripheral */
+&pll2 {
+ clocks = <&clk_hse>;
+ div-m = <12>;
+ mul-n = <250>;
+ div-p = <2>;
+ div-q = <2>;
+ div-r = <2>;
+ div-s = <2>;
+ div-t = <2>;
+ status = "okay";
+};
+
&rcc {
clocks = <&pll>;
clock-frequency = <DT_FREQ_M(250)>;
I don't know if that's a valid configuration at all, but now I am getting this log: |
FRASTM
force-pushed
the
stm32h7rs_xip
branch
2 times, most recently
from
cfd1bdf to
19360c8
Compare
| tags: introduction | ||
| sysbuild: true | ||
| extra_args: | ||
| - SB_CONFIG_BOOTLOADER_MCUBOOT=y |
There was a problem hiding this comment.
This should be put in a sysbuild.conf file.
| - b_u585i_iot02a | ||
| platform_allow: | ||
| - nucleo_h7s3l8 | ||
| - stm32h7s78_dk |
There was a problem hiding this comment.
please add STM32H750B-DK as well
There was a problem hiding this comment.
yes, as soon as this is tested,
--> coming soon
There was a problem hiding this comment.
The stm32h750b_dk has quadspi NOR, that will be handled by another PR
There was a problem hiding this comment.
CONFIG_FLASH & CONFIG_STM32_MEMMAP need to be enabled.
There was a problem hiding this comment.
Not here, the xspi flash is configured in MemMapped from the mcuboot point of view
There is no need for configuring the MEMMAP from this hello_world_xip application POV : this application is not supposed to access the xspi for its own purpose, the external flash is "reserved" for executing the application
There was a problem hiding this comment.
Maybe, I'm not sure (kernel/app rodata for exp is in external Flash, so isn't MemMapped mode needed to be able to read it?). But in any casewest flash won't be able to put the app image in external Flash if CONFIG_STM32_MEMMAP is not enabled, because of if(CONFIG_STM32_MEMMAP) in board.cmake
There was a problem hiding this comment.
That's the case with the samples/application_development/code_relocation_nocopy :
CONFIG_STM32_MEMMAP is set and west flash is downloading from board.cmake instruction at the right memory addresses
For the samples/boards/st/hello_world_xip, Up to now I download with stm32cubeprogrammer GUI
the build/mcuboot/zephyr/zephyr.bin at internal flash address 0x8000000
the build/hello_world_xip/zephyr/zephyr.signed.bin at external flash address 0x70000000 (or 0x90000000)
FRASTM
force-pushed
the
stm32h7rs_xip
branch
4 times, most recently
from
cc29174 to
30803be
Compare
Hello, |
|
Hello @FRASTM !
Indeed, it got lost in the PR discussion and I had forgotten about it. I just checked out your MCUboot PR (in bootloader/mcuboot), and compiled again with the same west command as above. I don't see any error message from MCUBoot anymore, but the application is still not booting. In the log below, we can see that many more reads from flash succeed, but I don't see the Zephyr banner showing up when the application is supposed to boot. Output from the board's consoleFurthermore, I've modified the application to add a blinky like this (in case the application booted correctly but there's an UART issue), but I don't see the LED blinnking so it looks to me that the application hasn't booted at all. diff --git a/samples/sysbuild/with_mcuboot/src/main.c b/samples/sysbuild/with_mcuboot/src/main.c
index 6a6197a801b..ee11a2d9de8 100644
--- a/samples/sysbuild/with_mcuboot/src/main.c
+++ b/samples/sysbuild/with_mcuboot/src/main.c
@@ -7,9 +7,21 @@
#include <zephyr/kernel.h>
#include <zephyr/linker/linker-defs.h>
+#include <zephyr/drivers/gpio.h>
+
+static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(DT_ALIAS(led0), gpios);
+
int main(void)
{
printk("Address of sample %p\n", (void *)__rom_region_start);
printk("Hello sysbuild with mcuboot! %s\n", CONFIG_BOARD);
+
+ gpio_pin_configure_dt(&led, GPIO_OUTPUT_INACTIVE);
+
+ while (1) {
+ gpio_pin_toggle_dt(&led);
+ k_msleep(500);
+ }
+
return 0;
} |
I will get a st32h7rs target and come back to you |
|
I confirm that Did you see that the application is correctly downloaded in the external flash |
|
|
Add the memory attributes to XiP in MemoryMapped mode on the external octo-flash of the nucleo_h7s3l8 board. Use the STM32Cube programmer to flash with the corresponding external loader for XiP mode. Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add the memory attributes to XiP in MemoryMapped mode on the external octo-flash of the stm32h7s78_dk board. Use the STM32Cube programmer to flash with the corresponding external loader for XiP mode. Signed-off-by: Francois Ramu <francois.ramu@st.com>
Samples to execute code in external memory in Memory mapped mode on the stm32h7s3l8 nucleo or stm32h7s78 disco kit Signed-off-by: Francois Ramu <francois.ramu@st.com>
Run the sample to execute in place on the external flash of the stm32h7s78_dk or nucleo_h7s3l8 boards. with_boot is build and linked for the external flash Download the mcuboot zephyr.bin in internal memory Download the with_mcuboot zephyr.signed.bin in external memory Signed-off-by: Francois Ramu <francois.ramu@st.com>
|
Hello @FRASTM and thank you for following that up. In just pulled your latest changes from a few minutes ago, and I still encounter the same issue of the application not starting up on my STM32H7S78-DK. With that being said, I built for the same board as you did (nucleo_h7s3l8), and then I compared the generated zephyr/boards/st/stm32h7s78_dk/stm32h7s78_dk.dts Lines 197 to 222 in 0ca6230 I will try to understand why XSPI1 (PSRAM) is interfering with XSPI2 (FLASH), but let me know if you have any hint. |
|
|
I notice that the |
|
I still keep forgetting about the MCUBoot PR, but the culprit was in there. |
I think the main reason is that the flash_stm32_xspi driver is not supporting more than one xpsi instance |
the stm32h7rs nucleo or disco kit boards can run an application in external flash
The internal flash memory is limited to 64KB which is enough for mcuboot but might be too small for some zephyr applications
With this PR it enable the memorymapped mode on the external flash memory so that XIP is possible on the external NOR octoflash
Two samples are running in XIP on the external flash
This PR completes the #88051
with samples to run application in external NOR memory on stm32h7rs target boards