Re: AW: AW: [PATCH 4/4] kern_ntptime: sys_ntp_adjtime() does not return error when modes is 0 or MOD_TAI
On 08/02/2022 08:13, gabriel.moy...@dlr.de wrote: 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 is retval, is saved in td->td_retval[0]. Chris modified this, being retval saved in the variable error, which is the one returned by sys_ntp_adjtime(). In libbsd, copyout() is just a memcpy() which returns 0. Under some situations, ntp_adjtime() is called with modes = 0 just for retrieving some values (for example herehttps://github.com/ptpd/ptpd/blob/master/src/dep/sys.c#L2036, please notice that here adjtimex() is ntp_adjtime()). In those cases, returning retval may not be meaningful. Other similar situation happens when mode is MOD_TAI (https://github.com/ptpd/ptpd/blob/master/src/dep/sys.c#L2070). This is more or less the reason. If there is better way to solve this, is welcome. I don't think the changes make sense. The td->td_retval[0] is the return value of the system call if it is successful. The "error" indicates if the system call was successful (== 0), otherwise it returns -1 with errno set to "error". So, do you also propose to remove the line "error = retval;" ? I think it is better keeping the return value meaning of sys_ntp_adjtime(), i.e. just returning 0 (successful) or -1 (in case of error) The return values should match with the documentation in the man page. I will send a patch to import kern_ntptime.c to RTEMS shortly. -- 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
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 > ntp_is_time_error(), which variable name is retval, is saved in > td->td_retval[0]. Chris modified this, being retval saved in the variable > error, which is the one returned by sys_ntp_adjtime(). > > In libbsd, copyout() is just a memcpy() which returns 0. > > > > > Under some situations, ntp_adjtime() is called with modes = 0 just for > > retrieving some values (for example > herehttps://github.com/ptpd/ptpd/blob/master/src/dep/sys.c#L2036, please > notice that here adjtimex() is ntp_adjtime()). In those > cases, returning retval may not be meaningful. Other similar situation > happens when mode is MOD_TAI > (https://github.com/ptpd/ptpd/blob/master/src/dep/sys.c#L2070). > > > > This is more or less the reason. If there is better way to solve this, is > > welcome. > > I don't think the changes make sense. The td->td_retval[0] is the return > value of the system call if it is successful. The "error" indicates > if the system call was successful (== 0), otherwise it returns -1 with errno > set to "error". > So, do you also propose to remove the line "error = retval;" ? I think it is better keeping the return value meaning of sys_ntp_adjtime(), i.e. just returning 0 (successful) or -1 (in case of error) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Call for Mentors, Project Ideas
Hello all, RTEMS Project is applying to participate in GSoC 2022. There are a few significant changes to GSoC this year, including that eligibility is expanded beyond students, the program timeline can be more flexible to expend effort over more months (until November) if agreed upon by all involved, and project scope can be either small or large with stipend scaling. We are encouraged to have/consider a variety of large and small scope projects. Instead of calling GSoC participants as "students" they are now referred to as "contributors". If you would like to be a primary or secondary mentor, please let me know so I can invite you later on. If you have ideas for small/large projects, feel free to add them as tickets, as explained on our ideas page: https://devel.rtems.org/wiki/Developer/OpenProjects Thanks, Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: i2c initialization MVME3100
Glad you figured it out. Are you going to file a ticket or at least
post a patch? :)
--joel
On Mon, Feb 7, 2022 at 12:20 PM Heinz Junkes wrote:
>
> I'll answer my question myself ;-)
>
> I changed
>
> > RTEMS_SYSINIT_ITEM{
> > mvme3100_i2c_initialize,
> > RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> > RTEMS_SYSINIT_ORDER_MIDDLE
> > );
>
> to
>
> RTEMS_SYSINIT_ITEM{
>mvme3100_i2c_initialize,
>RTEMS_SYSINIT_BSP_DRVMGR_LEVEL_2,
>RTEMS_SYSINIT_ORDER_MIDDLE
> );
>
> Heinz
>
> > On 7. Feb 2022, at 14:42, Heinz Junkes wrote:
> >
> > in bsps/powerpc/mvme3100/start/bspstart.c I can find
> >
> > RTEMS_SYSINIT_ITEM{
> > mvme3100_i2c_initialize,
> > RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> > RTEMS_SYSINIT_ORDER_MIDDLE
> > );
> >
> > mvme3100_i2c_initialize calls BSP_i2c_initialize
> >
> > This can be found in bsps/powerpc/mvme3100/i2c/i2c_init.c
> > This function calls rtems_libi2c_initialize() from cpukit/libi2c/libi2c.c
> >
> > and here rtems_io_register_driver gets called:
> >
> > sc = rtems_io_register_driver (0, _libi2c_io_ops,
> > _libi2c_major);
> >
> > But in cpukit/sapi/src/ioregisterdriver.c
> >
> > in rtems_io_register_driver () the call of the associated init routine gets
> > postponed to
> > a later stage because _IO_All_drivers_initializes is not true in this early
> > of bspstart.
> > so
> > } else {
> > /* The driver will be initialized together with all other drivers
> > * in a later stage by _IO_Initialize_all_drivers();
> > */
> > return RTEMS_SUCCESSFUL;
> > }
> >
> > Now in
> > bsps/powerpc/mvme3100/i2c/i2c_init.c
> >
> > the following calls e.g.
> > busno=rtems_libi2c_register_bus(
> > BSP_I2C_BUS0_NAME,
> > …
> > must fail?
> >
> > I hope I have analysed this correctly. I may be wrong, but the output of
> > the mvme3100 looks like this:
> >
> > Registering mpc8540 i2c bus driver :No such file or directory
> > Registering /dev/console as minor 0 (==/dev/ttyS0)
> > ds1375_probe (open): No such file or directory
> >
> > This happens during initialization in EPICS. The test suite programmes do
> > not produce this output.
> >
> > In the test programmes, however, the initialisation probably fails because
> > the MAXIMUM_DRIVER is default 4.
> > e.g. TEST I2C 1
> >
> > libi2c: Claiming driver slot failed (rtems status code 10)
> > Initializing I2C library failed
> >
> > Danke Heinz
> >
> >
> > ___
> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: i2c initialization MVME3100
I'll answer my question myself ;-)
I changed
> RTEMS_SYSINIT_ITEM{
> mvme3100_i2c_initialize,
> RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> RTEMS_SYSINIT_ORDER_MIDDLE
> );
to
RTEMS_SYSINIT_ITEM{
mvme3100_i2c_initialize,
RTEMS_SYSINIT_BSP_DRVMGR_LEVEL_2,
RTEMS_SYSINIT_ORDER_MIDDLE
);
Heinz
> On 7. Feb 2022, at 14:42, Heinz Junkes wrote:
>
> in bsps/powerpc/mvme3100/start/bspstart.c I can find
>
> RTEMS_SYSINIT_ITEM{
> mvme3100_i2c_initialize,
> RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> RTEMS_SYSINIT_ORDER_MIDDLE
> );
>
> mvme3100_i2c_initialize calls BSP_i2c_initialize
>
> This can be found in bsps/powerpc/mvme3100/i2c/i2c_init.c
> This function calls rtems_libi2c_initialize() from cpukit/libi2c/libi2c.c
>
> and here rtems_io_register_driver gets called:
>
> sc = rtems_io_register_driver (0, _libi2c_io_ops, _libi2c_major);
>
> But in cpukit/sapi/src/ioregisterdriver.c
>
> in rtems_io_register_driver () the call of the associated init routine gets
> postponed to
> a later stage because _IO_All_drivers_initializes is not true in this early
> of bspstart.
> so
> } else {
> /* The driver will be initialized together with all other drivers
> * in a later stage by _IO_Initialize_all_drivers();
> */
> return RTEMS_SUCCESSFUL;
> }
>
> Now in
> bsps/powerpc/mvme3100/i2c/i2c_init.c
>
> the following calls e.g.
> busno=rtems_libi2c_register_bus(
> BSP_I2C_BUS0_NAME,
> …
> must fail?
>
> I hope I have analysed this correctly. I may be wrong, but the output of the
> mvme3100 looks like this:
>
> Registering mpc8540 i2c bus driver :No such file or directory
> Registering /dev/console as minor 0 (==/dev/ttyS0)
> ds1375_probe (open): No such file or directory
>
> This happens during initialization in EPICS. The test suite programmes do not
> produce this output.
>
> In the test programmes, however, the initialisation probably fails because
> the MAXIMUM_DRIVER is default 4.
> e.g. TEST I2C 1
>
> libi2c: Claiming driver slot failed (rtems status code 10)
> Initializing I2C library failed
>
> Danke Heinz
>
>
> ___
> 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
Re: [PATCHES] Fix PPP in libbsd and optimize ATSAM console
On Mon, Feb 7, 2022 at 9:05 AM Christian MAUDERER wrote: > > Hello Gedare, > > Am 07.02.22 um 16:40 schrieb Gedare Bloom: > > On Wed, Feb 2, 2022 at 8:20 AM Christian MAUDERER > > wrote: > >> > >> Hello, > >> > >> I received no comments for these in the last two weeks. I assume there > >> are no further objections and I can push the patches to master in about > >> a week so that the bug is fixed at least for 6. > >> > > Yeah, that's fine with me, thanks for getting it tested on another > > BSP, and for following up. > > Thanks for the response. > > > > > If you can advise how the API change affects other BSPs on 5, I think > > that can be accepted with a proper release note/documentation of what > > those users may expect. > There are two relevant changes in cpukit/include/rtems/termiostypes.h: > > 1. I added a field to the struct rtems_termios_tty. With that the binary > interface changes. > This should be ok but needs to be noted. Without looking, the main concern would be potential memory corruption. > 2. I added a parameter to one of the line discipline functions. > > - int (*l_start)(struct rtems_termios_tty *tp); > + int (*l_start)(struct rtems_termios_tty *tp,int len); > > If someone is using the line discipline functions that should trigger a > warning that the function prototype doesn't match. I think that an extra > parameter in a function pointer is just ignored otherwise. At least I > don't know of a case where it would have an effect. Please correct me if > I'm wrong. > Yes, it should just be a warning. There should be clear guidance about it in the release note. > Best regards > > Christian > > > > >> Best regards > >> > >> Christian > >> > >> Am 27.01.22 um 13:25 schrieb Christian MAUDERER: > >>> Hello, > >>> > >>> again: What can I do to make the patches acceptable? > >>> > >>> Best regards > >>> > >>> Christian > >>> > >>> Am 21.01.22 um 11:57 schrieb Christian MAUDERER: > Ping. > > Am 18.01.22 um 12:22 schrieb Christian MAUDERER: > > Hello, > > > > I noted that I still have this patch set open. I first posted it in > > August 2021 and later pinged it in September 2021. Both times no > > conclusion has been found. I would like to finally finish this topic > > and get the patches in an acceptable state. To simplify it a bit, > > let's only discuss the following two: > > > > * [PATCH rtems 2/2] termios: Pass number of sent chars to l_start > > https://lists.rtems.org/pipermail/devel/2021-August/068892.html > > > > * [PATCH rtems-libbsd] ppp: Fix transmitting data > > https://lists.rtems.org/pipermail/devel/2021-August/068893.html > > > > The third one (or rather first one) is a BSP specific optimization > > and not necessary for the other two. I'll not push that together with > > these two. I'll start a separate discussion for it as soon as we are > > done with these two. > > > > From my point of view, the best case would be to apply the patches > > to master and 5. Back when I started the discussion I created tickets > > for both: > > > > https://devel.rtems.org/ticket/4493 > > https://devel.rtems.org/ticket/4494 > > > > > > @Gedare: In the following mail thread you asked about tests on > > further BSPs: > > > > https://lists.rtems.org/pipermail/devel/2021-August/068908.html > > > > I now finally tested the patches on an i.MXRT BSP. PPP works with the > > patches and doesn't work without them on that target. That's what I > > expected. The patches are tested on three serial drivers now: > > > > - ATSAM and i.MXRT: Don't work without patches. Work with them. > > - SC16IS752: Works for small packets only without patches. Works well > > with them. > > > > > > @Chris: We had two open discussions: > > > > 1. A style topic: > > https://lists.rtems.org/pipermail/devel/2021-August/068912.html > > > > Like said there, I would prefer not to reformat the whole file as > > long as we don't do that at least a bit automatic for most files. > > > > 2. A discussion about the direction and the necessary API change: > > https://lists.rtems.org/pipermail/devel/2021-September/069468.html > > > > Like I explained: That PPP bug exists basically on all BSPs. > > Depending on how many bytes a serial driver can process in it's write > > function, PPP works better or worse. My assumption is that at the > > moment, the PPP runs only on BSPs where it is "well enough" that no > > one noted the bug. > > > > To fix that bug, the PPP needs the information how many characters > > have been sent out. My patch set uses our RTEMS default path via > > rtems_termios_dequeue_characters(). > > > > I'm not entirely happy that I had to change the API. But I didn't > > find a better solution and the API is still compatible. It will only >
Re: [PATCHES] Fix PPP in libbsd and optimize ATSAM console
Hello Gedare, Am 07.02.22 um 16:40 schrieb Gedare Bloom: On Wed, Feb 2, 2022 at 8:20 AM Christian MAUDERER wrote: Hello, I received no comments for these in the last two weeks. I assume there are no further objections and I can push the patches to master in about a week so that the bug is fixed at least for 6. Yeah, that's fine with me, thanks for getting it tested on another BSP, and for following up. Thanks for the response. If you can advise how the API change affects other BSPs on 5, I think that can be accepted with a proper release note/documentation of what those users may expect. There are two relevant changes in cpukit/include/rtems/termiostypes.h: 1. I added a field to the struct rtems_termios_tty. With that the binary interface changes. 2. I added a parameter to one of the line discipline functions. - int (*l_start)(struct rtems_termios_tty *tp); + int (*l_start)(struct rtems_termios_tty *tp,int len); If someone is using the line discipline functions that should trigger a warning that the function prototype doesn't match. I think that an extra parameter in a function pointer is just ignored otherwise. At least I don't know of a case where it would have an effect. Please correct me if I'm wrong. Best regards Christian Best regards Christian Am 27.01.22 um 13:25 schrieb Christian MAUDERER: Hello, again: What can I do to make the patches acceptable? Best regards Christian Am 21.01.22 um 11:57 schrieb Christian MAUDERER: Ping. Am 18.01.22 um 12:22 schrieb Christian MAUDERER: Hello, I noted that I still have this patch set open. I first posted it in August 2021 and later pinged it in September 2021. Both times no conclusion has been found. I would like to finally finish this topic and get the patches in an acceptable state. To simplify it a bit, let's only discuss the following two: * [PATCH rtems 2/2] termios: Pass number of sent chars to l_start https://lists.rtems.org/pipermail/devel/2021-August/068892.html * [PATCH rtems-libbsd] ppp: Fix transmitting data https://lists.rtems.org/pipermail/devel/2021-August/068893.html The third one (or rather first one) is a BSP specific optimization and not necessary for the other two. I'll not push that together with these two. I'll start a separate discussion for it as soon as we are done with these two. From my point of view, the best case would be to apply the patches to master and 5. Back when I started the discussion I created tickets for both: https://devel.rtems.org/ticket/4493 https://devel.rtems.org/ticket/4494 @Gedare: In the following mail thread you asked about tests on further BSPs: https://lists.rtems.org/pipermail/devel/2021-August/068908.html I now finally tested the patches on an i.MXRT BSP. PPP works with the patches and doesn't work without them on that target. That's what I expected. The patches are tested on three serial drivers now: - ATSAM and i.MXRT: Don't work without patches. Work with them. - SC16IS752: Works for small packets only without patches. Works well with them. @Chris: We had two open discussions: 1. A style topic: https://lists.rtems.org/pipermail/devel/2021-August/068912.html Like said there, I would prefer not to reformat the whole file as long as we don't do that at least a bit automatic for most files. 2. A discussion about the direction and the necessary API change: https://lists.rtems.org/pipermail/devel/2021-September/069468.html Like I explained: That PPP bug exists basically on all BSPs. Depending on how many bytes a serial driver can process in it's write function, PPP works better or worse. My assumption is that at the moment, the PPP runs only on BSPs where it is "well enough" that no one noted the bug. To fix that bug, the PPP needs the information how many characters have been sent out. My patch set uses our RTEMS default path via rtems_termios_dequeue_characters(). I'm not entirely happy that I had to change the API. But I didn't find a better solution and the API is still compatible. It will only trigger a warning if someone doesn't use that extra parameter. If you have a better idea how the bug could be fixed, I'm open to adapt the patches. But I need a suggestion what would be a better solution because - like I said - I didn't find one. Best regards Christian Am 12.08.21 um 13:41 schrieb Christian Mauderer: Hello, this set of patches fixes PPP. Basically the current implementation in libbsd can't work with console drivers that can't buffer a lot of characters. The pppstart() function just assumes that the low level console write can send an arbitrary number of characters without checking how many characters are actually send. In the extreme case of the ATSAM interfaces (only one character can be send at once) it's not even possible to establish a PPP connection with that. For UARTS that have some FIFO establishing might work but bigger packets won't go through. I opened tickets for 6 and 5 here:
Re: [PATCHES] Fix PPP in libbsd and optimize ATSAM console
On Wed, Feb 2, 2022 at 8:20 AM Christian MAUDERER wrote: > > Hello, > > I received no comments for these in the last two weeks. I assume there > are no further objections and I can push the patches to master in about > a week so that the bug is fixed at least for 6. > Yeah, that's fine with me, thanks for getting it tested on another BSP, and for following up. If you can advise how the API change affects other BSPs on 5, I think that can be accepted with a proper release note/documentation of what those users may expect. > Best regards > > Christian > > Am 27.01.22 um 13:25 schrieb Christian MAUDERER: > > Hello, > > > > again: What can I do to make the patches acceptable? > > > > Best regards > > > > Christian > > > > Am 21.01.22 um 11:57 schrieb Christian MAUDERER: > >> Ping. > >> > >> Am 18.01.22 um 12:22 schrieb Christian MAUDERER: > >>> Hello, > >>> > >>> I noted that I still have this patch set open. I first posted it in > >>> August 2021 and later pinged it in September 2021. Both times no > >>> conclusion has been found. I would like to finally finish this topic > >>> and get the patches in an acceptable state. To simplify it a bit, > >>> let's only discuss the following two: > >>> > >>> * [PATCH rtems 2/2] termios: Pass number of sent chars to l_start > >>>https://lists.rtems.org/pipermail/devel/2021-August/068892.html > >>> > >>> * [PATCH rtems-libbsd] ppp: Fix transmitting data > >>>https://lists.rtems.org/pipermail/devel/2021-August/068893.html > >>> > >>> The third one (or rather first one) is a BSP specific optimization > >>> and not necessary for the other two. I'll not push that together with > >>> these two. I'll start a separate discussion for it as soon as we are > >>> done with these two. > >>> > >>> From my point of view, the best case would be to apply the patches > >>> to master and 5. Back when I started the discussion I created tickets > >>> for both: > >>> > >>>https://devel.rtems.org/ticket/4493 > >>>https://devel.rtems.org/ticket/4494 > >>> > >>> > >>> @Gedare: In the following mail thread you asked about tests on > >>> further BSPs: > >>> > >>> https://lists.rtems.org/pipermail/devel/2021-August/068908.html > >>> > >>> I now finally tested the patches on an i.MXRT BSP. PPP works with the > >>> patches and doesn't work without them on that target. That's what I > >>> expected. The patches are tested on three serial drivers now: > >>> > >>> - ATSAM and i.MXRT: Don't work without patches. Work with them. > >>> - SC16IS752: Works for small packets only without patches. Works well > >>> with them. > >>> > >>> > >>> @Chris: We had two open discussions: > >>> > >>> 1. A style topic: > >>> https://lists.rtems.org/pipermail/devel/2021-August/068912.html > >>> > >>> Like said there, I would prefer not to reformat the whole file as > >>> long as we don't do that at least a bit automatic for most files. > >>> > >>> 2. A discussion about the direction and the necessary API change: > >>> https://lists.rtems.org/pipermail/devel/2021-September/069468.html > >>> > >>> Like I explained: That PPP bug exists basically on all BSPs. > >>> Depending on how many bytes a serial driver can process in it's write > >>> function, PPP works better or worse. My assumption is that at the > >>> moment, the PPP runs only on BSPs where it is "well enough" that no > >>> one noted the bug. > >>> > >>> To fix that bug, the PPP needs the information how many characters > >>> have been sent out. My patch set uses our RTEMS default path via > >>> rtems_termios_dequeue_characters(). > >>> > >>> I'm not entirely happy that I had to change the API. But I didn't > >>> find a better solution and the API is still compatible. It will only > >>> trigger a warning if someone doesn't use that extra parameter. If you > >>> have a better idea how the bug could be fixed, I'm open to adapt the > >>> patches. But I need a suggestion what would be a better solution > >>> because - like I said - I didn't find one. > >>> > >>> Best regards > >>> > >>> Christian > >>> > >>> Am 12.08.21 um 13:41 schrieb Christian Mauderer: > Hello, > > this set of patches fixes PPP. Basically the current implementation in > libbsd can't work with console drivers that can't buffer a lot of > characters. The pppstart() function just assumes that the low level > console write can send an arbitrary number of characters without > checking how many characters are actually send. > > In the extreme case of the ATSAM interfaces (only one character can be > send at once) it's not even possible to establish a PPP connection with > that. For UARTS that have some FIFO establishing might work but bigger > packets won't go through. I opened tickets for 6 and 5 here: > > https://devel.rtems.org/ticket/4493 > https://devel.rtems.org/ticket/4494 > > I would like to apply the patches to both branches (5 and 6). > > The solution I implemented in this patch set
Re: rtems-bsp-builder and rtems version
On Wed, Feb 2, 2022 at 11:41 PM Joel Sherrill wrote: > > Hi > > Did this get an option added to force the use of a specific RTEMS version? > You can set the version in rtems-tools by use of a VERSION file. See the comments in rtemstoolkit/version.py I don't know if it is tested for rtems-bsp-builder. > I have been building newlib master with all the build system changes > as 7 and was going to build all the BSPs with those tools but don't > see the magic. > > Help appreciated. > > Thanks. > > --joel > ___ > 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
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 good. There still some functions needed by PPS API which are in rtems-libbsd. So it is still required to set some pointers to function before running a synchronization using PPS. > The ntp_update_second() is called by _Timecounter_Windup() under protection > of the _Timecounter_Lock. I don't think we need the > extra ntp_lock. > > I will work on a patch which includes the current kern_ntptime.c to RTEMS. It > should be ready by end of next week. > > Do you have plans to enable the PPS_SYNC option? > Yes. Actually, I have something working. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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. The ntp_update_second() is called by _Timecounter_Windup() under protection of the _Timecounter_Lock. I don't think we need the extra ntp_lock. I will work on a patch which includes the current kern_ntptime.c to RTEMS. It should be ready by end of next week. Do you have plans to enable the PPS_SYNC option? -- 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: [rtems-libbsd commit] sys/kern: Add VFS support
Hello Chris,
sorry, this slipped through may review list.
On 02/09/2021 04:43, Chris Johns wrote:
@@ -1232,9 +993,6 @@ osendmsg(struct thread *td, struct osendmsg_args *uap)
#endif
#endif /* __rtems__ */
-#ifdef __rtems__
-static
-#endif /* __rtems__ */
int
sys_sendmsg(struct thread *td, struct sendmsg_args *uap)
{
@@ -1257,35 +1015,7 @@ sys_sendmsg(struct thread *td, struct sendmsg_args *uap)
free(iov, M_IOV);
return (error);
}
-#ifdef __rtems__
-ssize_t
-sendmsg(int socket, const struct msghdr *message, int flags)
-{
- struct thread *td = rtems_bsd_get_curthread_or_null();
- struct sendmsg_args ua = {
- .s = socket,
- .msg = message,
- .flags = flags
- };
- int error;
-
- if (td != NULL) {
- error = sys_sendmsg(td, );
- } else {
- error = ENOMEM;
- }
-
- if (error == 0) {
- return td->td_retval[0];
- } else {
- rtems_set_errno_and_return_minus_one(error);
- }
-}
-#endif /* __rtems__ */
Why did you move all these system call implementations for RTEMS into a
separate file? The sys_sendmsg() was a static function so the compiler
was able to optimize the use of struct sendmsg_args away and there was
no function call overhead. In the successful case the return value was
determined by td->td_retval[0]. I don't think this now the case?
ssize_t
sendmsg(int socket, const struct msghdr *message, int flags)
{
struct thread *td = rtems_bsd_get_curthread_or_null();
struct sendmsg_args ua;
int ffd;
int error;
if (RTEMS_BSD_SYSCALL_TRACE) {
printf("bsd: sys: sendmsg: %d\n", socket);
}
if (td == NULL) {
return rtems_bsd_error_to_status_and_errno(ENOMEM);
}
ffd = rtems_bsd_libio_iop_hold(socket, NULL);
if (ffd < 0) {
return rtems_bsd_error_to_status_and_errno(EBADF);
}
ua.s = ffd;
ua.msg = message;
ua.flags = flags;
error = sys_sendmsg(td, );
rtems_bsd_libio_iop_drop(socket);
return rtems_bsd_error_to_status_and_errno(error);
}
Unfortunately syscalls01 only tests error conditions and not a good case.
It seems that the commit is not present in the master branch. This means
all the work will be lost when we update to a newer FreeBSD baseline.
--
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
i2c initialization MVME3100
in bsps/powerpc/mvme3100/start/bspstart.c I can find
RTEMS_SYSINIT_ITEM{
mvme3100_i2c_initialize,
RTEMS_SYSINIT_BSP_PRE_DRIVERS,
RTEMS_SYSINIT_ORDER_MIDDLE
);
mvme3100_i2c_initialize calls BSP_i2c_initialize
This can be found in bsps/powerpc/mvme3100/i2c/i2c_init.c
This function calls rtems_libi2c_initialize() from cpukit/libi2c/libi2c.c
and here rtems_io_register_driver gets called:
sc = rtems_io_register_driver (0, _libi2c_io_ops, _libi2c_major);
But in cpukit/sapi/src/ioregisterdriver.c
in rtems_io_register_driver () the call of the associated init routine gets
postponed to
a later stage because _IO_All_drivers_initializes is not true in this early of
bspstart.
so
} else {
/* The driver will be initialized together with all other drivers
* in a later stage by _IO_Initialize_all_drivers();
*/
return RTEMS_SUCCESSFUL;
}
Now in
bsps/powerpc/mvme3100/i2c/i2c_init.c
the following calls e.g.
busno=rtems_libi2c_register_bus(
BSP_I2C_BUS0_NAME,
…
must fail?
I hope I have analysed this correctly. I may be wrong, but the output of the
mvme3100 looks like this:
Registering mpc8540 i2c bus driver :No such file or directory
Registering /dev/console as minor 0 (==/dev/ttyS0)
ds1375_probe (open): No such file or directory
This happens during initialization in EPICS. The test suite programmes do not
produce this output.
In the test programmes, however, the initialisation probably fails because the
MAXIMUM_DRIVER is default 4.
e.g. TEST I2C 1
libi2c: Claiming driver slot failed (rtems status code 10)
Initializing I2C library failed
Danke Heinz
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: AW: [PATCH 4/4] kern_ntptime: sys_ntp_adjtime() does not return error when modes is 0 or MOD_TAI
On 04/02/2022 09:12, gabriel.moy...@dlr.de wrote: 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 is retval, is saved in td->td_retval[0]. Chris modified this, being retval saved in the variable error, which is the one returned by sys_ntp_adjtime(). In libbsd, copyout() is just a memcpy() which returns 0. Under some situations, ntp_adjtime() is called with modes = 0 just for retrieving some values (for example herehttps://github.com/ptpd/ptpd/blob/master/src/dep/sys.c#L2036, please notice that here adjtimex() is ntp_adjtime()). In those cases, returning retval may not be meaningful. Other similar situation happens when mode is MOD_TAI (https://github.com/ptpd/ptpd/blob/master/src/dep/sys.c#L2070). This is more or less the reason. If there is better way to solve this, is welcome. I don't think the changes make sense. The td->td_retval[0] is the return value of the system call if it is successful. The "error" indicates if the system call was successful (== 0), otherwise it returns -1 with errno set to "error". -- 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
