Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

Am 28.01.21 um 06:28 schrieb Chris Johns: On 28/1/21 4:12 am, Niteesh G. S. wrote: Hello Christian, On Wed, Jan 27, 2021 at 3:59 PM Christian MAUDERER mailto:christian.maude...@embedded-brains.de>> wrote: Hello Niteesh, I think there is an open Question from Chris for that patch:

Re: Buildbot failure in RTEMS on CHECK sparc/erc32 FreeBSD 10.1-STABLE GCC 7.3.0 POSIX

On 28/1/21 4:44 pm, Sebastian Huber wrote: > Hello, > > On 28/01/2021 06:37, build...@rtems.org wrote: >> The Buildbot has detected a failed build on builder CHECK sparc/erc32 FreeBSD >> 10.1-STABLE GCC 7.3.0 POSIX while building rtems. >> Full details are available at: >> https://buildbot.rt

Re: Buildbot failure in RTEMS on CHECK sparc/erc32 FreeBSD 10.1-STABLE GCC 7.3.0 POSIX

Hello, On 28/01/2021 06:37, build...@rtems.org wrote: The Buildbot has detected a failed build on builder CHECK sparc/erc32 FreeBSD 10.1-STABLE GCC 7.3.0 POSIX while building rtems. Full details are available at: https://buildbot.rtems.org/#builders/20/builds/440 Buildbot URL: https://bui

Re: devel Digest, Vol 110, Issue 38

On 28/1/21 4:25 am, Niteesh G. S. wrote: > Date: Fri, 22 Jan 2021 04:28:37 +1100 > From: Chris Johns mailto:chr...@rtems.org>> > To: devel@rtems.org > Subject: Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation > Message-ID:

Re: Lots of BSPs have undefined references to TLS symbols

On 27/01/2021 22:41, Joel Sherrill wrote: https://lists.rtems.org/pipermail/build/2021-January/024936.html shows lots (1345 which might be all) of failures like this across multiple architectures: It was an issue in the ol

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

On 28/1/21 4:12 am, Niteesh G. S. wrote: > Hello Christian, > > On Wed, Jan 27, 2021 at 3:59 PM Christian MAUDERER > > wrote: > > Hello Niteesh, > > I think there is an open Question from Chris for that patch: > > https://lists.rtems.or

Re: [PATCH] score: Add _Thread_Demand_objects_information()

On 27/01/2021 21:25, Joel Sherrill wrote: Piling on Gedare's comment but also ... (1) If this is justifiable, then every use should have a comment block about why the id is known to be good. (2) What does this really save? That should be documented for the method. Seems like a micro-optimizat

[PATCH v2] score: Add _Thread_Demand_objects_information()

We do not need all the checks if we have a valid indentifier to a thread class object. Using the new _Thread_Demand_objects_information() instead of the inline function _Thread_Get_objects_information() avoids dead code since for valid identifiers the API is valid and the return NULL path in _Thre

Fwd: New Defects reported by Coverity Scan for RTEMS

FYI -- Forwarded message - From: Date: Wed, Jan 27, 2021, 9:21 PM Subject: New Defects reported by Coverity Scan for RTEMS To: Hi, Please find the latest report on new defect(s) introduced to RTEMS found with Coverity Scan. 11 new defect(s) introduced to RTEMS found with Cove

Lots of BSPs have undefined references to TLS symbols

Hi https://lists.rtems.org/pipermail/build/2021-January/024936.html shows lots (1345 which might be all) of failures like this across multiple architectures: 39 no-network arm/beagleboneblack build: configure: /home/joel/rtems-cron-6/rtems/configure --target=arm-\ rtems6 --enable-rte

Fwd: DWARF Committee resumes meetings

In case anyone in the RTEMS Community is interested.in reviewing the proposals or participating. -- Forwarded message - From: Michael Eager Date: Wed, Jan 27, 2021, 2:26 PM Subject: DWARF Committee resumes meetings To: , , < llvm-...@lists.llvm.org>, GCC Mailing List The DWARF

Re: Coverity model file

On Wed, Jan 27, 2021 at 1:10 PM Gedare Bloom wrote: > Super, let's do it. Changing it is a manual process. So whoever pushes the > file in the tools repo should also be responsible to make sure it gets > uploaded. I'm willing to do the upload on-demand. > +1 It would also be nice to add some mo

Re: [PATCH] score: Add _Thread_Demand_objects_information()

On Wed, Jan 27, 2021 at 11:38 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > We do not need all the checks if we have a valid indentifier to a thread > class object. > > Move _RTEMS_tasks_Free() to the only source file which calls this > function. > --- > cpukit/include/rtems/r

Re: Coverity model file

Super, let's do it. Changing it is a manual process. So whoever pushes the file in the tools repo should also be responsible to make sure it gets uploaded. I'm willing to do the upload on-demand. (Apparently the last coverity build failed.) On Wed, Jan 27, 2021 at 11:17 AM Sebastian Huber < seba

[PATCH] score: Add _Thread_Demand_objects_information()

We do not need all the checks if we have a valid indentifier to a thread class object. Move _RTEMS_tasks_Free() to the only source file which calls this function. --- cpukit/include/rtems/rtems/tasksimpl.h | 16 cpukit/include/rtems/score/threadimpl.h | 25 ++

Coverity model file

Hello, we use a Coverity model file for https://scan.coverity.com/projects/rtems I have to issues with his model file. 1. You have to be an administrator to see it. 2. It is not version controlled. I suggest to add the model file to the RTEMS tools, for example "coverity/model.c". I would

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

