date:20160922

Trying to build mvme5500 "Beatnik" for 4.11, option manager (no-foobar.rel: No such file or directory) issue?

2016-09-22 Thread Peter Dufault

I’m trying to update my MVME5500 “beatnik” BSP application from 4.7 to 4.11 and 
when I get to the final step to link my application I get what follows.

[dufault@take5 rtems]$ make
powerpc-rtems4.11-g++: error: 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-dpmem.rel: No 
such file or directory
powerpc-rtems4.11-g++: error: 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-msg.rel: No such 
file or directory
powerpc-rtems4.11-g++: error: 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-mp.rel: No such 
file or directory
powerpc-rtems4.11-g++: error: 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-part.rel: No 
such file or directory
powerpc-rtems4.11-g++: error: 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-signal.rel: No 
such file or directory
powerpc-rtems4.11-g++: error: 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-timer.rel: No 
such file or directory
powerpc-rtems4.11-g++: error: 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-rtmon.rel: No 
such file or directory
make: *** [/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid] 
Error 1

If I look at what I’m trying to do I see I’m linking to these "no-foobar.rel” 
directly.  (I inserted some  to make it clear):

[dufault@take5 rtems]$ make -n
mkdir -p /home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin; \
powerpc-rtems4.11-g++ -u rpcUdpInit -u nfsInit 
-B/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/ -specs bsp_specs 
-qrtems 

/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-dpmem.rel 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-msg.rel 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-mp.rel 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-part.rel 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-signal.rel 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-timer.rel 
/opt/flatland/opt/rtems-4.11/powerpc-rtems4.11/beatnik//lib/no-rtmon.rel

-g  \
-o 
/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid \

/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/_init.o
 
/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/grid.o
 
/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/main.o
 
/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/opt/flatland/exesrc/gridmain/rtems/mvme5500.o
   -lgrid -lzboard -lacromag -lvme -lembedtcl -lecseqtcl -lecseq -lmrsfile 
-lpowerpc -lmotors -lrtems_osintf -lzboard -lposix_wrap -lrtems-gdb-stub 
-lregex -lsearch -lbsd -lcexp -lspencer_regexp -ltecla_r -lpmbfd -lpmelf 
-ltelnetd -lnfs -L/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/lib 
-L/opt/stepper/opt/powerpc-beatnik-rtems/lib  -lregex -lsearch -lbsd
powerpc-rtems4.11-objcopy -Obinary 
/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid 
/home/dufault/work/scratch/dpixEE/powerpc-beatnik-rtems/bin/grid.bin
[dufault@take5 rtems]$ 

If I remove the section bracketed by “” the link finishes cleanly, but I 
haven’t had much luck figuring out what generates this.  I get problems when I 
try to boot the binary, but I want to fix this before proceeding further.

- Am I correct that this is some kind of initialization of optional managers?
- Does anyone recognize where I should be looking?

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email, like most email, is delivered unencrypted via internet email 
protocols subject to interception and tampering.  Contact HDA to discuss 
methods we can use that ensure secure communication.

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

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Sebastian Huber


On 22/09/16 15:25, Joel Sherrill wrote:

/The target pattern in the commit message doesn't look right.
It should be *-*-rtems* I think.


It should be ok since host_os is used:

# It uses the following shell variables as set by config.guess:
#   hostThe configuration host (full CPU-vendor-OS triplet)
#   host_cpuThe configuration host CPU
#   host_os The configuration host OS



Do all BSPs for m68k build with C++ enabled?


Yes, but I face currently some other problems with GCC 7:

https://gcc.gnu.org/ml/gcc/2016-09/msg00114.html

There is also a NULL pointer access in wctob() with the latest Newlib.



What code is used for atomic operations on say a 68000 or
68020?


They use the libatomic if the atomic operations are not supported by 
hardware. libatomic uses _Libatomic_Protect_start() and 
_Libatomic_Protect_end() on RTEMS.




Thanks.

--joel

On Thu, Sep 22, 2016 at 3:47 AM, Sebastian Huber 
> wrote:


v2: Fix shell script part since shell grouping is expressed by { }.

