|
Maciej Dębski <maciej.debski@...>
Hello,
I am developing support for
nucleo board, with stm32f030r8 MCU. The goal was to compile and run the
samples provided with Zephyr, blinky and hello_world. I
managed to finish the job, all was good, so I have done a pull request.
Then, one of the reviewers pointed out that new approach to pinctrl
nodes and uart pinctrl configuration in stm32 socs DT files was
introduced. I was asked to do appropriate changes.
I
modified my code to fit the Zephyr master. Sadly, blinky and
hello_world have stopped working. The code itself is compiling and
flashing fine. Just the board is reporting a fatal error before even my
code is executed.
After checking the code over and over, I think I need help! I
believe most of the values are correct. I just do not fully understand
the new dts/arm file structure, which is in Python, maybe I have missed
something. Would you be so kind as to look at my code and help me find
the issue?
This is my pull request. I would focus on dts/arm and include/dt-bindings.
Yours faithfully, Maciej Dębski
|
|
|
Happy to help. What issue are you running into?
Also, you can find good help on IRC (#zephyrproject on freenode)
- k
toggle quoted message
Show quoted text
On Aug 23, 2017, at 4:47 AM, Maciej Dębski <maciej.debski@...> wrote:
Hello,
I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!
I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
https://github.com/zephyrproject-rtos/zephyr/pull/1103
This is my pull request. I would focus on dts/arm and include/dt-bindings.
Yours faithfully,
Maciej Dębski
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Hi Maciej, On 08/23/2017 11:47 AM, Maciej Dębski wrote: Hello,
I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!
I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue? I took a look into the PR and the pinctrl nodes and uart pinctrl configuration seems fine. Could you provide more information about the fatal error? What do you mean by "before even my code is executed"? I will have a better look in your PR the following days but it is hard to find the problem without the hardware to test it.
https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>
This is my pull request. I would focus on dts/arm and include/dt-bindings.
Yours faithfully,
Maciej Dębski
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
Yannis
|
|
|
Maciej Dębski <maciej.debski@...>
Gentlemen,
thank you for your quick responses! As I wanted to provide more info and debug output, I accidentally found the issue. This little change in arch/arm/core/cortex_m/prep_c. c caused sys fatal error on my f0 board, even before the stm32f0_init. Here is the commit: And here are the specific changes causing problem:
diff --git a/arch/arm/core/cortex_m/prep_ c.c b/arch/arm/core/cortex_m/prep_ c.c index d23dd8b..1382379 100644 --- a/arch/arm/core/cortex_m/prep_ c.c +++ b/arch/arm/core/cortex_m/prep_ c.c @@ -22,9 +22,20 @@ #include <linker/linker-defs.h> #include <nano_internal.h> #include <arch/arm/cortex_m/cmsis.h> +#include <string.h> #ifdef CONFIG_ARMV6_M -static inline void relocate_vector_table(void) { /* do nothing */ } + +#define VECTOR_ADDRESS 0 +static inline void relocate_vector_table(void) +{ +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \ + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0) + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start; + memcpy(VECTOR_ADDRESS, _vector_start, vector_size); +#endif +} + #elif defined(CONFIG_ARMV7_M) #ifdef CONFIG_XIP #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?
Thank you!
Yours faithfully,
Maciej Dębski
On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@...> wrote: Hello,
I am developing support for
nucleo board, with stm32f030r8 MCU. The goal was to compile and run the
samples provided with Zephyr, blinky and hello_world. I
managed to finish the job, all was good, so I have done a pull request.
Then, one of the reviewers pointed out that new approach to pinctrl
nodes and uart pinctrl configuration in stm32 socs DT files was
introduced. I was asked to do appropriate changes.
I
modified my code to fit the Zephyr master. Sadly, blinky and
hello_world have stopped working. The code itself is compiling and
flashing fine. Just the board is reporting a fatal error before even my
code is executed.
After checking the code over and over, I think I need help! I
believe most of the values are correct. I just do not fully understand
the new dts/arm file structure, which is in Python, maybe I have missed
something. Would you be so kind as to look at my code and help me find
the issue?
This is my pull request. I would focus on dts/arm and include/dt-bindings.
Yours faithfully, Maciej Dębski
|
|
|
Hi Maciej, On 08/25/2017 03:24 PM, Maciej Dębski wrote: Gentlemen,
thank you for your quick responses!
As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
Here is the commit:
https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
And here are the specific changes causing problem:
diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
#include <linker/linker-defs.h>
#include <nano_internal.h>
#include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
#ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+ !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+ size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+ memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
#elif defined(CONFIG_ARMV7_M)
#ifdef CONFIG_XIP
#define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
As I understand it (I may be wrong), the code above does not handle the case of stm32f0 where the main Flash memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x0800 0000). When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly? You could provide a patch to address the issue and/or you could report it using github issues. Yannis
|
|
|
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
I do not have a board that needs the relocation. So this is untested for such boards. Nevertheless the commit passes my local sanity check.
If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
Bobby
Gentlemen,
thank you for your quick responses! As I wanted to provide more info and debug output, I accidentally found the issue. This little change in arch/arm/core/cortex_m/prep_c. c caused sys fatal error on my f0 board, even before the stm32f0_init. Here is the commit: And here are the specific changes causing problem:
diff --git a/arch/arm/core/cortex_m/prep_ c.c b/arch/arm/core/cortex_m/prep_ c.c index d23dd8b..1382379 100644 --- a/arch/arm/core/cortex_m/prep_ c.c +++ b/arch/arm/core/cortex_m/prep_ c.c @@ -22,9 +22,20 @@ #include <linker/linker-defs.h> #include <nano_internal.h> #include <arch/arm/cortex_m/cmsis.h> +#include <string.h> #ifdef CONFIG_ARMV6_M -static inline void relocate_vector_table(void) { /* do nothing */ } + +#define VECTOR_ADDRESS 0 +static inline void relocate_vector_table(void) +{ +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \ + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0) + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start; + memcpy(VECTOR_ADDRESS, _vector_start, vector_size); +#endif +} + #elif defined(CONFIG_ARMV7_M) #ifdef CONFIG_XIP #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?
Thank you!
Yours faithfully,
Maciej Dębski
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Maciej Dębski <maciej.debski@...>
Hello Bobby,
amazing, thank you for doing this! Yes, it works on my Nucleo-F030R8, hello world and blinky, both are fine. Try to emphasize that this is related to my patch, so these should be released together. If anyone knows what the procedure is in such cases, please, let me know. Should I just wait?
Thank you, Maciej Dębski
On Sun, Sep 3, 2017 at 7:22 PM, b0661 <b0661n0e17e@...> wrote: works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
I do not have a board that needs the relocation. So this is untested for such boards. Nevertheless the commit passes my local sanity check.
If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
Bobby
|
|
|
Hi Maciej and Bobby,
you can collaborate on Maciej github repository and push this commit
as a PR there and then to Zephyr's repo.
@Booby You declare vector_table_src as constant and the you change its
value. Does the compiler give you a warning for undefined behavior?
Yannis
|
|
|
@Bobby I missed that it is a pointer to const u32_t. It is fine. On Mon, Sep 4, 2017 at 12:01 PM, Yannis Damigos <giannis.damigos@...> wrote: Hi Maciej and Bobby,
you can collaborate on Maciej github repository and push this commit
as a PR there and then to Zephyr's repo.
@Booby You declare vector_table_src as constant and the you change its
value. Does the compiler give you a warning for undefined behavior?
Yannis
|
|
|
Hi All,
I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
The #if is bogus :
#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
And it doesn't take in account what is actually mapped at address 0 !
On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
@Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
@kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
Neil
toggle quoted message
Show quoted text
On 09/03/2017 07:22 PM, b0661 wrote: Hello Maciej,
I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
The commit "arch: arm: core: fix vector table relocate write to flash"
https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
I do not have a board that needs the relocation. So this is untested for such boards.
Nevertheless the commit passes my local sanity check.
If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
Bobby
2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...>>:
Gentlemen,
thank you for your quick responses!
As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
Here is the commit:
https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
And here are the specific changes causing problem:
diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
#include <linker/linker-defs.h>
#include <nano_internal.h>
#include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
#ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+ !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+ size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+ memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
#elif defined(CONFIG_ARMV7_M)
#ifdef CONFIG_XIP
#define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?
Thank you!
Yours faithfully,
Maciej Dębski
On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...>> wrote:
Hello,
I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!
I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>
This is my pull request. I would focus on dts/arm and include/dt-bindings.
Yours faithfully,
Maciej Dębski
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@... <mailto:Zephyr-devel@...>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Hi All,
On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
Neil
toggle quoted message
Show quoted text
On 09/11/2017 12:06 PM, Neil Armstrong wrote: Hi All,
I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
The #if is bogus :
#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
And it doesn't take in account what is actually mapped at address 0 !
On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
@Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
@kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
Neil
On 09/03/2017 07:22 PM, b0661 wrote:
Hello Maciej,
I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
The commit "arch: arm: core: fix vector table relocate write to flash"
https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
I do not have a board that needs the relocation. So this is untested for such boards.
Nevertheless the commit passes my local sanity check.
If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
Bobby
2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...>>:
Gentlemen,
thank you for your quick responses!
As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
Here is the commit:
https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
And here are the specific changes causing problem:
diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
#include <linker/linker-defs.h>
#include <nano_internal.h>
#include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
#ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+ !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+ size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+ memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
#elif defined(CONFIG_ARMV7_M)
#ifdef CONFIG_XIP
#define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?
Thank you!
Yours faithfully,
Maciej Dębski
On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...>> wrote:
Hello,
I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!
I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>
This is my pull request. I would focus on dts/arm and include/dt-bindings.
Yours faithfully,
Maciej Dębski
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@... <mailto:Zephyr-devel@...>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Hi Maciej, Bobby,
Could test the following patch ?
If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
--><---------------------------------------------------------------------------
diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index 1382379..57e0e92 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -26,12 +26,25 @@
#ifdef CONFIG_ARMV6_M
+/**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ * This functions is a hook before the vector memory relocation to
+ * ensure the mapped memory is correct.
+ */
+void __weak relocate_vector_memory(void)
+{
+ /* Nothing to do by default */
+}
+
#define VECTOR_ADDRESS 0
static inline void relocate_vector_table(void)
{
#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
!defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+
+ relocate_vector_memory();
+
memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
#endif
}
diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
index 727c348..2c056c2 100644
--- a/arch/arm/soc/st_stm32/stm32f0/soc.c
+++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
@@ -17,6 +17,16 @@
#include <cortex_m/exc.h>
/**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ * This functions is a hook before the vector memory relocation to
+ * ensure the mapped memory is correct.
+ */
+void relocate_vector_memory(void)
+{
+ LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
+}
+
+/**
* @brief This function configures the source of stm32cube time base.
* Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
* Tick interrupt priority is not used
--
Thanks,
Neil
toggle quoted message
Show quoted text
On 09/11/2017 02:35 PM, Neil Armstrong wrote: Hi All,
On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
Neil
On 09/11/2017 12:06 PM, Neil Armstrong wrote:
Hi All,
I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
The #if is bogus :
#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
And it doesn't take in account what is actually mapped at address 0 !
On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
@Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
@kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
Neil
On 09/03/2017 07:22 PM, b0661 wrote:
Hello Maciej,
I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
The commit "arch: arm: core: fix vector table relocate write to flash"
https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
I do not have a board that needs the relocation. So this is untested for such boards.
Nevertheless the commit passes my local sanity check.
If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
Bobby
2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...>>:
Gentlemen,
thank you for your quick responses!
As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
Here is the commit:
https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
And here are the specific changes causing problem:
diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
#include <linker/linker-defs.h>
#include <nano_internal.h>
#include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
#ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+ !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+ size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+ memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
#elif defined(CONFIG_ARMV7_M)
#ifdef CONFIG_XIP
#define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?
Thank you!
Yours faithfully,
Maciej Dębski
On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...>> wrote:
Hello,
I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!
I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>
This is my pull request. I would focus on dts/arm and include/dt-bindings.
Yours faithfully,
Maciej Dębski
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@... <mailto:Zephyr-devel@...>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Hi Neil,
the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
I would appreciate to save precious SRAM and do the remap only if it is needed.
I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
I will test your patch.
Bobby
Hi Maciej, Bobby,
Could test the following patch ?
If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
--><---------------------------------------------------------------------------
diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index 1382379..57e0e92 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -26,12 +26,25 @@
#ifdef CONFIG_ARMV6_M
+/**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ * This functions is a hook before the vector memory relocation to
+ * ensure the mapped memory is correct.
+ */
+void __weak relocate_vector_memory(void)
+{
+ /* Nothing to do by default */
+}
+
#define VECTOR_ADDRESS 0
static inline void relocate_vector_table(void)
{
#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
!defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+
+ relocate_vector_memory();
+
memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
#endif
}
diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
index 727c348..2c056c2 100644
--- a/arch/arm/soc/st_stm32/stm32f0/soc.c
+++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
@@ -17,6 +17,16 @@
#include <cortex_m/exc.h>
/**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ * This functions is a hook before the vector memory relocation to
+ * ensure the mapped memory is correct.
+ */
+void relocate_vector_memory(void)
+{
+ LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
+}
+
+/**
* @brief This function configures the source of stm32cube time base.
* Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
* Tick interrupt priority is not used
--
Thanks,
Neil
On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> Hi All,
>
> On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
>
> I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
>
> Neil
>
> On 09/11/2017 12:06 PM, Neil Armstrong wrote:
>> Hi All,
>>
>> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4 e0cf52dae8 (arm: armv6-m: Support relocating vector table).
>>
>> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
>>
>> The #if is bogus :
>> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>>
>> And it doesn't take in account what is actually mapped at address 0 !
>>
>> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
>>
>> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
>>
>> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
>>
>> Neil
>>
>> On 09/03/2017 07:22 PM, b0661 wrote:
>>> Hello Maciej,
>>>
>>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
>>>
>>> The commit "arch: arm: core: fix vector table relocate write to flash"
>>> https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 < https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>
>>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
>>>
>>> I do not have a board that needs the relocation. So this is untested for such boards.
>>> Nevertheless the commit passes my local sanity check.
>>>
>>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
>>>
>>> Bobby
>>>
>>>
>>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski < maciej.debski@... <mailto: maciej.debski@rndity.com>>:
>>>
>>> Gentlemen,
>>>
>>> thank you for your quick responses!
>>>
>>> As I wanted to provide more info and debug output, I accidentally found the issue.
>>> This little change in arch/arm/core/cortex_m/prep_c. c caused sys fatal error on my f0 board, even before the stm32f0_init.
>>>
>>> Here is the commit:
>>> https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 < https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
>>>
>>> And here are the specific changes causing problem:
>>>
>>> diff --git a/arch/arm/core/cortex_m/prep_ c.c b/arch/arm/core/cortex_m/prep_ c.c
>>> index d23dd8b..1382379 100644
>>> --- a/arch/arm/core/cortex_m/prep_ c.c
>>> +++ b/arch/arm/core/cortex_m/prep_ c.c
>>> @@ -22,9 +22,20 @@
>>> #include <linker/linker-defs.h>
>>> #include <nano_internal.h>
>>> #include <arch/arm/cortex_m/cmsis.h>
>>> +#include <string.h>
>>>
>>> #ifdef CONFIG_ARMV6_M
>>> -static inline void relocate_vector_table(void) { /* do nothing */ }
>>> +
>>> +#define VECTOR_ADDRESS 0
>>> +static inline void relocate_vector_table(void)
>>> +{
>>> +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
>>> + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>>> + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
>>> + memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
>>> +#endif
>>> +}
>>> +
>>> #elif defined(CONFIG_ARMV7_M)
>>> #ifdef CONFIG_XIP
>>> #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
>>>
>>>
>>> When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
>>> What should I do now? How to report it properly?
>>>
>>> Thank you!
>>>
>>> Yours faithfully,
>>> Maciej Dębski
>>>
>>>
>>>
>>>
>>> On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski < maciej.debski@... <mailto: maciej.debski@rndity.com>> wrote:
>>>
>>> Hello,
>>>
>>> I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
>>>
>>> I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
>>>
>>> I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
>>> After checking the code over and over, I think I need help!
>>>
>>> I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
>>>
>>> https://github.com/zephyrproject-rtos/zephyr/pull/1103 < https://github.com/zephyrproject-rtos/zephyr/pull/1103>
>>>
>>> This is my pull request. I would focus on dts/arm and include/dt-bindings.
>>>
>>> Yours faithfully,
>>> Maciej Dębski
>>>
>>>
>>>
>>> ______________________________ _________________
>>> Zephyr-devel mailing list
>>> Zephyr-devel@lists.zephyrproject.org <mailto: Zephyr-devel@lists.zephyrproject.org>
>>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel < https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
>>>
>>>
>>>
>>>
>>> ______________________________ _________________
>>> Zephyr-devel mailing list
>>> Zephyr-devel@lists.zephyrproject.org
>>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>>>
>>
>
|
|
|
Hi,
Since Cortex-M0 cannot relocate the vector base with a processor register, the vector must be moved.
Yes you can map the first kbytes of the flash to the first 32k bytes of 0, but you won't tun change the vector or run other applications if you have a bootloader.
But yes, you may need to add a further Kconfig to completely disable relocation, but also disable vector modification because it can only occur in this SRAM mapped a 0.
Neil
toggle quoted message
Show quoted text
On 09/11/2017 04:02 PM, b0661 wrote: Hi Neil,
the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
I would appreciate to save precious SRAM and do the remap only if it is needed.
I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
I will test your patch.
Bobby
2017-09-11 14:54 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...>>:
Hi Maciej, Bobby,
Could test the following patch ?
If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
--><---------------------------------------------------------------------------
diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index 1382379..57e0e92 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -26,12 +26,25 @@
#ifdef CONFIG_ARMV6_M
+/**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ * This functions is a hook before the vector memory relocation to
+ * ensure the mapped memory is correct.
+ */
+void __weak relocate_vector_memory(void)
+{
+ /* Nothing to do by default */
+}
+
#define VECTOR_ADDRESS 0
static inline void relocate_vector_table(void)
{
#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
!defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+
+ relocate_vector_memory();
+
memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
#endif
}
diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
index 727c348..2c056c2 100644
--- a/arch/arm/soc/st_stm32/stm32f0/soc.c
+++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
@@ -17,6 +17,16 @@
#include <cortex_m/exc.h>
/**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ * This functions is a hook before the vector memory relocation to
+ * ensure the mapped memory is correct.
+ */
+void relocate_vector_memory(void)
+{
+ LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
+}
+
+/**
* @brief This function configures the source of stm32cube time base.
* Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
* Tick interrupt priority is not used
--
Thanks,
Neil
On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> Hi All,
>
> On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
>
> I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
>
> Neil
>
> On 09/11/2017 12:06 PM, Neil Armstrong wrote:
>> Hi All,
>>
>> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
>>
>> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
>>
>> The #if is bogus :
>> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>>
>> And it doesn't take in account what is actually mapped at address 0 !
>>
>> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
>>
>> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
>>
>> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
>>
>> Neil
>>
>> On 09/03/2017 07:22 PM, b0661 wrote:
>>> Hello Maciej,
>>>
>>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
>>>
>>> The commit "arch: arm: core: fix vector table relocate write to flash"
>>> https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>
>>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
>>>
>>> I do not have a board that needs the relocation. So this is untested for such boards.
>>> Nevertheless the commit passes my local sanity check.
>>>
>>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
>>>
>>> Bobby
>>>
>>>
>>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>:
>>>
>>> Gentlemen,
>>>
>>> thank you for your quick responses!
>>>
>>> As I wanted to provide more info and debug output, I accidentally found the issue.
>>> This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
>>>
>>> Here is the commit:
>>> https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>
>>>
>>> And here are the specific changes causing problem:
>>>
>>> diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
>>> index d23dd8b..1382379 100644
>>> --- a/arch/arm/core/cortex_m/prep_c.c
>>> +++ b/arch/arm/core/cortex_m/prep_c.c
>>> @@ -22,9 +22,20 @@
>>> #include <linker/linker-defs.h>
>>> #include <nano_internal.h>
>>> #include <arch/arm/cortex_m/cmsis.h>
>>> +#include <string.h>
>>>
>>> #ifdef CONFIG_ARMV6_M
>>> -static inline void relocate_vector_table(void) { /* do nothing */ }
>>> +
>>> +#define VECTOR_ADDRESS 0
>>> +static inline void relocate_vector_table(void)
>>> +{
>>> +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
>>> + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>>> + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
>>> + memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
>>> +#endif
>>> +}
>>> +
>>> #elif defined(CONFIG_ARMV7_M)
>>> #ifdef CONFIG_XIP
>>> #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
>>>
>>>
>>> When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
>>> What should I do now? How to report it properly?
>>>
>>> Thank you!
>>>
>>> Yours faithfully,
>>> Maciej Dębski
>>>
>>>
>>>
>>>
>>> On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>> wrote:
>>>
>>> Hello,
>>>
>>> I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
>>>
>>> I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
>>>
>>> I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
>>> After checking the code over and over, I think I need help!
>>>
>>> I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
>>>
>>> https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>
>>>
>>> This is my pull request. I would focus on dts/arm and include/dt-bindings.
>>>
>>> Yours faithfully,
>>> Maciej Dębski
>>>
>>>
>>>
>>> _______________________________________________
>>> Zephyr-devel mailing list
>>> Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>
>>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Zephyr-devel mailing list
>>> Zephyr-devel@... <mailto:Zephyr-devel@...>
>>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
>>>
>>
>
|
|
|
Transfer of the vector table to address 0.. of the SRAM will either write to the application .data section or the kernel .bss section. The .bss section will be zeroed just after the relocation of the vector table.
I think there must be a memory reservation for the vector table at the start of the RAMABLE_REGION.
I still do not see why execution in place (XIP) mandates the interrupt vector table to be in SRAM. This should be a different configuration option to be set by e.g. bootloaders. Event bootloaders may avoid that by using trampolines. Based on this option the memory at the start of the SRAM can be reseved, the SRAM mapped to address 0 and the vector table transfered from flash to SRAM.
Bobby
Hi,
Since Cortex-M0 cannot relocate the vector base with a processor register, the vector must be moved.
Yes you can map the first kbytes of the flash to the first 32k bytes of 0, but you won't tun change the vector or run other applications if you have a bootloader.
But yes, you may need to add a further Kconfig to completely disable relocation, but also disable vector modification because it can only occur in this SRAM mapped a 0.
Neil
On 09/11/2017 04:02 PM, b0661 wrote:
> Hi Neil,
>
> the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
>
> I would appreciate to save precious SRAM and do the remap only if it is needed.
>
> I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
>
> My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
>
> I will test your patch.
>
> Bobby
>
>
> 2017-09-11 14:54 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@baylibre.com>>:
>
> Hi Maciej, Bobby,
>
> Could test the following patch ?
>
> If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
>
>
> --><---------------------------------------------------------------------------
>
> diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> index 1382379..57e0e92 100644
> --- a/arch/arm/core/cortex_m/prep_c.c
> +++ b/arch/arm/core/cortex_m/prep_c.c
> @@ -26,12 +26,25 @@
>
> #ifdef CONFIG_ARMV6_M
>
> +/**
> + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> + * This functions is a hook before the vector memory relocation to
> + * ensure the mapped memory is correct.
> + */
> +void __weak relocate_vector_memory(void)
> +{
> + /* Nothing to do by default */
> +}
> +
> #define VECTOR_ADDRESS 0
> static inline void relocate_vector_table(void)
> {
> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> +
> + relocate_vector_memory();
> +
> memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> #endif
> }
> diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
> index 727c348..2c056c2 100644
> --- a/arch/arm/soc/st_stm32/stm32f0/soc.c
> +++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
> @@ -17,6 +17,16 @@
> #include <cortex_m/exc.h>
>
> /**
> + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> + * This functions is a hook before the vector memory relocation to
> + * ensure the mapped memory is correct.
> + */
> +void relocate_vector_memory(void)
> +{
> + LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
> +}
> +
> +/**
> * @brief This function configures the source of stm32cube time base.
> * Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
> * Tick interrupt priority is not used
> --
>
> Thanks,
> Neil
>
>
> On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> > Hi All,
> >
> > On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
> >
> > I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
> >
> > Neil
> >
> > On 09/11/2017 12:06 PM, Neil Armstrong wrote:
> >> Hi All,
> >>
> >> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
> >>
> >> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
> >>
> >> The #if is bogus :
> >> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> >>
> >> And it doesn't take in account what is actually mapped at address 0 !
> >>
> >> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
> >>
> >> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
> >>
> >> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
> >>
> >> Neil
> >>
> >> On 09/03/2017 07:22 PM, b0661 wrote:
> >>> Hello Maciej,
> >>>
> >>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
> >>>
> >>> The commit "arch: arm: core: fix vector table relocate write to flash"
> >>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
> >>>
> >>> I do not have a board that needs the relocation. So this is untested for such boards.
> >>> Nevertheless the commit passes my local sanity check.
> >>>
> >>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
> >>>
> >>> Bobby
> >>>
> >>>
> >>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>>>:
> >>>
> >>> Gentlemen,
> >>>
> >>> thank you for your quick responses!
> >>>
> >>> As I wanted to provide more info and debug output, I accidentally found the issue.
> >>> This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
> >>>
> >>> Here is the commit:
> >>> https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>
> >>>
> >>> And here are the specific changes causing problem:
> >>>
> >>> diff --git a/arch/arm/core/cortex_m/prep_ c.c b/arch/arm/core/cortex_m/prep_ c.c
> >>> index d23dd8b..1382379 100644
> >>> --- a/arch/arm/core/cortex_m/prep_ c.c
> >>> +++ b/arch/arm/core/cortex_m/prep_ c.c
> >>> @@ -22,9 +22,20 @@
> >>> #include <linker/linker-defs.h>
> >>> #include <nano_internal.h>
> >>> #include <arch/arm/cortex_m/cmsis.h>
> >>> +#include <string.h>
> >>>
> >>> #ifdef CONFIG_ARMV6_M
> >>> -static inline void relocate_vector_table(void) { /* do nothing */ }
> >>> +
> >>> +#define VECTOR_ADDRESS 0
> >>> +static inline void relocate_vector_table(void)
> >>> +{
> >>> +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> >>> + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> >>> + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> >>> + memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> >>> +#endif
> >>> +}
> >>> +
> >>> #elif defined(CONFIG_ARMV7_M)
> >>> #ifdef CONFIG_XIP
> >>> #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
> >>>
> >>>
> >>> When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
> >>> What should I do now? How to report it properly?
> >>>
> >>> Thank you!
> >>>
> >>> Yours faithfully,
> >>> Maciej Dębski
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Hello,
> >>>
> >>> I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
> >>>
> >>> I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
> >>>
> >>> I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
> >>> After checking the code over and over, I think I need help!
> >>>
> >>> I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
> >>>
> >>> https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>
> >>>
> >>> This is my pull request. I would focus on dts/arm and include/dt-bindings.
> >>>
> >>> Yours faithfully,
> >>> Maciej Dębski
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Zephyr-devel mailing list
> >>> Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>>
> >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>
|
|
|
On 09/13/2017 02:09 PM, b0661 wrote: Hi Neal,
I had a look at the linker script https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld which is also used for STM32F0.
Transfer of the vector table to address 0.. of the SRAM will either write to the application .data section or the kernel .bss section. The .bss section will be zeroed just after the relocation of the vector table.
I think there must be a memory reservation for the vector table at the start of the RAMABLE_REGION. Exact
I still do not see why execution in place (XIP) mandates the interrupt vector table to be in SRAM. This should be a different configuration option to be set by e.g. bootloaders. Event bootloaders may avoid that by using trampolines. Based on this option the memory at the start of the SRAM can be reseved, the SRAM mapped to address 0 and the vector table transfered from flash to SRAM.
Yes it should, then it should disable all the dynamic update and generation of the vector table.
Bobby
2017-09-11 17:09 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...>>:
Hi,
Since Cortex-M0 cannot relocate the vector base with a processor register, the vector must be moved.
Yes you can map the first kbytes of the flash to the first 32k bytes of 0, but you won't tun change the vector or run other applications if you have a bootloader.
But yes, you may need to add a further Kconfig to completely disable relocation, but also disable vector modification because it can only occur in this SRAM mapped a 0.
Neil
On 09/11/2017 04:02 PM, b0661 wrote:
> Hi Neil,
>
> the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
>
> I would appreciate to save precious SRAM and do the remap only if it is needed.
>
> I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
>
> My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
>
> I will test your patch.
>
> Bobby
>
>
> 2017-09-11 14:54 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>>>:
>
> Hi Maciej, Bobby,
>
> Could test the following patch ?
>
> If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
>
>
> --><---------------------------------------------------------------------------
>
> diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> index 1382379..57e0e92 100644
> --- a/arch/arm/core/cortex_m/prep_c.c
> +++ b/arch/arm/core/cortex_m/prep_c.c
> @@ -26,12 +26,25 @@
>
> #ifdef CONFIG_ARMV6_M
>
> +/**
> + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> + * This functions is a hook before the vector memory relocation to
> + * ensure the mapped memory is correct.
> + */
> +void __weak relocate_vector_memory(void)
> +{
> + /* Nothing to do by default */
> +}
> +
> #define VECTOR_ADDRESS 0
> static inline void relocate_vector_table(void)
> {
> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> +
> + relocate_vector_memory();
> +
> memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> #endif
> }
> diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
> index 727c348..2c056c2 100644
> --- a/arch/arm/soc/st_stm32/stm32f0/soc.c
> +++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
> @@ -17,6 +17,16 @@
> #include <cortex_m/exc.h>
>
> /**
> + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> + * This functions is a hook before the vector memory relocation to
> + * ensure the mapped memory is correct.
> + */
> +void relocate_vector_memory(void)
> +{
> + LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
> +}
> +
> +/**
> * @brief This function configures the source of stm32cube time base.
> * Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
> * Tick interrupt priority is not used
> --
>
> Thanks,
> Neil
>
>
> On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> > Hi All,
> >
> > On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
> >
> > I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
> >
> > Neil
> >
> > On 09/11/2017 12:06 PM, Neil Armstrong wrote:
> >> Hi All,
> >>
> >> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
> >>
> >> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
> >>
> >> The #if is bogus :
> >> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> >>
> >> And it doesn't take in account what is actually mapped at address 0 !
> >>
> >> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
> >>
> >> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
> >>
> >> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
> >>
> >> Neil
> >>
> >> On 09/03/2017 07:22 PM, b0661 wrote:
> >>> Hello Maciej,
> >>>
> >>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
> >>>
> >>> The commit "arch: arm: core: fix vector table relocate write to flash"
> >>> https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>>
> >>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
> >>>
> >>> I do not have a board that needs the relocation. So this is untested for such boards.
> >>> Nevertheless the commit passes my local sanity check.
> >>>
> >>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
> >>>
> >>> Bobby
> >>>
> >>>
> >>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>>:
> >>>
> >>> Gentlemen,
> >>>
> >>> thank you for your quick responses!
> >>>
> >>> As I wanted to provide more info and debug output, I accidentally found the issue.
> >>> This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
> >>>
> >>> Here is the commit:
> >>> https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>>
> >>>
> >>> And here are the specific changes causing problem:
> >>>
> >>> diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> >>> index d23dd8b..1382379 100644
> >>> --- a/arch/arm/core/cortex_m/prep_c.c
> >>> +++ b/arch/arm/core/cortex_m/prep_c.c
> >>> @@ -22,9 +22,20 @@
> >>> #include <linker/linker-defs.h>
> >>> #include <nano_internal.h>
> >>> #include <arch/arm/cortex_m/cmsis.h>
> >>> +#include <string.h>
> >>>
> >>> #ifdef CONFIG_ARMV6_M
> >>> -static inline void relocate_vector_table(void) { /* do nothing */ }
> >>> +
> >>> +#define VECTOR_ADDRESS 0
> >>> +static inline void relocate_vector_table(void)
> >>> +{
> >>> +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> >>> + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> >>> + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> >>> + memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> >>> +#endif
> >>> +}
> >>> +
> >>> #elif defined(CONFIG_ARMV7_M)
> >>> #ifdef CONFIG_XIP
> >>> #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
> >>>
> >>>
> >>> When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
> >>> What should I do now? How to report it properly?
> >>>
> >>> Thank you!
> >>>
> >>> Yours faithfully,
> >>> Maciej Dębski
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
> >>>
> >>> I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
> >>>
> >>> I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
> >>> After checking the code over and over, I think I need help!
> >>>
> >>> I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
> >>>
> >>> https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>>
> >>>
> >>> This is my pull request. I would focus on dts/arm and include/dt-bindings.
> >>>
> >>> Yours faithfully,
> >>> Maciej Dębski
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Zephyr-devel mailing list
> >>> Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>>
> >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Zephyr-devel mailing list
> >>> Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>
> >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>
> >>>
> >>
> >
>
>
|
|
|
|
|
|
On 09/13/2017 02:30 PM, b0661 wrote: Hi Neal,
2017-09-13 14:10 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...>>:
On 09/13/2017 02:09 PM, b0661 wrote:
> Hi Neal,
>
> I had a look at the linker script https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld> which is also used for STM32F0.
>
> Transfer of the vector table to address 0.. of the SRAM will either write to the application .data section or the kernel .bss section. The .bss section will be zeroed just after the relocation of the vector table.
>
> I think there must be a memory reservation for the vector table at the start of the RAMABLE_REGION.
Exact
>
>
> I still do not see why execution in place (XIP) mandates the interrupt vector table to be in SRAM. This should be a different configuration option to be set by e.g. bootloaders. Event bootloaders may avoid that by using trampolines. Based on this option the memory at the start of the SRAM can be reseved, the SRAM mapped to address 0 and the vector table transfered from flash to SRAM.
Yes it should, then it should disable all the dynamic update and generation of the vector table.
There are use cases where you really do not need the dynamic updates (mine for example - updates are done by the supervising system) but as much RAM as possible. So why not make it a config option? Yes, I think the SRAM mapped case should be an option, but selected by default. Anyway, something must be pushed along the STM32F0 basic support. Neil
>
>
> Bobby
>
> 2017-09-11 17:09 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>>>:
>
> Hi,
>
> Since Cortex-M0 cannot relocate the vector base with a processor register, the vector must be moved.
>
> Yes you can map the first kbytes of the flash to the first 32k bytes of 0, but you won't tun change the vector or run other applications if you have a bootloader.
>
> But yes, you may need to add a further Kconfig to completely disable relocation, but also disable vector modification because it can only occur in this SRAM mapped a 0.
>
> Neil
>
> On 09/11/2017 04:02 PM, b0661 wrote:
> > Hi Neil,
> >
> > the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
> >
> > I would appreciate to save precious SRAM and do the remap only if it is needed.
> >
> > I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
> >
> > My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
> >
> > I will test your patch.
> >
> > Bobby
> >
> >
> > 2017-09-11 14:54 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>> <mailto:narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>>>>:
> >
> > Hi Maciej, Bobby,
> >
> > Could test the following patch ?
> >
> > If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
> >
> >
> > --><---------------------------------------------------------------------------
> >
> > diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> > index 1382379..57e0e92 100644
> > --- a/arch/arm/core/cortex_m/prep_c.c
> > +++ b/arch/arm/core/cortex_m/prep_c.c
> > @@ -26,12 +26,25 @@
> >
> > #ifdef CONFIG_ARMV6_M
> >
> > +/**
> > + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> > + * This functions is a hook before the vector memory relocation to
> > + * ensure the mapped memory is correct.
> > + */
> > +void __weak relocate_vector_memory(void)
> > +{
> > + /* Nothing to do by default */
> > +}
> > +
> > #define VECTOR_ADDRESS 0
> > static inline void relocate_vector_table(void)
> > {
> > #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> > !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> > +
> > + relocate_vector_memory();
> > +
> > memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> > #endif
> > }
> > diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
> > index 727c348..2c056c2 100644
> > --- a/arch/arm/soc/st_stm32/stm32f0/soc.c
> > +++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
> > @@ -17,6 +17,16 @@
> > #include <cortex_m/exc.h>
> >
> > /**
> > + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> > + * This functions is a hook before the vector memory relocation to
> > + * ensure the mapped memory is correct.
> > + */
> > +void relocate_vector_memory(void)
> > +{
> > + LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
> > +}
> > +
> > +/**
> > * @brief This function configures the source of stm32cube time base.
> > * Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
> > * Tick interrupt priority is not used
> > --
> >
> > Thanks,
> > Neil
> >
> >
> > On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> > > Hi All,
> > >
> > > On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
> > >
> > > I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
> > >
> > > Neil
> > >
> > > On 09/11/2017 12:06 PM, Neil Armstrong wrote:
> > >> Hi All,
> > >>
> > >> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
> > >>
> > >> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
> > >>
> > >> The #if is bogus :
> > >> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > >>
> > >> And it doesn't take in account what is actually mapped at address 0 !
> > >>
> > >> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
> > >>
> > >> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
> > >>
> > >> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
> > >>
> > >> Neil
> > >>
> > >> On 09/03/2017 07:22 PM, b0661 wrote:
> > >>> Hello Maciej,
> > >>>
> > >>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
> > >>>
> > >>> The commit "arch: arm: core: fix vector table relocate write to flash"
> > >>> https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314
<https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>>>
> > >>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
> > >>>
> > >>> I do not have a board that needs the relocation. So this is untested for such boards.
> > >>> Nevertheless the commit passes my local sanity check.
> > >>>
> > >>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
> > >>>
> > >>> Bobby
> > >>>
> > >>>
> > >>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>>>:
> > >>>
> > >>> Gentlemen,
> > >>>
> > >>> thank you for your quick responses!
> > >>>
> > >>> As I wanted to provide more info and debug output, I accidentally found the issue.
> > >>> This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
> > >>>
> > >>> Here is the commit:
> > >>> https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
<https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>>>
> > >>>
> > >>> And here are the specific changes causing problem:
> > >>>
> > >>> diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> > >>> index d23dd8b..1382379 100644
> > >>> --- a/arch/arm/core/cortex_m/prep_c.c
> > >>> +++ b/arch/arm/core/cortex_m/prep_c.c
> > >>> @@ -22,9 +22,20 @@
> > >>> #include <linker/linker-defs.h>
> > >>> #include <nano_internal.h>
> > >>> #include <arch/arm/cortex_m/cmsis.h>
> > >>> +#include <string.h>
> > >>>
> > >>> #ifdef CONFIG_ARMV6_M
> > >>> -static inline void relocate_vector_table(void) { /* do nothing */ }
> > >>> +
> > >>> +#define VECTOR_ADDRESS 0
> > >>> +static inline void relocate_vector_table(void)
> > >>> +{
> > >>> +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> > >>> + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > >>> + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> > >>> + memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> > >>> +#endif
> > >>> +}
> > >>> +
> > >>> #elif defined(CONFIG_ARMV7_M)
> > >>> #ifdef CONFIG_XIP
> > >>> #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
> > >>>
> > >>>
> > >>> When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
> > >>> What should I do now? How to report it properly?
> > >>>
> > >>> Thank you!
> > >>>
> > >>> Yours faithfully,
> > >>> Maciej Dębski
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>>> wrote:
> > >>>
> > >>> Hello,
> > >>>
> > >>> I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
> > >>>
> > >>> I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
> > >>>
> > >>> I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
> > >>> After checking the code over and over, I think I need help!
> > >>>
> > >>> I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
> > >>>
> > >>> https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>>>
> > >>>
> > >>> This is my pull request. I would focus on dts/arm and include/dt-bindings.
> > >>>
> > >>> Yours faithfully,
> > >>> Maciej Dębski
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Zephyr-devel mailing list
> > >>> Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>>>
> > >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
<https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Zephyr-devel mailing list
> > >>> Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>>
> > >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>
> > >>>
> > >>
> > >
> >
> >
>
>
|
|
|
I don´t know much about the bootloader mechanisms you mentioned - please review/ comment. Thanks Bobby
On 09/13/2017 02:30 PM, b0661 wrote:
> Hi Neal,
>
> 2017-09-13 14:10 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@baylibre.com>>:
>
> On 09/13/2017 02:09 PM, b0661 wrote:
> > Hi Neal,
> >
> > I had a look at the linker script https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld> which is also used for STM32F0.
> >
> > Transfer of the vector table to address 0.. of the SRAM will either write to the application .data section or the kernel .bss section. The .bss section will be zeroed just after the relocation of the vector table.
> >
> > I think there must be a memory reservation for the vector table at the start of the RAMABLE_REGION.
>
> Exact
>
> >
> >
> > I still do not see why execution in place (XIP) mandates the interrupt vector table to be in SRAM. This should be a different configuration option to be set by e.g. bootloaders. Event bootloaders may avoid that by using trampolines. Based on this option the memory at the start of the SRAM can be reseved, the SRAM mapped to address 0 and the vector table transfered from flash to SRAM.
>
> Yes it should, then it should disable all the dynamic update and generation of the vector table.
>
>
> There are use cases where you really do not need the dynamic updates (mine for example - updates are done by the supervising system) but as much RAM as possible. So why not make it a config option?
Yes, I think the SRAM mapped case should be an option, but selected by default. Anyway, something must be pushed along the STM32F0 basic support.
Neil
>
>
> >
> >
> > Bobby
> >
> > 2017-09-11 17:09 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@baylibre.com> <mailto:narmstrong@baylibre.com <mailto:narmstrong@baylibre.com>>>:
> >
> > Hi,
> >
> > Since Cortex-M0 cannot relocate the vector base with a processor register, the vector must be moved.
> >
> > Yes you can map the first kbytes of the flash to the first 32k bytes of 0, but you won't tun change the vector or run other applications if you have a bootloader.
> >
> > But yes, you may need to add a further Kconfig to completely disable relocation, but also disable vector modification because it can only occur in this SRAM mapped a 0.
> >
> > Neil
> >
> > On 09/11/2017 04:02 PM, b0661 wrote:
> > > Hi Neil,
> > >
> > > the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
> > >
> > > I would appreciate to save precious SRAM and do the remap only if it is needed.
> > >
> > > I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
> > >
> > > My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
> > >
> > > I will test your patch.
> > >
> > > Bobby
> > >
> > >
> > > 2017-09-11 14:54 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@baylibre.com> <mailto:narmstrong@baylibre.com <mailto:narmstrong@baylibre.com>> <mailto:narmstrong@baylibre.com <mailto:narmstrong@baylibre.com> <mailto:narmstrong@baylibre.com <mailto:narmstrong@baylibre.com>>>>:
> > >
> > > Hi Maciej, Bobby,
> > >
> > > Could test the following patch ?
> > >
> > > If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
> > >
> > >
> > > --><---------------------------------------------------------------------------
> > >
> > > diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> > > index 1382379..57e0e92 100644
> > > --- a/arch/arm/core/cortex_m/prep_c.c
> > > +++ b/arch/arm/core/cortex_m/prep_c.c
> > > @@ -26,12 +26,25 @@
> > >
> > > #ifdef CONFIG_ARMV6_M
> > >
> > > +/**
> > > + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> > > + * This functions is a hook before the vector memory relocation to
> > > + * ensure the mapped memory is correct.
> > > + */
> > > +void __weak relocate_vector_memory(void)
> > > +{
> > > + /* Nothing to do by default */
> > > +}
> > > +
> > > #define VECTOR_ADDRESS 0
> > > static inline void relocate_vector_table(void)
> > > {
> > > #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> > > !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > > size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> > > +
> > > + relocate_vector_memory();
> > > +
> > > memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> > > #endif
> > > }
> > > diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
> > > index 727c348..2c056c2 100644
> > > --- a/arch/arm/soc/st_stm32/stm32f0/soc.c
> > > +++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
> > > @@ -17,6 +17,16 @@
> > > #include <cortex_m/exc.h>
> > >
> > > /**
> > > + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> > > + * This functions is a hook before the vector memory relocation to
> > > + * ensure the mapped memory is correct.
> > > + */
> > > +void relocate_vector_memory(void)
> > > +{
> > > + LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
> > > +}
> > > +
> > > +/**
> > > * @brief This function configures the source of stm32cube time base.
> > > * Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
> > > * Tick interrupt priority is not used
> > > --
> > >
> > > Thanks,
> > > Neil
> > >
> > >
> > > On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> > > > Hi All,
> > > >
> > > > On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
> > > >
> > > > I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
> > > >
> > > > Neil
> > > >
> > > > On 09/11/2017 12:06 PM, Neil Armstrong wrote:
> > > >> Hi All,
> > > >>
> > > >> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
> > > >>
> > > >> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
> > > >>
> > > >> The #if is bogus :
> > > >> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > > >>
> > > >> And it doesn't take in account what is actually mapped at address 0 !
> > > >>
> > > >> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
> > > >>
> > > >> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
> > > >>
> > > >> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
> > > >>
> > > >> Neil
> > > >>
> > > >> On 09/03/2017 07:22 PM, b0661 wrote:
> > > >>> Hello Maciej,
> > > >>>
> > > >>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
> > > >>>
> > > >>> The commit "arch: arm: core: fix vector table relocate write to flash"
> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>>>
> > > >>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
> > > >>>
> > > >>> I do not have a board that needs the relocation. So this is untested for such boards.
> > > >>> Nevertheless the commit passes my local sanity check.
> > > >>>
> > > >>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
> > > >>>
> > > >>> Bobby
> > > >>>
> > > >>>
> > > >>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>>> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>>>>>:
> > > >>>
> > > >>> Gentlemen,
> > > >>>
> > > >>> thank you for your quick responses!
> > > >>>
> > > >>> As I wanted to provide more info and debug output, I accidentally found the issue.
> > > >>> This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
> > > >>>
> > > >>> Here is the commit:
> > > >>> https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
> > > >>> On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>>> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@rndity.com <mailto:maciej.debski@rndity.com>>>>> wrote:
> > > >>>
> > > >>> Hello,
> > > >>>
> > > >>> I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
> > > >>>
> > > >>> I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
> > > >>>
> > > >>> I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
> > > >>> After checking the code over and over, I think I need help!
> > > >>>
> > > >>> I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
> > > >>>
> > > >>> https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>>>
> > > >>>
> > > >>> This is my pull request. I would focus on dts/arm and include/dt-bindings.
> > > >>>
> > > >>> Yours faithfully,
> > > >>> Maciej Dębski
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> Zephyr-devel mailing list
> > > >>> Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>>> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org> <mailto:Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>>>>
> > > >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Hi Bobby,
I was thinking of something similar, good work !
I'll test it,
@Maciej, would you have time to test it and integrate it to your pull request ?
Thanks,
Neil
toggle quoted message
Show quoted text
On 09/13/2017 09:54 PM, b0661 wrote: Hi Neil,
I created another vector table relocation function and adjusted the linker control file.
Please have a look at https://github.com/b0661/zephyr/commit/6be292fab8580b3afa4a50cd59b8c406701d08d3.
I don´t know much about the bootloader mechanisms you mentioned - please review/ comment.
Thanks
Bobby
2017-09-13 14:44 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...>>:
On 09/13/2017 02:30 PM, b0661 wrote:
> Hi Neal,
>
> 2017-09-13 14:10 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>>>:
>
> On 09/13/2017 02:09 PM, b0661 wrote:
> > Hi Neal,
> >
> > I had a look at the linker script https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld> <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld>> which is also used for STM32F0.
> >
> > Transfer of the vector table to address 0.. of the SRAM will either write to the application .data section or the kernel .bss section. The .bss section will be zeroed just after the relocation of the vector table.
> >
> > I think there must be a memory reservation for the vector table at the start of the RAMABLE_REGION.
>
> Exact
>
> >
> >
> > I still do not see why execution in place (XIP) mandates the interrupt vector table to be in SRAM. This should be a different configuration option to be set by e.g. bootloaders. Event bootloaders may avoid that by using trampolines. Based on this option the memory at the start of the SRAM can be reseved, the SRAM mapped to address 0 and the vector table transfered from flash to SRAM.
>
> Yes it should, then it should disable all the dynamic update and generation of the vector table.
>
>
> There are use cases where you really do not need the dynamic updates (mine for example - updates are done by the supervising system) but as much RAM as possible. So why not make it a config option?
Yes, I think the SRAM mapped case should be an option, but selected by default. Anyway, something must be pushed along the STM32F0 basic support.
Neil
>
>
> >
> >
> > Bobby
> >
> > 2017-09-11 17:09 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>> <mailto:narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>>>>:
> >
> > Hi,
> >
> > Since Cortex-M0 cannot relocate the vector base with a processor register, the vector must be moved.
> >
> > Yes you can map the first kbytes of the flash to the first 32k bytes of 0, but you won't tun change the vector or run other applications if you have a bootloader.
> >
> > But yes, you may need to add a further Kconfig to completely disable relocation, but also disable vector modification because it can only occur in this SRAM mapped a 0.
> >
> > Neil
> >
> > On 09/11/2017 04:02 PM, b0661 wrote:
> > > Hi Neil,
> > >
> > > the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
> > >
> > > I would appreciate to save precious SRAM and do the remap only if it is needed.
> > >
> > > I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
> > >
> > > My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
> > >
> > > I will test your patch.
> > >
> > > Bobby
> > >
> > >
> > > 2017-09-11 14:54 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>> <mailto:narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>>> <mailto:narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>> <mailto:narmstrong@... <mailto:narmstrong@...> <mailto:narmstrong@... <mailto:narmstrong@...>>>>>:
> > >
> > > Hi Maciej, Bobby,
> > >
> > > Could test the following patch ?
> > >
> > > If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
> > >
> > >
> > > --><---------------------------------------------------------------------------
> > >
> > > diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> > > index 1382379..57e0e92 100644
> > > --- a/arch/arm/core/cortex_m/prep_c.c
> > > +++ b/arch/arm/core/cortex_m/prep_c.c
> > > @@ -26,12 +26,25 @@
> > >
> > > #ifdef CONFIG_ARMV6_M
> > >
> > > +/**
> > > + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> > > + * This functions is a hook before the vector memory relocation to
> > > + * ensure the mapped memory is correct.
> > > + */
> > > +void __weak relocate_vector_memory(void)
> > > +{
> > > + /* Nothing to do by default */
> > > +}
> > > +
> > > #define VECTOR_ADDRESS 0
> > > static inline void relocate_vector_table(void)
> > > {
> > > #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> > > !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > > size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> > > +
> > > + relocate_vector_memory();
> > > +
> > > memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> > > #endif
> > > }
> > > diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
> > > index 727c348..2c056c2 100644
> > > --- a/arch/arm/soc/st_stm32/stm32f0/soc.c
> > > +++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
> > > @@ -17,6 +17,16 @@
> > > #include <cortex_m/exc.h>
> > >
> > > /**
> > > + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
> > > + * This functions is a hook before the vector memory relocation to
> > > + * ensure the mapped memory is correct.
> > > + */
> > > +void relocate_vector_memory(void)
> > > +{
> > > + LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
> > > +}
> > > +
> > > +/**
> > > * @brief This function configures the source of stm32cube time base.
> > > * Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
> > > * Tick interrupt priority is not used
> > > --
> > >
> > > Thanks,
> > > Neil
> > >
> > >
> > > On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> > > > Hi All,
> > > >
> > > > On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
> > > >
> > > > I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
> > > >
> > > > Neil
> > > >
> > > > On 09/11/2017 12:06 PM, Neil Armstrong wrote:
> > > >> Hi All,
> > > >>
> > > >> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
> > > >>
> > > >> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
> > > >>
> > > >> The #if is bogus :
> > > >> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > > >>
> > > >> And it doesn't take in account what is actually mapped at address 0 !
> > > >>
> > > >> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
> > > >>
> > > >> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
> > > >>
> > > >> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
> > > >>
> > > >> Neil
> > > >>
> > > >> On 09/03/2017 07:22 PM, b0661 wrote:
> > > >>> Hello Maciej,
> > > >>>
> > > >>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way execution.
> > > >>>
> > > >>> The commit "arch: arm: core: fix vector table relocate write to flash"
> > > >>> https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314
<https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>
> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>>>>
> > > >>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
> > > >>>
> > > >>> I do not have a board that needs the relocation. So this is untested for such boards.
> > > >>> Nevertheless the commit passes my local sanity check.
> > > >>>
> > > >>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
> > > >>>
> > > >>> Bobby
> > > >>>
> > > >>>
> > > >>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@...
<mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>>>>:
> > > >>>
> > > >>> Gentlemen,
> > > >>>
> > > >>> thank you for your quick responses!
> > > >>>
> > > >>> As I wanted to provide more info and debug output, I accidentally found the issue.
> > > >>> This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
> > > >>>
> > > >>> Here is the commit:
> > > >>> https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
<https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>
> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
<https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>>>>
> > > >>>
> > > >>> And here are the specific changes causing problem:
> > > >>>
> > > >>> diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
> > > >>> index d23dd8b..1382379 100644
> > > >>> --- a/arch/arm/core/cortex_m/prep_c.c
> > > >>> +++ b/arch/arm/core/cortex_m/prep_c.c
> > > >>> @@ -22,9 +22,20 @@
> > > >>> #include <linker/linker-defs.h>
> > > >>> #include <nano_internal.h>
> > > >>> #include <arch/arm/cortex_m/cmsis.h>
> > > >>> +#include <string.h>
> > > >>>
> > > >>> #ifdef CONFIG_ARMV6_M
> > > >>> -static inline void relocate_vector_table(void) { /* do nothing */ }
> > > >>> +
> > > >>> +#define VECTOR_ADDRESS 0
> > > >>> +static inline void relocate_vector_table(void)
> > > >>> +{
> > > >>> +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
> > > >>> + !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
> > > >>> + size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
> > > >>> + memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
> > > >>> +#endif
> > > >>> +}
> > > >>> +
> > > >>> #elif defined(CONFIG_ARMV7_M)
> > > >>> #ifdef CONFIG_XIP
> > > >>> #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
> > > >>>
> > > >>>
> > > >>> When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
> > > >>> What should I do now? How to report it properly?
> > > >>>
> > > >>> Thank you!
> > > >>>
> > > >>> Yours faithfully,
> > > >>> Maciej Dębski
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>> <mailto:maciej.debski@... <mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>> <mailto:maciej.debski@...
<mailto:maciej.debski@...> <mailto:maciej.debski@... <mailto:maciej.debski@...>>>>>> wrote:
> > > >>>
> > > >>> Hello,
> > > >>>
> > > >>> I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
> > > >>>
> > > >>> I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
> > > >>>
> > > >>> I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
> > > >>> After checking the code over and over, I think I need help!
> > > >>>
> > > >>> I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
> > > >>>
> > > >>> https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>>>
<https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>>>>
> > > >>>
> > > >>> This is my pull request. I would focus on dts/arm and include/dt-bindings.
> > > >>>
> > > >>> Yours faithfully,
> > > >>> Maciej Dębski
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> Zephyr-devel mailing list
> > > >>> Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@...
<mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>>>>
> > > >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
<https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> Zephyr-devel mailing list
> > > >>> Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...> <mailto:Zephyr-devel@... <mailto:Zephyr-devel@...>>>>
> > > >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
<https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>>
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
