AW: [PATCH 02/18] ptpd: Add VERSION file

> > --- > > freebsd/contrib/ptpd/VERSION | 11 +++ > > 1 file changed, 11 insertions(+) > > create mode 100644 freebsd/contrib/ptpd/VERSION > > > > diff --git a/freebsd/contrib/ptpd/VERSION > > b/freebsd/contrib/ptpd/VERSION new file mode 100644 index > > ..4c95e563 > > ---

AW: [PATCH 00/18] Port PTPd to rtems-libbsd

> On 12/4/2023 11:54 pm, Gabriel Moyano wrote: > > These commits are for porting PTPd to rtems-libbsd and are based on the > master branch. > > > > This work is a joint effort with Chris Johns, which we started some time > ago. > > Originally, we wanted to port some of the commits to PTPd upstream

AW: Project Discussion for GSoC 2023

Hi Viraj, Please find the code in this branch: https://github.com/GabrielDai/rtems-libbsd/tree/port-greth-to-5-freebsd-12 Since this driver depends on drvmgr, you’ll have to compile your bsp with support for it (make sure your bsp register the driver for your gaisler card using the drvmgr

AW: Project Discussion for GSoC 2023

Hi Viraj, We ported the driver for greth to rtems-libbsd in the past but never got to submit it (it might need some further refinement). The driver depends on the driver manager (drvmgr). Not sure if this is the best approach but it is a good starting point and we’d be happy to share it. Best

AW: [PATCH] sppps01: Add test case for early returns of pps_event()

Hi Kinsey, Sorry for the late response, I wasn't available. The patch added a new test case (PPSEventEarlyReturns) for increasing the test coverage. The test case checks whether the function pps_event() (in file kern_tc.c) returns early. According to the result you shared, the test is failing

One test more for PPS API

Hi Sebastian, I added this test https://lists.rtems.org/pipermail/devel/2022-June/071926.html some time ago. Could you give me your feedback? Thanks in advance, Gabriel ___ devel mailing list devel@rtems.org

Porting PPS API support to RTEMS 5

Hello everyone, I ported the PPS API support from RTEMS 6 to RTEMS 5 and wanted to ask if somebody is interest to have the changes in the upstream. If yes, I can submit the patches. Best regards, Gabriel ___ devel mailing list devel@rtems.org

AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

> On 10.06.22 09:20, Gabriel Moyano wrote: > > Since pps->capgen is not used in uniprocessor configurations, there is > > no need to verified if it is equal to zero > > The pps->capgen is used in uniprocessor configurations. The difference to the > SMP configuration is that zero is not a special

AW: AW: AW: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

> On 08.06.22 09:54, gabriel.moy...@dlr.de wrote: > >> I don't know why there is this "if" in the code. I will ask on a > >> FreeBSD mailing list. > >> > > I think it is for the case that th_generation has changed in > > between saving the th and th_counter. If this happens

AW: AW: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

> I don't know why there is this "if" in the code. I will ask on a FreeBSD > mailing list. > > >>> I think it is for the case that th_generation has changed in between > >>> saving the th and th_counter. If this happens pps->capgen is set to > >>> 0 and later pps_event() returns

AW: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

> On 01/06/2022 08:55, gabriel.moy...@dlr.de wrote: > >> On 30/05/2022 09:29, Gabriel Moyano wrote: > >>> Since pps->capgen is not used in uniprocessor configurations, there > >>> is no need to verified if it is equal to zero > >>> > >>> Update #2349 > >>> --- > >>>cpukit/score/src/kern_tc.c |

AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

> On 30/05/2022 09:29, Gabriel Moyano wrote: > > Since pps->capgen is not used in uniprocessor configurations, there is > > no need to verified if it is equal to zero > > > > Update #2349 > > --- > > cpukit/score/src/kern_tc.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git