libstdc++-v3/
* config/cpu/m68k/atomicity.h: Adjust comment.
* acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor
explicit atomicity_dir setup via configure.host.
* configure.host (rtems-*): Set atomicity_dir.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4|  5 +++--
 libstdc++-v3/config/cpu/m68k/atomicity.h |  3 +++
 libstdc++-v3/configure   | 11 ++-
 libstdc++-v3/configure.host  |  4 
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 6d897be..d7db435 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3490,9 +3490,10 @@ EOF
   AC_LANG_RESTORE

   # Set atomicity_dir to builtins if all but the long long test
above passes.
-  if test "$glibcxx_cv_atomic_bool" = yes \
+  if { test "$glibcxx_cv_atomic_bool" = yes \
  && test "$glibcxx_cv_atomic_short" = yes \
- && test "$glibcxx_cv_atomic_int" = yes; then
+ && test "$glibcxx_cv_atomic_int" = yes } \
+ || test "$atomicity_dir" = "cpu/generic/atomicity_builtins";
then
 AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS, 1,
 [Define if the compiler supports C++11 atomics.])
 atomicity_dir=cpu/generic/atomicity_builtins
diff --git a/libstdc++-v3/config/cpu/m68k/atomicity.h
b/libstdc++-v3/config/cpu/m68k/atomicity.h
index f421330..a9ddc6b 100644
--- a/libstdc++-v3/config/cpu/m68k/atomicity.h
+++ b/libstdc++-v3/config/cpu/m68k/atomicity.h
@@ -48,6 +48,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }

 #elif defined(__rtems__)
+  // This code is only provided for reference.  RTEMS uses now
the atomic
+  // builtins and libatomic.  See configure.host.
+  //
   // TAS/JBNE is unsafe on systems with strict priority-based
scheduling.
   // Disable interrupts, which we can do only from supervisor mode.
   _Atomic_word
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 6332c4d..d09a7e0 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -15539,9 +15539,10 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu


   # Set atomicity_dir to builtins if all but the long long test
above passes.
-  if test "$glibcxx_cv_atomic_bool" = yes \
+  if { test "$glibcxx_cv_atomic_bool" = yes \
  && test "$glibcxx_cv_atomic_short" = yes \
- && test "$glibcxx_cv_atomic_int" = yes; then
+ && test "$glibcxx_cv_atomic_int" = yes } \
+ || test "$atomicity_dir" = "cpu/generic/atomicity_builtins";
then

 $as_echo "#define _GLIBCXX_ATOMIC_BUILTINS 1" >>confdefs.h

@@ -15573,7 +15574,7 @@ $as_echo "$as_me: WARNING: Performance of
certain classes will degrade as a resu
   # unnecessary for this test.

 cat > conftest.$ac_ext << EOF
-#line 15576 "configure"
+#line 15577 "configure"
 int main()
 {
   _Decimal32 d1;
@@ -15615,7 +15616,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
   # unnecessary for this test.

 cat > conftest.$ac_ext << EOF
-#line 15618 "configure"
+#line 15619 "configure"
 template
   struct same
   { typedef T2 type; };
@@ -15649,7 +15650,7 @@ $as_echo "$enable_int128" >&6; }
 rm -f conftest*

 cat > conftest.$ac_ext << EOF
-#line 15652 "configure"
+#line 15653 "configure"
 template
   struct same
   { typedef T2 type; };
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index c0cc3ee..eb56ab1 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -296,6 +296,10 @@ case "${host_os}" in
 os_include_dir="os/qnx/qnx6.1"

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Joel Sherrill

/The target pattern in the commit message doesn't look right.
It should be *-*-rtems* I think.

Do all BSPs for m68k build with C++ enabled?

What code is used for atomic operations on say a 68000 or
68020?

Thanks.

--joel

