[PATCH] arm: Fix ARMv7-M exception handler

[Sebastian Huber]

Store the stack pointer of the exception context to the exception frame.

Close #3987.
---
 .../score/cpu/arm/armv7m-exception-default.c  | 23 ---
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c 
b/cpukit/score/cpu/arm/armv7m-exception-default.c
index 0e4efad263..b57dac8d7a 100644
--- a/cpukit/score/cpu/arm/armv7m-exception-default.c
+++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
@@ -40,13 +40,20 @@ void __attribute__((naked)) _ARMV7M_Exception_default( void 
)
 "stm sp, {r0-r12}\n"
 "tst lr, #4\n"  /* Check if bit 2 of LR is zero. If so, PSR.Z = 1 
*/
 "itte eq\n" /* IF bit 2 of LR is zero... (PSR.Z == 1) */
-"mrseq r0, msp\n"   /* THEN we were using MSP. */
-"addeq r0, %[cpufsz]\n" /* THEN, set r0 = old MSP value. */
-"mrsne r0, psp\n"   /* ELSE it's not zero; we were using PSP. */
-"add r2, r0, %[v7mlroff]\n"
-"add r1, sp, %[cpulroff]\n"
-"ldm r2, {r3-r5}\n" /* Grab LR, PC and PSR from the stack.. */
-"stm r1, {r3-r5}\n" /* ..and store them in our CPU_Exception_frame. */
+"mrseq r3, msp\n"   /* THEN we were using MSP */
+"addeq r3, %[cpufsz]\n" /* THEN, set r3 = old MSP value */
+"mrsne r3, psp\n"   /* ELSE it is not zero; we were using PSP */
+"add r2, r3, %[v7mlroff]\n"
+"add r1, sp, %[cpuspoff]\n"
+"ldm r2, {r4-r6}\n" /* Grab LR, PC and xPSR from the stack */
+"tst lr, #16\n" /* Check if we have an FP state on the frame */
+"ite eq\n"
+"addeq r3, #104\n"  /* Back to previous SP with FP state */
+"addne r3, #32\n"   /* Back to previous SP without FP state */
+"tst r6, #512\n"/* Check xPSR if the SP was aligned */
+"it ne\n"
+"addne r3, #4\n"/* Undo alignment */
+"stm r1, {r3-r6}\n" /* Store to CPU_Exception_frame */
 "mrs r1, ipsr\n"
 "str r1, [sp, %[cpuvecoff]]\n"
 
@@ -85,7 +92,7 @@ void __attribute__((naked)) _ARMV7M_Exception_default( void )
 "b _ARM_Exception_default\n"
 :
 : [cpufsz] "i" (sizeof(CPU_Exception_frame)),
-  [cpulroff] "i" (offsetof(CPU_Exception_frame, register_lr)),
+  [cpuspoff] "i" (offsetof(CPU_Exception_frame, register_sp)),
   [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, register_lr)),
   [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
   [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] arm: Fix ARMv7-M exception handler

[Chris Johns]

> On 27 May 2020, at 5:43 pm, Sebastian Huber 
>  wrote:
> 
> Store the stack pointer of the exception context to the exception frame.

Ok to push. 

Chris

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems] libfreebsd: RTEMS to FreeBSD porting helper header

[G S Niteesh Babu]

This file serve the purpose as rtems-bsd-kernel-space.h in the
rtems-libbsd.
This file is intended to be included in every source file that
is to imported from FreeBSD. This is to reduce the number of
redefinitions for commonly used functions like malloc, free
and KASSERT.
---
 cpukit/libfreebsd/rtems-freebsd-helper.h | 44 
 1 file changed, 44 insertions(+)
 create mode 100644 cpukit/libfreebsd/rtems-freebsd-helper.h

diff --git a/cpukit/libfreebsd/rtems-freebsd-helper.h 
b/cpukit/libfreebsd/rtems-freebsd-helper.h
new file mode 100644
index 00..8135a1caf5
--- /dev/null
+++ b/cpukit/libfreebsd/rtems-freebsd-helper.h
@@ -0,0 +1,44 @@
+
+/* SPDX-License-Identifier: BSD-2-Clause
+
+ *
+ * @file
+ *
+ * @ingroup LIBFREEBSD
+ *
+ * @brief
+ */
+
+/*
+ * Copyright (C) <2020> Niteesh Babu 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H
+#define _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H
+
+#define KASSERT(cnd, msg)   assert(cnd)
+#define malloc(size, type, flags)   malloc(size)
+#define free(addr, type)free(addr)
+
+#endif /* _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H */
\ No newline at end of file
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

