Re: [PATCH] bsps/raspberrypi/console: Fix default console device

Hi Niteesh, I tried your firmware, booting directly instead of using u-boot. I was able to get the RTEMS 5 branch to run on the Raspberry Pi Zero, but I still cannot get the master/6 branch to run. I need some time to do additional tests. I was also going to re-try your patch and see if I can run t

RE: [PATCH v2] legacy nfs.c: Change filesystem utime_h handler to utimens_h

ping -Original Message- From: Ryan Long Sent: Monday, May 3, 2021 1:41 PM To: devel@rtems.org Cc: Ryan Long Subject: [PATCH v2] legacy nfs.c: Change filesystem utime_h handler to utimens_h Changed nfs_utime() to nfs_utimens(), changed the arguments to use a timespec array instead of i

RE: [PATCH v2] libbsd nfs.c: Change filesystem utime_h handler to utimens_h

ping -Original Message- From: Ryan Long Sent: Monday, May 3, 2021 1:41 PM To: devel@rtems.org Cc: Ryan Long Subject: [PATCH v2] libbsd nfs.c: Change filesystem utime_h handler to utimens_h Changed nfs_utime() to nfs_utimens(), changed the arguments to use a timespec array instead of i

[PATCH] sysconf: Removed sysconf(515)

GCC originally needed this 20 years ago. No longer needed, so it is being removed. Closes #4391 --- cpukit/posix/src/sysconf.c| 4 testsuites/psxtests/psxsysconf/init.c | 8 2 files changed, 12 deletions(-) diff --git a/cpukit/posix/src/sysconf.c b/cpukit/posix/src/sysc

Re: [PATCH] rtems-bsp-builder: Change to waf build system

