Re: os data.core memory section
Hey Will, thanks for the background - much appreciated. I did indeed need the additional memory to store a time series generated at high frequencies, so offloading wasn't an option. I solved it by storing some of the time series in CCM memory, which is probably the better solution anyway. Given the constraints around CCM and DTCM, it might actually be better if the OS doesn't use it. I guess I got confused, misled by the "core" in the section name, which in retrospect probably applies to the MCU and not the OS. Thanks for all the input, Markus On Mon, 2 Apr 2018 10:54:32 -0700 will sanfilippowrote: > Markus: > > I presume you are referring to these definitions: > > #define sec_data_core __attribute__((section(".data.core"))) > #define sec_bss_core__attribute__((section(".bss.core"))) > #define sec_bss_nz_core __attribute__((section(".bss.core.nz"))) > > As far as I know there is no real magic here but I am sure there is > some degree of inconsistency. > > The reason sec_bss_nz_core was added was to get around a HW problem > with early nordic chips (you can see the reference in nrf52.ld) so I > do not doubt that this is no longer used. Personally, I think the > idea of having a “non-zeroed .bss” is pretty cool. I guess one could > simply call that the heap but sometimes you just like allocating a > global variable and not allocating it from the heap. I realize that > the only real reason to do this is save time in the startup code > zeroing out memory (but still; that is cool!) :-) Not quite sure why > “core” was added to that defintion. Maybe because there was some > conflict with naming it bss.nz? > > I should probably look at the STM startup code to be sure of this but > I presume they use sec_data_core for both code and data they want to > locate in CCM. This is basically a .data section in that the startup > code needs to copy this from flash (whether it be code or initialized > data). > > I guess sec_bss_core is used to store variables in CCM that just need > to get zeroed by the startup code. > > btw, I am no STM CPU/memory architecture expert but I was reading up > on it and they do not suggest putting both code and data into CCM. Of > course, if you need the RAM you need the RAM… Is that why you want to > move a stack there? I guess if all your code is executing from flash > then putting data into CCM is fine (maybe faster is SRAM is slower?). > > Seems to me it would be nice to differentiate “core text” from “core > data”. No real reason I guess but seems a bit more intuitive. Might > be nice to come up with a set of “standard” section definitions (if > they do not already exist somewhere) that we can apply across all > BSPs/MCUs. > > > > On Mar 31, 2018, at 4:02 PM, markus wrote: > > > > I looked into moving the stack into the CCM memory of the stm32 > > mcu's - and although almost every linker script defines ".data.core" > > sections and there are some defines in bsp.h's for section > > attributes they don't seem to be used. > > > > Is there some hidden magic going on or is the CCM reserved for > > application code? > > > > Have fun, > > Markus >
Re: os data.core memory section
On Mon, Apr 2, 2018, at 4:42 PM, markus wrote: > On Mon, 02 Apr 2018 14:16:54 -0300 > Fabio Utzigwrote: > > > Both > > > > hw/mcu/stm/stm32f7xx/stm32f767.ld > > hw/mcu/stm/stm32f4xx/stm32f407.ld > > > > already define the stack on CCM (called DTCM on the F7xx). Am I > > missing something here? > > It might be me who's missing something (most likely scenario). The > linker scripts do indeed define the DTCM and CCM memory regions and > gives them names, ".stack" and ".data.core" depending on the linker > script. What I'm missing is that those sections aren't used anywhere in > the code. > > The stacks for (main/idle) tasks are defined by OS_TASK_STACK_DEFINE in > os_task.h, which sets the alignment but not the section. Looking at the > generated memory map from an stm32f7 app all the sections are there but > I cannot identify anything actually placed in there. > > But then the linker has always been a bit of a dark art to me so I > might just not be looking at the right things, or properly interpret > what I'm seeing. Ah, I see what you mean now, seems correct. Beyond main/idle it lso applies to any task for which the stack was allocated with malloc.
Re: os data.core memory section
On Mon, 02 Apr 2018 14:16:54 -0300 Fabio Utzigwrote: > Both > > hw/mcu/stm/stm32f7xx/stm32f767.ld > hw/mcu/stm/stm32f4xx/stm32f407.ld > > already define the stack on CCM (called DTCM on the F7xx). Am I > missing something here? It might be me who's missing something (most likely scenario). The linker scripts do indeed define the DTCM and CCM memory regions and gives them names, ".stack" and ".data.core" depending on the linker script. What I'm missing is that those sections aren't used anywhere in the code. The stacks for (main/idle) tasks are defined by OS_TASK_STACK_DEFINE in os_task.h, which sets the alignment but not the section. Looking at the generated memory map from an stm32f7 app all the sections are there but I cannot identify anything actually placed in there. But then the linker has always been a bit of a dark art to me so I might just not be looking at the right things, or properly interpret what I'm seeing. > > On Mon, Apr 2, 2018, at 2:15 PM, Christopher Collins wrote: > > Hi Markus, > > > > On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote: > > > I looked into moving the stack into the CCM memory of the stm32 > > > mcu's - and although almost every linker script defines > > > ".data.core" sections and there are some defines in bsp.h's for > > > section attributes they don't seem to be used. > > > > > > Is there some hidden magic going on or is the CCM reserved for > > > application code? > > > > No hidden magic; CCM is mostly unused and is up for grabs. I think > > there was some attempt to use this memory intelligently a while > > back, but as the number of supported BSPs increased, it became > > impractical. > > > > When you say "the stack", do you mean the interrupt handler stack? > > That sounds like a reasonable use of CCM (though you and others > > probably have a better sense of this than I do). If this is > > something that users will want to do, it might be good to create a > > syscfg setting to control whether the stack gets put in CCM or > > normal RAM. > > > > Chris
Re: os data.core memory section
Markus: I presume you are referring to these definitions: #define sec_data_core __attribute__((section(".data.core"))) #define sec_bss_core__attribute__((section(".bss.core"))) #define sec_bss_nz_core __attribute__((section(".bss.core.nz"))) As far as I know there is no real magic here but I am sure there is some degree of inconsistency. The reason sec_bss_nz_core was added was to get around a HW problem with early nordic chips (you can see the reference in nrf52.ld) so I do not doubt that this is no longer used. Personally, I think the idea of having a “non-zeroed .bss” is pretty cool. I guess one could simply call that the heap but sometimes you just like allocating a global variable and not allocating it from the heap. I realize that the only real reason to do this is save time in the startup code zeroing out memory (but still; that is cool!) :-) Not quite sure why “core” was added to that defintion. Maybe because there was some conflict with naming it bss.nz? I should probably look at the STM startup code to be sure of this but I presume they use sec_data_core for both code and data they want to locate in CCM. This is basically a .data section in that the startup code needs to copy this from flash (whether it be code or initialized data). I guess sec_bss_core is used to store variables in CCM that just need to get zeroed by the startup code. btw, I am no STM CPU/memory architecture expert but I was reading up on it and they do not suggest putting both code and data into CCM. Of course, if you need the RAM you need the RAM… Is that why you want to move a stack there? I guess if all your code is executing from flash then putting data into CCM is fine (maybe faster is SRAM is slower?). Seems to me it would be nice to differentiate “core text” from “core data”. No real reason I guess but seems a bit more intuitive. Might be nice to come up with a set of “standard” section definitions (if they do not already exist somewhere) that we can apply across all BSPs/MCUs. > On Mar 31, 2018, at 4:02 PM, markuswrote: > > I looked into moving the stack into the CCM memory of the stm32 > mcu's - and although almost every linker script defines ".data.core" > sections and there are some defines in bsp.h's for section > attributes they don't seem to be used. > > Is there some hidden magic going on or is the CCM reserved for > application code? > > Have fun, > Markus
Re: os data.core memory section
Both hw/mcu/stm/stm32f7xx/stm32f767.ld hw/mcu/stm/stm32f4xx/stm32f407.ld already define the stack on CCM (called DTCM on the F7xx). Am I missing something here? On Mon, Apr 2, 2018, at 2:15 PM, Christopher Collins wrote: > Hi Markus, > > On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote: > > I looked into moving the stack into the CCM memory of the stm32 > > mcu's - and although almost every linker script defines ".data.core" > > sections and there are some defines in bsp.h's for section > > attributes they don't seem to be used. > > > > Is there some hidden magic going on or is the CCM reserved for > > application code? > > No hidden magic; CCM is mostly unused and is up for grabs. I think > there was some attempt to use this memory intelligently a while back, > but as the number of supported BSPs increased, it became impractical. > > When you say "the stack", do you mean the interrupt handler stack? That > sounds like a reasonable use of CCM (though you and others probably have > a better sense of this than I do). If this is something that users will > want to do, it might be good to create a syscfg setting to control > whether the stack gets put in CCM or normal RAM. > > Chris
Re: os data.core memory section
Hi Markus, On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote: > I looked into moving the stack into the CCM memory of the stm32 > mcu's - and although almost every linker script defines ".data.core" > sections and there are some defines in bsp.h's for section > attributes they don't seem to be used. > > Is there some hidden magic going on or is the CCM reserved for > application code? No hidden magic; CCM is mostly unused and is up for grabs. I think there was some attempt to use this memory intelligently a while back, but as the number of supported BSPs increased, it became impractical. When you say "the stack", do you mean the interrupt handler stack? That sounds like a reasonable use of CCM (though you and others probably have a better sense of this than I do). If this is something that users will want to do, it might be good to create a syscfg setting to control whether the stack gets put in CCM or normal RAM. Chris