[Gedare Bloom]

On Tue, May 26, 2020 at 6:12 PM Utkarsh Rai  wrote:
>
>
>
> On Mon, May 25, 2020 at 9:32 PM Gedare Bloom  wrote:
>>
>> On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai  wrote:
>> >
>> >
>> > On Fri, May 22, 2020, at 10:59 AM Gedare Bloom  wrote:
>> >>
>> >> >  This means that our low-level design for providing thread stack 
>> >> > protection may look something like this:-
>> >> >
>> >> > 1. For MPU based processors, the number of protected stacks will depend 
>> >> > on the number of protection domains i.e. for MPUs with 8 protection 
>> >> > domains we can have 7 protected stacks ( 1 of the region will be 
>> >> > assigned for global data). For MMU based system we will have a section 
>> >> > (a page of size 1MB) for global data and task address space will be 
>> >> > divided into smaller pages, page sizes will be decided by keeping in 
>> >> > mind the number of TLB entries, in a manner I have described above in 
>> >> > the thread.
>> >> >
>> >> There is value to defining a few of the global regions. I'll assume
>> >> R/W/X permissions. Then code (.text) should be R/X. read-only data
>> >> sections should be grouped together and made R. Data sections should
>> >> be RW. And then stacks should be added to the end. The linker scripts
>> >> should be used to group the related sections together. I think some
>> >> ARM BSPs do some of this already.  That seems like a minimally useful
>> >> configuration for most users that would care, they want to have also
>> >> protection of code from accidental overwrite, and probably data too,
>> >> and non-executable data in general. You also may have to consider a
>> >> few more permission complications (shared/cacheable) depending on the
>> >> hardware.
>> >
>> >
>> > The low-level mmu implementation for ARMv7 BSPS has an 
>> > 'ARMV7_CP15_START_DEFAULT_SECTIONS' which lists out various regions with 
>> > appropriate permissions and then are grouped by a linker script. This 
>> > should be the standard way of handling the placement of statically 
>> > allocated regions.
>> >
>> >> >  2. The protection, size, page table, and sharing attributes of each 
>> >> > created thread will be tracked.
>> >> >
>> >> I'd rather we not be calling this a page table. MPU-based systems
>> >> don't have a notion of page table. But maybe it is OK as long as we
>> >> understand that you mean the data structure responsible for mapping
>> >> out the address space. I'm not sure what you mean by size, unless you
>> >> refer to that thread's stack.
>> >>
>> >> >  3. At every context switch, these attributes will be updated, the 
>> >> > static-global regions will be assigned a global ASID and will not 
>> >> > change during the switch only the protected regions will be updated.
>> >> >
>> >> Yes, assuming the hardware supports ASIDs and a global attribute.
>> >>
>> >> I don't know if you will be able to pin the global entries in
>> >> hardware. You'll want to keep an eye out for that. If not, you might
>> >> need to do something in software to ensure they don't get evicted
>> >> (e.g., touch them all before finishing a context switch assuming LRU
>> >> replacement).
>> >>
>> >> >  4. Whenever we share stacks, the page table entries of the shared 
>> >> > stack, with the access bits as specified by the mmap/shm high-level 
>> >> > APIs will be installed to the current thread. This is different from 
>> >> > simply providing the page table base address of the shared thread-stack 
>> >> > ( what if the user wants to make the shared thread only readable from 
>> >> > another thread while the 'original' thread is r/w enabled?) We will 
>> >> > also have to update the TLB by installing the shared regions while the 
>> >> > global regions remain untouched.
>> >> >
>> >>
>> >> Correct. I think we need to make a design decision whether a stack can
>> >> exceed one page. It will simplify things if we can assume that, but it
>> >> may limit applications unnecessarily. Have to think on that.
>> >
>> >
>> > If we go with the above assumption, we will need to increase the size of 
>> > the page i.e. pages of 16Kib or 64Kib. Most of the applications won't 
>> > require stacks of this size and will result in wasted memory for each 
>> > thread. I think it would be better if we have multiple pages, as most of 
>> > the applications will have stacks that may fit in a single 4KiB page 
>> > anyway.
>> >
>>
>> I mis-typed. I meant I think we can assume stacks fit in one page. It
>> would be impossible to deal with otherwise.
>>
>> >>
>> >> The "page table base address" points to the entire structure that maps
>> >> out a thread's address space, so you'd have to walk it to find the
>> >> entry/entries for its stack. So, definitely not something you'd want
>> >> to do.
>> >>
>> >> The shm/mmap should convey the privileges to the requesting thread
>> >> asking to share. This will result in adding the shared entry/entries
>> >> to that thread's address space, with the appropriately set
>> >> permissions. So, if the entr