On Thu, Sep 22, 2016 at 3:47 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> v2: Fix shell script part since shell grouping is expressed by { }.
>
> libstdc++-v3/
> * config/cpu/m68k/atomicity.h: Adjust comment.
> * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor
> explicit atomicity_dir setup via configure.host.
> * configure.host (rtems-*): Set atomicity_dir.
> * configure: Regenerate.
> ---
>  libstdc++-v3/acinclude.m4|  5 +++--
>  libstdc++-v3/config/cpu/m68k/atomicity.h |  3 +++
>  libstdc++-v3/configure   | 11 ++-
>  libstdc++-v3/configure.host  |  4 
>  4 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index 6d897be..d7db435 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -3490,9 +3490,10 @@ EOF
>AC_LANG_RESTORE
>
># Set atomicity_dir to builtins if all but the long long test above
> passes.
> -  if test "$glibcxx_cv_atomic_bool" = yes \
> +  if { test "$glibcxx_cv_atomic_bool" = yes \
>   && test "$glibcxx_cv_atomic_short" = yes \
> - && test "$glibcxx_cv_atomic_int" = yes; then
> + && test "$glibcxx_cv_atomic_int" = yes } \
> + || test "$atomicity_dir" = "cpu/generic/atomicity_builtins"; then
>  AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS, 1,
>  [Define if the compiler supports C++11 atomics.])
>  atomicity_dir=cpu/generic/atomicity_builtins
> diff --git a/libstdc++-v3/config/cpu/m68k/atomicity.h
> b/libstdc++-v3/config/cpu/m68k/atomicity.h
> index f421330..a9ddc6b 100644
> --- a/libstdc++-v3/config/cpu/m68k/atomicity.h
> +++ b/libstdc++-v3/config/cpu/m68k/atomicity.h
> @@ -48,6 +48,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>}
>
>  #elif defined(__rtems__)
> +  // This code is only provided for reference.  RTEMS uses now the atomic
> +  // builtins and libatomic.  See configure.host.
> +  //
>// TAS/JBNE is unsafe on systems with strict priority-based scheduling.
>// Disable interrupts, which we can do only from supervisor mode.
>_Atomic_word
> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
> index 6332c4d..d09a7e0 100755
> --- a/libstdc++-v3/configure
> +++ b/libstdc++-v3/configure
> @@ -15539,9 +15539,10 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>
>
># Set atomicity_dir to builtins if all but the long long test above
> passes.
> -  if test "$glibcxx_cv_atomic_bool" = yes \
> +  if { test "$glibcxx_cv_atomic_bool" = yes \
>   && test "$glibcxx_cv_atomic_short" = yes \
> - && test "$glibcxx_cv_atomic_int" = yes; then
> + && test "$glibcxx_cv_atomic_int" = yes } \
> + || test "$atomicity_dir" = "cpu/generic/atomicity_builtins"; then
>
>  $as_echo "#define _GLIBCXX_ATOMIC_BUILTINS 1" >>confdefs.h
>
> @@ -15573,7 +15574,7 @@ $as_echo "$as_me: WARNING: Performance of certain
> classes will degrade as a resu
># unnecessary for this test.
>
>  cat > conftest.$ac_ext << EOF
> -#line 15576 "configure"
> +#line 15577 "configure"
>  int main()
>  {
>_Decimal32 d1;
> @@ -15615,7 +15616,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
># unnecessary for this test.
>
>  cat > conftest.$ac_ext << EOF
> -#line 15618 "configure"
> +#line 15619 "configure"
>  template
>struct same
>{ typedef T2 type; };
> @@ -15649,7 +15650,7 @@ $as_echo "$enable_int128" >&6; }
>  rm -f conftest*
>
>  cat > conftest.$ac_ext << EOF
> -#line 15652 "configure"
> +#line 15653 "configure"
>  template
>struct same
>{ typedef T2 type; };
> diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
> index c0cc3ee..eb56ab1 100644
> --- a/libstdc++-v3/configure.host
> +++ b/libstdc++-v3/configure.host
> @@ -296,6 +296,10 @@ case "${host_os}" in
>  os_include_dir="os/qnx/qnx6.1"
>  c_model=c
>  ;;
> +  rtems*)
> +# Use libatomic if necessary and avoid libstdc++ specific atomicity
> support
> +atomicity_dir="cpu/generic/atomicity_builtins"
> +;;
>solaris2)
>  # This too-vague configuration does not provide enough information
>  # to select a ctype include, and thus os_include_dir is a crap shoot.
> --
> 1.8.4.5
>
> ___
> 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

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Sebastian Huber




