arch: arm: cortex_m: Allow relocation of vector table in RAM #87468

Martinhoff-maker · 2025-03-21T11:16:47Z

The goal of this PR is to add the support of vector table relocation for cortex_m architecture in case the symbol CONFIG_SRAM_VECTOR_TABLE is set to yes and VTOR register is present.

Actually, as said in the current Kconfig.zephyr, the symbol CONFIG_SRAM_VECTOR_TABLE should place the vector table at the start of the SRAM (which indirectly place the irq_vector_table in the SRAM too).

CONFIG_SRAM_VECTOR_TABLE is currently only used by some boards/soc:

Nuvoton/npcm400_evb -> activate by default but don't see any use of the symbol? (might add maxdog988 NUVOTON NPCM platform maintainer on the review)
adi/max32 -> activate by default on all the max32 boards but no use of it as I see ? (might add MaureenHelm ADI maintener on the review) (edit : confirmation that this is not used by adi/max32)
renesas/smartbond/da1469x -> It has an m33 then have a VTOR register. Actually, it's set to yes by default in the defconfig file of the soc. The symbol is not used at all, but they do unconditionnaly reserve some space at the start of the SRAM (might add ioannis-karachalios RENESAS smartbond maintainer on the review) (edit : PR to remove the symbol)
st/stm32f0x -> they didn't have VTOR for the specific board that uses CONFIG_SRAM_VECTOR_TABLE (but it's where I take inspiration for this PR) so it should not enter into conflict. (might add erwango ST maintainer on the review) (edit : no problem, seen with mathieuchopstm)

It's hence not generic at all and would like to make this more generic for arm/cortex_m architecture which have VTOR register.

Considerations:

Vector table is not necessarily at the start of the ram region: in the case that you also use code relocation, it will place the vector table after the relocated code. Relocated code will always be at the start of the RAM SECTION because of the hard coded generated value in file with "gen_relocate_app.py". It can create quite big gaps and lose about the size of alignment of the vector table section (which is 0x200 for siwx917). Either we consider to not have the vector table at the start of the SRAM section while using code_relocation (what is done is my code actually), or we need to modify the script that relocates the code.
MPU is handled for the code relocation strategies and I think I need to handle this for the small ram section that I reserved for the Vector table. I have tried something concerning this consideration.
VTOR register can be modified in HAL files so this modification can be discarded later in the code execution.
VTOR can also be modified by MCU_BOOT with the software relay vector table and I did not handle that part for the moment.

andyross

Notes and nitpicks. Nothing fatal, feature is definitely useful. Though ideally I guess we'd want to combine this with a "dynamic direct interrupts" feature with an app-visible API. As it stands it requires an app to poke values directly into the table?

andyross · 2025-04-07T16:45:34Z

arch/arm/core/cortex_m/prep_c.c

+
+#define VECTOR_ADDRESS ((uintptr_t)_sram_vector_start)
+
+static inline void relocate_vector_table(void)


Any particular reason you can't just leave this in .data and rely on the pre-existing copy code?

We have some specific alignment constraint over the vector table. We would also like to have the _vector_table section at the start of the SRAM.

andyross · 2025-04-07T16:47:20Z

arch/arm/core/cortex_m/prep_c.c

+	(void) memcpy(_sram_vector_start, _vector_start, vector_size);
+	SCB->VTOR = VECTOR_ADDRESS & VTOR_MASK;
+	barrier_dsync_fence_full();
+	barrier_isync_fence_full();


The barrier instructions shouldn't be needed. Interrupts don't get enabled until the switch to main, which involves a full context switch and implicit barriers from the PendSV. And we absolutely shouldn't be tossing exceptions out of early init code. :)

Agree with what you are saying. I have placed the barrier because of the arm documentation concerning the VTOR register (ARM doc). But I imagine that this is necessary when we would like to modify VTOR register at runtime ? Nevertheless, I've tried without the barrier and it works well.

andyross · 2025-04-07T16:48:03Z