Re: GSoC: Porting OFW to RTEMS

[Niteesh G. S.]

On Tue, May 26, 2020 at 11:26 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> On 25/05/2020 11:20, Niteesh G. S. wrote:
> > Hello,
> >
> > I have completed the porting of the OFW code from FreeBSD to RTEMS.
> > I do acknowledge the fact that we haven't decided on the directory for
> files
> > to be placed in. The previous conversation had stopped quite a while ago.
> > Christian suggested I work on the patch since that would also start the
> > conversation again and also refactoring the patch to the correct
> directory
> > will not be much of work.
> >
> > cpukit/libfreebsd was suggested as one of the directories to place the
> > ported
> > FreeBSD files. It is suggested to place all the source files under this
> > directory.
> > Since this will make the sync part easier. But this causes issues when
> > porting
> > BSP dependent files. Since RTEMS currently doesn't allow files in cpukit
> to
> > reference bsp headers. I faced a similar issue during my porting process
> > also.
> > The OFW init function require bsp_fdt_get function to get a reference to
> > the fdt
> > blob. But I can't include the bsp/fdt.h header file from a source file
> > under cpukit.
> > We must decide the directory quickly because my project will import other
> > FreeBSD sources like the pinmux driver for beaglebone into RTEMS.
>
> Do you have a suggestion for another directory?
>
> If cpukit makes problems (which it clearly does due to the BSP
> dependencies) maybe something in bsps/shared?
>

The more organized way, in my opinion, will be to have the source files
in their respective directories. This is would make more sense than having
all source files under a single directory. But as discussed in the previous
mailing list using this approach will make it harder for the person writing
the sync script. I also have no idea of what complexity goes behind such
a script. So points from the person who's most probably going to write the
script will be really important.


> >
> > https://github.com/gs-niteesh/rtems/commits/ofw_branch
>
> For small patches it would be better to send them to the list using "git
> send-email". That allows to comment directly on the patches. But in this
> case using a repo is OK because especially the import is quite big.
>

Once we have a decent enough patch I'll send it to the mailing list.


> I'll add comments for small stuff directly on github. I hope that works ;-)
>
> Best regards
>
> Christian
>
> > Please have a look at the last 6 patches for the ported work.
> > Below is a short summary of the patch.
> > * The openfirm.h is the OF interface that will provided to the user.
> > * The openfirm.c contains the function definition for openfirm.h. The
> > functions
> > call the respective OFW_* functions which are responsible for choosing
> > the correct implementation for OF interface.
> > * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto
> > generated
> > header in FreeBSD which choose the correct OF implementation(ofw_fdt,
> > ofw_std,
> > ofw_32bit, ofw_real). In RTEMS we directly map to the FDT implementation
> as
> > suggested by Sebastian.
> > * ofw_fdt.c contains the fdt implementation of OF interface.
> >
> > Thanks,
> > Niteesh.
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

BSP to run PPC testsuite

[Eshan Dhawan]

Hello everyone,
I had added FENV support for PowerPC,
which BSP would be suitable to run testsuite.
also configurations of qemu-system-ppc  would be used ?

Thanks
- Eshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP to run PPC testsuite

[Joel Sherrill]

On Wed, May 27, 2020, 11:51 AM Eshan Dhawan  wrote:

> Hello everyone,
> I had added FENV support for PowerPC,
> which BSP would be suitable to run testsuite.
> also configurations of qemu-system-ppc  would be used ?
>

Use psim which is built into gdb. It has a configuration with the RTEMS
tester

>
> Thanks
> - Eshan
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: Porting OFW to RTEMS