On 22/09/16 10:47, Jonathan Wakely wrote:

On 22/09/16 09:41 +0200, Sebastian Huber wrote:

libstdc++-v3/
* config/cpu/m68k/atomicity.h: Adjust comment.
* acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor
explicit atomicity_dir setup via configure.host.
* configure.host (rtems-*): Set atomicity_dir.
* configure: Regenerate.
---
libstdc++-v3/acinclude.m4|  5 +++--
libstdc++-v3/config/cpu/m68k/atomicity.h |  3 +++
libstdc++-v3/configure   | 11 ++-
libstdc++-v3/configure.host  |  4 
4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 6d897be..3256ce4 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3490,9 +3490,10 @@ EOF
  AC_LANG_RESTORE

  # Set atomicity_dir to builtins if all but the long long test above 
passes.

-  if test "$glibcxx_cv_atomic_bool" = yes \
+  if ( test "$glibcxx_cv_atomic_bool" = yes \
 && test "$glibcxx_cv_atomic_short" = yes \
- && test "$glibcxx_cv_atomic_int" = yes; then
+ && test "$glibcxx_cv_atomic_int" = yes ) \
+ || test "$atomicity_dir" = "cpu/generic/atomicity_builtins"; then


Could you adjust the comment too please? Maybe something like:

  # Set atomicity_dir to builtins if all but the long long test above 
passes,

  # or if the builtins were already chosen (e.g. by configure.host).

OK with an adjusted comment, thanks.




Thanks for the quick review. I would like to back port this to GCC 6.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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

[PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

2016-09-22 Thread Sebastian Huber

v2: Fix shell script part since shell grouping is expressed by { }.

libstdc++-v3/
* config/cpu/m68k/atomicity.h: Adjust comment.
* acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor
explicit atomicity_dir setup via configure.host.
* configure.host (rtems-*): Set atomicity_dir.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4|  5 +++--
 libstdc++-v3/config/cpu/m68k/atomicity.h |  3 +++
 libstdc++-v3/configure   | 11 ++-
 libstdc++-v3/configure.host  |  4 
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 6d897be..d7db435 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3490,9 +3490,10 @@ EOF
   AC_LANG_RESTORE
 
   # Set atomicity_dir to builtins if all but the long long test above passes.
-  if test "$glibcxx_cv_atomic_bool" = yes \
+  if { test "$glibcxx_cv_atomic_bool" = yes \
  && test "$glibcxx_cv_atomic_short" = yes \
- && test "$glibcxx_cv_atomic_int" = yes; then
+ && test "$glibcxx_cv_atomic_int" = yes } \
+ || test "$atomicity_dir" = "cpu/generic/atomicity_builtins"; then
 AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS, 1,
 [Define if the compiler supports C++11 atomics.])
 atomicity_dir=cpu/generic/atomicity_builtins
diff --git a/libstdc++-v3/config/cpu/m68k/atomicity.h 
b/libstdc++-v3/config/cpu/m68k/atomicity.h
index f421330..a9ddc6b 100644
--- a/libstdc++-v3/config/cpu/m68k/atomicity.h
+++ b/libstdc++-v3/config/cpu/m68k/atomicity.h
@@ -48,6 +48,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 #elif defined(__rtems__)
+  // This code is only provided for reference.  RTEMS uses now the atomic
+  // builtins and libatomic.  See configure.host.
+  //
   // TAS/JBNE is unsafe on systems with strict priority-based scheduling.
   // Disable interrupts, which we can do only from supervisor mode.
   _Atomic_word
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 6332c4d..d09a7e0 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -15539,9 +15539,10 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
   # Set atomicity_dir to builtins if all but the long long test above passes.
-  if test "$glibcxx_cv_atomic_bool" = yes \
+  if { test "$glibcxx_cv_atomic_bool" = yes \
  && test "$glibcxx_cv_atomic_short" = yes \
- && test "$glibcxx_cv_atomic_int" = yes; then
+ && test "$glibcxx_cv_atomic_int" = yes } \
+ || test "$atomicity_dir" = "cpu/generic/atomicity_builtins"; then
 
 $as_echo "#define _GLIBCXX_ATOMIC_BUILTINS 1" >>confdefs.h
 