arch/arm/core/cortex_m/ram_vector_table.ld

+#if defined(CONFIG_ARMV6_M_ARMV8_M_BASELINE)
+. = ALIGN( 1 << LOG2CEIL(4 * 64) );
+#elif defined(CONFIG_ARMV7_M_ARMV8_M_MAINLINE)
+. = ALIGN( 1 << LOG2CEIL(4 * 32) );


It's generally preferred to put the alignment onto the chunk in the object file instead of manually here. Is that not already done?

Originally, the vector table alignment is already done in the linker script (vector_table.ld) and not in the object file (from vector_table.S and isr_table.c). That's why I still do the alignment here. But I wonder why it's not done before, will try to figure it out.

andyross · 2025-04-07T16:51:52Z

arch/arm/core/mpu/arm_core_mpu.c

+		.attr = K_MEM_PARTITION_P_R_U_RX,
+#else
+		.attr = K_MEM_PARTITION_P_RX_U_RX,
+#endif


This feels wrong. You're burning a whole MPU register to support this feature when kernel .data is already walled off from userspace threads.

I was thinking also to reuse an already configured MPU section like code relocation section (and it can also make sense to link CONFIG_CODE_DATA_RELOCATION_SRAM and CONFIG_SRAM_VECTOR_TABLE)

Martinhoff-maker · 2025-04-08T09:49:16Z

Thanks for the early feedback @andyross. Yes combining with "dynamic direct interrupts" was in my mind since I'm going later (in another PR) to make use of "dynamic interrupt" to place sw_isr_table also in RAM. I'm currently trying to resolve the compilations problem with mps3 and will update the PR with your feedback.

arch/arm/core/cortex_m/prep_c.c

arch/arm/core/cortex_m/ram_vector_table.ld

jerome-pouiller · 2025-04-14T10:17:45Z

arch/arm/core/cortex_m/prep_c.c

@@ -39,22 +39,40 @@ Z_GENERIC_SECTION(.vt_pointer_section) __attribute__((used)) void *_vector_table

 #ifdef CONFIG_CPU_CORTEX_M_HAS_VTOR


Does CONFIG_SRAM_VECTOR_TABLE depend on CONFIG_CPU_CORTEX_M_HAS_VTOR? If yes, maybe the declaration of CONFIG_SRAM_VECTOR_TABLE should be updated.

No CONFIG_SRAM_VECTOR_TABLE can be used when CONFIG_CPU_CORTEX_M_HAS_VTOR is not set but it is a special case with STM32f0 board

I have added a commit concerning this discussion.

jerome-pouiller · 2025-04-14T10:30:39Z

arch/arm/core/mpu/arm_core_mpu.c

+#if defined(CONFIG_ARM_MPU_PXN) && defined(CONFIG_USERSPACE)
+		.attr = K_MEM_PARTITION_P_R_U_RX,
+#else
+		.attr = K_MEM_PARTITION_P_RX_U_RX,


I believe _sram_vector_start only contains data. So, maybe K_MEM_PARTITION_P_RO_U_RO is sufficient? (unless it is strategy to coalesce the MPU segments)

Actually that's right, will change it to RO and will see if CI fails.

ioannis-karachalios · 2025-04-14T12:15:49Z

Hi @Martinhoff-maker,
There is a recent PR that drops the usage of CONFIG_SRAM_VECTOR_TABLE for the Smartbond devices. In fact, the SoC supports a custom mechanism for remapping IVT to SYSRAM. VTOR is implemented in M33 but not used, at all.

JarmouniA · 2025-04-17T09:25:53Z

arch/Kconfig

+	depends on XIP
+	help
+	  The option specifies that the vector table should be placed at the
+	  start of SRAM instead of the start of flash.


The help should clarify further that this is a modification of a behavior resulting from eXecute in Place.

agree, added.

arch/arm/core/cortex_m/ram_vector_table.ld

arch/Kconfig

Kconfig.zephyr

arch/Kconfig

tests/application_development/vector_table_relocation/prj.conf

