On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 16/08/2020 18:09, Utkarsh Rai wrote: > > > > > > > On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom <ged...@rtems.org > > <mailto:ged...@rtems.org>> wrote: > > > > On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai > > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: > > > > > > > > > > > > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai > > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: > > >> > > >> > > >> > > >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <ged...@rtems.org > > <mailto:ged...@rtems.org>> wrote: > > >>> > > >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai > > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: > > >>> > > > >>> > > > >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai > > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: > > >>> >> > > >>> >> Thanks, I'll check them out. > > >>> >> > > >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom > > <ged...@rtems.org <mailto:ged...@rtems.org>> wrote: > > >>> >>> > > >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai > > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: > > >>> >>> > > > >>> >>> > Hello, > > >>> >>> > I have been testing my code for thread stack isolation > > against various tests( Some written by me, and remaining already > > present). One of the limitations that I have found is that I > > encounter fatal errors whenever a context switch takes place > > through an ISR. Can you please explain how the context switching > > procedure works when an interrupt occurs. When I use gdb for > > stepping through the code it asynchronously moves to context > > switching code from the executing thread( for example psx16 test). > > >>> >>> > For thread stack protection, the part that deals with > > context switching simply 'sets 'the memory entries of the heir > > stack and 'unsets' that of the executing stack. > > >>> >>> > > >>> >>> There are two issues to start: interrupt stacks and > > dispatching from an ISR. > > >>> >>> > > >>> >>> I think you can start by reading some of the documentation: > > >>> >>> > > > https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt > > >>> >>> > > >>> >>> > > > https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks > > >>> >>> > > >>> >>> > > > https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size > > >>> >>> > > >>> >>> > > > https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing > > >>> >>> > > >>> >>> You can also find some material in rtems-docs.git/porting > > -- I don't > > >>> >>> know where that gets generated. > > >>> >>> > > >>> >>> Continue to ask questions, and writing blog posts. > > >>> > > > >>> > > > >>> > So after going through the materials, I was able to > > understand how an ISR is registered, ISR stack initialization. > > What is still not clear to me is what are the differences between > > dispatching a task in ISR different and a normal context-switch? > > >>> > > > >>> > For example the psxsignal06 test, we wait for a signal > > here, on setting the breakpoint at the context switch code > > (cpu_asm.S), after this line, I find that the heir context stack > > is the ISR stack. The next thread is dispatched from this ISR but > > as soon as I unset the memory attributes of the ISR stack I get a > > fatal error. One possible reason is that the ISR stack is not page > > aligned and unsettling its attributes unsets nearby memory > > regions. Is there something else that I am missing? > > >>> > > > >>> what else is on the same page as the ISR stack? > > >>> > > >> > > >> The idle thread stack is between 0x202e40 to 0x203e40 and the > > ISR stack is between 0x203e40 to 0x204e40. So when we unset the > > memory for the ISR it unsets between 0x203000 to 0x205000, I think > > this may be the problem. > > >> > > >> > > >>> > > >>> Not quite related, you'll need to also make sure to map the > > ISR stack > > >>> back in during ISR Handling, before using it. > > >> > > >> > > >> When the ISR gets called for the first time, it already has R/W > > permission and for subsequent context switches it's memory entry > > is accordingly set/unset. > > > > > > > > > The idle thread stack and the ISR stack are placed at these > > addresses with the BSP specific linker script as "rtemsstack.idle" > > and "rtemsstack.interrupt". So to make them page-aligned we may > > have to make changes in the lnker script. > > > > Give it a try. It should be relatively easy to hack in a couple of > > alignments. > > > > We can discuss later the correctness of that. > > > > Ok, I will report how it goes. > > Please use the CPU port option > > #define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES > > to define the interrupt and idle stack alignment. There is no need to > change the linker command file. > Thank you, this solves the issue. I have used, #define CPU_INTERRUPT_STACK_ALIGNMENT 4096, in the application code as well as cpu.h, to align for 4K pages.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel