Re: disable DCache on RTEMS SMP
Hello Stéphane, the rtems_cache_disable_data() has no real use case. It is quite difficult to implement and it is not unusual that its implementation is broken. I think on RTEMS 6 it should work for this BSP. However, I am not sure if the atomic operations work, if you disable the data cache. Without atomic operations, you will have unpredictable behaviour in SMP configurations. You can statically place data in a non-cacheable area with a section attribute: #include BSP_NOCACHE_SECTION char nocache[123]; Kind regards, Sebastian -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: multiple definition of `_Semaphore_Wait', multiple definition of `_Semaphore_Post' , undefined reference to `__dso_handle'
Hello Heinz, On 20.03.24 16:31, Heinz Junkes wrote: /home/rtems/MVME2500_PCI/rtems/6/bin/powerpc-rtems6-g++ -o libComTestHarness -static -L/home/rtems/MVME2500_PCI/EPICS/epics-base/lib/RTEMS-qoriq_e500 -L/home/rtems/MVME2500_PCI/rtems/6/powerpc-rtems6/qoriq_e500/lib -mcpu=8540 -msoft-float -meabi -msdata=sysv -mstrict-align -u POSIX_Init epicsTypesTest.o epicsInlineTest1.o epicsInlineTest2.o epicsInlineTest3.o epicsInlineTest4.o epicsCalcTest.o epicsAlgorithmTest.o epicsMathTest.o epicsMMIOTest.o epicsEllTest.o epicsEnvTest.o epicsEnvUnsetTest.o epicsErrlogTest.o epicsStdioTest.o epicsStdlibTest.o epicsSockResolveTest.o epicsStringTest.o epicsTimeTest.o epicsThreadTest.o epicsThreadClassTest.o epicsThreadOnceTest.o epicsThreadPriorityTest.o epicsThreadPrivateTest.o epicsThreadHooksTest.o epicsThreadPoolTest.o initHookTest.o epicsExitTest.o epicsTimerTest.o ringPointerTest.o ringBytesTest.o epicsEventTest.o epicsMutexTest.o epicsSpinTest.o epicsAtomicTest.o macDefExpandTest.o cvtFastTest.o macLibTest.o aslibtest.o taskwdTest.o blockingSockTest.o epicsMessageQueueTest.o epicsStackTraceTest.o ipAddrToAsciiTest.o osiSockTest.o epicsRunLibComTests.o epicsThreadPerform.o epicsMaxThreads.o buckTest.o epicsAtomicPerform.o cvtFastPerform.o epicsTimeZoneTest.o rtemsTestHarness.o rtemsTestData.o -lCom -Wl,--gc-sections -lm -lrtemsCom -lCom -lrtemscpu -lc -lm -lgcc I would use pkg-config to get the right linker and compiler flags. Here a -qrtems is probably missing. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: “AW:” ?
On 31.01.24 18:20, John Howard wrote: Lost in translation. Anybody here know what “AW:” in the Subject means? At first, I took it to mean a comical expression of sarcasm because of an accident. Ironically, that’s not it. It is an abbreviation of Antwort (answer) and was probably produced by some super smart software from Redmond. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS 5.0.0 GR712RC SMP Occasional Dropped Messages
Hello Don Oliver, with the information you provided it is hard to figure out what is going on. RTEMS 5.0.0 is not an RTEMS release. The problem you described could be caused by an operating system bug or an application issue. I recommend to first update to the current RTEMS master branch (RTEMS 6). We spent a lot of time and effort into maturing the SMP support in particular for the GR712RC over the last years. This all went into RTMES 6 and not RTEMS 5. Kind regards, Sebastian -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems6 master on darwin-x86_64 fails building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1
On 18.10.23 14:31, Heinz Junkes wrote:
Leider gibt es da noch andere Probleme?
I have now tried to build with gcc-10 and rsb-master:
../source-builder/sb-set-builder --prefix=${RTEMS_ROOT}
--with-rtems-gcc=tools/rtems-gcc-10-newlib-head.cfg 6/rtems-arm
...
/bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/./gcc/xgcc
-shared-libgcc
-B/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/./gcc
-nostdinc++
-L/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/src
-L/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/src/.libs
-L/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/libsupc++/.libs
-nostdinc
-B/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/newlib/
-isystem
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/newlib/targ-include
-isystem
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/gnu-mirror-gcc-d04fe55/newlib/libc/include
-B/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/bin/
-B/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/lib/ -isystem
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/include -isystem
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/sys-include
-I/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/gnu-mirror-gcc-d04fe55/libstdc++-v3/../libgcc
-I/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/include/arm-rtems6
-I/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/include
-I/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/gnu-mirror-gcc-d04fe55/libstdc++-v3/libsupc++
-std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=system_error.lo -g -O2 -c -o system_error.lo
../../../../../gnu-mirror-gcc-d04fe55/libstdc++-v3/src/c++11/system_error.cc
In file included from
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/include/random:51,
from
../../../../../gnu-mirror-gcc-d04fe55/libstdc++-v3/src/c++11/random.cc:28:
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/include/bits/random.tcc:
In function '_RealType
std::generate_canonical(_UniformRandomNumberGenerator&)':
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/include/bits/random.tcc:3296:54:
in 'constexpr' expansion of 'std::log(2.0e+0l)'
/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rsb/rtems/build/arm-rtems6-gcc-d04fe55-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/build/arm-rtems6/libstdc++-v3/include/bits/random.tcc:3296:44:
internal compiler error: Segmentation fault: 11
3296 | const size_t __log2r = std::log(__r) / std::log(2.0L);
| ~~^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
So, GCC 10, 12, and 13 don't work on this macOS version. I updated the
RTEMS 7 tools (GCC 14) right now, maybe this works:
../source-builder/sb-set-builder --prefix=${RTEMS_ROOT} 7/rtems-arm
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: rtems6 master on darwin-x86_64 fails building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1
On 18.10.23 12:29, Heinz Junkes wrote: unfortunately also with the GCC 13.2 configuration still the same error: nclude -g -O2 -mthumb -O2 -I../../../../gcc-13.2.0/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc -I../../../../gcc-13.2.0/libgcc -I../../../../gcc-13.2.0/libgcc/. -I../../../../gcc-13.2.0/libgcc/../gcc -I../../../../gcc-13.2.0/libgcc/../include -DHAVE_CC_TLS -o _divtc3.o -MT _divtc3.o -MD -MP -MF _divtc3.dep -DL_divtc3 -c ../../../../gcc-13.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc-13.2.0/libgcc/libgcc2.c: In function '__divdc3': ../../../../gcc-13.2.0/libgcc/libgcc2.c:2063:7: internal compiler error: Segmentation fault: 11 2063 | if (FABS (d) >= RBIG) | ^~ Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://gcc.gnu.org/bugs/> for instructions. make[4]: *** [_divdc3.o] Error 1 Ok, great. At least it is consistent. Maybe GCC 10 works. This bug should be reported to the GCC project. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems6 master on darwin-x86_64 fails building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1
Hello Heinz, I added a GCC 13.2 configuration. Maybe it works. You can test it with: ../source-builder/sb-set-builder --with-rtems-gcc=tools/rtems-gcc-13.2-newlib-head 6/rtems-arm On 18.10.23 09:44, Heinz Junkes wrote: Hello Sebastian, thank you for your answer. Unfortunately, it seems to have nothing to do with it: [junkes@h rsb ((a536dfe...))]$ git status HEAD detached at a536dfe U/rsb/rtems/build/arm-rtems6-gcc-506cb58-newlib-fbc5496-x86_64-apple-darwin22.6.0-1/gnu-mirror-gcc-506cb58/newlib/libc/include -B/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/bin/ -B/Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/lib/ -isystem /Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/include -isystem /Volumes/RTEMS_DEV/XILINX_ZYNQ_A9_QEMU/rtems/6/arm-rtems6/sys-include-g -O2 -mthumb -O2 -I../../../../gnu-mirror-gcc-506cb58/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc -I../../../../gnu-mirror-gcc-506cb58/libgcc -I../../../../gnu-mirror-gcc-506cb58/libgcc/. -I../../../../gnu-mirror-gcc-506cb58/libgcc/../gcc -I../../../../gnu-mirror-gcc-506cb58/libgcc/../include -DHAVE_CC_TLS -o _divtc3.o -MT _divtc3.o -MD -MP -MF _divtc3.dep -DL_divtc3 -c ../../../../gnu-mirror-gcc-506cb58/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../../gnu-mirror-gcc-506cb58/libgcc/libgcc2.c: In function '__divdc3': ../../../../gnu-mirror-gcc-506cb58/libgcc/libgcc2.c:2063:7: internal compiler error: Segmentation fault: 11 2063 | if (FABS (d) >= RBIG) | ^~ Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://gcc.gnu.org/bugs/> for instructions. make[4]: *** [_divdc3.o] Error 1 Heinz On 18. Oct 2023, at 07:39, Sebastian Huber wrote: On 17.10.23 21:52, Heinz Junkes wrote: Hi, unfortunately i can't build RTEMS6 on the Intel-Mac (darwin-x86_64) at the moment. it fails here: ... downloading: patches/fix-mac-arm64-mpc-config.patch - 347.0 bytes of 347.0 bytes (100%) download: https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0.tar.bz2 -> sources/mpfr-4.2.0.tar.bz2 downloading: sources/mpfr-4.2.0.tar.bz2 - 1.6MB of 1.6MB (100%) building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 error: building arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 Build FAILED See error report: rsb-report-arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1.txt Note: In some cases the error appears only in the complete build log (see --log option) error: building arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 Build Set: Time 0:31:04.275488 error: building arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 Build Set: Time 0:31:04.299122 Build FAILED with ../../../../gnu-mirror-gcc-814ec21/libgcc/libgcc2.c: In function '__divdc3': ../../../../gnu-mirror-gcc-814ec21/libgcc/libgcc2.c:2063:7: internal compiler error: Segmentation fault: 11 2063 | if (FABS (d) >= RBIG) | ^~ Please submit a full bug report, with preprocessed source (by using -freport-bug). Does it work with this RSB: commit a536dfe98585b648de0c8f49321d057675993153 Author: Sebastian Huber Date: Mon Oct 9 07:43:43 2023 +0200 6/7: Update Newlib Pick up latest changes from ARM/optimized-routines. Close 4510. If yes, then this is a GCC release branch regression between: -%define gcc_version 506cb58 +%define gcc_version 814ec21 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems6 master on darwin-x86_64 fails building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1
On 17.10.23 21:52, Heinz Junkes wrote: Hi, unfortunately i can't build RTEMS6 on the Intel-Mac (darwin-x86_64) at the moment. it fails here: ... downloading: patches/fix-mac-arm64-mpc-config.patch - 347.0 bytes of 347.0 bytes (100%) download: https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0.tar.bz2 -> sources/mpfr-4.2.0.tar.bz2 downloading: sources/mpfr-4.2.0.tar.bz2 - 1.6MB of 1.6MB (100%) building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 error: building arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 Build FAILED See error report: rsb-report-arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1.txt Note: In some cases the error appears only in the complete build log (see --log option) error: building arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 Build Set: Time 0:31:04.275488 error: building arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1 Build Set: Time 0:31:04.299122 Build FAILED with ../../../../gnu-mirror-gcc-814ec21/libgcc/libgcc2.c: In function '__divdc3': ../../../../gnu-mirror-gcc-814ec21/libgcc/libgcc2.c:2063:7: internal compiler error: Segmentation fault: 11 2063 | if (FABS (d) >= RBIG) | ^~ Please submit a full bug report, with preprocessed source (by using -freport-bug). Does it work with this RSB: commit a536dfe98585b648de0c8f49321d057675993153 Author: Sebastian Huber Date: Mon Oct 9 07:43:43 2023 +0200 6/7: Update Newlib Pick up latest changes from ARM/optimized-routines. Close 4510. If yes, then this is a GCC release branch regression between: -%define gcc_version 506cb58 +%define gcc_version 814ec21 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Windows 11 - Compiling toolchain (5.3 and 6)
Hello Chris, some of our customers use WSL2 with Ubuntu, they reported no issues with the RSB build of RTEMS 6. If you want to build mingw tools, then I would build them on Linux with a mingw cross compiler. Kind regards, Sebastian -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: arm bsps: changing the float-abi to softfp
Hello Ingolf, the -mfloat-abi=softfp instructs the compiler to emit floating-point instructions if other machine options specify a FPU. Why would you use this instead of -mfloat-abi=hard? For a statically linked executable this makes little sense. You still have to take care of the FPU context during context switches and interrupt processing. If you really need such a multilib, then you can patch gcc/config/arm/t-rtems. I don't know if you can add custom patches to the RTEMS Source Builder. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Issue with read() and flush()
Hello Jeff,
On 02.03.23 22:57, jeff.hat...@l3harris.com wrote:
I am working on a project that uses the RTEMS OS on a Leon3 processor. I
am trying to read/write from a UART that is connected up through the
termios interface. It works for the most part but I am running into an
issue with flushing and reading from the UART. It seems if I read a
small portion of the data use read() then flush then read again there is
still data returned. Is this expected behavior? If so is there any way
to clear out whatever is cached in read?
Pseudo Code
Open UART with open("/dev/console_b", O_RDWR | O_NONBLOCK); setup
terminal into raw mode with cfmakeraw() and tcsetattr(fd,
TCSADRAIN,term)
Setup the UART into loop back mode so its TX data is looped back into
its RX Write data into UART with write(fd, "TEST",4) Read a single
character with read(fd, buff, 1); buff will contain "T" here flush
buffers with tcflush(fd, TCIOFLUSH) Read a more from UART with read(fd,
buff, 3); Would expect nothing is returned here but "EST" will be returned.
this could be a limitation of the current Termios implementation. It
doesn't flush device buffers:
static void
flushInput (struct rtems_termios_tty *tty)
{
rtems_termios_device_context *ctx = tty->device_context;
rtems_interrupt_lock_context lock_context;
rtems_termios_device_lock_acquire (ctx, _context);
tty->rawInBuf.Tail = 0;
tty->rawInBuf.Head = 0;
rtems_termios_device_lock_release (ctx, _context);
}
If the characters are still in the UART FIFO, then they are not flushed.
This could be fixed by calling the device ioctl handler in this function
and additional device-specific handling.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Determining resource usage for BSP drivers
On 10.02.23 14:53, jan.som...@dlr.de wrote: -Original Message- From: users On Behalf Of Sebastian Huber Sent: Freitag, 10. Februar 2023 14:23 To:martinerikwerner@gmail.com;users@rtems.org Subject: Re: Determining resource usage for BSP drivers On 10.02.23 14:19,martinerikwerner@gmail.com wrote: Some BSP drivers use rtems objects in their implementation, for example GRCAN creating semaphores in bsps/shared/grlib/can/grcan.c. [...] Or is it assumed that the system will be configured with unlimited resources instead in most cases where this could become an issue? Yes, it is quite difficult to do the resource accounting for the Classic API objects. We rewrote a lot of drivers to use the self-contained synchronization objects: https://docs.rtems.org/branches/master/c-user/self_contained_objects.html Ah, very interesting and well explained. Can one use it as a general rule of thumb for new applications to prefer those self-contained objects instead of the classic rtems_semaphore_create() objects? And are there any pitfalls when mixing those two APIs or is it safe to do so? You can mix the APIs as you like. For applications, I would use a standard API such as POSIX or the C++ library. The POSIX objects perform a bit more error checking. The self-contained objects mentioned above are performance optimized. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Determining resource usage for BSP drivers
On 10.02.23 14:19, martinerikwerner@gmail.com wrote: Some BSP drivers use rtems objects in their implementation, for example GRCAN creating semaphores in bsps/shared/grlib/can/grcan.c. (GRCAN is only used as an example, there seems to be many BSP drivers which do this, the fact that GRCAN use the driver manager might make it not the best example..?) How is the application supposed to calculate the correct resource amount to set for the drivers it is using? Is there any support for this in either code or documentation? Or is the idea that a user needs to: * Know exactly what drivers are used/available. * Read the source code of each of these drivers and count up the rtems resources used. For example, in GRCAN, it looks like 4 semaphores are used for each device, so a user would then do something like: #define CONFIGURE_MAXIMUM_SEMAPHORES \ (MY_SEMAPHORES + MY_GRCAN_MAXIMUM_DEVICES * 4) As the number of drivers used increases, this seems like it could become quite hard to manage and prone to errors, if this manual method needs to be used. Or is it assumed that the system will be configured with unlimited resources instead in most cases where this could become an issue? Yes, it is quite difficult to do the resource accounting for the Classic API objects. We rewrote a lot of drivers to use the self-contained synchronization objects: https://docs.rtems.org/branches/master/c-user/self_contained_objects.html -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS5 and network statistics
Hello Miroslaw, On 11.01.23 23:57, Miroslaw Dach wrote: I use RTEMS5 on mvme3100. I would like to read network statistics. I am interested in the transmitted and received bytes and packets. There is a function call *rtems_bsdnet_show_if_stats (void)* in *./cpukit/libnetworking/rtems/rtems_showifstat.c* which uses the BSP specific call: *(*ifp->if_ioctl)(ifp, SIO_RTEMS_SHOW_STATS, NULL);* which calls the BSP related function: *BSP_tsec_dump_stats()* in *bsps/powerpc/mvme3100/net/tsec.c* Is there a way to retrieve the network statistics in the generic way BSP independent? in the old network stack (it is included in RTEMS 5, in RTEMS 6 it was moved to a separate repository), the network statistics are BSP-specific. In the new network stack (libbsd), the statistics have a standard interface. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Running two RTEMS instances on two RISC-V harts
Hello Jens, in general, such a setups works. We used it some time ago on the NXP P1020 before the SMP support was available. You just have to provide two MEMORY definitions for the linker. You also have to make sure that you don't accidentally share hardware modules between the two RTEMS instances without synchronization. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS5 and file descriptors
On 18/10/2022 06:15, Chris Johns wrote: On 18/10/2022 2:22 pm, Michael Davidsaver wrote: On 10/17/22 16:20, Chris Johns wrote: 2. Look at kqueue, it is a better interface for this type of blocking Maybe not relevant in Miroslaw's application, but I've found that the RTEMS kqueue implementation doesn't notify when a TCP connection is closed by reset. I think this is a lack of NOTE_EOF *. Thanks. I cannot find a ticket for this? Do you know if one has been created? This looks like a general FreeBSD limitation. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Is most drivers interfaces should be driver or application specific?
On 14.09.22 11:55, Y. HB wrote: Hello all. I'm writing drivers ( like ADC ) for tms570 on RTEMS. To my understanding for now, there are two ways to implement non common interface drivers. 1. write a specific driver.h/.c pair to be called like PWM driver inside bsps/arm/beagle/ 2. use I/O Manager interfaces. The latter IO Manager way still requires a specific void * argument to pass actual parameters into the driver, but at least it could provide a way to make application specific or general driver interface not SoC / Device specific. Is my understanding correct? I would not use the IO Manager for new drivers. It would introduced overheads and leads to difficult to use interfaces (ioctl). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Is rtems interrupt latency good enough for BLDC ESC? (on arm cortex-M or cortex-R)
On 05/09/2022 15:55, Y. HB wrote: I see zephyr provided a "Zero-Latency interrupt" facility to do with near bare metal performance interrupt handler, and a talk is about using Zero-Latency Interrupts feature to make a ESC with ZephyRTOS. A "zero-latency interrupt" in Zephyr is just an interrupt which has a higher priority than the interrupts managed by Zephyr. You cannot use operating system services in such an interrupt. Is rtems good enough to do the same thing? For ARMv7-M yes, the lower priority half of interrupt priorities is managed by RTEMS, the higher priority half can be used for such "zero-latency interrupts". For ARMv7-AR, the FIQ can be used. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Unknown task ID "Hefg" seen in thread_switch hook
On 29/08/2022 13:59, Schweikhardt, Jens (TSPCE6-TL5) wrote: Does this name ring a bell for you? No. Does RTEMS use “internal” tasks that we don’t see? Yes, idle tasks for example. How could the thread_switch hook see such a name? It is in the thread control block. You can inspect the other members to figure out which task it is. My only theory at the moment is that a wild pointer messed with the thread object. I would set a write break point to the name member in the thread control block to figure out the origin of this name. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Want to add RISC-V-based PolarFire SoC support to RTEMS
Hello Padmarao,
On 26/08/2022 13:37, padmarao.beg...@microchip.com wrote:
The boot HARTID configurable is Ok but I am thinking about SMP.
The PolarFire SoC has 4 U54's with hartid 1,2,3,4 but the SMP
starts with cpu number '0' to MAX cpu number then the PolarFire
SoC U54's hartid number should become 0,1,2,3 to run the SMP.
the numbers returned by
static inline uint32_t _CPU_SMP_Get_current_processor( void )
{
unsigned long mhartid;
__asm__ volatile (
".option push\n"
".option arch, +zicsr\n"
"csrr %0, mhartid\n"
".option pop" :
"=" ( mhartid )
);
return (uint32_t) mhartid;
}
must be in the range 0, ..., CPU count - 1. For your chip you need
something like
static inline uint32_t _CPU_SMP_Get_current_processor( void )
{
unsigned long mhartid;
__asm__ volatile (
".option push\n"
".option arch, +zicsr\n"
"csrr %0, mhartid\n"
".option pop" :
"=" ( mhartid )
);
return (uint32_t) mhartid + RISCV_MHARTID_OFFSET;
}
The RISCV_MHARTID_OFFSET could be a new CPU option which has
BSP-dependent default values. It would be the first CPU option in RTEMS
with BSP-dependent default values.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: How can I add LDFLAGS for bsp build?
On 25/07/2022 17:03, Y. HB wrote: Which way is a preferable way to add -lm for a BSP ? change bsp_specs ? So far all existing BSPs managed to avoid libm.a. The bsp_specs are gone in RTEMS 6. If you work on a new BSP, then I would use RTEMS 6 as a baseline. Actually, the -lrtemsbsp is added by the -qrtems option for GCC. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: How can I add LDFLAGS for bsp build?
On 25/07/2022 16:33, DAVE ERICKSON wrote: You NEED to, not optional, use the linker flag -L/path/to/correct/libm.a I would not do this. The libm.a is a multilib. This means for a given set of machine flags, GCC selects the associated multilib variant of libm.a, libc.a, etc. The multilibs are configured specifically for RTEMS in GCC and based on the set of supported BSPs. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: How can I add LDFLAGS for bsp build?
On 25/07/2022 16:47, Y. HB wrote: ['/home/hongbo/Developer/Embedded/rtems/5/bin/arm-rtems5-gcc', '-qrtems', '-B/home/hongbo/Developer/Embedded/rtems/5/arm-rtems5/lib/', '-B/home/hongbo/Developer/Embedded/rtems/5/arm-rtems5/tms570lc4357_launchxl/lib/', '--specs', 'bsp_specs', '-march=armv7-r', '-mthumb', '-mbig-endian', '-mfpu=vfpv3-d16', '-mfloat-abi=hard', '-ffunction-sections', '-fdata-sections', '-MMD', 'test.c.1.o', '-o/home/hongbo/Developer/Embedded/rtems/app/hello/build/.conf_check_261484d99ea5da27480d47dee9a30c04/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-Bstatic -lm'] err: /home/hongbo/Developer/Embedded/rtems/5/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /home/hongbo/Developer/Embedded/rtems/5/arm-rtems5/tms570lc4357_launchxl/lib/librtemsbsp.a(HL_sci.o): in function `sciSetBaudrate': /home/hongbo/Developer/Embedded/rtems/build/tms570lc4357/arm-rtems5/c/tms570lc4357_launchxl/lib/libbsp/arm/tms570/../../../../../../../../../rtems-master/c/src/lib/libbsp/arm/tms570/../../../../../../bsps/arm/tms570/start/tms570lc4357/source/HL_sci.c:284: undefined reference to `floor' collect2: error: ld returned 1 exit status This is a problem with the search order of the libraries. The -lrtemsbsp is implicitly given by the --specs bsp_specs. You can try this: -lrtemsbsp -lm Alternatively, avoid the use of floating point operations and the floor() function. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Failed to build rtems 5.1 by rsb under debian 11 with LLVM DebugInfo enabled
On 03/07/2022 06:13, 起飞的老杨sprhawk wrote: Hello there. I found the reason. The c++ features used inside Symbolize.h is std c++ 14, but c++ options listed in wscript in all projects under rtems-tools has -std=c++11, which cause it failed to build. I manually modified the options in wscript, it all compiled The next question is: how can I put a patch to let RSB build with -std=c++14? Thanks for having a look a this. I think this bug was already fixed by: commit 0a5d2057749066e7d184836e92c7ce5334fccc90 Author: Christian Mauderer Date: Mon Jun 8 08:52:10 2020 +0200 trace: Use c++14 instead of c++11 if possible llvm version 10 uses features from c++14 standard in the headers. With that, the record/record-main-lttng.cc doesn't build any more. This patch makes sure that c++14 is used if it is available. Updates #4495 Unfortunately, this fix is not included in the RTEMS 5.1 release. It will be included in the 5.2 release. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Failed to build rtems 5.1 by rsb under debian 11 with LLVM DebugInfo enabled
On 01.07.22 15:13, 起飞的老杨sprhawk wrote:
Yes, it is indeed.
But I see in every llvm-9, llvm-11, llvm-15, they all have the same
definitions
415 void ELFFile::getRelocationTypeName(uint32_t Type,
416 SmallVectorImpl
) const {
417 if (!isMipsELF64()) {
418 StringRef Name = getRelocationTypeName(Type);
419 Result.append(Name.begin(), Name.end());
So I think they may not be an error to LLVM, or it may be some
incompatibility to gcc + llvm?
What happens if you include this header file in a single source file and
try to build it with gcc or clang?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Failed to build rtems 5.1 by rsb under debian 11 with LLVM DebugInfo enabled
On 01.07.22 10:38, 起飞的老杨sprhawk wrote: Hello there. I'm building rtems 5.1 arm toolchain under debian 11. I got errors when building rtems-tools. Because I installed LLVM, the configure script checked llvm and 'llvm/DebugInfo/Symbolize/Symbolize.h' and added |LIB_LLVM|, but during build process, it reports build error with log as an attachment I checked |/usr/lib/llvm-11/include/llvm/Object/ELF.h|, StringRef defines interator as |const char *|,, while SmallVector Template defined in functions has || Is this a problem with the LLVM installation? The error seems to be in the LLVM provided header files? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Building newly for 6/rtems-arm blows on compiling iOS_failure.cc
On 24/05/2022 21:09, Andrei Chichak wrote: and the tail end of the log file reads: /bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile /Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/./gcc/xgcc -shared-libgcc -B/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/./gcc -nostdinc++ -L/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/src -L/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/src/.libs -L/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/libsupc++/.libs -nostdinc -B/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081- x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/newlib/ -isystem/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/newlib/targ-include -isystem /Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/newlib/libc/include -B/Users/andreichichak/quick-start/rtems/6/arm-rtems6/bin/ -B/Users/andreichichak/quick-start/rtems/6/arm-rtems6/lib/ -isystem /Users/andreichichak/quick-start/rtems/6/arm-rtems6/include -isystem /Users/andreichichak/quick-start/rtems/6/arm-rtems6/sys-include -march=armv5te+fp -mfloat-abi=hard -I/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/../libgcc -I/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18 .7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/arm-rtems6 -I/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include -I/Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/libsupc++ -std=gnu++98 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=ios_failure.lo -g -O2 -march=armv5te+fp -mfloat-abi=hard -c -o ios_failure.lo ../../../../../../../gnu-mirror-gcc-197b7ac/libstdc++-v3/src/c++98/ios_failure.cc In file included from /Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/bits/basic_ios.h:37, from /Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/ios:44, from /Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/istream:38, from /Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/fstream:38, from ../../../../../../../gnu-mirror-gcc-197b7ac/libstdc++-v3/src/c++98/globals_io.cc:24: /Users/andreichichak/quick-start/src/rsb/rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/bits/locale_facets.h:1546:10: fatal error: bits/ctype_inline.h: No such file or directory 1546 | #include | ^ This error is not reported by clang, it is an error produced by the GCC cross compiler. I guess this is an issue with the build system. Do you see the ctype_inline.h file in your build tree? Does it work if you run make in the existing build tree? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Try to load and run RTEMS Image on Cora-z7-10
On 03/05/2022 16:43, Sarmad Ahmad wrote: I create the image as follows ./mkimage.py -A arm -O linux -T kernel -a 0x1000 -e 0x1000 -n RTEMS -d hello.exe test5.img Maybe there is an issue with the mkimage.py script. I would try to use the mkimage tool from U-Boot. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS5 for arm on macOS 12.3. Or how Apple blew up RTEMS.
Hello Andrei, On 25/03/2022 22:44, Mr. Andrei Chichak wrote: I’m not sure how python is supposed to be configured. Maybe this is a clue: python —version -bash: python: command not found python3 —version Python 3.8.9 I seem to have a couple of instances of Python.h in an appropriately named directory: /usr/local/Cellar/python@3.8/3.8.13/Frameworks/Python.framework/Versions/3.8/include/python3.8/Python.h /System/Volumes/Data/usr/local/Cellar/python@3.8/3.8.13/Frameworks/Python.framework/Versions/3.8/include/python3.8/Python.h maybe you can try out this patch on the master branch for RSB for RTEMS 5: https://git.rtems.org/rtems-source-builder/commit/?id=571a182d4aa3be967791c8c715cedbd2a88b3b91 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Split BSP in RTEMS 4.11 - autotools newbie question
On 14/03/2022 15:12, dsa93 wrote: I tried to change it to "rtems-c-src-lib-libbsp-arm-samrh71" (same as bsp root folder), but doing this kind of autotools voodo didnt helped. The result is still the same: Make does not see any target inside BSP folder. I guess I will continue work on two GIT branches and maybe colleagues will fix it some day :) I would also recommend you try it with RTEMS 6 which uses a new build system. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Sparc-rtems5
Hello Gustavo, On 16/02/2022 09:52, Gustavo F. Paredes Delaloye - LU2JGP wrote: Does anyone have a description or help on the function of the scripts (sparc-rtems5-...) inside the/opt/rtems-5.1-2019.07.25/bin/ folder? to which scripts do you refer to in particular? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Barrier Manager cross-node behaviour
On 28/01/2022 14:39, Joel Sherrill wrote: As far as I'm aware, I've only seen nodes mentioned in Classic API Guide, in Barrier Manager Directives section: - https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-create - https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-ident - https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-delete I'll fix at least that. The wording in the documentation is correct from my point of view. The problem is that "node" is a generic term in general which has a very specific meaning in RTEMS (also "local" and "global"). We already have a ticket for this: https://devel.rtems.org/ticket/4453 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: mvme2500 PCIe support
On 17/11/2021 15:50, Brendan Chandler wrote: Hi Sebastian, On 11/12/21 8:03 AM, Sebastian Huber wrote: I tried to port the FreeBSD PCI bus driver for this platform to RTEMS, but it had not enough time to finish it in my given time budget. So the status is: 1. PCIe works in general on this platform. 2. An open PCI bus driver is missing. Could you point me to the freebsd driver you tried to port? I would like to take a look at its implementation. https://github.com/freebsd/freebsd-src/blob/main/sys/powerpc/mpc85xx/pci_mpc85xx.c -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: mvme2500 PCIe support
Hello Brendan, On 12/11/2021 00:53, Brendan Chandler wrote: I've been looking at running RTEMS 5 on an MVME2500 board. So far I've used the qoriq BSP which boots and connects to the network, but it lacks PCI support. My goal with PCI support for this board is to get VME bus working with EPICS. Does anyone have PCI support for this board working already? If not, I'd like to work on getting it added, though I'm somewhat new to RTEMS, BSPs, and even PCI so I appreciate any help or guidance anyone can provide. I played around with porting some of the PCI code from the other PPC BSPs (mvme3100 or 5500) but couldn't get all the devices found in the config space. Since the board supports PCIe, I'm wondering if it would make sense to try to implement PCIe support for it instead. Before starting that work, I thought I'd post my intentions here and get people's opinions and guidance. we use PCIe on the QorIQ (T4240 in our case). Mainly for NVMe storage devices. It works really well and the performance is great. We use the PCI device support from libbsd as well as the NVMe driver. However, we use a proprietary PCI bus driver written in C++. I tried to port the FreeBSD PCI bus driver for this platform to RTEMS, but it had not enough time to finish it in my given time budget. So the status is: 1. PCIe works in general on this platform. 2. An open PCI bus driver is missing. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Caching build objects: Waf and ccache
Hello Stanislav, On 05/10/2021 11:17, Stanislav Pankevich wrote: I have a very specific question about the Waf build system. I apologize if I missed this information somewhere in the documentation. From looking at ./waf --help it doesn't look like Waf would have a ccache-like functionality built in. When using CMake build system, I am used to providing -DCMAKE_CXX_COMPILER_LAUNCHER=ccache that makes CMake switch to using ccache. Is there an equivalent option for Waf or is there a native way in Waf for caching object artifacts? you may have a look at this: https://gitlab.com/ita1024/waf/blob/master/waflib/extras/wafcache.py I don't know if this works with RTEMS. Do you want to use this for the RTEMS build? I am not sure if it is worth the trouble since RTEMS builds in a couple of seconds. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Static allocation
On 28/09/2021 21:39, Joel Sherrill wrote: Sebastian is there any guidance in the Classic API or Users Guide about static systems? Not yet, but it is on my TODO list. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: [EXTERNAL] rtems_semaphore routines on SMP systems
On 28/09/2021 17:11, Johnson, Andrew N. wrote:
sc = rtems_semaphore_create (rtems_build_name ('B', c3, c2, c1),
initialState,
RTEMS_FIFO | RTEMS_SIMPLE_BINARY_SEMAPHORE |
RTEMS_NO_INHERIT_PRIORITY | RTEMS_NO_PRIORITY_CEILING |
RTEMS_LOCAL,
0,
);
We will want to use the same code on both SMP and UP systems and from
earlier posts it sounds like they would need different flags. Does RTEMS
define a macro that tells us which we’re compiling for, or will we have
to add our own?
You don't need different flags. The earlier post mentioned a new locking
protocol (MrsP) which is specifically added for SMP systems. This is not
relevant for this event stuff here.
You can use the RTEMS_SMP define to figure out if RTEMS was built with
SMP support enabled:
https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#application-configuration
Which RTEMS semaphore classes do you use in EPICS and in particular
which classes do you use in interrupt context?
An epicsEvent must be able to be triggered from interrupt context, and
in the above implementation epicsEventTrigger() calls
rtems_semaphore_release(). That’s the only routine we need AFAIK.
The RTEMS_SIMPLE_BINARY_SEMAPHORE semaphores can be used from within
interrupt context. An alternative are:
https://docs.rtems.org/branches/master/c-user/self_contained_objects.html#binary-semaphores
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: [EXTERNAL] rtems_semaphore routines on SMP systems
On 28/09/2021 12:24, Heinz Junkes wrote:
in EPICS osdMutex the semaphore is created like this:
sc = rtems_semaphore_create (rtems_build_name ('M', c3, c2, c1),
1,
RTEMS_PRIORITY|RTEMS_BINARY_SEMAPHORE|RTEMS_INHERIT_PRIORITY|RTEMS_NO_PRIORITY_CEILING|RTEMS_LOCAL,
0,
);
if (sc != RTEMS_SUCCESSFUL) {
errlogPrintf ("Can't create mutex semaphore: %s\n", rtems_status_text
(sc));
return NULL;
}
The implementation:
https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/osi/os/RTEMS-score/osdMutex.c
This is a priority inheritance mutex which must be used by threads only.
Using it from within interrupt context will not work.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Statically allocated build
On 28/09/2021 13:56, Петр Борисенко wrote> Oh, I got it. Does FS enabled by default and I am supposed to disable it during the build process? You need these configuration options: #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 0 #define CONFIGURE_DISABLE_NEWLIB_REENTRANCY #define CONFIGURE_APPLICATION_DISABLE_FILESYSTEM #define CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE XYZ -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: [EXTERNAL] rtems_semaphore routines on SMP systems
On 28/09/2021 11:46, Heinz Junkes wrote: Unfortunately we found out that EPICS uses the mutex handling also in the interrupt context and this leads to core-dumps in RTEMS :-( Yes, using any kind of mutexes in interrupt context is undefined behaviour. Mutexes may only be used from threads. Which RTEMS semaphore classes do you use in EPICS and in particular which classes do you use in interrupt context? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Statically allocated build
Hello, On 24/09/2021 20:08, Петр Борисенко wrote: Hello everyone! I am currently creating a aerial robot application upon the arm/stm32f4 bsp (extending it, possibly will contribute soon) I have just moved from RTEMS5 to RTEMS6 and have a few questions. 1. I don't understand how to build a system fully statically allocated. For safety reasons I shouldn't use neither heap for the system objects nor dynamic loading. if you don't use the unlimited objects option, then the Classic API objects are statically allocated in RTEMS 6. You can construct tasks and message queues with user-provided storage: https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-construct https://docs.rtems.org/branches/master/c-user/message/directives.html#rtems-message-queue-construct The POSIX and C++ synchronization objects use user-provided storage. 2. I have just noticed that `__usrenv.c` has been compiled into my application. I don't understand how to disable it. I would look at the linker map file. You probably use a file system. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: [EXTERNAL] Re: rtems_semaphore routines on SMP systems
Hello Michel, On 27/09/2021 18:59, Michel, John M wrote: Could you clarify what you mean by "concurrent use and deletion of a semaphore object is undefined behaviour on SMP systems". sorry for being so unclear. What I meant is using the semaphore (obtain or release) in one thread and deleting the semaphore at the same time in another thread (you need two processors for this). This is not supported on SMP systems. It works most of the time, but not always. It seems the whole point of semaphores is concurrent use. Does RTEMS not support two threads running on two different cores both accessing a semaphore? To me that would mean RTEMS does not support SMP. Concurrent use (obtain and release) of the semaphore works of course. The above restriction is not unusual: https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html "Attempting to destroy a locked mutex, or a mutex that another thread is attempting to lock, or a mutex that is being used in a pthread_cond_timedwait() or pthread_cond_wait() call by another thread, results in undefined behavior." This restriction is for performance reasons. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems_semaphore routines on SMP systems
Hello Heinz, On 25/09/2021 12:23, Heinz Junkes wrote: Can the rtems_semaphore_*() routines be used on SMP systems? all the rtems_semaphore_*() routines can be used on SMP systems. However, concurrent use and deletion of a semaphore object is undefined behaviour on SMP systems. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: 【About rtems condition variable signal intf】
Hello, On 01/07/2021 11:20, tia...@sugon.com wrote: Hello rtems_condition_variable_broadcast call _Condition_Broadcast, like this: but in score level, there is a _Condition_Signal func, like this: Is it a bug? thanks for reporting this. Yes, this is a bug. I fixed it like this: https://git.rtems.org/rtems/commit/?id=737e18dbca03c086601dfbe7f90ae143bc34f964 If you are interested, you could add a test case for this to: https://git.rtems.org/rtems/tree/testsuites/sptests/spthread01/init.c?id=737e18dbca03c086601dfbe7f90ae143bc34f964 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Heap allocation for libbsd overwrites IMFS
On 23/06/2021 17:51, jan.som...@dlr.de wrote: You probably have a general memory corruption issue. As a first step I would enable RTEMS_DEBUG = True to enable the heap protection. This could help to debug the issue. With this enabled a few asserts failed during early system initialization which were not related to our problem. I could post the points where this happened, but I don't know enough about the internals to fix them. It is likely that the failed asserts are actually bugs. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Heap allocation for libbsd overwrites IMFS
On 23/06/2021 10:32, jan.som...@dlr.de wrote: One of our applications for the Zedboard fails with fatal error after the setup of the network stack in libbsd. So far I traced it down to the point that the memory allocation for libbsd overwrites parts of the IMFS of rtems. When opening device files later this will lead to the crash. The backtrace looks like this for the bad allocation looks like this: _Heap_Block_split ../../../../../c/src/../../cpukit/score/src/heap.c:313 0x10dd58 _Heap_Block_allocate_from_begin ../../../../../c/src/../../cpukit/score/src/heap.c:378 0x10dfd6 _Heap_Block_allocate../../../../../c/src/../../cpukit/score/src/heap.c:465 0x10dfd6 _Heap_Allocate_aligned_with_boundary ../../../../../c/src/../../cpukit/score/src/heapallocate.c:265 0x10e19c rtems_heap_allocate_aligned_with_boundary ../../../../../c/src/../../cpukit/libcsupport/src/malloc_deferred.c:92 0x10962e malloc ../../../../../c/src/../../cpukit/libcsupport/src/malloc.c:39 0x10950e _bsd_malloc ../../rtemsbsd/rtems/rtems-kernel-malloc.c:80 0x170048 [more libbsd] ifconfig../../freebsd/sbin/ifconfig/ifconfig.c:1024 0x1724fa You probably have a general memory corruption issue. As a first step I would enable RTEMS_DEBUG = True to enable the heap protection. This could help to debug the issue. With 1 GiB of RAM, available memory shouldn't be a problem. At the moment we have configured the system with CONFIGURE_UNLIMITED_OBJECTS and CONFIGURE_UNIFIED_WORK_AREAS. This is fine. Maybe that is not right in this case. Are there any suggestions how to better configure the system? I found CONFIGURE_MEMORY_OVERHEAD in the docs, but I am not so sure how to use it or if it would help. No, it would not help. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: About kernel function _CPU_Counter_difference overflow issue
On 18/06/2021 10:25, wangqia...@sugon.com wrote:
1. Is it a bug?
static inline CPU_Counter_ticks _CPU_Counter_difference(
CPU_Counter_ticks second,
CPU_Counter_ticks first)
{
return second - first;
}
The CPU_Counter_ticks is an unsigned integer, so there should be no
issue unless you want to measure intervals geater than the maximum of
this integer type.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Timeslice issues with preemption enabled
On 10/06/2021 16:24, Gedare Bloom wrote: 5. Can anyone give some suggestions to solve the problem? thanks! Classic and POSIX APIs can be mixed. It is a poorly documented benefit of RTEMS. I think in this case, you should be able to use pthread_setschedparam(...) with passing policy == SCHED_RR to get the behavior you seek. You have to use posix priorities in the sched_param argument. though, or else your thread will have its priority changed. Pass the task_id instead of pthread_t as the first argument, and the rest should work itself out. Do let us know if that works or it doesn't work/you have more questions. You can use these directives to convert priority values: https://docs.rtems.org/branches/master/c-user/scheduling-concepts/directives.html#rtems-scheduler-map-priority-to-posix In general, the timeslicing based on clock tick quantum is quite coarse. The internal timestamps would allow a much finer grained timeslicing. This could be added if someone is interested in a small project. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: GSoC Introduction
Hello Ida, welcome on board. I am really looking forward to having an automatic code formatter in place which runs before patches are reviewed. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Can printf() be made SMP safe?
On 14/05/2021 03:09, Dave DeGroote wrote: I'm still beating my head against this so I wrote a simple RTEMS only test to narrow it down and the problem is still occurring. Sometimes it crashes, hangs, or runs fine, depending on the number of RTEMS objects created (it sometimes works with fewer objects and fails with more). If it crashes depending on the number of object, then this still looks like a general memory corruption which depends on the memory layout. Which RTEMS version do you use? Did enabling RTEMS_DEBUG help to get more information. I checked your example program on another target and it works fine. I didn't see anything obviously wrong in the example. - The code starts two tasks with printf() loops. - To start, the printf()'s do not overlap - this always works - The code then switches to fast overlapping printf()'s where it fails (depending on the #of objects). The compile command, code, and results are below. Thanks for any help or insight! Compile command (gcc version 7.2.0 (Cobham Gaisler RCC 1.3-rc7) ): sparc-gaisler-rtems5-gcc -Wall -g -O2 -Werror -mcpu=leon3 -mfix-gr712rc -qbsp=gr712rc_smp -o smp_test smp_test.c Results: fails with 20 semaphores: |gncsim||@gncsim||:~/grmon-pro-||3.0||.||9||/linux/bin64$ sudo ./grmon -ftdi -log /tmp/grmon-log.log -e ||"load ~/lander/flat_sat/DaveD/smp_test; run"||-u| |||GRMON LEON debug monitor v3.||0.9| |64||-bit pro version| || |||Copyright (C) ||2018| |Cobham Gaisler - All rights reserved.| |||For latest updates, go to http:||//www.gaisler.com/| |||Comments or bug-reports to support||@gaisler||.com| |JTAG chain (||1||): GR712RC| |Device ID: ||0x712| |||GRLIB build version: ||3696| |||Detected system: GR712RC| |||Detected frequency: ||80| |MHz| || |||Component Vendor| |||LEON3FT SPARC V8 Processor Cobham Gaisler| <... snip ...> || |||Timer Unit with Latches Cobham Gaisler| || |||Use command ||'info sys'| |to print a detailed report of attached cores| |||4000| |.text ||191||.7kB / ||191||.7kB [===>] ||100||%| |||4002FED0 .rtemsroset 96B [===>] ||100||%| |||40031F40 .data ||5||.6kB / ||5||.6kB [===>] ||100||%| |||Total size: ||197||.38kB (||774||.38kbit/s)| |||Entry point ||0x4000| |||Image /home/gncsim/lander/flat_sat/DaveD/smp_test loaded| |t1a:||0| |<||0||>| |t2a:||1| |[||0||]| |t1a:||0| |<||1||>| |t2a:||1| |[||1||]| |t1a:||0| |<||2||>| |t2a:||1| |[||2||]| |t2b:||1| |[||0||]| |t1b:||0| |<||0||>| |t2b:||1| |[||1||]| || |||CPU ||0||: Unknown watchpoint hit| |||0x400217b4||: ba100015 mov %l5, %i5 <_vfprintf_r+||316||>| |||CPU ||1||: IU exception (tt = ||0x2B||, data store error)| |||0x40011818||: ||9611| |mov %g1, %o3 <_Thread_queue_Queue_enqueue+||108||>| || |grmon3> bt cpu0| || |||%pc %sp| |||#||0| |0x400217b4| |0x4003eb60| |<_vfprintf_r+||0x13c||>| |||#||1| |0x4001e1ec| |0x4003ed38| || |||#||2| |0x40001334| |0x4003eda0| || |||#||3| |0x40010084| |0x4003ee00| |<_Thread_Entry_adaptor_numeric+||0x8||>| |||#||4| |0x4000ea8c| |0x4003ee60| |<_Thread_Handler+||0x60||>| |||#||5| |0x4000ea2c| |0x4003eec0| |<_Thread_Handler+||0||>| || |grmon3> bt cpu1| || |||%pc %sp| |||#||0| |0x40011818| |0x4003fae0| |<_Thread_queue_Queue_enqueue+||0x6c||>| |||#||1| |0x40010c00| |0x4003fb40| |<_Thread_queue_Enqueue+||0x80||>| |||#||2| |0x4002ce60| |0x4003fba8| || |||#||3| |0x4002cf34| |0x4003fcd8| || |||#||4| |0x400214c4| |0x4003fd38| || |||#||5| |0x400013dc| |0x4003fda8| || |||#||6| |0x40010084| |0x4003fe08| |<_Thread_Entry_adaptor_numeric+||0x8||>| |||#||7| |0x4000ea8c| |0x4003fe68| |<_Thread_Handler+||0x60||>| |||#||8| |0x4000ea2c| |0x4003fec8| |<_Thread_Handler+||0||>| || |grmon3>| There seems to be a data store error in usleep(). This function uses a global object: _Nanosleep_Pseudo_queue. I would check the state of this object during crash. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Can printf() be made SMP safe?
Hello Dave, this looks like a memory corruption issue. I would use GDB and check the value of mutex objects SMP lock. If next_ticket and now_serving differ by more than one on the GR712RC, something is seriously wrong. Which RTEMS version do you use? It may help to enable the stack checker and the RTEMS internal debugging support (RTEMS_DEBUG = True or --enable-rtems-debug). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Announce: RTEMS 5.1 Release
Hello Pierre, On 25/04/2021 16:31, Pierre FICHEUX wrote: Is Raspberry Pi 1 B+ BSP OK for RTEMS 5.1 ? maybe this BSP is affected by this bug: https://devel.rtems.org/ticket/4394 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: libbsd: React to link status change events
On 29/04/2021 13:43, jan.som...@dlr.de wrote: is there an easy way to register a callback function or block until a link status change of an Ethernet device occurs in the libbsd stack? Searching for it, I found some references for EV_NETDEV in kqueue, but this seems to be a legacy function which has been removed years ago. In the console of the Zedboard, for example, I see those events as info statements, but haven't found an API to hook into that: info: lo0: link state changed to UP info: cgem0: link state changed to DOWN info: cgem0: link state changed to UP You can look at the dhcpcd code to figure out how this works. I think a routing socket can be used to get these events. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Can not build rtems-examples for sparc/erc32
On 09/04/2021 09:20, junkes wrote: can not build examples (https://github.com/RTEMS/rtems-examples.git) for sparc/erc32. Seems to related to missing run time linker lib. I updated the RSB. I hope it is fixed now. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS only executes no task and only finds one core imx7
Hello Stefan, On 09/03/2021 20:11, Stefan Akatyschew wrote: core 1 is stuck at an IRQ intialisation routine (in irq/irq-gic.c) for ditto? I can't really debug the second core somehow. Though Trace32 is supposed to step through core 0 and 1 simultaniously (in SMP), it does only work on core 0 for me. Trying to do that on core 1 results in bus error for me... All I see is it being stuck at : irq/irq-gic.c:157 BSP_START_TEXT_SECTION void arm_gic_irq_initialize_secondary_cpu(void) I would try to fix the debug issues on core 1 so that you can debug the startup reliably. You can also contact the Lauterbach support. From the screenshots you see that core 0 waits for the core 1 to perform some parts of the clock driver initialization. However, core 1 waits in a very early step for an initialized interrupt controller (which was already done by core 0). Is the address of the GIC Distributor all right on core 1? If you look at the register via the Lauterbach peripheral view, is the Distributor enabled? Maybe there is an issue with the MMU setup on core 1. You can check the MMU initialization with the Lauterbach. The GIC area has to be a Device memory. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems-record-lttng: Corrupted timestamps after translating to CTF
On 18/03/2021 23:06, jan.som...@dlr.de wrote: The to_bt_scaler is quite a large value and I don't fully get what it scales. Does someone have some hints? It could be related to ring buffer overflows. Do you get RTEMS_RECORD_PER_CPU_OVERFLOW items? There could be also some bugs in record-client.c. More unit tests for it would be helpful. I had some more time to look at this. It turns out that the RTEMS_RECORD_UPTIME_* events are always assigned to cpu 0. I checked the watchdog and indeed the _Record_Watchdog (https://git.rtems.org/rtems/tree/cpukit/libtrace/record/record-sysinit.c#n64) is executed twice, but always on cpu 0. I tested with the rv32imac bsp with 2 cores, each with its own RTEMS_SCHEDULER_PRIORITY_SMP and with the following defines: #define CONFIGURE_RECORD_PER_PROCESSOR_ITEMS 2048 #define CONFIGURE_RECORD_EXTENSIONS_ENABLED #define CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB Do I need to configure something else? I am not familiar with the watchdog part. The initialization looks good as far as I can tell. Ok, I thought you use the Zynq. In a production SMP system, the clock driver interrupt must fire on all processors used by the system. That the current RISC-V clock driver uses only the boot processor is a known limitation and you see this in the smpclock01 test failure. I would fix the clock driver and use an approach similar to the Arm Generic Timer clock driver. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems-record-lttng: Corrupted timestamps after translating to CTF
On 05/03/2021 16:11, jan.som...@dlr.de wrote: Some of the resulting CTF events have a very large timestamp. This only occurs for events of which are created by CPUs other than CPU0, but not all of them. I ran rtems-record-lttng in gdb and could track it to record-client.c:176 (https://git.rtems.org/rtems-tools/tree/trace/record/record-client.c#n176). There the (delta * ctx->to_bt_scaler ) causes an overflow and sets per_cpu->uptime.bt to a very large negative number which then later becomes a very large (positive) timestamp. I have some trouble figuring out what is going wrong here. The timestamps which are read from the rtems record events looks quite reasonable to me. The to_bt_scaler is quite a large value and I don't fully get what it scales. Does someone have some hints? It could be related to ring buffer overflows. Do you get RTEMS_RECORD_PER_CPU_OVERFLOW items? There could be also some bugs in record-client.c. More unit tests for it would be helpful. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: SPI Driver Implementation
On 10/02/2021 08:37, jan.som...@dlr.de wrote: Assuming they need to be developed, I looked at the RTEMS 6 BSP and Driver Guide that specifies the use of the "SPI bus framework". However, I have looked at some of the Arm BSPs included with RTEMS and they all seem to use the libi2c library that is part of the cpukit. It claims to support both I2C and SPI. I think the preferred way is to use the libi2c API for i2c devices only and use the Linux spidev API for SPI devices. In the docs are a few drivers which already implement the spidev API (https://docs.rtems.org/branches/master/bsp-howto/spi.html). For the cadence-SPI driver I used the general layout of the NXP i.MX SPI driver linked there and implemented it according to the data sheet from Xilinx. The libi2c is a legacy interface. New I2C drivers should use: https://docs.rtems.org/branches/master/bsp-howto/i2c.html -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: GCC 11 and Static Analysis
Hello Matthew, On 29/01/2021 10:14, Matthew J Fletcher wrote: Hi, Does RTEMS trunk roughly follow GCC releases ?,. i've seen discussion of GCC 11 on the dev mailing list. you can already try out the GCC 11 based tools with the experimental RTEMS 7 tool chain available in the RSB. I wonder if we (RTEMS users) could take advantage of the new static analysis options in GCC 11. https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.redhat.com%2Fblog%2F2021%2F01%2F28%2Fstatic-analysis-updates-in-gcc-11%2F=04%7C01%7Cmatthew.fletcher%40se.com%7Cb41c34faa0154d5137e908d8c42830b3%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637475024180771568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=SmQ4xfLBvYSeQUx0xd0jKC2z%2F89gRLH6IrHg17EJmUI%3D=0> Would seem very useful for embedded projects where runtime analysis is difficult. Yes, you can give it a try. I never used it myself. The Coverity scan alone keeps me busy. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Using LwIP on the STM32H7
On 29/01/2021 12:01, Robin Müller wrote: The HAL_ETH_Transmit call just times out. If I set the timeout to 20 to HAL_MAX_DELAY, the function will just block indefinitely. Does anyone have an idea why this might happen? I would check the memory settings in the MPU for this area. You probably need some sort of device memory (uncached). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Using LwIP on the STM32H7
On 28/01/2021 16:45, Robin Müller wrote: *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*))) .bsp_nocache 0x3000 0x18c0 CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj 0x3000 DMARxDscrTab 0x3060 DMATxDscrTab 0x30c0 Rx_Buff 0x300018c0 bsp_section_nocache_end = . 0x18c0 bsp_section_nocache_size = (bsp_section_nocache_end - bsp_section_nocache_begin) But in the debugger, the descriptor entries are still zeroed out unfortunately.. If you place them in BSP_NOCACHENOLOAD_SECTION or BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Using LwIP on the STM32H7
On 28/01/2021 14:35, Robin Müller wrote:
So far, transferring the code has worked, but there are some specific
sections in the code used for our FreeRTOS example which put the
ethernet DMA descriptors in specific sections:
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
__attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA
Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
__attribute__((section(".TxDecripSection"))); /* Ethernet Tx DMA
Descriptors */
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]
__attribute__((section(".RxArraySection"))); /* Ethernet Receive
Buffers */
The BSP has a nocache section, see
bsps/arm/include/bsp/linker-symbols.h
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Delay until in Ada seems not to work
On 27/01/2021 15:27, Mattia Bottaro wrote: I've not specified it because I'm in a "non-conventional" situation: I'm running RTEMS over XtratuM: <https://fentiss.com/products/hypervisor/ <https://fentiss.com/products/hypervisor/>>. I'm using a BSP developed by FentISS. The hardware is the zynq7000. Then I suggest you try to reproduce the issue first using a RTEMS version distributed by the RTEMS Project. We have a Qemu BSP for this platform. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Delay until in Ada seems not to work
On 27/01/2021 11:54, Mattia Bottaro wrote: If you look at rtems_init.c file in that folder (<https://git.rtems.org/ada-examples/snapshot/ada-examples-4-10-2.tar.bz2 <https://git.rtems.org/ada-examples/snapshot/ada-examples-4-10-2.tar.bz2>>), you can see that there is no time of day. I thought it was ok since I'm running an example. Anyway, I've added time of day in rtems_init.c with these values: https://github.com/RTEMS/rtems-examples/blob/master/classic_api/triple_period/init.c#L39 <https://github.com/RTEMS/rtems-examples/blob/master/classic_api/triple_period/init.c#L39>. I've also set it with status = rtems_clock_set( ) , but the behaviour does not change. On which BSP and hardware did you try this out? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: problem while trying converting c program from rtems4 to rtems5
Hello, On 03/01/2021 13:20, Rotem Dror MTH wrote: we also updated the linkcmds file according to linkcmds.base does this indicate that you use a custom BSP? I would first try to run the RTEMS test suite (start with ticker.exe). If the test results are all right, then I would start migrating the application. There is a new configuration option https://docs.rtems.org/branches/master/c-user/config/general.html#configure-verbose-system-initialization which may help to debug system initialization issues. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: How to program fine-grained real-time concurrent applications in C or Ada
Hello Mattia,
On 24/12/2020 11:24, Mattia Bottaro wrote:
I need to develop a multitasking real-time application with RTEMS
(preferably in Ada, but also C solutions are welcomed). I see that I
can use the Classic API
<https://docs.rtems.org/branches/master/c-user/index.html>, but they
are unsuitable to my purposes. As you can read here
<https://docs.rtems.org/branches/master/c-user/task/directives.html#task-wake-when-wake-up-when-specified>,
the rtems_task_wake_when directive is too coarse: "The timing
granularity of this directive is a second.".
I need to work with microseconds-granularity and I cannot find how to
do it.
this limitation is do some implementation constraints which no longer
apply. From an API point of view
/**
* @ingroup RTEMSAPIClassicTypes
*
* @brief This type represents Classic API calendar times.
*/
typedef struct {
[...]
/**
* @brief This member contains the clock tick of the second with
values from 0
* to rtems_clock_get_ticks_per_second() minus one.
*/
uint32_t ticks;
} rtems_time_of_day;
it would be possible to also specify the clock driver ticks of a time
point. The rtems_task_wake_when() uses _Thread_Timer_insert_realtime()
which uses a time with a nanoseconds resolution. It would be easy to
change the implementation of rtems_task_wake_when() to use the clock
driver ticks.
As already mentioned, the clock_nanosleep() provides this functionality
already.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: mDNS DNS-SD ZeroConf in RTEMS 5 ?
Hello Andrei, On 02/12/2020 21:05, Mr. Andrei Chichak wrote: To that end, I was wondering if the bsd networking stack in RTEMS 5 had the widgets to support service advertising through the mDNS/DNS-SD system? the libbsd contains a port of the mDNSResponder, see test programs foobarclient and foobarserver. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hub...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Can't submit patch
Hello Robin, On 26/11/2020 11:22, Robin Müller wrote: The patch in its current form still does not work. How is it possible to propagate the config.ini defines to the header files? I hardcoded the 8 MHz HSE value for now again for the Nucleo board.. what is the name of the option? The config.ini is only read by the "./waf configure" command. This command generates the header files. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hub...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: How to run RISC-V test applications using qemu?
On 25/11/2020 16:57, Jiri Gaisler wrote: PS. I plan to add "pure" riscv support to sis, once I find the proper device-tree definitions for the bsps ... You can run a test on Qemu and dump the device tree blob via GDB. With the device tree compiler you can read the blob and convert it to a plain text file. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hub...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Acessing PL devices of Xilinx Zedboard
On 23/11/2020 20:42, jan.som...@dlr.de wrote:
BSP_START_TEXT_SECTION static inline void
arm_cp15_start_set_translation_table_entries(
uint32_t *ttb,
const arm_cp15_start_section_config *config
)
{
if (config->begin != config->end) {
uint32_t i;
uint32_t iend;
uint32_t index_mask;
uint32_t flags;
#ifdef ARM_MMU_USE_SMALL_PAGES
uint32_t *pt;
pt = [ARM_MMU_TRANSLATION_TABLE_ENTRY_COUNT];
i = ARM_MMU_SMALL_PAGE_GET_INDEX(config->begin);
iend =
ARM_MMU_SMALL_PAGE_GET_INDEX(ARM_MMU_SECT_MVA_ALIGN_UP(config->end));
ARM_MMU_SECT_MVA_ALIGN_UP seems to round the end address up to the next MiB (e.g.
0x40001000 -> 0x4010).
Doesn't that mean that now all 4kiB pages until the next 1MiB will be setup according to
"config->flags" in the loop below, i.e. the same as using 1MiB sections?
This looks like a bug. It should only round up to the next small page.
I would have expected that the address in config->end is rounded up only to the
next 4kiB boundary, but I am not sure if I missed something.
I didn't need the 4KiB MMU for the static sections, so I didn't pay much
attention to this area. I used the small pages for a specialized heap
protection.
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Acessing PL devices of Xilinx Zedboard
Hello Jonathan, On 18/11/2020 17:00, Jonathan Brandmeyer wrote: Caveat: My information could be a little out of date. We're still running on a pre-release version of RTEMS 5.0. But hopefully this points you in the right direction. In particular, I know that some work has been done to support 4kB pages, but I don't know if the entry point arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache currently uses that support or not. the 4KiB pages MMU configuration was added with this commit: commit f9648baf65ecec2cd01c96557a677ad6ecc06b11 Author: Sebastian Huber Date: Mon Oct 28 10:15:28 2019 +0100 bsps/arm: Add support for small pages MMU The small page MMU support reduces the granularity for memory settings through the MMU from 1MiB sections to 4KiB small pages. Enable it by default on the realview_pbx_a9_qemu BSP. A BSP needs some minor changes to support it. -- embedded brains GmbH Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de Phone: +49-89-18 94 741 - 16 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. embedded brains GmbH Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: libbsd select timeout issue(critial!!)
Hello Zhengxin, On 17/11/2020 03:04, RUI Zhengxin wrote: Hi Sebastian, The bug report is added, a patch which using relative timeout is attached. It has no time drift during 1 week testing. https://devel.rtems.org/ticket/4179 <https://devel.rtems.org/ticket/4179> thanks for adding a ticket. To fix the issue we have to change the conversion of the absolute timeout value so that error doesn't grow over time. -- embedded brains GmbH Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de Phone: +49-89-18 94 741 - 16 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. embedded brains GmbH Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: libbsd select timeout issue(critial!!)
On 11/11/2020 03:50, RUI Zhengxin wrote: This issue is very critial, it can make the select abnormally return timeout after long run time. If the timeout is set to 5ms, when the system run after 7s(19.4h), the select function will wait 10ms timeout, which is two times of setting value. This issue is created by calculating timeout watchdog expire tick using the absolute time since libbsd5 version. Yes, the calculation of the absolute timeout is broken. Could you please add a bug report: https://docs.rtems.org/branches/master/user/support/bugs.html It would be nice if you could create a patch which fixes the bug. -- embedded brains GmbH Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de Phone: +49-89-18 94 741 - 16 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. embedded brains GmbH Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: When to register termios devices?
Hello Jan, if it is a custom BSP, why don't you add it to the console driver of this BSP? If you add RTEMS_SYSINIT_ITEM( register_additional_termios, RTEMS_SYSINIT_DEVICE_DRIVERS, RTEMS_SYSINIT_ORDER_LAST_BUT_5 ); to the module which defines bsp_start(), then your drivers are registered. They are also registered, when the application doesn't need them. So, doing a driver registration in the application configuration is not that bad. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: does anybody generate a core dump in rtems?
Hello, On 20/10/2020 04:56, small...@aliyun.com wrote: hi, all When my application running in rtems encounters a fatal error, I want to let the whole system to generate a core file. After that I can use gdb to debug the core file to find the reason. However, there is no information about this function. Does anybody meet this question? there is no out of the box support for this. You have to write our own core file dumper for the fatal error handler. If support for this can be generalized, it could be a nice contribution to the RTEMS Project. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Important notice for all users of Cortex-A9 based BSPs
Hello, I added workarounds for Cortex-A9 Errata 794072 and 845369 to the RTEMS 5 and master branches: https://devel.rtems.org/ticket/4114 https://devel.rtems.org/ticket/4115 They are only relevant in SMP configurations. Some bootloader already enable these workarounds. The hardware bug in Errata 845369 can lead to data corruption and we noticed system crashes due to it which are hard to debug. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Is -malign-int a usual m68k/ColdFire option?
Hello, a test suite failure surfaced that we may have an issue with the alignment of basic data structures on ColdFire targets: https://devel.rtems.org/ticket/4013 The chips usually have at least a 32-bit data system bus. I am not sure why RTEMS didn't use the -malign-int for the ColdFire targets before. Has anyone experience using this option? ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: STM32H7 startup test in RTEMS 4-11.3
Hello Catalin, I added a BSP for the STM32H7 earlier this year: https://git.rtems.org/sebh/rtems.git/log/?h=stm32h7 It is not yet included in the RTEMS Project since it used the new build system. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Fatal source exception in loopback sample on powerpc/qoriq_e6500_64
Hello Steven, On 14/09/2020 19:11, Clukey (US), Steven A wrote: I am attempting to run the `loopback.exe` sample application provided with RTEMS on the PowerPC qoriq_e6500_64 BSP, but unfortunately it is crashing. the old network stack doesn't work on 64-bit targets. For this BSP, use the new network stack (libbsd): https://docs.rtems.org/branches/master/user/bsps/bsps-powerpc.html#qoriq-qoriq ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS 4.10 i386 undefined reference to `rtems_bdbuf_configuration'
On 07/09/2020 19:14, Heinz Junkes wrote: rtems 4.10 —with-network —with-posix Unfortunately I cannot resolve a reference: source/rtems-source-builder/rtems/build/i386-rtems4.10-kernel-4.10-1/i386-rtems4.10-kernel-4.10-1-4.10/build/i386-rtems4.10/c/pc686/cpukit/libblock/../../../../../../rtems-4.10/c/src/../../cpukit/libblock/src/bdbuf.c:1156: undefined reference to `rtems_bdbuf_configuration’ the linker order looks like this: -lCom -Wl,--gc-sections -lm -lrtemsCom -lc -lrtemscpu -lCom -lnfs -lm -lgcc Try: -lCom -Wl,--gc-sections -lm -lrtemsCom -lc -lrtemscpu -lrtemsCom -lCom -lnfs -lm -lgcc ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: handle Fatal exception
On 31/08/2020 19:06, Ярослав Лещинский wrote: sometimes I'm getting FATAL, like: *** FATAL *** fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION) is it possible to handle this exception, e.g. restart the whole system? Yes, some BSPs do this by default in their fatal error extension. You can customize the behaviour via an initial extension: https://docs.rtems.org/branches/master/c-user/config/general.html#configure-initial-extensions https://docs.rtems.org/branches/master/c-user/user_extensions.html#fatal-error-extension ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: RTEMS on Aurix/TriCore
Hello Felix, On 28/07/2020 10:50, Knopp, Felix Ulrich wrote: Hello, The company I work for is currently using AURIX/TriCore micro-controllers running PXROS as real time operating system. I am now investigating if we could use a free alternative like RTEMS instead. However, from what i've seen so far (I'm very new to RTEMS) the TriCore architecture is not supported by RTEMS. Would it be possible to run rtems on an aurix micro-controller? yes, there is currently no TriCore support for RTEMS. One of the reasons is that there is no free and maintained compiler available for this platform (at least as far as I know). What would have to be done to support a new processor architecture? Firstly, you need a compiler. Ideally one which can build Newlib. For the RTEMS core, you don't need a full C library, but if you can't use Newlib, then things get more complicated. Then you have to do a full CPU port for the TriCore. This is feasible, but not done in two weeks of work. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: How do you plan before starting to code ?
Hello Richi, we use Doxygen to document the software design. Maybe you can write your high-level description with it. This way it is integrated already integrated in the sources. You can use @dot for graphs and @msc for message sequences. I would document the data structures and the invariants of the data structures. I would also try to write code which checks that the invariants are satisfied. This can be used in _Assert() and RTEMS_DEBUG blocks. I would also write test cases. You can already run the test cases with: https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#arbitrary-processor-affinity-priority-smp-scheduler There should be test cases which would fail with the Linux push and pull scheduler. You should identify the key scheduler operations (e.g. block and unblock) and write a high level description of the algorithms used for these operations in some sort of pseudo code. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Where to define CPU_SIMPLE_VECTORED_INTERRUPTS for RISC-V?
On 02/06/2020 10:06, Schweikhardt, Jens (TSPCE3-TL4) wrote: we are using a customized RV32IMAF CPU with RTEMS and need to handle interrupts. I'm new to configuring low level things such as this and need a bit of guidance where goes what. I build using the RTEMS source builder. It appears that for RISC-V a value for CPU_SIMPLE_VECTORED_INTERRUPTS is not defined, and thus treated as FALSE. Other CPUs, such as sparc, define it in cpukit/score/cpu/sparc/include/rtems/score/cpu.h. This CPU option is only defined to TRUE on legacy architectures. Q: Should I simply add a macro definition to cpukit/score/cpu/riscv/include/rtems/score/cpu.h or is there a better (proper) way, say, passing it as an argument to sb-set-builder or sb-bootstrap or the configure script building the bsps? No, please keep this value as is (FALSE). Use rtems_interrupt_handler_install() to install interrupts on RISC-V. For the interrupt controller support code see the existing BSPs. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Question about rtems_cpu_usage_report
On 27/04/2020 14:49, Joel Sherrill wrote: On Mon, Apr 27, 2020 at 1:10 AM Sebastian Huber <mailto:sebastian.hu...@embedded-brains.de>> wrote: Hello Carmen, On 24/04/2020 10:10, Carmen Pastor wrote: > Hi All, > > I've a question for RTEMS 4.10. I'm using the function > rtems_cpu_usage_report() to get the CPU usage, and it is working well > but now I need to process the data of the output report, so I would > like to get the report data in some kind of structure. I see the function > rtems_cpu_usage_report_with_plugin() but I don't know how use it, > could someone of you give me an example? unfortunately, the CPU usage report is not available in a structure. You could refactor the rtems_cpu_usage_report_with_plugin() function and add a variant which passes a structure with the CPU usage to a visitor function. FWIW the stack usage information is in the same situation. These are both desirable features but no one has stepped up to see that they got implemented. I know of at least one application that actually wrote the reports to a file and then parsed it to get their structure. Why they didn't invest the effort in refactoring the code, I don't know. It seems some users have an unfounded fear about modifying RTEMS sources. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Question about rtems_cpu_usage_report
Hello Carmen, On 24/04/2020 10:10, Carmen Pastor wrote: Hi All, I've a question for RTEMS 4.10. I'm using the function rtems_cpu_usage_report() to get the CPU usage, and it is working well but now I need to process the data of the output report, so I would like to get the report data in some kind of structure. I see the function rtems_cpu_usage_report_with_plugin() but I don't know how use it, could someone of you give me an example? unfortunately, the CPU usage report is not available in a structure. You could refactor the rtems_cpu_usage_report_with_plugin() function and add a variant which passes a structure with the CPU usage to a visitor function. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Migration Guide for RTEMS 4.11 to 5
Hello, we started with a migration guide from RTEMS 4.11 (or other versions of course) to 5: https://docs.rtems.org/branches/master/user/migration/v4_11-to-v5.html There are probably a lot more things to consider. If someone already migrated an application to RTEMS 5, then please share your issues, workaround, necessary changes, etc. so that others may have it a bit easier. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: clock_settime fail on qemu-xilinx-zynq-a9
Hello Heinz, this assertion is definitely an error (clock_settime should return EINVAL instead), however, why do you want to set a time after Wednesday, May 30, 2514? ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: R: R: sptest SP06 strange behaviour
Hello Michele, On 25/03/2020 16:13, Michele Dekleva wrote: My customer request me to use RTEMS 4.11.3 so i need to use this version. this makes little sense given that we are about to release RTEMS 5 soon. Also consider that the FPGA based CortexM3 use a 133 MHz clock so I’m quite surprise that there could be problems with this CPU/clock. Anyway, since by apply little modification to some tests (just like the ones I’ve indicated) all test complete correctly, from your point of view this solution could be considered valid in order to accept the BSP ? At the moment I don’t see any test failed because of a critical issue (such as a broken driver or incorrect time measurement): almost all problems are on synchronization between tasks, avoidable with minimal modifications on task’s source code. I would run the testsuite with the RTEMS master. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: R: sptest SP06 strange behaviour
Hello Michele, I am not sure if the RTEMS 4.11 test suite works with an interrupt driven console driver. I would use the RTEMS master for new BSPs anyway. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: sptest SP06 strange behaviour
Hello Michele, both tests should run without errors. Which RTEMS version do you use? A frequent error in Cortex-M BSPs are improper interrupt priorities. Make sure all interrupt priorities are set up correctly: https://docs.rtems.org/branches/master/cpu-supplement/arm.html#interrupt-processing ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: write a network driver
Hello Mojtaba, On 11/03/2020 06:44, mojtaba nadi wrote: hello, I'm going to write a network driver for my mac ip core that I made in vivado for zedboard. I can write and read from it with using registers but now I want to use socket programming to access the mac. I understand the first step is adding a ifconfig name for my mac but I couldn't do this with using libbsd. Am I doing something wrong? How can I write a network driver for my mac? the libbsd is a port of the network stack from FreeBSD to RTEMS. You can use all the documentation which is available for FreeBSD. I would start with looking at an example network interface driver, e.g. freebsd/sys/dev/cadence/if_cgem.c ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Someone using CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE?
On 09/04/2019 09:08, Sebastian Huber wrote: Hello, is the CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE actually used in application configurations? I plan to remove CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE and CONFIGURE_HAS_OWN_INIT_TASK_TABLE next week: https://devel.rtems.org/ticket/3873 https://devel.rtems.org/ticket/3874 ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Someone using CONFIGURE_HAS_OWN_INIT_TASK_TABLE?
On 13/02/2020 16:37, Sebastian Huber wrote: Hello, I would like to revisit this configuration clean up opportunity: On 09/04/2019 14:55, Sebastian Huber wrote: On 09/04/2019 14:50, Joel Sherrill wrote: On Tue, Apr 9, 2019, 2:08 AM Sebastian Huber <mailto:sebastian.hu...@embedded-brains.de>> wrote: Hello, is the CONFIGURE_HAS_OWN_INIT_TASK_TABLE actually used in application configurations? After sending that last email, this one is more likely to be used than any of the others. Not responding to an email on the list doesn't mean it isn't used. If this option is deleted, the comparable POSIX one must go. then you get a single init task of one or both APIs. This one actually doesn't cause great pain to me at the moment. I just wanted to know if it actually used. Removing it would simplify things a bit, but not much. The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. I would like to remove them to simplify the configuration. It would be possible to keep them and still simplify the configuration, however, I doubt that these options were used at all. Any objections to remove them? I plan to remove them next week: https://devel.rtems.org/ticket/3873 https://devel.rtems.org/ticket/3874 ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Failure in cpukit/score/src/rbtreeextract.c if RTEMS_DEBUG is defined
On 13/02/2020 17:56, Heinz Junkes wrote:
I'm starting an EPICS IOC. Loading works if I don't set RTEMS_DEBUG.
The loaded images are similar in size.
I have not changed anything in the EPICS software. I still have the problem
that I do not understand
how the freebsd dhcpcd works and therefore wanted to set RTEMS_DEBUG to get
more detailed output.
Did you check some tests of the RTEMS test suite? Did you enable the
stack checker? How many file descriptors did you configure?
Without a debugger I would use the following approach:
* compile libbsd/application with --finstrument-functions,
* enable the event recording,
* dump the event records in base64 encoding in the fatal error handler,
* add support for base64 encoded data to the rtems-record-lttng
converter, and
* view the trace with babeltrace or Trace Compass.
__attribute__((__no_instrument_function__)) void
__cyg_profile_func_enter(void* this_fn, void* call_site)
{
rtems_record_produce_2(RTEMS_RECORD_CALLER,
(rtems_record_data)call_site,
RTEMS_RECORD_FUNCTION_ENTRY,
(rtems_record_data)this_fn);
}
__attribute__((__no_instrument_function__)) void
__cyg_profile_func_exit(void* this_fn, void* call_site)
{
rtems_record_produce(RTEMS_RECORD_FUNCTION_EXIT,
(rtems_record_data)this_fn);
}
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Failure in cpukit/score/src/rbtreeextract.c if RTEMS_DEBUG is defined
On 13/02/2020 17:25, Heinz Junkes wrote: Using qoriq_e500 BSP if configured with --enable-rtems-debug : ../../rtems-5.0.0-m1912/configure --enable-maintainer-mode --prefix=/home/epics/MVME2500/RTEMS/5.0.0-m1912 --target=powerpc-rtems5 --enable-rtemsbsp=qoriq_e500 --enable-posix --enable-cxx --disable-networking --enable-pci --enable-rtems-debug BSP_CONSOLE_BAUD=9600 Booting fails with … Uncompressing Kernel Image ... OK Loading Device Tree to 03ff9000, end 03fff04a ... OK assertion "_RBTree_Find_root( the_node ) == _RBTree_Root( the_rbtree )" failed: file "../../../../../../rtems-5.0.0-m1912/c/src/../../cpukit/score/src/rbtreeextract.c", line 40, function: _RBTree_Extract This error can be caused by a lot of things (e.g. memory corruption). With which application does this happen? ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Someone using CONFIGURE_HAS_OWN_INIT_TASK_TABLE?
Hello, I would like to revisit this configuration clean up opportunity: On 09/04/2019 14:55, Sebastian Huber wrote: On 09/04/2019 14:50, Joel Sherrill wrote: On Tue, Apr 9, 2019, 2:08 AM Sebastian Huber <mailto:sebastian.hu...@embedded-brains.de>> wrote: Hello, is the CONFIGURE_HAS_OWN_INIT_TASK_TABLE actually used in application configurations? After sending that last email, this one is more likely to be used than any of the others. Not responding to an email on the list doesn't mean it isn't used. If this option is deleted, the comparable POSIX one must go. then you get a single init task of one or both APIs. This one actually doesn't cause great pain to me at the moment. I just wanted to know if it actually used. Removing it would simplify things a bit, but not much. The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. I would like to remove them to simplify the configuration. It would be possible to keep them and still simplify the configuration, however, I doubt that these options were used at all. Any objections to remove them? ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Error with Boost scope
Hello, I think this is an issue with your build settings. I extracted the boost includes for the ros project and included them in an example C++ RTEMS file: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include It works fine with this boost patch: diff --git a/boost/config/detail/select_platform_config.hpp b/boost/config/detail/select_platform_config.hpp index b36eca5..b87a458 100644 --- a/boost/config/detail/select_platform_config.hpp +++ b/boost/config/detail/select_platform_config.hpp @@ -17,7 +17,7 @@ // linux, also other platforms (Hurd etc) that use GLIBC, should these really have their own config headers though? # define BOOST_PLATFORM_CONFIG "boost/config/platform/linux.hpp" -#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) +#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) || defined(__rtems__) // BSD: # define BOOST_PLATFORM_CONFIG "boost/config/platform/bsd.hpp" diff --git a/boost/config/platform/bsd.hpp b/boost/config/platform/bsd.hpp index 79e74a0..3b025b0 100644 --- a/boost/config/platform/bsd.hpp +++ b/boost/config/platform/bsd.hpp @@ -9,7 +9,7 @@ // generic BSD config options: -#if !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__OpenBSD__) && !defined(__DragonFly__) +#if !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__OpenBSD__) && !defined(__DragonFly__) && !defined(__rtems__) #error "This platform is not BSD" #endif ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Error with Boost scope
On 04/02/2020 14:37, M. Dodson wrote: Specifically, my waf has: includes = [ ... '/Users/michaeldodson/projects/rtems_root/boost_1_72_0', '/usr/local/include’] It seems to be finding the header files just fine, as the errors are associated with a declaration within the header that isn’t in scope. You should not use standard installation paths of your host system for header files of the RTEMS target. This may accidentally pull in undesired header files. I’m possibly misunderstanding your statement: I was only including '/Users/michaeldodson/projects/rtems_root/boost_1_72_0’ (the location of the Boost libraries built with the RTEMS cross-compilation tools. The errors I reported were based on a build only using that include path. In your first email there are also /usr/local/include paths in the log. Do you have an example code which triggers the issue? ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Error with Boost scope
On 04/02/2020 13:44, M. Dodson wrote: On 4 Feb 2020, at 12:32, Sebastian Huber wrote: On 04/02/2020 13:20, M. Dodson wrote: from /usr/local/include/boost/math/policies/policy.hpp:21, Did you add /usr/local/include to the include path used to build an RTEMS application? Yes. And when I cloned and build Boost from source, I added that to my include path. Specifically, my waf has: includes = [ ... '/Users/michaeldodson/projects/rtems_root/boost_1_72_0', '/usr/local/include’] It seems to be finding the header files just fine, as the errors are associated with a declaration within the header that isn’t in scope. You should not use standard installation paths of your host system for header files of the RTEMS target. This may accidentally pull in undesired header files. I would look at the pre-processed files (-save-temps -Wp,--dD) to figure out what happens. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
