[PATCH 10/10] pps: Round to closest integer in pps_event()
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 in the frequency accumulator, see hardpps().
So, rounding to the closest integer is probably slightly better.
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 b/cpukit/score/src/kern_tc.c
index 0aa0fdd393..95ae01b5b4 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2266,6 +2266,7 @@ pps_event(struct pps_state *pps, int event)
#ifdef PPS_SYNC
if (fhard) {
uint64_t delta_nsec;
+ uint64_t freq;
/*
* Feed the NTP PLL/FLL.
@@ -2277,7 +2278,8 @@ pps_event(struct pps_state *pps, int event)
tcount &= captc->tc_counter_mask;
delta_nsec = 10;
delta_nsec *= tcount;
- delta_nsec /= captc->tc_frequency;
+ freq = captc->tc_frequency;
+ delta_nsec = (delta_nsec + freq / 2) / freq;
hardpps(tsp, (long)delta_nsec);
}
#endif
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 05/10] pps: Load timecounter once in pps_capture()
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 b/cpukit/score/src/kern_tc.c
index 92da675172..eca1a80f33 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2141,6 +2141,7 @@ void
pps_capture(struct pps_state *pps)
{
struct timehands *th;
+ struct timecounter *tc;
KASSERT(pps != NULL, ("NULL pps pointer in pps_capture"));
th = timehands;
@@ -2149,7 +2150,8 @@ pps_capture(struct pps_state *pps)
#ifdef FFCLOCK
pps->capffth = fftimehands;
#endif
- pps->capcount = th->th_counter->tc_get_timecount(th->th_counter);
+ tc = th->th_counter;
+ pps->capcount = tc->tc_get_timecount(tc);
#if defined(RTEMS_SMP)
atomic_thread_fence_acq();
if (pps->capgen != th->th_generation)
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 09/10] pps: Simplify the nsec calculation in pps_event()
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 * ts.tv_sec);
and hardpps(..., delta_nsec):
u_nsec = delta_nsec;
if (u_nsec > (NANOSECOND >> 1))
u_nsec -= NANOSECOND;
else if (u_nsec < -(NANOSECOND >> 1))
u_nsec += NANOSECOND;
pps_fcount += u_nsec;
This change introduces a new calculation which is slightly simpler and more
straight forward. Name it B.
Consider the following sample values with a tcount of 200100 and a
tc_frequency of 20 (2GHz).
For A, the scale is 9223372036. Then scale * tcount is 18446744994337203600
which is larger than UINT64_MAX (= 18446744073709551615). The result is
920627651984 == 18446744994337203600 % UINT64_MAX. Since all operands are
unsigned the result is well defined through modulo arithmetic. The result of
bintime2timespec(, ) is 49. This is equal to the correct result
100049 % NANOSECOND.
In hardpps(), both conditional statements are not executed and pps_fcount is
incremented by 49.
For the new calculation B, we have 10 * tcount is 2001000
which is less than UINT64_MAX. This yields after the division with tc_frequency
the correct result of 100050 for delta_nsec.
In hardpps(), the first conditional statement is executed and pps_fcount is
incremented by 50.
This shows that both methods yield roughly the same results. However, method B
is easier to understand and requires fewer conditional statements.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/604
---
cpukit/score/src/kern_ntptime.c | 12 +++-
cpukit/score/src/kern_tc.c | 16 ++--
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/cpukit/score/src/kern_ntptime.c b/cpukit/score/src/kern_ntptime.c
index 44d56cf59e..c6f70079b3 100644
--- a/cpukit/score/src/kern_ntptime.c
+++ b/cpukit/score/src/kern_ntptime.c
@@ -900,16 +900,10 @@ hardpps(struct timespec *tsp, long delta_nsec)
pps_tf[0].tv_nsec = u_nsec;
/*
-* Compute the difference between the current and previous
-* counter values. If the difference exceeds 0.5 s, assume it
-* has wrapped around, so correct 1.0 s.
+* Update the frequency accumulator using the difference between the
+* current and previous PPS event measured directly by the timecounter.
*/
- u_nsec = delta_nsec;
- if (u_nsec > (NANOSECOND >> 1))
- u_nsec -= NANOSECOND;
- else if (u_nsec < -(NANOSECOND >> 1))
- u_nsec += NANOSECOND;
- pps_fcount += u_nsec;
+ pps_fcount += delta_nsec - NANOSECOND;
if (v_nsec > MAXFREQ || v_nsec < -MAXFREQ)
goto out;
time_status &= ~STA_PPSJITTER;
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 5e43964bf4..0aa0fdd393 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2161,7 +2161,7 @@ pps_event(struct pps_state *pps, int event)
struct timecounter *captc;
uint64_t capth_scale;
struct bintime bt;
- struct timespec ts, *tsp, *osp;
+ struct timespec *tsp, *osp;
uint32_t tcount, *pcount;
int foff;
pps_seq_t *pseq;
@@ -2265,7 +2265,7 @@ pps_event(struct pps_state *pps, int event)
#ifdef PPS_SYNC
if (fhard) {
- uint64_t scale;
+ uint64_t delta_nsec;
/*
* Feed the NTP PLL/FLL.
@@ -2275,14 +2275,10 @@ pps_event(struct pps_state *pps, int event)
tcount = pps->capcount - pps->ppscount[2];
pps->ppscount[2] = pps->capcount;
tcount &= captc->tc_counter_mask;
- 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 * ts.tv_sec);
+ delta_nsec = 10;
+ delta_nsec *= tcount;
+ delta_nsec /= captc->tc_frequency;
+ hardpps(tsp, (long)delta_nsec);
}
#endif
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 08/10] pps: Directly assign the timestamps in pps_event()
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
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2244,8 +2244,7 @@ pps_event(struct pps_state *pps, int event)
tcount = pps->capcount - tcount;
tcount &= captc->tc_counter_mask;
bintime_addx(, capth_scale * tcount);
- bintime2timespec(, );
- *tsp = ts;
+ bintime2timespec(, tsp);
if (foff) {
timespecadd(tsp, osp, tsp);
@@ -2260,9 +2259,8 @@ pps_event(struct pps_state *pps, int event)
bt = pps->capffth->tick_time;
ffclock_convert_delta(tcount, pps->capffth->cest.period, );
bintime_add(, >capffth->tick_time);
- bintime2timespec(, );
(*pseq_ffc)++;
- *tsp_ffc = ts;
+ bintime2timespec(, tsp_ffc);
#endif
#ifdef PPS_SYNC
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 06/10] pps: Simplify capture and event processing
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 early in pps_event(). Check
the timehand generation only once during the capture and event processing. Use
atomic_thread_fence_acq() similar to the other readers.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/604
---
cpukit/score/src/kern_tc.c | 42 +++---
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index eca1a80f33..99abd652d8 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2152,16 +2152,14 @@ pps_capture(struct pps_state *pps)
#endif
tc = th->th_counter;
pps->capcount = tc->tc_get_timecount(tc);
-#if defined(RTEMS_SMP)
- atomic_thread_fence_acq();
- if (pps->capgen != th->th_generation)
- pps->capgen = 0;
-#endif
}
void
pps_event(struct pps_state *pps, int event)
{
+ struct timehands *capth;
+ struct timecounter *captc;
+ uint64_t capth_scale;
struct bintime bt;
struct timespec ts, *tsp, *osp;
uint32_t tcount, *pcount;
@@ -2180,13 +2178,21 @@ pps_event(struct pps_state *pps, int event)
/* Nothing to do if not currently set to capture this event type. */
if ((event & pps->ppsparam.mode) == 0)
return;
+
+ /* Make a snapshot of the captured timehand */
+ capth = pps->capth;
+ captc = capth->th_counter;
+ capth_scale = capth->th_scale;
+ tcount = capth->th_offset_count;
+ bt = capth->th_bintime;
+
/* If the timecounter was wound up underneath us, bail out. */
+ atomic_thread_fence_acq();
#if defined(RTEMS_SMP)
- if (pps->capgen == 0 || pps->capgen !=
+ if (pps->capgen == 0 || pps->capgen != capth->th_generation)
#else
- if (pps->capgen !=
+ if (pps->capgen != capth->th_generation)
#endif
- atomic_load_acq_int(>capth->th_generation))
return;
/* Things would be easier with arrays. */
@@ -2224,25 +2230,19 @@ pps_event(struct pps_state *pps, int event)
* If the timecounter changed, we cannot compare the count values, so
* we have to drop the rest of the PPS-stuff until the next event.
*/
- if (pps->ppstc != pps->capth->th_counter) {
- pps->ppstc = pps->capth->th_counter;
+ if (__predict_false(pps->ppstc != captc)) {
+ pps->ppstc = captc;
*pcount = pps->capcount;
pps->ppscount[2] = pps->capcount;
return;
}
/* Convert the count to a timespec. */
- tcount = pps->capcount - pps->capth->th_offset_count;
- tcount &= pps->capth->th_counter->tc_counter_mask;
- bt = pps->capth->th_bintime;
- bintime_addx(, pps->capth->th_scale * tcount);
+ tcount = pps->capcount - tcount;
+ tcount &= captc->tc_counter_mask;
+ bintime_addx(, capth_scale * tcount);
bintime2timespec(, );
- /* If the timecounter was wound up underneath us, bail out. */
- atomic_thread_fence_acq();
- if (pps->capgen != pps->capth->th_generation)
- return;
-
*pcount = pps->capcount;
(*pseq)++;
*tsp = ts;
@@ -2276,9 +2276,9 @@ pps_event(struct pps_state *pps, int event)
*/
tcount = pps->capcount - pps->ppscount[2];
pps->ppscount[2] = pps->capcount;
- tcount &= pps->capth->th_counter->tc_counter_mask;
+ tcount &= captc->tc_counter_mask;
scale = (uint64_t)1 << 63;
- scale /= pps->capth->th_counter->tc_frequency;
+ scale /= captc->tc_frequency;
scale *= 2;
bt.sec = 0;
bt.frac = 0;
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 02/10] set_cputicker: use a bool
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 Foundation
Differential Revision: https://reviews.freebsd.org/D35459
---
cpukit/score/src/kern_tc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 8e43169934..92da675172 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2497,7 +2497,7 @@ SYSINIT(timecounter, SI_SUB_CLOCKS, SI_ORDER_SECOND,
inittimecounter, NULL);
/* Cpu tick handling -*/
-static int cpu_tick_variable;
+static bool cpu_tick_variable;
static uint64_tcpu_tick_frequency;
DPCPU_DEFINE_STATIC(uint64_t, tc_cpu_ticks_base);
@@ -2590,14 +2590,14 @@ cpu_tick_calibrate(int reset)
}
void
-set_cputicker(cpu_tick_f *func, uint64_t freq, unsigned var)
+set_cputicker(cpu_tick_f *func, uint64_t freq, bool isvariable)
{
if (func == NULL) {
cpu_ticks = tc_cpu_ticks;
} else {
cpu_tick_frequency = freq;
- cpu_tick_variable = var;
+ cpu_tick_variable = isvariable;
cpu_ticks = func;
}
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 00/10] Synchronize timekeeping with FreeBSD
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: Directly assign the timestamps in pps_event() pps: Simplify the nsec calculation in pps_event() pps: Round to closest integer in pps_event() firk (1): kern_tc.c/cputick2usec() cpukit/score/src/kern_ntptime.c | 24 +++-- cpukit/score/src/kern_tc.c | 94 +++-- 2 files changed, 50 insertions(+), 68 deletions(-) -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 04/10] ntptime: ansify
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
--- a/cpukit/score/src/kern_ntptime.c
+++ b/cpukit/score/src/kern_ntptime.c
@@ -782,8 +782,7 @@ RTEMS_SYSINIT_ITEM(_NTP_Initialize,
RTEMS_SYSINIT_DEVICE_DRIVERS,
* is selected by the STA_MODE status bit.
*/
static void
-hardupdate(offset)
- long offset;/* clock offset (ns) */
+hardupdate(long offset /* clock offset (ns) */)
{
long mtemp;
l_fp ftemp;
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 01/10] kern_tc.c/cputick2usec()
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 cputick2usec()
and then needlessly converting usec to nsec, obviously losing
precision even with fixed cputick2usec().
kern_time.c/kern_clock_getres() uses some weird (anyway wrong)
formula for getting cputick resolution.
PR: 262215
Reviewed by:gnn
Differential Revision: https://reviews.freebsd.org/D34558
---
cpukit/score/src/kern_tc.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 643026a1c8..8e43169934 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2617,20 +2617,14 @@ cpu_tickrate(void)
* years) and in 64 bits at 4 GHz (146 years), but if we do a multiply
* before divide conversion (to retain precision) we find that the
* margin shrinks to 1.5 hours (one millionth of 146y).
- * With a three prong approach we never lose significant bits, no
- * matter what the cputick rate and length of timeinterval is.
*/
uint64_t
cputick2usec(uint64_t tick)
{
-
- if (tick > 18446744073709551LL) /* floor(2^64 / 1000) */
- return (tick / (cpu_tickrate() / 100LL));
- else if (tick > 18446744073709LL) /* floor(2^64 / 100) */
- return ((tick * 1000LL) / (cpu_tickrate() / 1000LL));
- else
- return ((tick * 100LL) / cpu_tickrate());
+ uint64_t tr;
+ tr = cpu_tickrate();
+ return ((tick / tr) * 100ULL) + ((tick % tr) * 100ULL) / tr;
}
cpu_tick_f *cpu_ticks = tc_cpu_ticks;
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 03/10] Clarify hardpps() parameter name and comment
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 the code.
Pull Request: https://github.com/freebsd/freebsd-src/pull/640
Reviewed by: imp
---
cpukit/score/src/kern_ntptime.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/cpukit/score/src/kern_ntptime.c b/cpukit/score/src/kern_ntptime.c
index 1233166a61..0d982e397b 100644
--- a/cpukit/score/src/kern_ntptime.c
+++ b/cpukit/score/src/kern_ntptime.c
@@ -862,11 +862,11 @@ hardupdate(offset)
* variables, except for the actual time and frequency variables, which
* are determined by this routine and updated atomically.
*
- * tsp - time at PPS
- * nsec - hardware counter at PPS
+ * tsp - time at current PPS event
+ * delta_nsec - time elapsed between the previous and current PPS event
*/
void
-hardpps(struct timespec *tsp, long nsec)
+hardpps(struct timespec *tsp, long delta_nsec)
{
long u_sec, u_nsec, v_nsec; /* temps */
l_fp ftemp;
@@ -903,12 +903,9 @@ hardpps(struct timespec *tsp, long nsec)
/*
* Compute the difference between the current and previous
* counter values. If the difference exceeds 0.5 s, assume it
-* has wrapped around, so correct 1.0 s. If the result exceeds
-* the tick interval, the sample point has crossed a tick
-* boundary during the last second, so correct the tick. Very
-* intricate.
+* has wrapped around, so correct 1.0 s.
*/
- u_nsec = nsec;
+ u_nsec = delta_nsec;
if (u_nsec > (NANOSECOND >> 1))
u_nsec -= NANOSECOND;
else if (u_nsec < -(NANOSECOND >> 1))
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 07/10] pps: Move pcount assignment in pps_event()
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 b/cpukit/score/src/kern_tc.c
index 99abd652d8..586331dc7a 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2226,25 +2226,25 @@ pps_event(struct pps_state *pps, int event)
#endif
}
+ *pcount = pps->capcount;
+
/*
* If the timecounter changed, we cannot compare the count values, so
* we have to drop the rest of the PPS-stuff until the next event.
*/
if (__predict_false(pps->ppstc != captc)) {
pps->ppstc = captc;
- *pcount = pps->capcount;
pps->ppscount[2] = pps->capcount;
return;
}
+ (*pseq)++;
+
/* Convert the count to a timespec. */
tcount = pps->capcount - tcount;
tcount &= captc->tc_counter_mask;
bintime_addx(, capth_scale * tcount);
bintime2timespec(, );
-
- *pcount = pps->capcount;
- (*pseq)++;
*tsp = ts;
if (foff) {
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/1] testsuites/samples/hello/init.c: Modify the message in printf call
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 a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 83f6342ab3..2faff4a1ec 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -41,7 +41,8 @@ static rtems_task Init(
{
rtems_print_printer_fprintf_putc(_test_printer);
TEST_BEGIN();
- printf( "Hello World\n" );
+ /* printf( "Hello World\n" ); */
+ printf( "Hello RTEMS, from Ruturaj Nanoti!!\n" );
TEST_END();
rtems_test_exit( 0 );
}
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/1] GSOC Contributor Opportunity
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 Pico, Teensy 4.1, ItsyBitsy (nRF52840), etc. and also have experience with programming languages like C (both embedded and system level), C++, and Python. I came across RTEMS, while browsing through the organizations participating in GSOC this year, and found the work quite interesting and exciting. I would love to be a part of RTEMS and contribute to the project. Following are the links to some of the tasks, that I thought were quite exciting and I would really like to work on: - https://devel.rtems.org/ticket/4622 - https://devel.rtems.org/ticket/3302 - https://devel.rtems.org/ticket/4597 I have built RTEMS and modified the `init.c` file under the `hello` testuite, to say something else instead of "Hello World" as mentioned in the documentation for students interested in GSOC. I also tested building the project after making the change and the build suceeds, so I am sending over the changes as a patch. Please let me know about the next steps, and I look forward to work with you all. Thank You Ruturaj Nanoti (1): testsuites/samples/hello/init.c: Modify the message in printf call testsuites/samples/hello/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Print item UID in case of errors
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(+), 2 deletions(-)
>
> diff --git a/wscript b/wscript
> index a34cac51e2..567f42db2f 100755
> --- a/wscript
> +++ b/wscript
> @@ -214,14 +214,24 @@ class Item(object):
> self.prepare_configure(conf, cic)
> for p in self.links():
> p.configure(conf, cic)
> -self.do_configure(conf, cic)
> +try:
> +self.do_configure(conf, cic)
> +except Exception as e:
> +raise type(e)(
> +"Configuration error related to item spec:{}:
> {}".format(
> +self.uid, str(e)))
>
> def build(self, bld, bic):
> if _is_enabled(bld.env.ENABLE, self.get_enabled_by()):
> bic = self.prepare_build(bld, bic)
> for p in self.links():
> p.build(bld, bic)
> -self.do_build(bld, bic)
> +try:
> +self.do_build(bld, bic)
> +except Exception as e:
> +raise type(e)(
> +"Build error related to item spec:{}: {}".format(
> +self.uid, str(e)))
>
> def do_defaults(self, enabled):
> return
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] build: Print item UID in case of errors
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):
self.prepare_configure(conf, cic)
for p in self.links():
p.configure(conf, cic)
-self.do_configure(conf, cic)
+try:
+self.do_configure(conf, cic)
+except Exception as e:
+raise type(e)(
+"Configuration error related to item spec:{}: {}".format(
+self.uid, str(e)))
def build(self, bld, bic):
if _is_enabled(bld.env.ENABLE, self.get_enabled_by()):
bic = self.prepare_build(bld, bic)
for p in self.links():
p.build(bld, bic)
-self.do_build(bld, bic)
+try:
+self.do_build(bld, bic)
+except Exception as e:
+raise type(e)(
+"Build error related to item spec:{}: {}".format(
+self.uid, str(e)))
def do_defaults(self, enabled):
return
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
> 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 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? > > > > Not documented > > > Is this a common PLIC behaviour or just the case for the > > > MicroChip > > > implementation? > > > > > It's a common PLIC behaviour. > > It is not implemented in the Qemu PLIC emulation: > > https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242 > > Where do I see this behaviour in a PLIC implementation, for example: > > https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic > > That the interrupt completion depends on the interrupt enable/disable > status is quite unusual. > I will look into above links, mean while you can check the implemention of external interrupt service in the PolarFire SoC with same the siFive PLIC core. https://github.com/polarfire-soc/hart-software-services/blob/master/baremetal/polarfire-soc-bare-metal-library/src/platform/mpfs_hal/common/mss_mtrap.c#L623 Regards Padmarao > -- > 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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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 wrote: Is the claim complete message ignored if the interrupt is disabled? Yes. Is this an intended and documented behaviour of the PLIC? Not documented Is this a common PLIC behaviour or just the case for the MicroChip implementation? It's a common PLIC behaviour. It is not implemented in the Qemu PLIC emulation: https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242 Where do I see this behaviour in a PLIC implementation, for example: https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic That the interrupt completion depends on the interrupt enable/disable status is quite unusual. -- 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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
> 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 > > > > > the claim complete message ignored if the interrupt is > > > > > disabled? > > > > > > > > > Yes. > > > > > > Is this an intended and documented behaviour of the PLIC? > > > > Not documented > > Is this a common PLIC behaviour or just the case for the MicroChip > implementation? > It's a common PLIC behaviour. Regards Padmarao > > > This is a > > > hardware bug from my point of view. If we really need a software > > > workround just for the PLIC to work with the interrupt server, > > > then > > > we > > > should add a new function for this and keep the interrupt disable > > > as > > > is. > > > > Ok > > You could for example add a bsp_interrupt_vector_server_disable() > which > defaults to bsp_interrupt_vector_disable(). > > -- > 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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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 documented behaviour of the PLIC? Not documented Is this a common PLIC behaviour or just the case for the MicroChip implementation? This is a hardware bug from my point of view. If we really need a software workround just for the PLIC to work with the interrupt server, then we should add a new function for this and keep the interrupt disable as is. Ok You could for example add a bsp_interrupt_vector_server_disable() which defaults to bsp_interrupt_vector_disable(). -- 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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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? Not documented > This is a > hardware bug from my point of view. If we really need a software > workround just for the PLIC to work with the interrupt server, then > we > should add a new function for this and keep the interrupt disable as > is. Ok Regards Padmarao > > -- > 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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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 to work with the interrupt server, then we should add a new function for this and keep the interrupt disable as is. -- 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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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 interrupt complete should clear with the interrupt
> > > > number before disabling the interrupt in the PLIC to
> > > > get the next interrupt.
> > > Which problem does this patch address?
> > >
> > The problem occurs when the interrupt register(enabled) in the
> > RTEMS-
> > LIBBSD drivers and want to serve the interrupt subroutine in the
> > RTEMS.
> >
> > Example : CGEM driver
> >
> > When the application running to test the CGEM driver with RTEMS +
> > RTEMS-LIBBSD, The interrupt is occurred while transmiting the
> > ethernet
> > pocket, the RTEMS is received the interrupt but not served with the
> > register interrupt subroutine instead it disable the interrupt and
> > set
> > the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is
> > clearing the interrupt complete register but there is no effect and
> > the
> > next transmit pocket intereupt is not occurred because the
> > interrupt is
> > disabled before the interrupt complete clear.
> >
> > RISC-V interrupt stacktrace
> > **
> > _RISCV_Exception_handler()
> > _RISCV_Interrupt_dispatch()
> > bsp_interrupt_handler_dispatch_unchecked()
> > bsp_interrupt_dispatch_entries()
> > ( *entry->handler )( entry->arg ); ->
> > bsp_interrupt_server_trigger()
> > bsp_interrupt_server_trigger()
> > bsp_interrupt_is_valid_vector()
> > bsp_interrupt_vector_disable()
> > rtems_event_system_send()
> > *
>
> The claim complete register is written after the interrupt handler
> dispatch:
>
> while ((interrupt_index = plic_hart_regs->claim_complete) != 0)
> {
>bsp_interrupt_handler_dispatch(
> RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
>);
>
>plic_hart_regs->claim_complete = interrupt_index;
>
> If you write to the claim complete register also in the interrupt
> disable function, then this write is done twice.
>
Yes but no impact on second write.
> The interrupt disable function may be used in other contexts as well
> so
> doing a write to the claim complete register may have unexpected side
> effects.
>
> We should first figure out why the current implementation which works
> with several other interrupt controllers doesn't work with the PLIC.
Current Implemtation is working fine for UART, Timer because the ISR is
installed at the RTEMS source and when the interrupt is occured it is
going to call the ISR and clear the interrupt complete but not disable
the interrupt.
> Is
> the claim complete message ignored if the interrupt is disabled?
>
Yes.
Regards
Padmarao
> --
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
