Re: [PATCH rtems-libbsd] Import telnetd from RTEMS repository
On 09/04/2021 08:36, Chris Johns wrote: On 9/4/21 1:31 am, Gedare Bloom wrote: On Thu, Apr 8, 2021 at 2:18 AM Sebastian Huber I would keep the services in rtems.git and add APIs for the things which depend on RTEMS_NETWORKING. Then implement the API in the network stacks. It is not that much: Sebastian, I am sceptical this is possible for all but simplest networking services. As a test if PTPv2 can be made to build and work this way then I am happy to be convinced otherwise. Hint, it needs signals for the legacy stack and kqueue for libbsd. tftpfs, ftpfs, ftpd, telnetd, and libdebugger are simple networking services. PTPv2 is probably a separate package anyway. -- 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: Questions about waf config system: "grp" and updating configure.ac
On 09/04/2021 08:28, Chris Johns wrote: On 9/4/21 3:02 pm, Sebastian Huber wrote: I try to not break the old build system, however, I don't add new stuff to it. From my point of view the old build system should be removed. The major blocking point for the removal is that nobody had the time to convert the BSP builder to use the new build system. It looks like recent changes have broken the autotool build system... https://lists.rtems.org/pipermail/build/2021-April/027232.html Is there any point in it staying if it does not work? This failure is due to an out dated tool chain used by the build bot. I think only powerpc is broken due to the start/end file changes in GCC. -- 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 rtems-libbsd] Import telnetd from RTEMS repository
On 9/4/21 1:31 am, Gedare Bloom wrote: > On Thu, Apr 8, 2021 at 2:18 AM Sebastian Huber >> I would keep the services in rtems.git and add APIs for the things which >> depend on RTEMS_NETWORKING. Then implement the API in the network >> stacks. It is not that much: Sebastian, I am sceptical this is possible for all but simplest networking services. As a test if PTPv2 can be made to build and work this way then I am happy to be convinced otherwise. Hint, it needs signals for the legacy stack and kqueue for libbsd. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Questions about waf config system: "grp" and updating configure.ac
On 9/4/21 3:02 pm, Sebastian Huber wrote: > I try to not break the old build system, however, I don't add new stuff to it. > From my point of view the old build system should be removed. The major > blocking > point for the removal is that nobody had the time to convert the BSP builder > to > use the new build system. It looks like recent changes have broken the autotool build system... https://lists.rtems.org/pipermail/build/2021-April/027232.html Is there any point in it staying if it does not work? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Questions about waf config system: "grp" and updating configure.ac
Hello Peter,
On 08/04/2021 20:58, Peter Dufault wrote:
I wanted to fix default console baud rate handling in "powerpc/beatnik" (and
thus in anything using powerpc/shared/console). I believe:
- The bsps (at least the "motload" ones) start up with the baud rate set by
"motload" and some of the RTEMS tests actually work, that is, the baud rate must never be
set.
- The default console baud rate is hard-wired to 9600 in
powerpc/shared/{console.c,uart.c};
- If you change the hard-wiring to e.g. 115200 the baud rate gets set back to 9600 if you
use "termios" (in the first-open function the o_speed is still 9600).
I fixed these items and figured how to configure the baud rate using "waf" with
the BSP_CONSOLE_BAUD option but have questions:
1. I changed all the "spec/build/bsps/powerpc/foo/bspfoo.yml" files (for bsp
"foo", the ones that use powerpc/shared/{console.c,uart.c}) to add:
- role: build-dependency
- uid: ../../optconsolebaud
if a BSP has more than one bsp*.yml file (and thus a grp.yml file), it
should be added to the grp.yml file, see also:
https://docs.rtems.org/branches/master/eng/build-system.html#build-specification-items
2. I changed "spec/build/bsps/optconsolebaud.yml" to default those BSPs to 9600
(to retain current behavior):
- value: 9600
variants:
- m68k/m5484FireEngine
- powerpc/hsc_cm01
- powerpc/beatnik
- powerpc/haleakala
- powerpc/motorola_powerpc
- powerpc/mvme3100
- powerpc/mvme5500
Ok.
3. I changed the associated "configure.ac" for those BSPS to add:
RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
[default console baud])
I try to not break the old build system, however, I don't add new stuff
to it. From my point of view the old build system should be removed. The
major blocking point for the removal is that nobody had the time to
convert the BSP builder to use the new build system.
--
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: #3860 - GSoC enquiries
Hello All, Just a gentle reminder to please help me review this my proposal draft and help me with ways to make it better :) https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing Cheers, Ida On Thu, 8 Apr 2021, 6:51 am Ida Delphine, wrote: > Hello everyone, > Here is the link to my GSoC proposal. Will love if you leave comments on > ways I could make it better or any corrections (Especially the *Proposesd > Schedule* section so that I will be sure about my project deliverables > when inputting them). > > https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing > I will also love to know about any future improvements to this project. > > Cheers, > Ida. > > On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom wrote: > >> On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine wrote: >> > >> > Hello, >> > >> > In case I succeed with this project will I be required to do some >> documentation on how it works? >> > >> Yes, in general we expect students to produce documentation while they >> work on also creating code. >> >> I think the direction we're heading right now is toward using >> clang-format, perhaps with an update to a common coding style. In this >> case, we solve our problem by policy rather than technical solution, >> and your work should focus on tool integration and automation without >> concern about the coding style itself. >> >> > >> > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber < >> sebastian.hu...@embedded-brains.de> wrote: >> >> >> >> On 07/04/2021 09:03, Chris Johns wrote: >> >> >> >> > Would it be pragmatic to review these cases and change the standard? >> >> >> >> I sent a patch to review the format changes done by clang-format >> recently: >> >> >> >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html >> >> >> >> It doesn't look that bad from my point of view. Fixing the alignment >> >> issue would make it even better: >> >> >> >> https://reviews.llvm.org/D27651 >> >> >> >> > >> >> > I understand the long history but as you point out we either invest >> in the tools >> >> > to support the format, we change what we have or we manage it >> manually. >> >> I would prefer to change the style and use a widely used formatting >> >> tool. I think we spend to much time on the coding style in reviews. >> This >> >> is quite bad since we are all busy with all sorts of things and our >> time >> >> is better spent on more important tasks. A consistently formatted >> source >> >> code is very important, but enforcing this style manually is a waste of >> >> time. >> >> >> >> -- >> >> 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 >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Questions about waf config system: "grp" and updating configure.ac
I wanted to fix default console baud rate handling in "powerpc/beatnik" (and
thus in anything using powerpc/shared/console). I believe:
- The bsps (at least the "motload" ones) start up with the baud rate set by
"motload" and some of the RTEMS tests actually work, that is, the baud rate
must never be set.
- The default console baud rate is hard-wired to 9600 in
powerpc/shared/{console.c,uart.c};
- If you change the hard-wiring to e.g. 115200 the baud rate gets set back to
9600 if you use "termios" (in the first-open function the o_speed is still
9600).
I fixed these items and figured how to configure the baud rate using "waf" with
the BSP_CONSOLE_BAUD option but have questions:
1. I changed all the "spec/build/bsps/powerpc/foo/bspfoo.yml" files (for bsp
"foo", the ones that use powerpc/shared/{console.c,uart.c}) to add:
- role: build-dependency
- uid: ../../optconsolebaud
2. I changed "spec/build/bsps/optconsolebaud.yml" to default those BSPs to 9600
(to retain current behavior):
- value: 9600
variants:
- m68k/m5484FireEngine
- powerpc/hsc_cm01
- powerpc/beatnik
- powerpc/haleakala
- powerpc/motorola_powerpc
- powerpc/mvme3100
- powerpc/mvme5500
3. I changed the associated "configure.ac" for those BSPS to add:
RTEMS_BSPOPTS_SET([BSP_CONSOLE_BAUD],[*],[9600])
RTEMS_BSPOPTS_HELP([BSP_CONSOLE_BAUD],
[default console baud])
Questions:
1. Does this look about right?
2. I don't quite understand what "grp" does. Is there a way to create a group
for the above BSPS that use powerpc/shared/console to simplify the changes I
made? Or more likely going forward, to treat them more like a group since they
share a lot of code that should be cleaned up.
3. Is it correct to update the "configure.ac" files when new options are added
or are those now considered defunct?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] coverage/symbol-sets.ini : Add libuuid
--- tester/rtems/testing/coverage/symbol-sets.ini | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tester/rtems/testing/coverage/symbol-sets.ini b/tester/rtems/testing/coverage/symbol-sets.ini index 52e25ff..b2e0e5d 100644 --- a/tester/rtems/testing/coverage/symbol-sets.ini +++ b/tester/rtems/testing/coverage/symbol-sets.ini @@ -29,7 +29,7 @@ # [symbol-sets] -sets = score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace +sets = score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libuuid,libblock,libcrypt,libmd,libstdthreads,libtrace [libraries] score = @BUILD-TARGET@/@BSP@/cpukit/score/src @@ -67,7 +67,7 @@ libdumpbuf= @BUILD-TARGET@/@BSP@/cpukit/libmisc/dumpbuf #libtestsupport= @BUILD-TARGET@/@BSP@/cpukit/libmisc libuntar = @BUILD-TARGET@/@BSP@/cpukit/libmisc/untar #libutf8proc = @BUILD-TARGET@/@BSP@/cpukit/libmisc -#libuuid = @BUILD-TARGET@/@BSP@/cpukit/libmisc +libuuid = @BUILD-TARGET@/@BSP@/cpukit/libmisc/uuid #libxz = @BUILD-TARGET@/@BSP@/cpukit/libmisc libblock = @BUILD-TARGET@/@BSP@/cpukit/libblock/src #libpci= @BUILD-TARGET@/@BSP@/cpukit/libpci -- 2.27.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] Import telnetd from RTEMS repository
On Thu, Apr 8, 2021 at 2:18 AM Sebastian Huber wrote: > > On 08/04/2021 08:09, Gedare Bloom wrote: > > > On Wed, Apr 7, 2021 at 11:10 PM Sebastian Huber > > wrote: > >> On 08/04/2021 03:17, Vijay Kumar Banerjee wrote: > >> > >>> On Mon, Apr 5, 2021 at 3:48 PM Gedare Bloom wrote: > push this if no one complains by Wednesday > > I think we should keep this telnetd and the legacy one in sync for > now, and consider them as a good candidate for a new > 'rtems-net-services' repository. > > >>> Thanks. Pushed. > >> Sorry for being late, but why was this added to libbsd? Most parts of > >> the telnetd are network stack independent, see also: > >> > >> https://devel.rtems.org/ticket/3419 > >> > >> One reason to have the socket API in Newlib was to be able to write > >> network stack independent software. If this code is now duplicated, then > >> this is a step backwards. > >> > > Yes, this is probably an intermediate step. I have asked Vijay to look > > at the idea of creating a repo for these network services. > > Unfortunately, there were a few lines of code in the telnetd that > > seemed to be enabled only for the legacy stack, so it seems the > > telnetd isn't totally stack independent. In case some minor adaptation > > seems to be necessary based on the network stack, and we can't know > > what that stack will be for sure at RTEMS build time since we > > eliminated those configuration options. So, it doesn't make sense to > > keep these network services in rtems.git, without having a network > > stack? > It makes no sense to remove these services from rtems.git from my point > of view. The tftpfs, ftpfs, ftpd, telnetd, and libdebugger services > depend only on the socket API with some minor exceptions which are easy > to abstract. > > > > I anticipate that we will attempt to migrate and merge the network > > services, starting with telnetd, into a new repo that can be built > > after the user selects their network stack. Our first priority is to > > get things separated from rtems.git, and to get an lwip stack up in > > parallel. Then, we would like to see how well the telnetd code base > > can work with lwIP. Probably, we will get this done in the summer. > > > > Other ideas are welcomed. > > I would keep the services in rtems.git and add APIs for the things which > depend on RTEMS_NETWORKING. Then implement the API in the network > stacks. It is not that much: > OK, this seems like a fine idea. We'll get a proposal for API together shortly. For telnetd I think it requires some way to define the network task priority, or perhaps to obtain the network task id so that then its priority can be obtained from usual rtems APIs. > grep -r RTEMS_NETWORKING --include='*.[ch]' cpukit/ > cpukit/ftpd/ftpd.c:#ifndef RTEMS_NETWORKING > cpukit/libtest/testbeginend.c:#if RTEMS_NETWORKING > cpukit/libtest/testbeginend.c:" RTEMS_NETWORKING" > cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING > cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING > cpukit/include/rtems/shellconfig.h:#if RTEMS_NETWORKING > cpukit/include/rtems/shellconfig.h:#if RTEMS_NETWORKING > cpukit/include/rtems/monitor.h:#if defined(RTEMS_NETWORKING) > cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING > cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING > cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING > cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING > cpukit/libmisc/dummy/dummy-networking.c:#if defined(RTEMS_NETWORKING) > > -- > 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
[PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow
From: Frank Kühndel
This patch fixes issue #4338 by changing _TOD_Validate()
to only accept years till 2105. This requires another patch
to change the documentation of rtems_clock_set() and other
affected API functions (indicating the end date is 2105 not 2514).
I tried to support till year 2514 but it turned out that
this needs changing the Timer Manager too. That in turn
would mean to change _TOD_Seconds_since_epoch( void )
from 32 to 64 bit. Sebastian pointed out that a naive extension
leads to trouble with 32 bit processors. He deemed a safe
re-implementation too costly performance wise considering
that year 2106 is far away and current binaries using RTEMS
Classic API are unlikely to be in use by 2106.
The constant TOD_SECONDS_AT_2100_03_01_00_00 in
cpukit/rtems/src/clocktodtoseconds.c happens to be wrong by
1 hour. When setting the date 2100-Feb-28 23:59:59 and then
reading the date again you will find yourself in 2100-Feb-27.
Original Bug #4338 Text:
== Short Problem Description ==
[https://docs.rtems.org/branches/master/c-user/clock/directives.html
> RTEMS can represent time points of this clock in nanoseconds
> ranging from 1988-01-01T00:00:00.0Z to
> 2514-05-31T01:53:03.9Z.
* Yet, years larger than roughly 2105 to 2110 cannot be set
(or at least the date should be wrong but this never
occured in my tests).
> The possible RETURN VALUES are RTEMS_SUCCESSFUL,
> RTEMS_INVALID_ADDRESS, RTEMS_INVALID_CLOCK
* Yet, rtems_clock_set() can return status RTEMS_INVALID_NUMBER,
too. (Only for such dates in the far future.)
== How To Replicate? ==
Call rtems_clock_set() with this time_of-day:
{
year = 2514,
month = 5,
day = 31,
hour = 1,
minute = 53,
second = 3,
ticks = 995
}
The return value will be RTEMS_INVALID_NUMBER.
== Bugs in _TOD_To_seconds() ==
cpukit/rtems/src/clockset.c: rtems_clock_set() calls
* cpukit/rtems/src/clocktodvalidate.c: _TOD_Validate() and
* cpukit/rtems/src/clocktodtoseconds.c: _TOD_To_seconds() and
* cpukit/score/src/coretodset.c: _TOD_Set()
First issue:
_TOD_To_seconds() converts the time_of_day structure into
seconds using a variable `time` of type `uint32_t`. This simply
overflows when in comes close to year 2110.
Debugger output at the end of _TOD_To_seconds():
(gdb) print the_tod->year
$16 = 2104
(gdb) print time
$17 = 4233686400
with a higher year:
(gdb) print the_tod->year
$28 = 2514
(gdb) print *the_tod
$31 = {
year = 2514,
month = 5,
day = 31,
hour = 1,
minute = 53,
second = 3,
ticks = 995
}
(gdb) print time
$29 = 192272
Second issue:
_TOD_To_seconds() can (most likely) not handle the leap year
issues of the years 2200, 2300, 2400, 2500 because it has
dedicated code for the 2100 case only:
/* The year 2100 is not a leap year */
if ( time
>= (TOD_SECONDS_AT_2100_03_01_00_00 -
TOD_SECONDS_1970_THROUGH_1988)) {
time -= TOD_SECONDS_PER_DAY;
}
== _TOD_Check_time_of_day_and_run_hooks() causes STATUS_INVALID_NUMBER ==
cpukit/score/src/coretodset.c: _TOD_Set() calls
* cpukit/score/src/coretodset.c:
_TOD_Check_time_of_day_and_run_hooks()
in this code snippet (note `return status`):
status = _TOD_Check_time_of_day_and_run_hooks( tod );
if ( status != STATUS_SUCCESSFUL ) {
_TOD_Release( lock_context );
return status;
}
_TOD_Check_time_of_day_and_run_hooks( tod ) can return status
STATUS_INVALID_NUMBER which is not documented for
rtems_clock_set(). The small time in seconds value 192272 from
the integer overrun discussed above triggers the middle `if`
clause:
static Status_Control _TOD_Check_time_of_day_and_run_hooks(
const struct timespec *tod
)
{
if ( !_Watchdog_Is_valid_timespec( tod ) ) {
return STATUS_INVALID_NUMBER;
}
if ( tod->tv_sec < TOD_SECONDS_1970_THROUGH_1988 ) {
return STATUS_INVALID_NUMBER;
}
if ( _Watchdog_Is_far_future_timespec( tod ) ) {
return STATUS_INVALID_NUMBER;
}
return _TOD_Hook_Run( TOD_ACTION_SET_CLOCK, tod );
}
== Final Notes ==
* I found #2665 and #2548 but I do not say these are relevant here.
* `#define WATCHDOG_MAX_SECONDS 0x3` in
cpukit/include/rtems/score/watchdogimpl.h covers 17179869183
seconds which are some 544 years
* _TOD_Check_time_of_day_and_run_hooks() seems to be only used by
_TOD_Set() but _TOD_Set() has three users.
* I did not check whether the invers conversation
(rtems_clock_get_tod())
works for dates which are centuries in the future.
Update #4338
---
cpukit/include/rtems/score/todimpl.h | 16
cpukit/rtems/src/clocktodtoseconds.c | 2 +-
cpukit/rtems/src/clocktodvalidate.c | 1 +
testsuites/sptests/sp2038/init.c | 28 ++--
4 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/cpukit/include/rtems/score/todimpl.h
b/cpukit/include/rtems/score/todimpl.h
index 9805ec
Fwd: GCC 10.3 Released
Is it time to bump the RSB GCC version for rtems6? -- Forwarded message - From: Richard Biener Date: Thu, Apr 8, 2021 at 7:30 AM Subject: GCC 10.3 Released To: , , The GNU Compiler Collection version 10.3 has been released. GCC 10.3 is a bug-fix release from the GCC 10 branch containing important fixes for regressions and serious bugs in GCC 10.2 with more than 178 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [libbsd] How to install machine header files?
On 08/04/2021 13:35, jan.som...@dlr.de wrote: @Sebastian: Do you have a suggestion how I could resolve this? I think you have the most experience with the libbsd build system. Sorry, I don't have an off hand solution for this. -- 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: [libbsd] How to install machine header files?
@Sebastian: Do you have a suggestion how I could resolve this? I think you have the most experience with the libbsd build system. Best regards, Jan > -Original Message- > From: devel On Behalf Of jan.som...@dlr.de > Sent: Thursday, April 1, 2021 11:59 AM > To: chr...@rtems.org; devel@rtems.org > Subject: RE: [libbsd] How to install machine header files? > > > -Original Message- > > From: Chris Johns > > Sent: Thursday, April 1, 2021 6:25 AM > > To: Sommer, Jan ; devel@rtems.org > > Subject: Re: [libbsd] How to install machine header files? > > > > On 1/4/21 6:37 am, jan.som...@dlr.de wrote: > > > Hello, > > > > > > I stumbled upon some include path problems in libbsd while looking > > > at > > Chris' ptpd port and I am not sure what is the recommended way to solve > it. > > > It starts with "freebsd/sys/sys/bus.h" including "machine/_bus.h". > > > Currently, this will be the one from within "rtemsbd" which will > > > redirect to > > "rtemsbsd/include/machine/bus.h" which is amd64 specific. > > > For the pc686 BSP this will create a compile error for applications > > > which > > include "". > > > > OK. > > > > > I tried to solve it by removing the "_bus.h" in rtemsbsd and > > > installing the > > correct one from "freebsd/sys/i386/include/machine/_bus.h", but I am > > not sure how to tell waf to install the file. > > > Is there a way to add a single architecture specific header to the > > > install > > headers? > > > > Yes > > > > https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n111 > > https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n2903 > > > > > I could add a corresponding path and wildcard to the "header-paths" > > > in > > libbsd.py, but I am not sure if this is the right place. > > > > I think the PCI module is the place to handle this. I am sorry but I > > cannot see the issue clear at the moment and I cannot invest time > performing a build. > > > > Thank you for taking a look at it. > The main problem is, that the header files added there are not copied to the > prefix with "waf install". > To me it looks like only the files matched with header-paths > (https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n123) are installed. > I checked today with the pc686 and zedboard builds and the header files > which end up in PREFIX/lib/include/machine are only the ones from within > the rtemsbsd directory and none from the > freebsd/sys/$ARCH/include/machine. > > > The addCPUDependentFreeBSDHeaderFiles() on line 2931 of libbsd.py in > > the PCI module looks a little suspect because there is no list of archs > provided. > > Could the issue be as simple as the list of archs is not there and the > > list is empty? > > > > It looks like only some of the add* functions take an archs list. > addCPUDependentFreeBSDHeaderFiles() only takes the header file list. > I dug around in the waf_libbsd.py, but I couldn't figure out what happens to > the header files added by this function. > > Best regards, > > Jan > > > Chris > ___ > 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: [PATCH rtems-libbsd] Import telnetd from RTEMS repository
On 08/04/2021 08:09, Gedare Bloom wrote: On Wed, Apr 7, 2021 at 11:10 PM Sebastian Huber wrote: On 08/04/2021 03:17, Vijay Kumar Banerjee wrote: On Mon, Apr 5, 2021 at 3:48 PM Gedare Bloom wrote: push this if no one complains by Wednesday I think we should keep this telnetd and the legacy one in sync for now, and consider them as a good candidate for a new 'rtems-net-services' repository. Thanks. Pushed. Sorry for being late, but why was this added to libbsd? Most parts of the telnetd are network stack independent, see also: https://devel.rtems.org/ticket/3419 One reason to have the socket API in Newlib was to be able to write network stack independent software. If this code is now duplicated, then this is a step backwards. Yes, this is probably an intermediate step. I have asked Vijay to look at the idea of creating a repo for these network services. Unfortunately, there were a few lines of code in the telnetd that seemed to be enabled only for the legacy stack, so it seems the telnetd isn't totally stack independent. In case some minor adaptation seems to be necessary based on the network stack, and we can't know what that stack will be for sure at RTEMS build time since we eliminated those configuration options. So, it doesn't make sense to keep these network services in rtems.git, without having a network stack? It makes no sense to remove these services from rtems.git from my point of view. The tftpfs, ftpfs, ftpd, telnetd, and libdebugger services depend only on the socket API with some minor exceptions which are easy to abstract. I anticipate that we will attempt to migrate and merge the network services, starting with telnetd, into a new repo that can be built after the user selects their network stack. Our first priority is to get things separated from rtems.git, and to get an lwip stack up in parallel. Then, we would like to see how well the telnetd code base can work with lwIP. Probably, we will get this done in the summer. Other ideas are welcomed. I would keep the services in rtems.git and add APIs for the things which depend on RTEMS_NETWORKING. Then implement the API in the network stacks. It is not that much: grep -r RTEMS_NETWORKING --include='*.[ch]' cpukit/ cpukit/ftpd/ftpd.c:#ifndef RTEMS_NETWORKING cpukit/libtest/testbeginend.c:#if RTEMS_NETWORKING cpukit/libtest/testbeginend.c: " RTEMS_NETWORKING" cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING cpukit/include/rtems/shellconfig.h:#if RTEMS_NETWORKING cpukit/include/rtems/shellconfig.h: #if RTEMS_NETWORKING cpukit/include/rtems/monitor.h:#if defined(RTEMS_NETWORKING) cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING cpukit/libmisc/dummy/dummy-networking.c:#if defined(RTEMS_NETWORKING) -- 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: libbsd: Backport fd_set size fixes for racoon and ping6 to 5
On 29/03/2021 16:57, Gedare Bloom wrote: On Mon, Mar 29, 2021 at 8:47 AM Christian MAUDERER wrote: Hello Gedare, Am 29.03.21 um 16:40 schrieb Gedare Bloom: On Mon, Mar 29, 2021 at 1:31 AM Christian MAUDERER wrote: Hello Gedare, Am 26.03.21 um 16:03 schrieb Gedare Bloom: seems fine to me. Thanks. I just wanted to push the patches and noted that there haven't been any changes to the 5 branch of libbsd since the release. But there have been some fixes on the 5-freebsd-12 branch. Did I miss something and the 5 branch shouldn't be updated with fixes? Or have the fixes just not been applied to 5? I don't use libbsd enough to remember what is the agreed-upon protocol for its branches. I recall there is some confusing parts about how some branches track freebsd's head, while others track some freebsd branches. I guess, when we release a version of rtems, we need to freeze on a commit/point of freebsd? Basically there is the master (or 5) branch which tracks FreeBSD master and the *-freebsd-12 branch which tracks the FreeBSD stable release. I would suggest everyone who want's to use libbsd in a productive environment to use the *-freebsd-12. But I'm not sure what our post-release-policy for the branches is. From the current commits on the branches it seems to be: Don't touch 5 and only fix stuff on 5-freebsd-12. But I'm still not sure. If we don't have a policy, then we should define one. My inclination here is that we should either abandon the 5/ tracking the upstream master after a release. Possibly, we should name the recommended version to use with rtems5 as 5/ though, to make life a bit more consistent across our repos. I would delete the "5" branch. It makes no sense to track the FreeBSD head on an RTEMS release branch. -- 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: GSOC project: #4272 BSP Executable Conversion
Sir I have made a draft for the project https://devel.rtems.org/ticket/4272 after some discussion about it on discord and mail-list . I would be highly grateful to get some comments and reviews about it in improving the draft (for example the part related to adding support of newly created scripts in rtems-tools to rtems-test.) https://docs.google.com/document/d/19HeKc6W2ng2X8PoCMVi68A1Z1BbO5D7C0xVHhkgMgBY/edit?usp=sharing . Also since I am little new to this project it will be really helpful if anyone can please point out any basic errors which I may have made in the project description. On Tue, Apr 6, 2021 at 10:30 PM Joel Sherrill wrote: > > > > On Tue, Apr 6, 2021 at 6:22 AM Ayushman Mishra > wrote: >> >> I checked all the BSPs having bsp-post-link in their config file (find >> . -name *.cfg | xargs -e grep define | grep bsp-post-link) but >> couldn't find similarity between them (other than "$(OBJCOPY) -O >> binary --strip-all \ $(basename $@)$(EXEEXT) $(basename $@)$(BINEXT) " >> in most of them . Sir I wanted to know is there any specific way to >> categorize them from other BSPs, And I am not able to find similar set >> of commands in rtems 4.11 (since in project description >> "https://devel.rtems.org/ticket/4272"; its written that post-link was >> active in earlier versions of rtems). > > > In 4.11, these were under c/src/lib/libbsp. There was a source reorganization > between 4.11 and 5 to ease the transition to waf. This command finds the > same set of bsp-post-link definitions once you are on the 4.11 branch. > > find c/src/lib/libbsp -name "*.cfg" | xargs -e grep post- > > I mentioned there was a few patterns of what these do. mrm332.cfg > is creating an S-Record image to download. mvme2100.cfg is creating > a compressed binary with a program prepended that decompresses it > and jumps to it. > > I'd suggest using Google Sheets to capture a list of every BSP with > a bsp-post-link stanza and a second column to categorize them based > on the output format. You and I have talked about the compressed > binary with header, S-Records, and mkimage for U-Boot. I would > expect that without those types, you will find similarities and a set > of repeating things that get tailored from BSP to BSP. > > Compare two that have the same output format. The S-Record > output ones should be easy to compare. > >> >> Also I have started making a draft on this project and wanted to know >> where I should post it to get some initial reviews on it. > > > This is pressing as is getting an application and draft filed with Google. > > --joel > >> >> Thanks, Ayushman >> >> On Mon, Apr 5, 2021 at 9:35 AM Ayushman Mishra >> wrote: >> > >> > Boot-loader is used to initialize the hardware device , but is there >> > any way to simulate the boot-loader without hardware?. >> > And I suppose the command "rtems-boot-image" performs somewhat similar >> > function to one of the objective of this project "This project is >> > about capturing the commands and logic needed to convert the RTEMS >> > executable format to the BSP boot loader format" ( 3rd point of "The >> > boot image tool can:" >> > https://docs.rtems.org/branches/master/user/tools/boot-image.html) >> > >> > Also I think potential mentors of this project are Chris Johns and >> > Joel Sherrill , please correct me if I'm wrong. >> > >> > On Sun, Apr 4, 2021 at 10:27 PM Ayushman Mishra >> > wrote: >> > > >> > > Respected Sir, >> > > I went through project description https://devel.rtems.org/ticket/4272 >> > > (BSP Executable Conversion) and wanted to take it as GSOC project. >> > > I know python programming ,shell scripting and after working a little >> > > bit on project #4334 "Replace Mongoose with Civetweb" (in which I am >> > > not able to proceed further) I have gained some knowledge about bsp >> > > build system in rtems6. >> > > I have already build tools and bsp xilinx_zynq_a9_qemu on rtems5 and >> > > rtems6 and package libbsd for bsp erc32 and xilinx_zynq_a9_qemu. >> > > >> > > Also, I have a few doubts regarding project "BSP Executable Conversion" : >> > > 1. In description its written to make a command "rtems-exe-convert" , >> > > I wanted to ask what will be the actual function of this command like >> > > after capturing the commands and logic for converting 'RTEMS >> > > executable format' will it create a boot-loader for specific bsp and >> > > provide it with 'RTEMS executable format' ?, >> > > and also I wanted to ask what is need for this command (or this >> > > project in general) and how will it affect the present building >> > > procedure of rtems? >> > > (like first building the specific tools then installing the particular >> > > bsp) >> > > >> > > 2. I have build 2 BSP in simulation but wanted to ask are all BSPs >> > > available in rtems able to perfectly build in simulation or do I need >> > > some specific hardware for any BSP. >> > > I would be very thankful if you can please clarify my above doubts and >> > > provide a little guidanc
About Strong APA scheduler
Hi, The ticket 2510 (https://devel.rtems.org/ticket/2510) which is about the Strong APA scheduler is going to be closed very soon! We are giving a few touches to the code tests before we submit the final patch. The documentation of the scheduler is live at: https://richidubey.github.io/Strong-APA-Documentation/html/. I started working on this project as a part of GSoC 2020 and I could not have done any of this without the community's support. Thanks! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