On Wed, Jan 27, 2021 at 10:13 AM Niteesh G. S. wrote: > Hello Christian, > > On Wed, Jan 27, 2021 at 3:59 PM Christian MAUDERER < > christian.maude...@embedded-brains.de> wrote: > >> Hello Niteesh, >> >> I think there is an open Question from Chris for that patch: >> >> https://lists.rtems.org/pi

Re: devel Digest, Vol 110, Issue 38

> > Date: Fri, 22 Jan 2021 04:28:37 +1100 > From: Chris Johns > To: devel@rtems.org > Subject: Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On 20/1/21 7:31 pm, G S Niteesh Babu wrote: > > This commit modifies the OFW inte

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

Hello Christian, On Wed, Jan 27, 2021 at 3:59 PM Christian MAUDERER < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > I think there is an open Question from Chris for that patch: > > https://lists.rtems.org/pipermail/devel/2021-January/063988.html I never received that mail,

Re: Phrases for CONSTRAINTS section in the directive documentation

On Wed, Jan 27, 2021 at 1:14 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 23/01/2021 23:44, Chris Johns wrote: > > > On 23/1/21 12:19 am, Gedare Bloom wrote: > > On Fri, Jan 22, 2021 at 5:55 AM Andrew Butterfield > >> mailto:andrew.butterfi...@scss.tcd.ie>> > wrote: > >>

Re: [PATCH 0/6] Updates for Nios II

Will these changes impact any documentation? The TLS addition seems like it could impact the CPU supplement. --joel On Wed, Jan 27, 2021, 3:13 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > This patch series brings the Nios II support up to date. Tests were > performed on rea

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

Hello Niteesh, I think there is an open Question from Chris for that patch: https://lists.rtems.org/pipermail/devel/2021-January/063988.html Best regards Christian Am 27.01.21 um 11:14 schrieb Niteesh G. S.: ping. On Wed, Jan 20, 2021 at 2:01 PM G S Niteesh Babu

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

ping. On Wed, Jan 20, 2021 at 2:01 PM G S Niteesh Babu wrote: > This commit modifies the OFW interface to the RTEMS FDT > implementation instead of the default FreeBSD. > --- > freebsd/sys/dev/ofw/openfirm.c| 2 ++ > freebsd/sys/dev/ofw/openfirm.h| 9

[PATCH 6/6] nios2: Allow ISR nesting in dispatch variant

Rename _Nios2_ISR_Dispatch_with_shadow_non_preemptive() in _Nios2_ISR_Dispatch_with_shadow_register_set(). Remove _Nios2_ISR_Dispatch_with_shadow_preemptive(). --- cpukit/Makefile.am| 1 - .../score/cpu/nios2/nios2-eic-il-low-level.S | 23 ++- .../cpu/nios2/nios2-e

[PATCH 0/6] Updates for Nios II

This patch series brings the Nios II support up to date. Tests were performed on real hardware with a custom BSP. Sebastian Huber (6): nios2: Fix ISR dispatch variants nios2: Make _ISR_Is_in_progress() weak nios2: Add TLS support nios2: Use Per_CPU_Control::isr_dispatch_disable nios2: O

[PATCH 3/6] nios2: Add TLS support

Update #4214. --- .../cpu/nios2/nios2-context-initialize.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/cpukit/score/cpu/nios2/nios2-context-initialize.c b/cpukit/score/cpu/nios2/nios2-context-initialize.c index 1b7d1bbc9e..6950ce4bd6 100644 --- a/

[PATCH 2/6] nios2: Make _ISR_Is_in_progress() weak

This allows the BSP to override this function. --- cpukit/score/cpu/nios2/nios2-isr-is-in-progress.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/score/cpu/nios2/nios2-isr-is-in-progress.c b/cpukit/score/cpu/nios2/nios2-isr-is-in-progress.c index 17eb8958a6..cb6ddb8c

[PATCH 1/6] nios2: Fix ISR dispatch variants

The thread dispatch disabled level moved to _Per_CPU_Information some time ago. --- cpukit/score/cpu/nios2/nios2-eic-il-low-level.S | 7 +++ cpukit/score/cpu/nios2/nios2-eic-rsie-low-level.S | 9 - 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/cpukit/score/cpu/nios2/

[PATCH 5/6] nios2: Optimize ISR dispatch variant

Use _Thread_Do_dispatch() in _Nios2_ISR_Dispatch_with_shadow_non_preemptive(). --- .../score/cpu/nios2/nios2-eic-il-low-level.S | 102 ++ 1 file changed, 60 insertions(+), 42 deletions(-) diff --git a/cpukit/score/cpu/nios2/nios2-eic-il-low-level.S b/cpukit/score/cpu/nios2/nios2

[PATCH 4/6] nios2: Use Per_CPU_Control::isr_dispatch_disable

--- cpukit/score/cpu/nios2/include/rtems/score/cpu.h | 14 -- .../cpu/nios2/include/rtems/score/nios2-utility.h | 13 + cpukit/score/cpu/nios2/nios2-context-switch.S | 12 ++-- cpukit/score/cpu/nios2/nios2-eic-il-low-level.S | 15 +++ .../cpu/nios

Re: Phrases for CONSTRAINTS section in the directive documentation

On 23/01/2021 23:44, Chris Johns wrote: On 23/1/21 12:19 am, Gedare Bloom wrote: On Fri, Jan 22, 2021 at 5:55 AM Andrew Butterfield mailto:andrew.butterfi...@scss.tcd.ie>> wrote: Hi Sebastian, I'd prefer 2. The directive may be called from an interrupt context (substit