AW: AW: [PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

> On 27.05.22 11:49, gabriel.moy...@dlr.de wrote: > >> On 27.05.22 10:51, Sebastian Huber wrote: > >>> Hello Gabriel, > >>> > >>> the uniprocessor version uses an optimization at the reader side: > >>> > >>> #if defined(RTEMS_SMP) > >>> } while (gen == 0 || gen != th->th_generation); #else >

AW: [PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

> On 27.05.22 10:51, Sebastian Huber wrote: > > Hello Gabriel, > > > > the uniprocessor version uses an optimization at the reader side: > > > > #if defined(RTEMS_SMP) > > } while (gen == 0 || gen != th->th_generation); #else > > } while (gen != th->th_generation); #endif > > > > This is

AW: [PATCH] score: Fix pps_fetch()

Hi Sebastian, It is ok. Thx for adding this, I must have removed this "if" accidentally. > Return early only if there was a timeout, otherwise return the PPS info. > > Update #2349. > --- > cpukit/score/src/kern_tc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git

AW: [PATCH v3 04/11] kern_tc.c: Replace FREEBSD event mechanism by adding pointers to function

Thx, I'll send a new version of the commits today. The issue in the NTP test will also be resolved. > FREEBSD should be FreeBSD. > > On 04/05/2022 14:12, Gabriel Moyano wrote: > > --- > > cpukit/include/sys/timepps.h | 21 > > cpukit/score/src/kern_tc.c | 38

AW: [PATCH v3 00/11] ENABLE PPS API in RTEMS6

> Hello Gabriel, > > I get a test failure in spntp01 now using the sparc/gr740 and > arm/xilinx_zynq_a9_qemu BSP: > > F:23:0:UI1:init.c:84:2 == 0 > > Did you observe this test failure also? > Yes, thanks for noticing it. It is due the changes in [PATCH v3 09/11]. The default value for

AW: [PATCH v3 00/11] ENABLE PPS API in RTEMS6

> This is the 3rd version of the patches for enabling the PPS API in RTEMS6. > It contains the changes suggested by Sebastian from yesterday (03/05/2022). > > Gabriel Moyano (11): > kern_ntptime.c: Disable freebsd features > kern_ntptime.c: Add lmax() qmin() definitions > kern_tc.c: Add

AW: [PATCH v2 12/12] testsuites/sptests: Add sppps01 test

> On 29/04/2022 09:20, Gabriel Moyano wrote: > > +- Copyright (C) 2022 German Aerospace Center (DLR) > > Is this a legal entity or shouldn't this be "Deutsche Zentrum für Luft- und > Raumfahrt e. V. (DLR)"? > I would have also preferred that one but I asked Jan (in CC) about it and the one in

AW: [PATCH v2 11/12] timepps.h: Move hardpps to the _ namespace

> On 29/04/2022 09:20, Gabriel Moyano wrote: > > --- > > cpukit/include/sys/timepps.h | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/cpukit/include/sys/timepps.h > > b/cpukit/include/sys/timepps.h index b13ac6bf26..25370f3f4b 100644 > > --- a/cpukit/include/sys/timepps.h > > +++

AW: [PATCH v2 05/12] kern_tc.c: Replace FREEBSD event mechanism by adding pointers to function

> On 29/04/2022 09:20, Gabriel Moyano wrote: > > --- > > cpukit/include/sys/timepps.h | 6 ++ > > cpukit/score/src/kern_tc.c | 25 + > > 2 files changed, 31 insertions(+) > > > > diff --git a/cpukit/include/sys/timepps.h > > b/cpukit/include/sys/timepps.h index

AW: AW: AW: AW: [PATCH 07/12] kern_tc.c: Remove verification of th_generation for pps functions

> On 27.04.22 15:13, gabriel.moy...@dlr.de wrote: > >> On 07/04/2022 15:16, Sebastian Huber wrote: > >>> On 07/04/2022 15:10, gabriel.moy...@dlr.de wrote: > > Which sequence of function calls and timings cases the problem? > > This should be definitely a test case. > The generation is

AW: AW: AW: AW: AW: [PATCH 11/12] kern_ntptime: Add define in order to remove warning

> On 08/04/2022 08:28, gabriel.moy...@dlr.de wrote: > PPS device drivers should use the kernel space API. Since we don't > have a user and kernel space in RTEMS, the kerne space API should be > available also if __rtems__ is defined. > >>> So, you mean to remove the #ifdef _KERNEL

AW: AW: AW: [PATCH 07/12] kern_tc.c: Remove verification of th_generation for pps functions

> On 07/04/2022 15:16, Sebastian Huber wrote: > > On 07/04/2022 15:10, gabriel.moy...@dlr.de wrote: > >>> Which sequence of function calls and timings cases the problem? This > >>> should be definitely a test case. > >> The generation is updated every time tc_windup() is called. So it is > >> more

AW: AW: [PATCH 12/12] spec/build/cpukit: Add option for enabling PPS synchronization

> > > >> In general, the patch set lacks test cases. > > > > I was thinking that the next step could be to add a generic device which is > > required to use the API (a file descriptor is needed). This is > something that wanted to ask in the mailing list first. When this device is > added, also

AW: AW: AW: AW: [PATCH 11/12] kern_ntptime: Add define in order to remove warning

> >> PPS device drivers should use the kernel space API. Since we don't > >> have a user and kernel space in RTEMS, the kerne space API should be > >> available also if __rtems__ is defined. > > > > So, you mean to remove the #ifdef _KERNEL using #ifndef__rtems__. > > It is an > > #ifdef

AW: AW: AW: [PATCH 11/12] kern_ntptime: Add define in order to remove warning

> On 07/04/2022 14:51, gabriel.moy...@dlr.de wrote: > >> On 07/04/2022 11:56, gabriel.moy...@dlr.de wrote: > On 07/04/2022 10:36, Gabriel Moyano wrote: > > --- > > cpukit/score/src/kern_ntptime.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git

AW: AW: [PATCH 05/12] kern_tc.c: Replace atomic functions required by PPS API

> On 07/04/2022 11:55, gabriel.moy...@dlr.de wrote: > >> On 07/04/2022 10:36, Gabriel Moyano wrote: > >>> --- > >>>cpukit/include/sys/timepps.h | 4 > >>>cpukit/score/src/kern_tc.c | 7 +++ > >>>2 files changed, 11 insertions(+) > >>> > >>> diff --git

AW: AW: [PATCH 07/12] kern_tc.c: Remove verification of th_generation for pps functions

> On 07/04/2022 11:56, gabriel.moy...@dlr.de wrote: > >> On 07/04/2022 10:36, Gabriel Moyano wrote: > >>> --- > >>>cpukit/score/src/kern_tc.c | 6 ++ > >>>1 file changed, 6 insertions(+) > >>> > >>> diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c > >>> index

AW: AW: [PATCH 08/12] kern_tc.c: Add definition of tc_getfrequency in kern_tc

> On 07/04/2022 12:43, gabriel.moy...@dlr.de wrote: > > > >> On 07/04/2022 10:36, Gabriel Moyano wrote: > >>> --- > >>>cpukit/score/src/kern_tc.c | 2 +- > >>>1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c > >>>

AW: AW: [PATCH 12/12] spec/build/cpukit: Add option for enabling PPS synchronization

> On 07/04/2022 11:57, gabriel.moy...@dlr.de wrote: > >> On 07/04/2022 10:36, Gabriel Moyano wrote: > >>> --- > >>>spec/build/cpukit/cpuopts.yml| 2 ++ > >>>spec/build/cpukit/optppssync.yml | 16 > >>>2 files changed, 18 insertions(+) > >>>create mode 100644

AW: AW: [PATCH 11/12] kern_ntptime: Add define in order to remove warning

> On 07/04/2022 11:56, gabriel.moy...@dlr.de wrote: > >> On 07/04/2022 10:36, Gabriel Moyano wrote: > >>> --- > >>>cpukit/score/src/kern_ntptime.c | 3 +++ > >>>1 file changed, 3 insertions(+) > >>> > >>> diff --git a/cpukit/score/src/kern_ntptime.c > >>> b/cpukit/score/src/kern_ntptime.c

AW: [PATCH 12/12] spec/build/cpukit: Add option for enabling PPS synchronization

> On 07/04/2022 10:36, Gabriel Moyano wrote: > > --- > > spec/build/cpukit/cpuopts.yml| 2 ++ > > spec/build/cpukit/optppssync.yml | 16 > > 2 files changed, 18 insertions(+) > > create mode 100644 spec/build/cpukit/optppssync.yml > > > > diff --git

AW: [PATCH 06/12] kern_tc.c: Replace FREEBSD event mechanism by adding pointers to function

> On 07/04/2022 10:36, Gabriel Moyano wrote: > > +#else /* __rtems__ */ > > +if (pps->wait_event != NULL) > > +err = (*pps->wait_event)(pps, fapi->timeout); > > +else > > +err = EAGAIN; > > +#endif /* __rtems__ */ > > if

AW: [PATCH 11/12] kern_ntptime: Add define in order to remove warning

> On 07/04/2022 10:36, Gabriel Moyano wrote: > > --- > > cpukit/score/src/kern_ntptime.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/cpukit/score/src/kern_ntptime.c > > b/cpukit/score/src/kern_ntptime.c index d4a233f67e..d6ea739f5b 100644 > > ---

AW: [PATCH 07/12] kern_tc.c: Remove verification of th_generation for pps functions

> On 07/04/2022 10:36, Gabriel Moyano wrote: > > --- > > cpukit/score/src/kern_tc.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c > > index a5c7b4b841..a8ba268ea3 100644 > > --- a/cpukit/score/src/kern_tc.c > > +++

AW: [PATCH 06/12] kern_tc.c: Replace FREEBSD event mechanism by adding pointers to function

> On 07/04/2022 10:36, Gabriel Moyano wrote: > > diff --git a/cpukit/include/sys/timepps.h > > b/cpukit/include/sys/timepps.h index 5703381ffa..a72579d5d7 100644 > > --- a/cpukit/include/sys/timepps.h > > +++ b/cpukit/include/sys/timepps.h > > @@ -149,6 +149,12 @@ struct mtx; > > > > #define

AW: [PATCH 05/12] kern_tc.c: Replace atomic functions required by PPS API

> On 07/04/2022 10:36, Gabriel Moyano wrote: > > --- > > cpukit/include/sys/timepps.h | 4 > > cpukit/score/src/kern_tc.c | 7 +++ > > 2 files changed, 11 insertions(+) > > > > diff --git a/cpukit/include/sys/timepps.h > > b/cpukit/include/sys/timepps.h index 621afb08ec..5703381ffa

AW: AW: AW: Dependencies of PPS API in rtems-libbsd

> On 30/03/2022 15:19, gabriel.moy...@dlr.de wrote: > >>> Ok, it seems the pps_event() could be called by interrupt service > >>> routines. In this case, you cannot use a mutex and condition variables. > >>> You have to use a thread queue directly. Use the thread queue ISR > >>> lock for mutual

AW: AW: AW: Dependencies of PPS API in rtems-libbsd

> > On 30/03/2022 15:19, gabriel.moy...@dlr.de wrote: > >>> Ok, it seems the pps_event() could be called by interrupt service > >>> routines. In this case, you cannot use a mutex and condition variables. > >>> You have to use a thread queue directly. Use the thread queue ISR > >>> lock for mutual

AW: AW: Dependencies of PPS API in rtems-libbsd

> > >> I guess you want to enable tc_poll_pps in struct timecounter as well? > > > > > > I didn't plan to do that but it can be done just removing some #ifndef, > > > right? > > > > Is this handler not use for the PPS support? If it is currently unused, > > then please let it disabled. > > Ok.

AW: AW: Dependencies of PPS API in rtems-libbsd

> >> I guess you want to enable tc_poll_pps in struct timecounter as well? > > > > I didn't plan to do that but it can be done just removing some #ifndef, > > right? > > Is this handler not use for the PPS support? If it is currently unused, then > please let it disabled. Ok. For now I was

AW: Dependencies of PPS API in rtems-libbsd

Hello Sebastian, > On 15/03/2022 16:31, gabriel.moy...@dlr.de wrote: > > I'm working on enabling PPS support in RTEMS > > does this mean you want to define PPS_SYNC for kern_tc.c and kern_ntptime.c > in RTEMS? yes > I guess you want to enable tc_poll_pps in struct timecounter as well? I

Dependencies of PPS API in rtems-libbsd

Hi everybody, I'm working on enabling PPS support in RTEMS (actually it is already running and I'm preparing the commits to send them) but have couple of questions about functions/macros that are defined in rtems-libbsd repository. Since the repository where the changes need to be applied is

AW: [PATCH 1/2] kern_ntptime.c: Import from FreeBSD

> +#ifdef PPS_SYNC > +SYSCTL_INT(_kern_ntp_pll, OID_AUTO, pps_shiftmax, CTLFLAG_RW, > +_shiftmax, 0, "Max interval duration (sec) (shift)"); > +SYSCTL_INT(_kern_ntp_pll, OID_AUTO, pps_shift, CTLFLAG_RW, > +_shift, 0, "Interval duration (sec) (shift)"); > +SYSCTL_LONG(_kern_ntp_pll,

AW: [PATCH 0/2] Add NTP support

Is there anyone who would like to have NTP support in RTEMS 5? Just wondering if it makes sense to port it back to RTEMS 5 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

AW: AW: [PATCH 4/4] kern_ntptime: sys_ntp_adjtime() does not return error when modes is 0 or MOD_TAI

> >> What is the reason for this patch? > >> > > This change is something I would like to have a second opinion. So, thanks > > for the question. > > > > Originally at the end of sys_ntp_adjtime(), if the function copyout() > > doesn't return an error, the value returned by >

AW: [PATCH 0/4] NTP support (master)

> Hello Gabriel, > I reviewed the patch set and the kern_ntptime.c. Changes in FreeBSD in > kern_ntptime.c are infrequently. The module is pretty self > contained. I suggest to import this file into the RTEMS sources due to the > coupling with kern_tc.c which is already present in RTEMS. Sounds

AW: [PATCH 4/4] kern_ntptime: sys_ntp_adjtime() does not return error when modes is 0 or MOD_TAI

> > What is the reason for this patch? > This change is something I would like to have a second opinion. So, thanks for the question. Originally at the end of sys_ntp_adjtime(), if the function copyout() doesn't return an error, the value returned by ntp_is_time_error(), which variable name

AW: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

> > > >> I am fine with this change being pushed to the 5 branch but I think it > > > >> needs to built with the tier 1 archs (i386, powerpc, arm). > > > > > > > > I could compile them for the BSPs of those archs. > > > > > > Thanks. > > > > > > > Does it make sense to run some test in qemu? > >

AW: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

> > >> I am fine with this change being pushed to the 5 branch but I think it > > >> needs to built with the tier 1 archs (i386, powerpc, arm). > > > > > > I could compile them for the BSPs of those archs. > > > > Thanks. > > > > > Does it make sense to run some test in qemu? > > > > Test results

AW: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

> >> I am fine with this change being pushed to the 5 branch but I think it > >> needs to built with the tier 1 archs (i386, powerpc, arm). > > > > I could compile them for the BSPs of those archs. > > Thanks. > > > Does it make sense to run some test in qemu? > > Test results are always

AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

> I am fine with this change being pushed to the 5 branch but I think it needs > to built with the tier 1 archs (i386, powerpc, arm). I could compile them for the BSPs of those archs. Does it make sense to run some test in qemu? > Once pushed I would appreciate an update to: > >

AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

Hi Sebastian, Thx for your quick answer. > > These commits port to rtems 5 the last changes in kern_tc and timecounter > > pushed by Sebastian Huber. > > Additionally the last commit closes the ticket 4549, which is a clone of > > 2348(NTP support) for rtems 5. > > From my point of view this

Question about ticket 2349

Hi Sebastian, In my team we are wondering what is required to add PPS support and since you've added the ticket (https://devel.rtems.org/ticket/2349), you may be the first person to ask about. Thanks in advance. Best regards, Gabriel -- Deutsches Zentrum für Luft- und

commit hash of rtems-libbsd

Hi everyone, is there any macro defined while compiling rtems-libbsd with the commit hash of the current commit? Thx! Gabriel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

AW: question about posix timer expiration

Hi Chris, 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 with kqueue, thx!. Regards, Gabriel Von:

AW: question about posix timer expiration

>From further investigation I've found that when a timer expires, >_POSIX_Timer_TSR() is called and this uses pthread_kill() to send a signal. >Shouldn't ptimer->inf.sigev_value be used here in order to create a siginfo_t >object with the right value? Did anyone have to deal with this while

question about posix timer expiration

Hello everyone, Currently I am trying to get running ptpd on rtems (following the Chris' work, thx btw). Ptpd uses posix timers and when a timer expires a handler with this signature void(int sig, siginfo_t *info, void *ucontext) is called. Unfortunately (*info) doesn't have the right values,

AW: [PATCH 0/1] grlib/genirq: Issue when enabling/disabling interrupt

>Yes, rtems 5 also has it. I can create a ticket. Here is the link to the ticket https://devel.rtems.org/ticket/4385#ticket. BTW the proposed solution for the master branch can be also applied to 5 as well. >Regarding the proposed solution, I wanted to start a thread for discussing it >(maybe

AW: [PATCH 0/1] grlib/genirq: Issue when enabling/disabling interrupt

Yes, rtems 5 also has it. I can create a ticket. Regarding the proposed solution, I wanted to start a thread for discussing it (maybe there is better was to do it). >Is this a bug in rtems 5 also? > >If so, does it warrant a back-port fix and a ticket? > >On Mon, Apr 12, 2021 at 3:16 AM

AW: [PATCH 0/2] Import ehci_pci

Sorry, I have forgotten to mention that this patch is for the master -Ursprüngliche Nachricht- Von: Moyano Heredia, Victor Gabriel Gesendet: Montag, 22. Februar 2021 11:53 An: devel@rtems.org Cc: Moyano Heredia, Victor Gabriel Betreff: [PATCH 0/2] Import ehci_pci Import ehci_pci from

AW: [PATCH 0/2] ehci_pci - ticket #4263

Sorry, I have forgotten to mention that this patch is for 5-freebsd-12 -Ursprüngliche Nachricht- Von: Moyano Heredia, Victor Gabriel Gesendet: Montag, 22. Februar 2021 11:49 An: devel@rtems.org Cc: Moyano Heredia, Victor Gabriel Betreff: [PATCH 0/2] ehci_pci - ticket #4263 Import

Porting ptpd to rtems

Hi Chris, I hope you are doing well. Last year I asked about running ptpd on RTEMS https://lists.rtems.org/pipermail/devel/2020-September/062208.html. May I ask about the last state of this? Thanks in advance, Gabriel -- Deutsches Zentrum für Luft- und Raumfahrt e.V.

AW: AW: [PATCH 1/3] Remove duplicate GRETH driver

> Hi Jiri, > > My understanding was that one driver version was meant to be used > with >>> drvmgr (greth.c) and the other without it (greth2.c). May I ask why >>> do you've chosen to remove greth.c and not greth2.c? >>> >>> I have fixed-up the greth.c file to avoid inline SPARC

AW: [PATCH 1/3] Remove duplicate GRETH driver

Hi Jiri, My understanding was that one driver version was meant to be used with drvmgr (greth.c) and the other without it (greth2.c). May I ask why do you've chosen to remove greth.c and not greth2.c? Thanks, Gabriel -Ursprüngliche Nachricht- Von: devel Im Auftrag von Jiri Gaisler

RE: legacy stack or libbsd

>> Hi Chris, >> >>> I will get back around to it. There are 2 sets of changes. In PTP itself a >>> change is to add kqueue support because select in libbsd does not support >>> signals. The PTP code runs a number of timers and they run of an alarm >>> signal. >>> The other piece of support is to

RE: legacy stack or libbsd

Hi Chris, >I will get back around to it. There are 2 sets of changes. In PTP itself a >change is to add kqueue support because select in libbsd does not support >signals. The PTP code runs a number of timers and they run of an alarm signal. >The other piece of support is to the score to bring in

RE: legacy stack or libbsd

>On 5/8/20 2:13 pm, Gedare Bloom wrote: >> On Tue, Aug 4, 2020 at 6:41 PM Chris Johns wrote: > >>> On 5/8/20 10:23 am, Chris Johns wrote: On 5/8/20 2:04 am, Heinz Junkes wrote: > Because the libbsd stack does not support some things yet (e.g. ntp) > I have PTP running on libbsd. I

RE: busdma: question about header

Thank you very much Sebastian! -Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Mittwoch, 5. August 2020 15:07 To: Moyano Heredia, Victor Gabriel; devel@rtems.org Subject: Re: busdma: question about header Hello Gabriel, this should be fixed

busdma: question about header

Hello, After one of the last changes on the file rtems-kernel-bus-dma.c, commit 5e3780023 on branch 6-freebsd-12, it is not possible to compile the tests for i386 because is not found. How is the best way to solve this issue? Adding an #ifndef __i386__? Something like this: #ifndef __i386__

RE: Command line for Qemu and libbsd for pc386

Hi Joel, Before running qemu, some qtabs should be created. How to do that it is described on file libbsd.txt (line 333). Then I usually run qemu as follows: qemu-system-i386 -append --console=/dev/com1 -no-reboot -serial stdio -monitor none -nographic -netdev

RE: [PATCH v2 0/1] testsuite: A description for each test added

Hi everyone, I am wondering why this patch was not accepted. Is there anything bad or missing? (I was following this https://www.mail-archive.com/devel@rtems.org/msg23478.html) -Original Message- From: Moyano Heredia, Victor Gabriel Sent: Freitag, 3. April 2020 09:35 To:

RE: [PATCH 3/3] testsuite/dhcpd0x: Tests automatized

Hi Sebastian, Sorry to bother you for this again. When you say "mark a test as interactive", do you mean to add TEST_STATE_USER_INPUT in the test? Regards, Gabriel -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of gabriel.moy...@dlr.de Sent: Dienstag, 31.

RE: [PATCH 3/3] testsuite/dhcpd0x: Tests automatized

Is this meaning to leave them unchanged? (or there is a define for this?) -Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Dienstag, 31. März 2020 11:46 To: Moyano Heredia, Victor Gabriel; devel@rtems.org Subject: Re: [PATCH 3/3]

RE: [PATCH 3/3] testsuite/dhcpd0x: Tests automatized

If both tests are interactive, should both of them include "the user input" define? Otherwise RTEMS tester will be waiting until the timeout. -Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Dienstag, 31. März 2020 11:35 To: Moyano Heredia,

RE: [PATCH 3/3] testsuite/dhcpd0x: Tests automatized

Hi Sebastian, The short answer to your question (Do we see the environment in the test output after this change?) is no. I understood that the idea of the test is to verify that the hook is called. If this is not correct, the change can be removed. Let me ask you if you consider useful the

Re: Description of rtems-libbsd testsuite applications

Hello Sebastian, I followed your recommendations regarding rtems_test_begin(), rtems_test_end() and RTEMS_TEST_STATE_USER_INPUT. Now I'm working on getting running the rtems-libbsd testsuit with RTEMS Tester. I would like to ask you 2 questions: 1. About arphole: In the arp_processor()