[Niteesh G. S.]

On Wed, May 27, 2020 at 12:04 AM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> On 26/05/2020 19:56, Christian Mauderer wrote:
> > Hello Niteesh,
> >
> > On 25/05/2020 11:20, Niteesh G. S. wrote:
> >> Hello,
> >>
> >> I have completed the porting of the OFW code from FreeBSD to RTEMS.
> >> I do acknowledge the fact that we haven't decided on the directory for
> files
> >> to be placed in. The previous conversation had stopped quite a while
> ago.
> >> Christian suggested I work on the patch since that would also start the
> >> conversation again and also refactoring the patch to the correct
> directory
> >> will not be much of work.
> >>
> >> cpukit/libfreebsd was suggested as one of the directories to place the
> >> ported
> >> FreeBSD files. It is suggested to place all the source files under this
> >> directory.
> >> Since this will make the sync part easier. But this causes issues when
> >> porting
> >> BSP dependent files. Since RTEMS currently doesn't allow files in
> cpukit to
> >> reference bsp headers. I faced a similar issue during my porting process
> >> also.
> >> The OFW init function require bsp_fdt_get function to get a reference to
> >> the fdt
> >> blob. But I can't include the bsp/fdt.h header file from a source file
> >> under cpukit.
> >> We must decide the directory quickly because my project will import
> other
> >> FreeBSD sources like the pinmux driver for beaglebone into RTEMS.
> >
> > Do you have a suggestion for another directory?
> >
> > If cpukit makes problems (which it clearly does due to the BSP
> > dependencies) maybe something in bsps/shared?
> >
> >>
> >> https://github.com/gs-niteesh/rtems/commits/ofw_branch
> >
> > For small patches it would be better to send them to the list using "git
> > send-email". That allows to comment directly on the patches. But in this
> > case using a repo is OK because especially the import is quite big.
> >
> > I'll add comments for small stuff directly on github. I hope that works
> ;-)
>
> Finished adding comments for small stuff. Some bigger questions:
>
> - How do you plan to include ofw_if.h in some driver files? RTEMS
> currently puts every file that can be included with  into a path
> called "include".


Will ofw_if.h be included in driver files? As far as I have searched in the
FreeBSD sources, other than the OFW implementation none of the driver
files include this header. So this could be placed in the same directory as
the OFW sources and need not be added to the global include path.
If there is a case where it is included in some driver please let me know.

And also all the references to this header in the OFW implementations are
relative so in future, if we add other implementations, having it in the
same
directory would be the right choice.



> - You created quite some commits. I would suggest to merge all porting
> commits so that you have one import commit, one port commit and maybe
> one commit adding RTEMS specific files


I have squashed them into a single port commit.


>

- You have at least one completely hand written file (ofw_if.h). Maybe
> we should think about whether that is located well in the same directory
> as the imported code or whether a similar structure like used in libbsd
> would be better. One tree for imported files and one for RTEMS specific
> hand written ones.
>

Do we need a separate directory for RTEMS specific handwritten ones depends
on what we will be importing in the future? Since we intend only to import
mostly
driver related code I don't think there is a need for a separate directory.
I think
this way because I assuming we don't need any RTEMS specific file for the
drivers.
But if we plan to include some simple subsystem then having a separate
directory
will be nice.

This also makes me think about if having all sources under a single
directory under
cpukit a good idea. Since our main import targets are drivers placing them
in the
cpukit directory or any other directory other than their respective BSP
directory is not
a good idea. This would make writing the sync script harder but this will
decrease the
coupling and dependencies between various folders. The other way around
will be
to have all headers accessible in the global path i.e. files under cpukit
should be
able to access bsp related headers. This would increase the coupling but I
guess
it will make writing the script easier since it has to track only a single
directory.
I am not really sure which is a better tradeoff. If someone could shed some
light on
the complexity of the script it'll help in coming up with a conclusion
easier.
But from a logical perspective, Having the drivers in their respective
directories
seems to be a better idea to me.


> Please see all comments as advises. Feel free to argue against any of
> them if you think different ;-)
>
> Best regards
>
> Christian
>
> >
> > Best regards
> >
> > Christian
> >
> >> Please have a look at the last 6 patches for the ported work.
> >> Below is a short summary of the patc

Re: GSoC: Porting OFW to RTEMS