JarmouniA · 2025-04-22T16:24:50Z

arch/Kconfig

+	  The option specifies that the vector table will be placed at the
+	  start of SRAM instead of the start of the flash when XIP is enabled.


Suggested change

The option specifies that the vector table will be placed at the

start of SRAM instead of the start of the flash when XIP is enabled.

When XiP is enabled, this option will result in the vector table being

relocated from Flash to SRAM.

Agree changed

JarmouniA · 2025-04-22T16:26:22Z

arch/arm/core/cortex_m/prep_c.c

 #define VECTOR_ADDRESS ((uintptr_t)_vector_start)
+#endif


Suggested change

#endif

#endif /* CONFIG_SRAM_VECTOR_TABLE */

I'm not fan of that kind of commentary since the #ifdef block is really small... IMO it just add noise in the code readability...

Indeed, the Linux Coding Style says "at the end of non-trivial #if or #ifdef block"

It's inside another ifdef and comes after an else, that's why I thought it would be clearer to have the comment.

JarmouniA · 2025-04-22T16:26:37Z

arch/arm/core/cortex_m/prep_c.c

+	size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+
+	z_early_memcpy(_sram_vector_start, _vector_start, vector_size);
+#endif


Suggested change

#endif

#endif /* CONFIG_SRAM_VECTOR_TABLE */

Same comment as the other one

JarmouniA · 2025-04-22T16:43:51Z

arch/arm/core/cortex_m/ram_vector_table.ld