The BSP Builder builds multiple BSPs at the same time. At one point, I thought waf had a problem with that. Has that been resolved. Are the config files and build directories sufficiently unique (BSP only isn't unique enough I think) for this to work with waf? This is a step in the right directio

[PATCH v2] sysconf: Remove sysconf(515)

GCC originally needed this 20 years ago. No longer needed, so it is being removed. Closes #4391 --- cpukit/posix/src/sysconf.c| 4 testsuites/psxtests/psxsysconf/init.c | 8 2 files changed, 12 deletions(-) diff --git a/cpukit/posix/src/sysconf.c b/cpukit/posix/src/sysc

Writing code that takes time to run

Hi, We are thinking of writing a piece of code that takes some time to run (it would be amazing if it takes around 2 secs to run on hardware, but we would be happy with something that takes a few milliseconds as well). We tried writing this: for(int i = 0; i<1000; ++i){ fib2 = fib0 +

Re: Writing code that takes time to run

On Thu, May 20, 2021 at 9:54 AM Richi Dubey wrote: > Hi, > > We are thinking of writing a piece of code that takes some time to run (it > would be amazing if it takes around 2 secs to run on hardware, but we would > be happy with something that takes a few milliseconds as well). > > We tried writ

RE: Writing code that takes time to run

Hi Richi, You can checkout the T_busy functions here: https://git.rtems.org/rtems/tree/cpukit/include/rtems/test.h#n2390 uint_fast32_t T_get_one_clock_tick_busy(void) gives you the busy count for one tick. You can then calculate the number of cycles you need to wait for you desired certain tim

[PATCH] score: Fix _Thread_Cancel()

The _Thread_Cancel() (in contrast to _Thread_Restart() which used a similar code block) may have produced ready threads with an active timer in case the thread to cancel had its thread life protection enabled. The problem was this code block: Priority_Control priority; _Thread_Add_life_ch

Re: Writing code that takes time to run

On Thu, May 20, 2021 at 10:05 AM wrote: > Hi Richi, > > > > You can checkout the T_busy functions here: > https://git.rtems.org/rtems/tree/cpukit/include/rtems/test.h#n2390 > > uint_fast32_t T_get_one_clock_tick_busy(void) gives you the busy count > for one tick. > > > > You can then calculate th

Re: [PATCH] score: Fix _Thread_Cancel()

Is there a test case for this situation? On Thu, May 20, 2021 at 10:18 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > The _Thread_Cancel() (in contrast to _Thread_Restart() which used a > similar code block) may have produced ready threads with an active timer > in case the thr

Re: [PATCH] score: Fix _Thread_Cancel()

On 20/05/2021 17:30, Joel Sherrill wrote: Is there a test case for this situation? Not in the current test suite. I write currently the specification for rtems_task_restart() and the validation tests. My plan is to start with the integration of the new validation test suites after they are f

Re: [PATCH] score: Fix _Thread_Cancel()

On Thu, May 20, 2021, 10:33 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 20/05/2021 17:30, Joel Sherrill wrote: > > Is there a test case for this situation? > > Not in the current test suite. I write currently the specification for > rtems_task_restart() and the validation

Re: [PATCH] score: Fix _Thread_Cancel()

On 20/05/2021 17:35, Joel Sherrill wrote: On Thu, May 20, 2021, 10:33 AM Sebastian Huber > wrote: On 20/05/2021 17:30, Joel Sherrill wrote: > Is there a test case for this situation? Not in the current test suite. I write currently the

RTEMS Documentation build problem

Hi all, I'm trying to build the RTEMS Documentation, but having a problem with sphinxcontrib-bibtex. It's been a long time since I've tried this, so maybe there's a configuration problem on my end. Anyway, I've pulled down the rtems-docs repo and tried to follow the instructions in the README

Re: [PATCH 0/3] Thread exit/cancel changes

Hello, this patch set probably got lost in all the e-mails. I work currently on the thread exit/cancel specification and would like to specify this behaviour. On 17/05/2021 15:06, Sebastian Huber wrote: Sebastian Huber (3): rtems: Return RTEMS_CALLED_FROM_ISR score: Simplify calling _T

Re: [PATCH] score: Fix _Thread_Cancel()

On Thu, May 20, 2021 at 9:18 AM Sebastian Huber wrote: > > The _Thread_Cancel() (in contrast to _Thread_Restart() which used a > similar code block) may have produced ready threads with an active timer > in case the thread to cancel had its thread life protection enabled. The > problem was this co

[PATCH 1/2] Fix the linux specific include

From: Chris Johns --- common/latex.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/common/latex.py b/common/latex.py index a1b3917..17d3015 100644 --- a/common/latex.py +++ b/common/latex.py @@ -4,10 +4,6 @@ import os import re -try: -from distro import lin

[PATCH 2/2] Fix the bibtex extension configure test

From: Chris Johns --- common/waf.py | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/common/waf.py b/common/waf.py index 3806209..fa9aecb 100644 --- a/common/waf.py +++ b/common/waf.py @@ -181,10 +181,12 @@ def check_sphinx_extension(ctx, extension): def run_sphinx(

Re: RTEMS Documentation build problem

On 21/5/21 4:28 am, Jeff Mayes wrote: > I’m trying to build the RTEMS Documentation, but having a problem with > sphinxcontrib-bibtex.  It’s been a long time since I’ve tried this, so maybe > there’s a configuration problem on my end.  Anyway, I’ve pulled down the > rtems-docs repo and tried to fol

RE: RTEMS Documentation build problem

Patches applied and yes indeed that fixed it. I'm on CentOS 7. Thank you Chris! Jeff >-Original Message- >From: Chris Johns >Sent: Thursday, May 20, 2021 5:18 PM >To: Jeff Mayes ; devel@rtems.org >Subject: Re: RTEMS Documentation build problem > >On 21/5/21 4:28 am, Jeff Mayes wrote: >>

Re: [PATCH rtems 1/2] telnetd.c: Remove RTEMS_NETWORKING check

Hi, On Thu, Apr 22, 2021 at 12:21 PM Gedare Bloom wrote: > > I guess there's not much else to do here without a network stack API > to manipulate the network task(s). > > Is there a ticket to fix the lack of ability to configure and access > network task priorities? I'm guessing libbsd and lwip

Re: [PATCH rtems v2] testsuites: Remove telnetd01

Hi, In the last review, the commit message wasn't clear, I fixed it in this version. Does this look Ok to be merged? Best regards, Vijay On Thu, Apr 22, 2021 at 8:02 PM Vijay Kumar Banerjee wrote: > > telnetd01 test cannot be run without a network stack, so this test is being > moved to the rte

Re: [PATCH rtems v2] testsuites: Remove telnetd01

Sure. Push it. On Thu, May 20, 2021, 6:36 PM Vijay Kumar Banerjee wrote: > Hi, > > In the last review, the commit message wasn't clear, I fixed it in this > version. > Does this look Ok to be merged? > > Best regards, > Vijay > > On Thu, Apr 22, 2021 at 8:02 PM Vijay Kumar Banerjee > wrote: > >

Re: [PATCH rtems v2] testsuites: Remove telnetd01

On Thu, May 20, 2021 at 5:49 PM Joel Sherrill wrote: > > Sure. Push it. > Thanks. Pushed. > On Thu, May 20, 2021, 6:36 PM Vijay Kumar Banerjee wrote: >> >> Hi, >> >> In the last review, the commit message wasn't clear, I fixed it in this >> version. >> Does this look Ok to be merged? >> >> Best

Re: [PATCH rtems 1/2] telnetd.c: Remove RTEMS_NETWORKING check

Seems fine by me, but wait until Monday to let anyone complain if they want. On Thu, May 20, 2021 at 5:35 PM Vijay Kumar Banerjee wrote: > > Hi, > > > On Thu, Apr 22, 2021 at 12:21 PM Gedare Bloom wrote: > > > > I guess there's not much else to do here without a network stack API > > to manipula

Re: [PATCH rtems 1/2] telnetd.c: Remove RTEMS_NETWORKING check

Well, since you pushed 2/2, you should push 1/2 (unless there are different patch series?) We should prefer to review and merge all/none of a series. On Thu, May 20, 2021 at 9:56 PM Gedare Bloom wrote: > > Seems fine by me, but wait until Monday to let anyone complain if they want. > > On Thu, M

Re: [PATCH 2/2] Fix the bibtex extension configure test

ok On Thu, May 20, 2021 at 4:15 PM wrote: > > From: Chris Johns > > --- > common/waf.py | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/common/waf.py b/common/waf.py > index 3806209..fa9aecb 100644 > --- a/common/waf.py > +++ b/common/waf.py > @@ -181,10 +181,12 @

Re: [PATCH 3/3] posix: Allow pthread_cancel() from within ISRs

These looked ok to me, I skimmed before but forgot to ACK... On Mon, May 17, 2021 at 7:07 AM Sebastian Huber wrote: > > Close #4413. > --- > cpukit/posix/src/cancel.c | 13 ++--- > testsuites/psxtests/psxcancel01/init.c | 72 +++--- > 2 files changed, 45 insertio

Re: [PATCH v2] sysconf: Remove sysconf(515)

looks good On Thu, May 20, 2021 at 7:25 AM Ryan Long wrote: > > GCC originally needed this 20 years ago. No longer needed, so it > is being removed. > > Closes #4391 > --- > cpukit/posix/src/sysconf.c| 4 > testsuites/psxtests/psxsysconf/init.c | 8 > 2 files changed, 1

Re: [PATCH rtems 1/2] telnetd.c: Remove RTEMS_NETWORKING check

On Thu, May 20, 2021 at 9:57 PM Gedare Bloom wrote: > > Well, since you pushed 2/2, you should push 1/2 (unless there are > different patch series?) > Pushed. > We should prefer to review and merge all/none of a series. > Ok, Understood. Thanks. > On Thu, May 20, 2021 at 9:56 PM Gedare Bloom wr

Re: Writing code that takes time to run

Hi, Thanks for your quick responses! The suggestion certainly is helpful, we are going to try it out. I'll post the result here. On Thu, May 20, 2021 at 8:57 PM Joel Sherrill wrote: > > > On Thu, May 20, 2021 at 10:05 AM wrote: > >> Hi Richi, >> >> >> >> You can checkout the T_busy functions

How to debug on leon3 with sis and gdb

Hi, A test fails at the assert(sc==RTEMS_SUCCESSFUL) after a call to rtems_task_set_affinity. So, following the docs , I figured out where the break point should be set: --- $ ~/quick-start/rtems/6/bin/s

Re: [PATCH] score: Fix _Thread_Cancel()

On 20/05/2021 22:33, Gedare Bloom wrote: +static void _Thread_Consider_life_change_request( Minor, I'd prefer "_Thread_Try_life_change_request(" Yes, this is better, thanks for the suggestion. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.