[Christian Mauderer]

On 27/05/2020 19:32, Niteesh G. S. wrote:
> 
> 
> On Wed, May 27, 2020 at 12:04 AM Christian Mauderer  > wrote:
> 
> Hello Niteesh,
> 
> On 26/05/2020 19:56, Christian Mauderer wrote:
> > Hello Niteesh,
> >
> > On 25/05/2020 11:20, Niteesh G. S. wrote:
> >> Hello,
> >>
> >> I have completed the porting of the OFW code from FreeBSD to RTEMS.
> >> I do acknowledge the fact that we haven't decided on the
> directory for files
> >> to be placed in. The previous conversation had stopped quite a
> while ago.
> >> Christian suggested I work on the patch since that would also
> start the
> >> conversation again and also refactoring the patch to the correct
> directory
> >> will not be much of work.
> >>
> >> cpukit/libfreebsd was suggested as one of the directories to
> place the
> >> ported
> >> FreeBSD files. It is suggested to place all the source files
> under this
> >> directory.
> >> Since this will make the sync part easier. But this causes issues
> when
> >> porting
> >> BSP dependent files. Since RTEMS currently doesn't allow files in
> cpukit to
> >> reference bsp headers. I faced a similar issue during my porting
> process
> >> also.
> >> The OFW init function require bsp_fdt_get function to get a
> reference to
> >> the fdt
> >> blob. But I can't include the bsp/fdt.h header file from a source
> file
> >> under cpukit.
> >> We must decide the directory quickly because my project will
> import other
> >> FreeBSD sources like the pinmux driver for beaglebone into RTEMS.
> >
> > Do you have a suggestion for another directory?
> >
> > If cpukit makes problems (which it clearly does due to the BSP
> > dependencies) maybe something in bsps/shared?
> >
> >>
> >> https://github.com/gs-niteesh/rtems/commits/ofw_branch
> >
> > For small patches it would be better to send them to the list
> using "git
> > send-email". That allows to comment directly on the patches. But
> in this
> > case using a repo is OK because especially the import is quite big.
> >
> > I'll add comments for small stuff directly on github. I hope that
> works ;-)
> 
> Finished adding comments for small stuff. Some bigger questions:
> 
> - How do you plan to include ofw_if.h in some driver files? RTEMS
> currently puts every file that can be included with  into a path
> called "include".
> 
> 
> Will ofw_if.h be included in driver files? As far as I have searched in the
> FreeBSD sources, other than the OFW implementation none of the driver
> files include this header. So this could be placed in the same directory as
> the OFW sources and need not be added to the global include path.
> If there is a case where it is included in some driver please let me know. 
> 
> And also all the references to this header in the OFW implementations are
> relative so in future, if we add other implementations, having it in the
> same
> directory would be the right choice.
> 

You are right. I didn't have a detailed enough look. The functions like
OFW_GETPROP (declared in ofw_if.h) are only used in openfirm.c. So that
location is OK.

>  
> 
> - You created quite some commits. I would suggest to merge all porting
> commits so that you have one import commit, one port commit and maybe
> one commit adding RTEMS specific files
> 
> 
> I have squashed them into a single port commit.
>  
> 
>  
> 
> - You have at least one completely hand written file (ofw_if.h). Maybe
> we should think about whether that is located well in the same directory
> as the imported code or whether a similar structure like used in libbsd
> would be better. One tree for imported files and one for RTEMS specific
> hand written ones.
> 
> 
> Do we need a separate directory for RTEMS specific handwritten ones depends
> on what we will be importing in the future? Since we intend only to
> import mostly
> driver related code I don't think there is a need for a separate
> directory. I think
> this way because I assuming we don't need any RTEMS specific file for
> the drivers.
> But if we plan to include some simple subsystem then having a separate
> directory
> will be nice.

Things like that tend to grow. So even if we don't want to import much
for now, it's quite possible that it will be more in the future.
Therefore I would use the future-proof approach even if it is a bit
overkill for now.

> 
> This also makes me think about if having all sources under a single
> directory under
> cpukit a good idea. Since our main import targets are drivers placing
> them in the
> cpukit directory or any other directory other than their respective BSP
> directory is not
> a good idea. This would make writing the sync script harder but this
> will decrease the
> coupling and dependencies between vario