[PATCH] arm/xilinx_zynq: Disable the MMU and the data and instruction cache on boot.
The u-boot loader can enable the MMU plus the data and instruction caches.
Disable them and if the data cache is enabled clear it before turn the caches
off.
Closes #2774.
---
c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h | 4
c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
b/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
index 01fdbb3..7734ddc 100644
--- a/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
+++ b/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
@@ -166,6 +166,10 @@ arm_cp15_start_setup_mmu_and_cache(uint32_t ctrl_clear,
uint32_t ctrl_set)
{
uint32_t ctrl = arm_cp15_get_control();
+ if ((ctrl & ARM_CP15_CTRL_C) != 0) {
+arm_cp15_data_cache_clean_all_levels();
+ }
+
ctrl &= ~ctrl_clear;
ctrl |= ctrl_set;
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
b/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
index c7a1089..0918588 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
@@ -41,7 +41,7 @@ BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
__attribute__ ((weak)
BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
{
uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
-ARM_CP15_CTRL_A,
+ARM_CP15_CTRL_A | ARM_CP15_CTRL_C | ARM_CP15_CTRL_I | ARM_CP15_CTRL_M,
ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
);
--
2.4.6
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] libbsp/arm: Add the TTB table to the default MMU set up as read/write.
This lets the table be changed at runtime for dynamic loading and
debugger support.
---
c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h | 4
1 file changed, 4 insertions(+)
diff --git a/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
b/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
index 01fdbb3..a749f7d 100644
--- a/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
+++ b/c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
@@ -88,6 +88,10 @@ typedef struct {
.begin = (uint32_t) bsp_section_nocachenoload_begin, \
.end = (uint32_t) bsp_section_nocachenoload_end, \
.flags = ARMV7_MMU_DEVICE \
+ }, { \
+.begin = (uint32_t) bsp_translation_table_base, \
+.end = (uint32_t) bsp_translation_table_end, \
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED \
}
BSP_START_DATA_SECTION extern const arm_cp15_start_section_config
--
2.4.6
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd: Manipulating object files using waf build system
Am 02.08.2016 um 08:04 schrieb Christian Mauderer: > Hello, > > I have a second waf problem beneath the one already discussed in the > other thread: Is it possible to do some object file manipulation before > linking? To be exact I would need to rename some of the sections in the > object files. > > > If you want to stop reading, you can do it here. The following is only > some background Information why this is necessary: > > Currently I'm porting the user space tool pfctl to set up the firewall > pf to libbsd. For all initialized (zero or value) global or static > variables I basically use the following method: > > - put all variables into one named linker section > - save the section before calling the main > - restore the section after calling main > > I'll add a more detailed description for the method that I used to port > into the libbsd.txt as soon as I'm finished with the work. > > > I have made some changes that I was trying to upstream to FreeBSD. The > changes are quite similar to the ones for other programs: > > - Make const what can be const. > - Make global variables static if possible. > - Move some static variables out of function scope. > > I've suggested these changes on the FreeBSD mailing list here: > > https://lists.freebsd.org/pipermail/freebsd-hackers/2016-July/049772.html > > The last one (moving the static variables out of the functions) was > necessary so I could easily add an attribute to the variables. Due to > the fact that it is not really an improvement, it has started some > discussion: > > https://lists.freebsd.org/pipermail/freebsd-hackers/2016-August/049821.html > > The method described there would not work for us. But we should be able > to rename some of the sections. Compared to my current method (adding an > attribute to every variable) this would make it simpler to update to a > newer version with some changed global variables. So it's worth a try. > > Kind regards, > > Christian Mauderer > Hello, Sebastian noted a problem with the approach of manipulating the object files: On some architectures (e.g. PowerPC) there is a small data section. If we just rename the section inside the object file, this could have the effect that the variables wouldn't longer be inside the small data section memory range. Sebastian described it with some more details on the FreeBSD mailing list where I started to discuss the patch that pulls out the function static variables: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=12034+0+current/freebsd-hackers I think currently it's not really useful to continue the object file manipulation approach. With my current approach (adding a header at the end of each c file) this could also be a problem with every variable that is not only used in one c file but in multiple c files. For global variables the attribute most likely has to be added to the original FreeBSD header. Kind regards Christian Mauderer -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: librtems++ examples
Thank you for your fast reply -Message d'origine- De : devel [mailto:devel-boun...@rtems.org] De la part de Chris Johns Envoyé : mardi 9 août 2016 07:30 À : devel@rtems.org Objet : Re: librtems++ examples On 09/08/2016 00:57, Boughedada Kamal wrote: > > I found librtems++ wrapper for the RTEMS API on the net. But I don't > know how to use it. Is it possible to get examples about the c++ usage > of rtems > Please do not use it. I am about to remove it from RTEMS. The standards base C++ support should be used these days. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB toolchain builds on Windows 10/Windows Subsystem for Linux
I thought I would try the new Windows Subsystem for Linux to see how the RSB toolchain build would go. WSL is a port of the Ubuntu 14.04 user space binaries to the windows 10 kernel: https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux The RSB toolchain builds the same here as it does on a native ubuntu 14.04 machine. No problems or differences that I can tell. Note that I'm not advocating this, just reporting another option for RTEMS developers :) Alan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RSB toolchain builds on Windows 10/Windows Subsystem for Linux
On 09/08/2016 23:51, Alan Cudmore wrote: I thought I would try the new Windows Subsystem for Linux to see how the RSB toolchain build would go. WSL is a port of the Ubuntu 14.04 user space binaries to the windows 10 kernel: https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux The RSB toolchain builds the same here as it does on a native ubuntu 14.04 machine. No problems or differences that I can tell. Note that I'm not advocating this, just reporting another option for RTEMS developers :) Could you please update the doc in the RSB to mention this? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] build-system: Always enable C++ if the compiler is present.
We always build a C++ compiler and building with C++ does not effect
RTEMS or the runtime. This patch always enabled the support. There is
no need to manually enable it any more.
You can disable C++ with '--disable-cxx'.
If an architecture does not have a C++ compiler support is automatically
disabled.
---
aclocal/enable-cxx.m4| 4 ++--
c/src/aclocal/enable-cxx.m4 | 5 +++--
c/src/aclocal/prog-cxx.m4| 37 +
c/src/configure.ac | 2 ++
cpukit/configure.ac | 6 --
testsuites/aclocal/enable-cxx.m4 | 5 +++--
testsuites/aclocal/prog-cxx.m4 | 39 ++-
testsuites/configure.ac | 6 +-
8 files changed, 62 insertions(+), 42 deletions(-)
diff --git a/aclocal/enable-cxx.m4 b/aclocal/enable-cxx.m4
index ddd37dc..952f015 100644
--- a/aclocal/enable-cxx.m4
+++ b/aclocal/enable-cxx.m4
@@ -2,10 +2,10 @@ AC_DEFUN([RTEMS_ENABLE_CXX],
[
AC_ARG_ENABLE(cxx,
[AS_HELP_STRING([--enable-cxx],
-[enable C++ support and build the rtems++ library])],
+[enable C++ support])],
[case "${enable_cxx}" in
yes) RTEMS_HAS_CPLUSPLUS=yes ;;
no) RTEMS_HAS_CPLUSPLUS=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for enable-cxx option) ;;
-esac], [RTEMS_HAS_CPLUSPLUS=no])
+esac], [RTEMS_HAS_CPLUSPLUS=yes])
])
diff --git a/c/src/aclocal/enable-cxx.m4 b/c/src/aclocal/enable-cxx.m4
index 759d81b..952f015 100644
--- a/c/src/aclocal/enable-cxx.m4
+++ b/c/src/aclocal/enable-cxx.m4
@@ -1,10 +1,11 @@
AC_DEFUN([RTEMS_ENABLE_CXX],
[
AC_ARG_ENABLE(cxx,
-[AS_HELP_STRING(--enable-cxx,enable C++ support and build the rtems++
library)],
+[AS_HELP_STRING([--enable-cxx],
+[enable C++ support])],
[case "${enable_cxx}" in
yes) RTEMS_HAS_CPLUSPLUS=yes ;;
no) RTEMS_HAS_CPLUSPLUS=no ;;
*) AC_MSG_ERROR(bad value ${enableval} for enable-cxx option) ;;
-esac], [RTEMS_HAS_CPLUSPLUS=no])
+esac], [RTEMS_HAS_CPLUSPLUS=yes])
])
diff --git a/c/src/aclocal/prog-cxx.m4 b/c/src/aclocal/prog-cxx.m4
index 957a595..66c986c 100644
--- a/c/src/aclocal/prog-cxx.m4
+++ b/c/src/aclocal/prog-cxx.m4
@@ -1,6 +1,6 @@
-dnl
+dnl
dnl Check for target g++
-dnl
+dnl
AC_DEFUN([RTEMS_PROG_CXX_FOR_TARGET],
[
@@ -18,21 +18,26 @@ fi
RTEMS_CHECK_TOOL(CXX,g++)
if test "$RTEMS_HAS_CPLUSPLUS" = "yes";
then
-dnl Only accept g++
-dnl NOTE: This might be too restrictive
-test -z "$CXX" \
- && AC_MSG_ERROR([no acceptable c++ found in \$PATH])
-AC_PROG_CXX
-AC_PROG_CXXCPP
-
- if test "$ac_cv_prog_cc_cross" != "$ac_cv_prog_cxx_cross"; then
-AC_MSG_ERROR([***]
- [Inconsistency in compiler configuration:]
- [Target C compiler and target C++ compiler]
- [must both either be cross compilers or native compilers])
+ dnl Only accept g++
+ dnl NOTE: This might be too restrictive
+ if test -z "$CXX";
+ then
+RTEMS_HAS_CPLUSPLUS=no
+HAS_CPLUSPLUS=no
+## Work-around to a bug in automake
+AM_CONDITIONAL([am__fastdepCXX],[false])
+ else
+AC_PROG_CXX
+AC_PROG_CXXCPP
+if test "$ac_cv_prog_cc_cross" != "$ac_cv_prog_cxx_cross"; then
+ AC_MSG_ERROR([***]
+ [Inconsistency in compiler configuration:]
+ [Target C compiler and target C++ compiler]
+ [must both either be cross compilers or native compilers])
+fi
fi
else
-## Work-around to a bug in automake
-AM_CONDITIONAL([am__fastdepCXX],[false])
+ ## Work-around to a bug in automake
+ AM_CONDITIONAL([am__fastdepCXX],[false])
fi
])
diff --git a/c/src/configure.ac b/c/src/configure.ac
index f0d482c..6b34eb5 100644
--- a/c/src/configure.ac
+++ b/c/src/configure.ac
@@ -16,6 +16,7 @@ AM_MAINTAINER_MODE
RTEMS_ENABLE_MULTILIB
RTEMS_ENABLE_MULTIPROCESSING
+RTEMS_ENABLE_CXX
RTEMS_ENV_RTEMSBSP
RTEMS_CHECK_CUSTOM_BSP(RTEMS_BSP)
@@ -93,6 +94,7 @@ rtems_cv_CFLAGS_set="${CFLAGS+set}"
CFLAGS="${CFLAGS-${CPU_CFLAGS} ${CFLAGS_OPTIMIZE_V}}"
RTEMS_PROG_CC_FOR_TARGET
+RTEMS_PROG_CXX_FOR_TARGET
AM_PROG_CC_C_O
RTEMS_PROG_CCAS
RTEMS_CANONICALIZE_TOOLS
diff --git a/cpukit/configure.ac b/cpukit/configure.ac
index 054e60e..136630b 100644
--- a/cpukit/configure.ac
+++ b/cpukit/configure.ac
@@ -13,6 +13,7 @@ AM_MAINTAINER_MODE
RTEMS_ENABLE_MULTILIB
RTEMS_ENABLE_MULTIPROCESSING
RTEMS_ENABLE_POSIX
+RTEMS_ENABLE_CXX
RTEMS_ENABLE_RTEMS_DEBUG
RTEMS_ENABLE_NETWORKING
RTEMS_ENABLE_PARAVIRT
@@ -31,9 +32,10 @@ else
fi
RTEMS_PROG_CC_FOR_TARGET
-RTEMS_PROG_CCAS
-RTEMS_CANONICALIZE_TOOLS
+RTEMS_PROG_CXX_FOR_TARGET
AM_PROG_CC_C_O
+RTEMS_CANONICALIZE_TOOLS
+RTEMS_PROG_CCAS
AC_PROG_RANLIB
RTEMS_CHECK_NEWLIB
diff --git a/testsuites/aclocal/enable-cxx.m4 b/testsuites/aclocal/enable-cxx.m4
index 759d81b..952f015 100644
--- a/testsuites/aclocal/enable-cxx.m4
+++ b/testsuites/aclocal/enable-cxx.m4
@@ -1,10 +1,11 @@
AC_DEFUN([RTEMS_ENABLE_CXX],
[
AC_ARG_ENABLE(cxx,
-[AS_HELP_STRING(--enable-cxx,enable C++ support and build the rtems++
library)],
+[AS_HELP_STRING([--enable-cxx],
+[enable C++ support])],
[case "${enable_cxx
Re: [PATCH] build-system: Always enable C++ if the compiler is present.
I think this is a good idea. It reduces the configuration options a bit and
doesn't add any run time code. It barely adds any build time.
On Aug 9, 2016 10:11 PM, "Chris Johns" wrote:
> We always build a C++ compiler and building with C++ does not effect
> RTEMS or the runtime. This patch always enabled the support. There is
> no need to manually enable it any more.
>
> You can disable C++ with '--disable-cxx'.
>
> If an architecture does not have a C++ compiler support is automatically
> disabled.
> ---
> aclocal/enable-cxx.m4| 4 ++--
> c/src/aclocal/enable-cxx.m4 | 5 +++--
> c/src/aclocal/prog-cxx.m4| 37 +-
> ---
> c/src/configure.ac | 2 ++
> cpukit/configure.ac | 6 --
> testsuites/aclocal/enable-cxx.m4 | 5 +++--
> testsuites/aclocal/prog-cxx.m4 | 39 ++
> -
> testsuites/configure.ac | 6 +-
> 8 files changed, 62 insertions(+), 42 deletions(-)
>
> diff --git a/aclocal/enable-cxx.m4 b/aclocal/enable-cxx.m4
> index ddd37dc..952f015 100644
> --- a/aclocal/enable-cxx.m4
> +++ b/aclocal/enable-cxx.m4
> @@ -2,10 +2,10 @@ AC_DEFUN([RTEMS_ENABLE_CXX],
> [
> AC_ARG_ENABLE(cxx,
> [AS_HELP_STRING([--enable-cxx],
> -[enable C++ support and build the rtems++ library])],
> +[enable C++ support])],
> [case "${enable_cxx}" in
>yes) RTEMS_HAS_CPLUSPLUS=yes ;;
>no) RTEMS_HAS_CPLUSPLUS=no ;;
>*) AC_MSG_ERROR(bad value ${enableval} for enable-cxx option) ;;
> -esac], [RTEMS_HAS_CPLUSPLUS=no])
> +esac], [RTEMS_HAS_CPLUSPLUS=yes])
> ])
> diff --git a/c/src/aclocal/enable-cxx.m4 b/c/src/aclocal/enable-cxx.m4
> index 759d81b..952f015 100644
> --- a/c/src/aclocal/enable-cxx.m4
> +++ b/c/src/aclocal/enable-cxx.m4
> @@ -1,10 +1,11 @@
> AC_DEFUN([RTEMS_ENABLE_CXX],
> [
> AC_ARG_ENABLE(cxx,
> -[AS_HELP_STRING(--enable-cxx,enable C++ support and build the rtems++
> library)],
> +[AS_HELP_STRING([--enable-cxx],
> +[enable C++ support])],
> [case "${enable_cxx}" in
>yes) RTEMS_HAS_CPLUSPLUS=yes ;;
>no) RTEMS_HAS_CPLUSPLUS=no ;;
>*) AC_MSG_ERROR(bad value ${enableval} for enable-cxx option) ;;
> -esac], [RTEMS_HAS_CPLUSPLUS=no])
> +esac], [RTEMS_HAS_CPLUSPLUS=yes])
> ])
> diff --git a/c/src/aclocal/prog-cxx.m4 b/c/src/aclocal/prog-cxx.m4
> index 957a595..66c986c 100644
> --- a/c/src/aclocal/prog-cxx.m4
> +++ b/c/src/aclocal/prog-cxx.m4
> @@ -1,6 +1,6 @@
> -dnl
> +dnl
> dnl Check for target g++
> -dnl
> +dnl
>
> AC_DEFUN([RTEMS_PROG_CXX_FOR_TARGET],
> [
> @@ -18,21 +18,26 @@ fi
> RTEMS_CHECK_TOOL(CXX,g++)
> if test "$RTEMS_HAS_CPLUSPLUS" = "yes";
> then
> -dnl Only accept g++
> -dnl NOTE: This might be too restrictive
> -test -z "$CXX" \
> - && AC_MSG_ERROR([no acceptable c++ found in \$PATH])
> -AC_PROG_CXX
> -AC_PROG_CXXCPP
> -
> - if test "$ac_cv_prog_cc_cross" != "$ac_cv_prog_cxx_cross"; then
> -AC_MSG_ERROR([***]
> - [Inconsistency in compiler configuration:]
> - [Target C compiler and target C++ compiler]
> - [must both either be cross compilers or native compilers])
> + dnl Only accept g++
> + dnl NOTE: This might be too restrictive
> + if test -z "$CXX";
> + then
> +RTEMS_HAS_CPLUSPLUS=no
> +HAS_CPLUSPLUS=no
> +## Work-around to a bug in automake
> +AM_CONDITIONAL([am__fastdepCXX],[false])
> + else
> +AC_PROG_CXX
> +AC_PROG_CXXCPP
> +if test "$ac_cv_prog_cc_cross" != "$ac_cv_prog_cxx_cross"; then
> + AC_MSG_ERROR([***]
> + [Inconsistency in compiler configuration:]
> + [Target C compiler and target C++ compiler]
> + [must both either be cross compilers or native compilers])
> +fi
>fi
> else
> -## Work-around to a bug in automake
> -AM_CONDITIONAL([am__fastdepCXX],[false])
> + ## Work-around to a bug in automake
> + AM_CONDITIONAL([am__fastdepCXX],[false])
> fi
> ])
> diff --git a/c/src/configure.ac b/c/src/configure.ac
> index f0d482c..6b34eb5 100644
> --- a/c/src/configure.ac
> +++ b/c/src/configure.ac
> @@ -16,6 +16,7 @@ AM_MAINTAINER_MODE
>
> RTEMS_ENABLE_MULTILIB
> RTEMS_ENABLE_MULTIPROCESSING
> +RTEMS_ENABLE_CXX
> RTEMS_ENV_RTEMSBSP
>
> RTEMS_CHECK_CUSTOM_BSP(RTEMS_BSP)
> @@ -93,6 +94,7 @@ rtems_cv_CFLAGS_set="${CFLAGS+set}"
> CFLAGS="${CFLAGS-${CPU_CFLAGS} ${CFLAGS_OPTIMIZE_V}}"
>
> RTEMS_PROG_CC_FOR_TARGET
> +RTEMS_PROG_CXX_FOR_TARGET
> AM_PROG_CC_C_O
> RTEMS_PROG_CCAS
> RTEMS_CANONICALIZE_TOOLS
> diff --git a/cpukit/configure.ac b/cpukit/configure.ac
> index 054e60e..136630b 100644
> --- a/cpukit/configure.ac
> +++ b/cpukit/configure.ac
> @@ -13,6 +13,7 @@ AM_MAINTAINER_MODE
> RTEMS_ENABLE_MULTILIB
> RTEMS_ENABLE_MULTIPROCESSING
> RTEMS_ENABLE_POSIX
> +RTEMS_ENABLE_CXX
> RTEMS_ENABLE_RTEMS_DEBUG
> RTEMS_ENABLE_NETWORKING
> RTEMS_ENABLE_PARAVIRT
> @@ -31,9 +32,10 @@ else
> fi
>
> RTEMS_PROG_CC_FOR_TARGET
> -RTEMS_PROG_CCAS
> -RTEMS_CANONICALIZE_TOOLS
> +RTEMS_PROG_CXX_FOR_TARGET
> AM_PROG_CC_C_O
> +RTEMS_CANONICALIZE_TOOLS
Re: Add RTEMS_BSD_CONFIG_xxx and rc.conf interface for PF
On 09/08/2016 00:32, Christian Mauderer wrote: The appended patch set adds - RTEMS_BSD_CONFIG_FIREWALL_PF - RTEMS_BSD_CONFIG_FIREWALL_PFLOG - RTEMS_BSD_CONFIG_FIREWALL_PFSYNC for enabling the PF firewall. Further it adds an rc.conf interface that mimics the one in FreeBSD. It handles the following directives: - pf_enable - pf_rules - pf_flags It can't handle the pf_program directive. OK to push. Thanks for these patches. It is great to have PF and even better to have rc.conf support. Please note that I also increased the stack size of the rc-worker-task. The task used far less stack than most of the testsuite and therefore used an untested configuration. OK. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] librtems++: Remove from RTEMS.
This is old and there are better design patterns for threading and C++. We recommend you use the new C++ standards based support. Closes #2777. --- c/src/configure.ac | 6 - c/src/librtems++/Makefile.am | 23 - c/src/librtems++/README| 262 - c/src/librtems++/configure.ac | 35 -- c/src/librtems++/include/rtems++/rtemsEvent.h | 120 c/src/librtems++/include/rtems++/rtemsInterrupt.h | 98 .../librtems++/include/rtems++/rtemsMessageQueue.h | 170 -- c/src/librtems++/include/rtems++/rtemsSemaphore.h | 144 - c/src/librtems++/include/rtems++/rtemsStatusCode.h | 55 -- c/src/librtems++/include/rtems++/rtemsTask.h | 160 -- c/src/librtems++/include/rtems++/rtemsTaskMode.h | 204 --- c/src/librtems++/include/rtems++/rtemsTimer.h | 135 - c/src/librtems++/preinstall.am | 67 --- c/src/librtems++/src/rtemsEvent.cc | 73 --- c/src/librtems++/src/rtemsInterrupt.cc | 126 c/src/librtems++/src/rtemsMessageQueue.cc | 163 -- c/src/librtems++/src/rtemsSemaphore.cc | 173 -- c/src/librtems++/src/rtemsStatusCode.cc| 75 --- c/src/librtems++/src/rtemsTask.cc | 274 - c/src/librtems++/src/rtemsTimer.cc | 99 testsuites/libtests/Makefile.am| 2 +- testsuites/libtests/configure.ac | 1 - testsuites/libtests/rtems++/Init.cc| 66 --- testsuites/libtests/rtems++/Makefile.am| 27 - testsuites/libtests/rtems++/System.h | 135 - testsuites/libtests/rtems++/Task1.cc | 631 - testsuites/libtests/rtems++/Task2.cc | 82 --- testsuites/libtests/rtems++/Task3.cc | 82 --- testsuites/libtests/rtems++/rtems++.doc| 26 - testsuites/libtests/rtems++/rtems++.scn| 149 - 30 files changed, 1 insertion(+), 3662 deletions(-) delete mode 100644 c/src/librtems++/Makefile.am delete mode 100644 c/src/librtems++/README delete mode 100644 c/src/librtems++/configure.ac delete mode 100644 c/src/librtems++/include/rtems++/rtemsEvent.h delete mode 100644 c/src/librtems++/include/rtems++/rtemsInterrupt.h delete mode 100644 c/src/librtems++/include/rtems++/rtemsMessageQueue.h delete mode 100644 c/src/librtems++/include/rtems++/rtemsSemaphore.h delete mode 100644 c/src/librtems++/include/rtems++/rtemsStatusCode.h delete mode 100644 c/src/librtems++/include/rtems++/rtemsTask.h delete mode 100644 c/src/librtems++/include/rtems++/rtemsTaskMode.h delete mode 100644 c/src/librtems++/include/rtems++/rtemsTimer.h delete mode 100644 c/src/librtems++/preinstall.am delete mode 100644 c/src/librtems++/src/rtemsEvent.cc delete mode 100644 c/src/librtems++/src/rtemsInterrupt.cc delete mode 100644 c/src/librtems++/src/rtemsMessageQueue.cc delete mode 100644 c/src/librtems++/src/rtemsSemaphore.cc delete mode 100644 c/src/librtems++/src/rtemsStatusCode.cc delete mode 100644 c/src/librtems++/src/rtemsTask.cc delete mode 100644 c/src/librtems++/src/rtemsTimer.cc delete mode 100644 testsuites/libtests/rtems++/Init.cc delete mode 100644 testsuites/libtests/rtems++/Makefile.am delete mode 100644 testsuites/libtests/rtems++/System.h delete mode 100644 testsuites/libtests/rtems++/Task1.cc delete mode 100644 testsuites/libtests/rtems++/Task2.cc delete mode 100644 testsuites/libtests/rtems++/Task3.cc delete mode 100644 testsuites/libtests/rtems++/rtems++.doc delete mode 100644 testsuites/libtests/rtems++/rtems++.scn diff --git a/c/src/configure.ac b/c/src/configure.ac index 6b34eb5..1543b5d 100644 --- a/c/src/configure.ac +++ b/c/src/configure.ac @@ -140,12 +140,6 @@ AC_SUBST(libbsp_cpu_subdir,$RTEMS_CPU) BSP_SUBDIRS="$BSP_SUBDIRS lib" BSP_SUBDIRS="$BSP_SUBDIRS libchip" - -AS_IF([test "$RTEMS_HAS_CPLUSPLUS" = "yes"],[ - AC_CONFIG_SUBDIRS([librtems++]) - BSP_SUBDIRS="$BSP_SUBDIRS librtems++" -]) - BSP_SUBDIRS="$BSP_SUBDIRS support" BSP_SUBDIRS="$BSP_SUBDIRS ada" BSP_SUBDIRS="$BSP_SUBDIRS wrapup" diff --git a/c/src/librtems++/Makefile.am b/c/src/librtems++/Makefile.am deleted file mode 100644 index ffc369c..000 --- a/c/src/librtems++/Makefile.am +++ /dev/null @@ -1,23 +0,0 @@ -ACLOCAL_AMFLAGS = -I ../aclocal - -include $(top_srcdir)/../automake/compile.am - -if HAS_CXX -include_rtems__dir = $(includedir)/rtems++ - -include_rtems___HEADERS = include/rtems++/rtemsEvent.h \ -include/rtems++/rtemsInterrupt.h include/rtems++/rtemsMessageQueue.h \ -include/rtems++/rtemsSemaphore.h include/rtems++/rtemsStatusCode.h \ -include/rtems++/rtemsTask.h include/rtems++/rtemsTaskMode.h \ -include/rtems++/rtemsTimer.h - -project_lib_LIBRARIES = librtems++.a - -librtems___a_SOURCES = src/rtemsEvent.cc src/rtemsInterrupt.cc \ -src/rtemsMessageQueue.cc src/rte
SPI Framework
Hello, for a project, I want to integrate the following software pieces into RTEMS: - cpukit: a general SPI framework which shall be used for upcoming SPI drivers - cpukit: a generic RS232/485 Termios driver for the microcontroller NXP89LPC935 http://pdf1.alldatasheet.com/datasheet-pdf/view/97462/PHILIPS/P89LPC935FA.html - bsp/arm/atsam: SPI bus driver The corresponding ticket can be found in the RTEMS tracking system: https://devel.rtems.org/ticket/2776 With best regards, Alexander Krutwig -- embedded brains GmbH Alexander Krutwig Dornierstr. 4 D-82178 Puchheim Germany email: alexander.krut...@embedded-brains.de Phone: +49-89-18 94 741 - 17 Fax: +49-89-18 94 741 - 09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
