Re: [PATCH] rtems-binutils-head.cfg, rtems-gdb-head.cfg: Bump to 3b2bef8

I am ok with this going in but I am becoming concerned we are building a debt around MacOS and Windows in the tools that we need to resolve. Our ability to release when we would like to depends on the state of the tools and the state of the tools for all archs. :) On 22/5/21 9:20 am, Joel

Re: RTEMS_VERSION on 5 branch

Hello Chris, thanks for the detailed response. Should we add a bit of that to the doxygen documentation of the rtems_version_* functions so that I don't ask it again because I have forgotten it in a year? Best regards Christian Am 26.05.21 um 01:24 schrieb Chris Johns: On 25/5/21 8:56 pm,

Re: RTEMS_VERSION on 5 branch

On 26/5/21 6:47 pm, Christian MAUDERER wrote: > thanks for the detailed response. Should we add a bit of that to the doxygen > documentation of the rtems_version_* functions so that I don't ask it again > because I have forgotten it in a year? Yes we should. I also would to add a detailed section

Re: RTEMS_VERSION on 5 branch

Am 26.05.21 um 09:22 schrieb Chris Johns: On 26/5/21 6:47 pm, Christian MAUDERER wrote: thanks for the detailed response. Should we add a bit of that to the doxygen documentation of the rtems_version_* functions so that I don't ask it again because I have forgotten it in a year? Yes we

[PATCH v2] Add CoreMark Benchmark

CoreMark's primary goals are simplicity and providing a method for testing only a processor's core features. It is used primarily here as a performance benchmark. Built and tested for RISC-V rv64imafdc_medany on QEMU and HW --- .gitmodules | 3 +++ benchmarks/coremark/coremark

Re: [PATCH rtems] thread-API: Add rtems_*mutex_try_lock

On 26/05/2021 11:33, Christian Mauderer wrote: This adds a rtems_mutex_try_lock and a rtems_recursive_mutex_try_lock. Update #4440. Looks good. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741

Re: Building llvm toolchain for RTEMS

Hello Jan, Unlike GCC, LLVM/Clang only gives you one toolchain for all backend architectures (depending on how you configured it). You'll also need to tell LLVM/Clang where to find the sysroot to pick newlib and builtins headers/libs. GCC does that automatically for you, but LLVM/Clang does not.

[PATCH] score: Get current priority with proper locking

The current priority is a 64-bit integer which should be read under protection of the right ISR lock to avoid potential issues with non-atomic loads on 32-bit architectures. Update #4411. --- cpukit/score/src/threadrestart.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-)

[PATCH rtems] thread-API: Add rtems_*mutex_try_lock

This adds a rtems_mutex_try_lock and a rtems_recursive_mutex_try_lock. Update #4440. --- cpukit/include/rtems/thread.h| 12 + testsuites/sptests/spthread01/init.c | 79 2 files changed, 91 insertions(+) diff --git a/cpukit/include/rtems/thread.h

[PATCH] c-users: Add rtems_*mutex_try_lock

--- c-user/self_contained_objects.rst | 35 +++ 1 file changed, 35 insertions(+) diff --git a/c-user/self_contained_objects.rst b/c-user/self_contained_objects.rst index 0be1423..3351b98 100644 --- a/c-user/self_contained_objects.rst +++

RE: Building llvm toolchain for RTEMS

Ok, I build the llvm buildset with RSB and then tried to set the COMPILER option in the ini file for the BSP, but that did not work. Is it only available for certain BSPs or am I completely of the track? Best regards, Jan > -Original Message- > From: devel On Behalf Of

Re: [PATCH] score: Get current priority with proper locking

On 26/05/2021 14:10, Sebastian Huber wrote: The current priority is a 64-bit integer which should be read under protection of the right ISR lock to avoid potential issues with non-atomic loads on 32-bit architectures. Please ignore this patch. It doesn't work. There is a strange priority

Re: [PATCH v2] Add CoreMark Benchmark

Submitting that again based on Joel's request. I created a ticket [1] for future Make support as it only builds with waf. [1] https://devel.rtems.org/ticket/4441#ticket On Wed, 26 May 2021 at 11:23, Hesham Almatary wrote: > > CoreMark's primary goals are simplicity and providing a method for >

Re: Minimum.exe Text Size Outliers

On 25/05/2021 20:33, Christian Mauderer wrote: I thought Sebastian added a "malloc" for the BSP to use before the heap was initialized. But I don't remember the name. Am I remembering correctly? I don't really know that malloc. But I doubt that it works that early. Again: Copying the FDT

[PATCH] Add CoreMark Benchmark

CoreMark's primary goals are simplicity and providing a method for testing only a processor's core features. It is used primarily here as a performance benchmark. Built and tested for RISC-V rv64imafdc_medany on QEMU and HW --- .gitmodules | 3 +++ benchmarks/coremark/coremark

[PATCH] cpukit: Add description of release version numbers

The release version in the git sources doesn't change. Add a note why that is the case. --- cpukit/include/rtems/version.h | 12 1 file changed, 12 insertions(+) diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h index a8aff732f3..2e068cd976 100644 ---

[PATCH] cpukit/libpci: fix potential buffer overflow in pci_cfg_print_code.c

See also CID 1399721 Closes #4442 --- cpukit/libpci/pci_cfg_print_code.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cpukit/libpci/pci_cfg_print_code.c b/cpukit/libpci/pci_cfg_print_code.c index e758fa661a..e0979db74a 100644 --- a/cpukit/libpci/pci_cfg_print_code.c

Re: Minimum.exe Text Size Outliers

On Wed, May 26, 2021 at 6:02 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 25/05/2021 20:33, Christian Mauderer wrote: > > > >> > >> I thought Sebastian added a "malloc" for the BSP to use before the > >> heap was initialized. But I don't remember the name. Am I remembering

Re: Minimum.exe Text Size Outliers

On 26/05/2021 19:23, Joel Sherrill wrote: On Wed, May 26, 2021 at 6:02 AM Sebastian Huber > wrote: On 25/05/2021 20:33, Christian Mauderer wrote: > >> >> I thought Sebastian added a "malloc" for the BSP to use before the

[PATCH] tester: Expand special case for minimum.exe

The minimum.exe test case is expected to fail as an "invalid" test in the tester since it is completely stripped down and does not output the normal test header and footer. When fatal error detection support was added, this caught minimum.exe and started flagging it as "fatal" instead of

[PATCH rtems] i2c: Add non blocking read / write

This adds the possibility to open an I2C bus with O_NONBLOCK (or set it later via fcntl) to get non-blocking transmissions. This means that if the bus is busy, a read, write or transfer ioctl will return with a EAGAIN errno. --- NOTE: This patch needs

Re: Minimum.exe Text Size Outliers

Another minimum size report. If the text size after subtracting the FDT blob is below 64K, the BSP is not in the report. The adjusted size is reported. It looks like some significant percentage of those over 64k are managing to pull in printf or something in the family. I wonder if we should ban

Re: [PATCH] cpukit/libpci: fix potential buffer overflow in pci_cfg_print_code.c

On Wed, May 26, 2021 at 1:58 PM Harrison Edward Gerber wrote: > See also CID 1399721 > Closes #4442 > Blank line between these. But otherwise I think this looks good. Gedare... this looks like a good paper on this family of methods for advice on safe programming:

[PATCH v2 2/6] bsps/aarch64: Align MVAs consistently

This fixes a bug where addresses were not being aligned correctly. Addresses used in cache functions are now aligned consistently using RTEMS_ALIGN_DOWN. --- bsps/aarch64/shared/cache/cache.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git

[PATCH v2 4/6] bsps/a53: Increase available RAM

The default available RAM on the A53 BSP is quite small at 8MB. This bumps that to 128MB to avoid allocation failures in tmcontext01 caused by large allocations on a cache size of 16MB reported by the system registers in QEMU. --- spec/build/bsps/aarch64/a53/optramlen.yml | 2 +- 1 file changed,