@@ -15573,7 +15574,7 @@ $as_echo "$as_me: WARNING: Performance of certain 
classes will degrade as a resu
   # unnecessary for this test.
 
 cat > conftest.$ac_ext << EOF
-#line 15576 "configure"
+#line 15577 "configure"
 int main()
 {
   _Decimal32 d1;
@@ -15615,7 +15616,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
   # unnecessary for this test.
 
 cat > conftest.$ac_ext << EOF
-#line 15618 "configure"
+#line 15619 "configure"
 template
   struct same
   { typedef T2 type; };
@@ -15649,7 +15650,7 @@ $as_echo "$enable_int128" >&6; }
 rm -f conftest*
 
 cat > conftest.$ac_ext << EOF
-#line 15652 "configure"
+#line 15653 "configure"
 template
   struct same
   { typedef T2 type; };
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index c0cc3ee..eb56ab1 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -296,6 +296,10 @@ case "${host_os}" in
 os_include_dir="os/qnx/qnx6.1"
 c_model=c
 ;;
+  rtems*)
+# Use libatomic if necessary and avoid libstdc++ specific atomicity support
+atomicity_dir="cpu/generic/atomicity_builtins"
+;;
   solaris2)
 # This too-vague configuration does not provide enough information
 # to select a ctype include, and thus os_include_dir is a crap shoot.
-- 
1.8.4.5

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

Re: [PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

2016-09-22 Thread Pavel Pisa

Hello Gedare,

On Thursday 22 of September 2016 03:26:32 Gedare Bloom wrote:
> I only added a couple of very minor inline comments. Looks good, I
> think you can push directly no one else needs to re-read this
> BSP-specific stuff.

thanks much for reading that huge pieces.

I have corrected some typos and renamed tms570_test_parity*
files to tms570_selftest_parity* to match function names
you proposed.

I have pushed agreed upon patches.
The result builds without single warning form me.
I need testing on HW. But generally there has been
no real code change after last tests. Only style, comments
etc.

MPU patch is left out, it needs to transform from generated
code (bunch of hexa values) to some readable and verifiable
form.

I have not pushed update of SDRAM init as well.

>  c/src/lib/libbsp/arm/tms570/hwinit/init_emif_sdram.c
> @@ -1,5 +1,6 @@
>  #include 
>  #include 
> +#include 
>  #include "tms570_hwinit.h"
>
>  void tms570_emif_sdram_init( void )
> @@ -45,12 +46,21 @@ void tms570_emif_sdram_init( void )
>/* Page Size. This field defines the internal page size of connected
> SDRAM devices. */ sdcr = TMS570_EMIF_SDCR_PAGESIZE_SET( sdcr, 0 ); /*
> elements_256 */
>
> +  _ARM_Data_synchronization_barrier();
> +  _ARM_Instruction_synchronization_barrier();
> +
> @gedare
> gedare 7 hours ago
>
> I think it usually worthwhile to comment why barrier/fence are necessary.

The EMIF/SDRAM address range can be/is on another bus than peripheral
which registers control EMIF timing and setup. So my idea has been that
test/setup propagation read from SDRAM space can reach interface before
it is configured. The barriers should prevent that.

But the code/HW has some glitches even with barriers included.
The sequence is (should be) exactly same as HalCoGen generated code
but it is compiled with Ti tools and they optimize much less
in used basic setup than GCC. But I expect that problem is somewhere
else anyway. May it be initialization too early after power on,
some clock domain or power enable not controlled right way.

Genrally, the SDRAM configuration fails for the first start after
POR, the configuration is correct after second and more system resets.
I can put there code to retry it. But it needs more debugging
and I would like to find real cause.

Best wishes,

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

Trying to build mvme5500 "Beatnik" for 4.11, option manager (no-foobar.rel: No such file or directory) issue?

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

Re: [PATCH] [RTEMS] Always use atomic builtins for libstdc++

[PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

Re: [PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

6 matches

Site Navigation

Mail list logo

Footer information