+/* Vector table is not necessarily at the start of the ram region: in the case that you also use
+ * code relocation, it will place the vector table after the relocated code. Relocated code
+ * will always be at the start of the RAM SECTION because of the hardcoded generated value in file
+ * with "gen_relocate_app.py". It can create quite big gap and lose about the size of alignment
+ * of RAM Space


Suggested change

/* Vector table is not necessarily at the start of the ram region: in the case that you also use

* code relocation, it will place the vector table after the relocated code. Relocated code

* will always be at the start of the RAM SECTION because of the hardcoded generated value in file

* with "gen_relocate_app.py". It can create quite big gap and lose about the size of alignment

* of RAM Space

/* Vector table is not necessarily at the start of the RAM region: in the case where Zephyr code

* relocation is used, the vector table is placed after the relocated code.

* Relocated code is always placed at the start of the RAM SECTION because of the hard-coded value

* generated by "gen_relocate_app.py" in the file. It can create quite a big gap and lose about the

* size of alignment in RAM space.

MaureenHelm · 2025-04-22T21:00:49Z

CONFIG_SRAM_VECTOR_TABLE is currently only used by some boards/soc:

adi/max32 -> activate by default on all the max32 boards but no use of it as I see ? (might add MaureenHelm ADI maintener on the review)

That's correct, it's not being used by the max32 port. I think it was incorrectly copied from another port when the max32 port was first done.

JarmouniA

Looks good to me.

The symbol SRAM_VECTOR_TABLE is not used in the adi/max32 soc. Removed it in order to clean up the Kconfig file and avoid confusion with the upcoming new definition of SRAM_VECTOR_TABLE symbol. (PR zephyrproject-rtos#87468) Signed-off-by: Martin Hoff <[email protected]>

Move SRAM_VECTOR_TABLE symbol from general Kconfig to Arch Kconfig because it depends on the architecture possibility to relocate the vector table. Signed-off-by: Martin Hoff <[email protected]>

Allow to place the vector table section in SRAM with CONFIG_SRAM_VECTOR_TABLE option for all cortex-m architecture that have VTOR register. Signed-off-by: Martin Hoff <[email protected]>

Add a basic test for vector table relocation to SRAM. This test verifies that the vector table can be relocated to SRAM and that the VTOR register correctly points to the SRAM address range. Signed-off-by: Martin Hoff <[email protected]>

bjarki-andreasen

Looks good :)

The symbol SRAM_VECTOR_TABLE is not used in the adi/max32 soc. Removed it in order to clean up the Kconfig file and avoid confusion with the upcoming new definition of SRAM_VECTOR_TABLE symbol. (PR #87468) Signed-off-by: Martin Hoff <[email protected]>

Martinhoff-maker requested review from asmellby and jerome-pouiller March 21, 2025 11:17

JarmouniA added area: ARM ARM (32-bit) Architecture RFC Request For Comments: want input from the community labels Mar 21, 2025

carlescufi requested review from bjarki-andreasen, andyross, gmarull and ithinuel March 21, 2025 13:37

carlescufi assigned ithinuel Mar 21, 2025

jerome-pouiller mentioned this pull request Mar 25, 2025

driver: sleeptimer: siwx917: Add siwx91x Sleeptimer driver #87603

Merged

Martinhoff-maker force-pushed the siwx917_ram_execution branch 2 times, most recently from 92b1ec4 to b999504 Compare April 7, 2025 16:25

andyross reviewed Apr 7, 2025

View reviewed changes

Martinhoff-maker force-pushed the siwx917_ram_execution branch from b999504 to 6a470ae Compare April 11, 2025 15:39

Martinhoff-maker marked this pull request as ready for review April 11, 2025 16:20

github-actions bot added the area: Linker Scripts label Apr 11, 2025

github-actions bot requested review from bbolen, carlocaione, galak, MaureenHelm, microbuilder, nashif, stephanosio and wearyzen April 11, 2025 16:21

jerome-pouiller reviewed Apr 14, 2025

View reviewed changes

ydamigos requested a review from ioannis-karachalios April 14, 2025 11:31

Martinhoff-maker force-pushed the siwx917_ram_execution branch from 6a470ae to 3e8fa67 Compare April 15, 2025 09:20

github-actions bot added the area: Architectures label Apr 15, 2025

JarmouniA suggested changes Apr 17, 2025

View reviewed changes

Martinhoff-maker force-pushed the siwx917_ram_execution branch from ec5518c to 58ab375 Compare April 17, 2025 11:58

JarmouniA approved these changes Apr 17, 2025

View reviewed changes

Martinhoff-maker requested a review from andyross April 18, 2025 07:23

wearyzen reviewed Apr 22, 2025

View reviewed changes

arch/arm/core/cortex_m/ram_vector_table.ld Show resolved Hide resolved

arch/Kconfig Outdated Show resolved Hide resolved

Kconfig.zephyr Show resolved Hide resolved

arch/Kconfig Show resolved Hide resolved

tests/application_development/vector_table_relocation/prj.conf Show resolved Hide resolved

JarmouniA reviewed Apr 22, 2025

View reviewed changes

JarmouniA suggested changes Apr 22, 2025

View reviewed changes

Martinhoff-maker force-pushed the siwx917_ram_execution branch from 58ab375 to eb9dada Compare April 23, 2025 12:02

github-actions bot added the Release Notes To be mentioned in the release notes label Apr 23, 2025

Martinhoff-maker force-pushed the siwx917_ram_execution branch 2 times, most recently from 10b19d9 to 1d301ec Compare April 23, 2025 13:16

JarmouniA approved these changes Apr 23, 2025

View reviewed changes

JarmouniA requested a review from tejlmand April 23, 2025 19:11

Martinhoff-maker force-pushed the siwx917_ram_execution branch from 1d301ec to 986e9a8 Compare April 24, 2025 08:30

Martinhoff-maker added 2 commits April 24, 2025 10:45

arch: add dependencie for CONFIG_SRAM_VECTOR_TABLE

68a0e25

Move SRAM_VECTOR_TABLE symbol from general Kconfig to Arch Kconfig because it depends on the architecture possibility to relocate the vector table. Signed-off-by: Martin Hoff <[email protected]>

arch: arm: cortex_m: generalizing SRAM vector table relocation

5386f41

Allow to place the vector table section in SRAM with CONFIG_SRAM_VECTOR_TABLE option for all cortex-m architecture that have VTOR register. Signed-off-by: Martin Hoff <[email protected]>

Martinhoff-maker force-pushed the siwx917_ram_execution branch from 986e9a8 to bc2816b Compare April 24, 2025 08:45

Martinhoff-maker force-pushed the siwx917_ram_execution branch from bc2816b to e9865bd Compare April 24, 2025 09:04

Martinhoff-maker mentioned this pull request Apr 24, 2025

arch: Add SRAM based context for ISR #88883

Open

bjarki-andreasen approved these changes Apr 24, 2025

View reviewed changes

Martinhoff-maker mentioned this pull request Apr 24, 2025

soc: adi: remove unused symbol sram_vector_table #89013

Merged

wearyzen approved these changes Apr 24, 2025

View reviewed changes

jhedberg approved these changes Apr 24, 2025

View reviewed changes

jhedberg removed the RFC Request For Comments: want input from the community label Apr 25, 2025

jhedberg assigned wearyzen Apr 25, 2025

kartben merged commit 64d20cf into zephyrproject-rtos:main Apr 25, 2025
30 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

arch: arm: cortex_m: Allow relocation of vector table in RAM #87468

arch: arm: cortex_m: Allow relocation of vector table in RAM #87468

Martinhoff-maker commented Mar 21, 2025 •

edited

Loading

andyross left a comment

andyross Apr 7, 2025

Martinhoff-maker Apr 11, 2025 •

edited

Loading

andyross Apr 7, 2025

Martinhoff-maker Apr 10, 2025

andyross Apr 7, 2025

Martinhoff-maker Apr 10, 2025

andyross Apr 7, 2025

Martinhoff-maker Apr 11, 2025

Martinhoff-maker commented Apr 8, 2025

jerome-pouiller Apr 14, 2025

Martinhoff-maker Apr 14, 2025

Martinhoff-maker Apr 15, 2025

jerome-pouiller Apr 14, 2025

Martinhoff-maker Apr 14, 2025

ioannis-karachalios commented Apr 14, 2025

JarmouniA Apr 17, 2025

Martinhoff-maker Apr 17, 2025

JarmouniA Apr 22, 2025

Martinhoff-maker Apr 23, 2025

JarmouniA Apr 22, 2025

Martinhoff-maker Apr 23, 2025

jerome-pouiller Apr 23, 2025 •

edited

Loading

JarmouniA Apr 23, 2025

JarmouniA Apr 22, 2025

Martinhoff-maker Apr 23, 2025

JarmouniA Apr 22, 2025 •

edited

Loading

Martinhoff-maker Apr 23, 2025

MaureenHelm commented Apr 22, 2025

JarmouniA left a comment

bjarki-andreasen left a comment


		#define VECTOR_ADDRESS ((uintptr_t)_sram_vector_start)

		static inline void relocate_vector_table(void)

		@@ -39,22 +39,40 @@ Z_GENERIC_SECTION(.vt_pointer_section) __attribute__((used)) void *_vector_table

		#ifdef CONFIG_CPU_CORTEX_M_HAS_VTOR

		The option specifies that the vector table will be placed at the
		start of SRAM instead of the start of the flash when XIP is enabled.

arch: arm: cortex_m: Allow relocation of vector table in RAM #87468

arch: arm: cortex_m: Allow relocation of vector table in RAM #87468

Conversation

Martinhoff-maker commented Mar 21, 2025 • edited Loading

andyross left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Martinhoff-maker Apr 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Martinhoff-maker commented Apr 8, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ioannis-karachalios commented Apr 14, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerome-pouiller Apr 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JarmouniA Apr 22, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MaureenHelm commented Apr 22, 2025

JarmouniA left a comment

Choose a reason for hiding this comment

bjarki-andreasen left a comment

Choose a reason for hiding this comment

Martinhoff-maker commented Mar 21, 2025 •

edited

Loading

Martinhoff-maker Apr 11, 2025 •

edited

Loading

jerome-pouiller Apr 23, 2025 •

edited

Loading

JarmouniA Apr 22, 2025 •

edited

Loading