[PATCH 10/10] pps: Round to closest integer in pps_event()

2023-03-06 Thread Sebastian Huber
The comment above bintime2timespec() says: When converting between timestamps on parallel timescales of differing resolutions it is historical and scientific practice to round down. However, the delta_nsec value is a time difference and not a timestamp. Also the rounding errors accumulate

[PATCH 05/10] pps: Load timecounter once in pps_capture()

2023-03-06 Thread Sebastian Huber
This ensures that the timecounter and the tc_get_timecount handler belong together. Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/604 --- cpukit/score/src/kern_tc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/cpukit/score/src/kern_tc.c

[PATCH 09/10] pps: Simplify the nsec calculation in pps_event()

2023-03-06 Thread Sebastian Huber
Let A be the current calculation of the frequency accumulator (pps_fcount) update in pps_event() scale = (uint64_t)1 << 63; scale /= captc->tc_frequency; scale *= 2; bt.sec = 0; bt.frac = 0; bintime_addx(, scale * tcount); bintime2timespec(, ); hardpps(tsp, ts.tv_nsec + 10

[PATCH 08/10] pps: Directly assign the timestamps in pps_event()

2023-03-06 Thread Sebastian Huber
Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/604 --- cpukit/score/src/kern_tc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c index 586331dc7a..5e43964bf4 100644 ---

[PATCH 06/10] pps: Simplify capture and event processing

2023-03-06 Thread Sebastian Huber
Use local variables for the captured timehand and timecounter in pps_event(). This fixes a potential issue in the nsec preparation for hardpps(). Here the timecounter was accessed through the captured timehand after the generation was checked. Make a snapshot of the relevent timehand values

[PATCH 02/10] set_cputicker: use a bool

2023-03-06 Thread Sebastian Huber
From: Mitchell Horne The third argument to this function indicates whether the supplied ticker is fixed or variable, i.e. requiring calibration. Give this argument a type and name that better conveys this purpose. Reviewed by:kib, markj MFC after: 1 week Sponsored by: The FreeBSD

[PATCH 00/10] Synchronize timekeeping with FreeBSD

2023-03-06 Thread Sebastian Huber
Mateusz Guzik (1): ntptime: ansify Mitchell Horne (1): set_cputicker: use a bool Sebastian Huber (7): Clarify hardpps() parameter name and comment pps: Load timecounter once in pps_capture() pps: Simplify capture and event processing pps: Move pcount assignment in pps_event() pps:

[PATCH 04/10] ntptime: ansify

2023-03-06 Thread Sebastian Huber
From: Mateusz Guzik Sponsored by: Rubicon Communications, LLC ("Netgate") --- cpukit/score/src/kern_ntptime.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/cpukit/score/src/kern_ntptime.c b/cpukit/score/src/kern_ntptime.c index 0d982e397b..44d56cf59e 100644 ---

[PATCH 01/10] kern_tc.c/cputick2usec()

2023-03-06 Thread Sebastian Huber
From: firk (which is used to calculate cputime from cpu ticks) has some imprecision and, worse, huge timestep (about 20 minutes on 4GHz CPU) near 53.4 days of elapsed time. kern_time.c/cputick2timespec() (it is used for clock_gettime() for querying process or thread consumed cpu time) Uses

[PATCH 03/10] Clarify hardpps() parameter name and comment

2023-03-06 Thread Sebastian Huber
Since 32c203577a5e by phk in 1999 (Make even more of the PPSAPI implementations generic), the "nsec" parameter of hardpps() is a time difference and no longer a time point. Change the name to "delta_nsec" and adjust the comment. Remove comment about a clock tick adjustment which is no longer in

[PATCH 07/10] pps: Move pcount assignment in pps_event()

2023-03-06 Thread Sebastian Huber
Move the pseq increment. This makes it possible to reuse registers earlier. Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/604 --- cpukit/score/src/kern_tc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/cpukit/score/src/kern_tc.c

[PATCH 1/1] testsuites/samples/hello/init.c: Modify the message in printf call

2023-03-06 Thread Ruturaj Nanoti
Changed the message printed out in the hello testsuite from `Hello World` to `Hello RTEMS, from Ruturaj Nanoti!!` to demonstrate the ability to work with the RTEMS project. --- testsuites/samples/hello/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH 0/1] GSOC Contributor Opportunity

2023-03-06 Thread Ruturaj Nanoti
Hi All, My name is Ruturaj Nanoti, I am currently pursuing my Master's degree in Electrical Engineering at the University of Pennsylvania. I am interested in Firmware development for embedded system applications. I have worked with microcontrollers and development boards like STM32F4, RP2040 Pi

Re: [PATCH] build: Print item UID in case of errors

2023-03-06 Thread Kinsey Moore
Looks good. A welcome improvement for anyone working on the build system. Kinsey On Mon, Mar 6, 2023 at 9:40 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > This helps to identify issues in build items. > --- > wscript | 14 -- > 1 file changed, 12 insertions(+),

[PATCH] build: Print item UID in case of errors

2023-03-06 Thread Sebastian Huber
This helps to identify issues in build items. --- wscript | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/wscript b/wscript index a34cac51e2..567f42db2f 100755 --- a/wscript +++ b/wscript @@ -214,14 +214,24 @@ class Item(object):

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

2023-03-06 Thread Padmarao.Begari
> On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote: > > On 06.03.23 13:00, padmarao.beg...@microchip.com wrote: > > > On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote: > > > > > > On 06.03.23 10:24,padmarao.beg...@microchip.com wrote: > > > > Hi Sebastian, > > > > > > > > > On

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

2023-03-06 Thread Sebastian Huber
On 06.03.23 13:00, padmarao.beg...@microchip.com wrote: On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote: On 06.03.23 10:24,padmarao.beg...@microchip.com wrote: Hi Sebastian, On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote: On 06.03.23 09:37,padmarao.beg...@microchip.com

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

2023-03-06 Thread Padmarao.Begari
> On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote: > > On 06.03.23 10:24, padmarao.beg...@microchip.com wrote: > > Hi Sebastian, > > > > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote: > > > > > > On 06.03.23 09:37, padmarao.beg...@microchip.com wrote: > > > > > Is > > > >

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

2023-03-06 Thread Sebastian Huber
On 06.03.23 10:24, padmarao.beg...@microchip.com wrote: Hi Sebastian, On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote: On 06.03.23 09:37, padmarao.beg...@microchip.com wrote: Is the claim complete message ignored if the interrupt is disabled? Yes. Is this an intended and

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

2023-03-06 Thread Padmarao.Begari
Hi Sebastian, > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote: > > On 06.03.23 09:37, padmarao.beg...@microchip.com wrote: > > > Is > > > the claim complete message ignored if the interrupt is disabled? > > > > > Yes. > > Is this an intended and documented behaviour of the PLIC?

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

2023-03-06 Thread Sebastian Huber
On 06.03.23 09:37, padmarao.beg...@microchip.com wrote: Is the claim complete message ignored if the interrupt is disabled? Yes. Is this an intended and documented behaviour of the PLIC? This is a hardware bug from my point of view. If we really need a software workround just for the PLIC

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

2023-03-06 Thread Padmarao.Begari
Hi Sebastian, > On Mon, 2023-03-06 at 08:01 +0100, Sebastian Huber wrote: > > Hello Padmarao, > > On 03.03.23 15:55, padmarao.beg...@microchip.com wrote: > > > On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote: > > > > > > > > > On 27.02.23 16:51, Padmarao Begari wrote: > > > > The