[PATCH v2 6/6] spec/aarch64: Add BSPs for real ZynqMP hardware

Add the BSPs for running on the ZU3EG Ultrascale+ Zynq MPSoC and alter the option defaults necessary for them to run properly using the standard BOOT.BIN configured for PetaLinux that comes in the Out-of-Box package. --- spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml | 1 +

[PATCH v2 3/6] bsps/aarch64: Advertise cache function support

Ensure that cache functions are flagged as usable by the generic cache implementation code. --- bsps/aarch64/shared/cache/cache.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/bsps/aarch64/shared/cache/cache.c b/bsps/aarch64/shared/cache/cache.c index 47722c21e4..9e7446a077

[PATCH v2 5/6] bsps/aarch64: Add MMU driver to relax alignment

Currently, the AArch64 BSPs have a hard time running on real hardware without building the toolchain and the bsps with -mstrict-align in multiple places. Configuring the MMU on these chips allows for unaligned memory accesses for non-device memory which avoids requiring strict alignment in the

Re: RTEMS source builder: can't find RTEMS include files but then can?

On Wed, May 26, 2021, 7:54 PM Chris Johns wrote: > On 30/4/21 1:15 am, dufa...@hda.com wrote: > > > > > >> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote: > >> > >> Can I override what to use as "cmake" in RSB to specify "cmake3"? > >> > >>> On Apr 30, 2021, at 04:41 , Peter Dufault wrote: >

Re: [PATCH] tester: Expand special case for minimum.exe

On 5/26/2021 19:22, Chris Johns wrote: On 27/5/21 12:06 pm, Joel Sherrill wrote: On Wed, May 26, 2021, 7:03 PM Chris Johns mailto:chr...@rtems.org>> wrote: On 26/5/21 1:52 am, Kinsey Moore wrote: > The minimum.exe test case is expected to fail as an "invalid" test in > the

Re: [PATCH] tester: Expand special case for minimum.exe

On 27/5/21 2:04 pm, Kinsey Moore wrote: > On 5/26/2021 19:22, Chris Johns wrote: >> On 27/5/21 12:06 pm, Joel Sherrill wrote: >>> On Wed, May 26, 2021, 7:03 PM Chris Johns >> > wrote: >>> >>> On 26/5/21 1:52 am, Kinsey Moore wrote: >>> > The minimum.exe test case

Re: RFS and 2038

On 1/5/21 6:19 am, Joel Sherrill wrote: > Hi > > Ryan has been working to add support for the new (not obsolete) nanosecond > granularity variants of utime. In changing the utime_h file system handler to > utimens_h and propagating the changes, Ryan tripped across this. > >

Re: [PATCH] riscv/console: console-config.c update

Hi Hesham/Sebastian, Please find the attached device tree source file which I used for rtems testing on PolarFire SoC ICICLE Kit. On Wed, May 19, 2021 at 2:43 PM Hesham Almatary < hesham.almat...@cl.cam.ac.uk> wrote: > Hello Somesh, > > This patch will break other existing BSPs that don't have

Re: [PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

On Wed, May 26, 2021 at 4:35 PM Harrison Edward Gerber wrote: > > See also CID 1399727 > > Closes # > --- > cpukit/libmisc/monitor/mon-editor.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/cpukit/libmisc/monitor/mon-editor.c >

Re: [PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

On Wed, May 26, 2021, 8:46 PM Gedare Bloom wrote: > On Wed, May 26, 2021 at 4:35 PM Harrison Edward Gerber > wrote: > > > > See also CID 1399727 > > > > Closes # > > --- > > cpukit/libmisc/monitor/mon-editor.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git

Re: [PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

On Wed, May 26, 2021 at 7:56 PM Joel Sherrill wrote: > > > > On Wed, May 26, 2021, 8:46 PM Gedare Bloom wrote: >> >> On Wed, May 26, 2021 at 4:35 PM Harrison Edward Gerber >> wrote: >> > >> > See also CID 1399727 >> > >> > Closes # >> > --- >> > cpukit/libmisc/monitor/mon-editor.c | 3 ++-

[PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

See also CID 1399727 Closes # --- cpukit/libmisc/monitor/mon-editor.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cpukit/libmisc/monitor/mon-editor.c b/cpukit/libmisc/monitor/mon-editor.c index dcea9fcc69..1392be51f1 100644 --- a/cpukit/libmisc/monitor/mon-editor.c

Re: [PATCH] cpukit/libpci: fix potential buffer overflow in pci_cfg_print_code.c

Hi, On Wed, May 26, 2021 at 2:45 PM Joel Sherrill wrote: > > > > On Wed, May 26, 2021 at 1:58 PM Harrison Edward Gerber > wrote: >> >> See also CID 1399721 >> Closes #4442 > > > Blank line between these. > > But otherwise I think this looks good. > I pushed it with the added blank line in the

Re: [PATCH] cpukit: Add description of release version numbers

Thank you for this. On 26/5/21 7:41 pm, Christian Mauderer wrote: > The release version in the git sources doesn't change. Add a note why > that is the case. > --- > cpukit/include/rtems/version.h | 12 > 1 file changed, 12 insertions(+) > > diff --git

Re: [PATCH] tester: Expand special case for minimum.exe

On 26/5/21 1:52 am, Kinsey Moore wrote: > The minimum.exe test case is expected to fail as an "invalid" test in > the tester since it is completely stripped down and does not output the > normal test header and footer. When fatal error detection support was > added, this caught minimum.exe and

Re: AW: question about posix timer expiration

On 21/5/21 9:44 pm, gabriel.moy...@dlr.de wrote: > Did you compile ptpd with kqueue only? I’ve tried with posix timer, which are > implemented in rtems, but it seems that the handler with siginfo_t is not > called > correctly. I’ve managed to get it working using a workaround but I’ll continue >

Re: [PATCH v4] sb: Merge mailer changes from rtems-tools

On 12/5/21 3:19 am, Alex White wrote: > This adds the improved mailer.py script from rtems-tools. > > Closes #4388 > --- > source-builder/sb/mailer.py | 194 ++-- > source-builder/sb/options.py| 26 - > source-builder/sb/setbuilder.py | 2 + > 3 files

Re: RTEMS source builder: can't find RTEMS include files but then can?

On 30/4/21 1:15 am, dufa...@hda.com wrote: > > >> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote: >> >> Can I override what to use as "cmake" in RSB to specify "cmake3"? >> >>> On Apr 30, 2021, at 04:41 , Peter Dufault wrote: >>> >>> I verified my environment is squeaky-clean with a simple

Re: [PATCH] tester: Expand special case for minimum.exe

On Wed, May 26, 2021, 7:03 PM Chris Johns wrote: > On 26/5/21 1:52 am, Kinsey Moore wrote: > > The minimum.exe test case is expected to fail as an "invalid" test in > > the tester since it is completely stripped down and does not output the > > normal test header and footer. When fatal error

Re: [PATCH] tester: Expand special case for minimum.exe

On 27/5/21 12:06 pm, Joel Sherrill wrote: > On Wed, May 26, 2021, 7:03 PM Chris Johns > wrote: > > On 26/5/21 1:52 am, Kinsey Moore wrote: > > The minimum.exe test case is expected to fail as an "invalid" test in > > the tester since it is completely stripped

Re: [PATCH v2 6/6] spec/aarch64: Add BSPs for real ZynqMP hardware

On 26/05/2021 23:01, Kinsey Moore wrote: Add the BSPs for running on the ZU3EG Ultrascale+ Zynq MPSoC and alter the option defaults necessary for them to run properly using the standard BOOT.BIN configured for PetaLinux that comes in the Out-of-Box package. Thanks for the update, this patch