date:20210327

Re: #4328: New APIs added to POSIX Standard (2021)

2021-03-27 Thread Eshan Dhawan


> On 27-Mar-2021, at 1:49 AM, Matthew Joyce  wrote:
> 
> Hi Dr. Joel,
> 
> I finally built rtems-libbsd and see that pselect and sockatmark are
> both defined there. I went ahead and added a "In rtems-libbsd" column
> in the spreadsheet to reflect that.
> 
> With those two defined, it looks like the only methods from the FACE
> 3.0 General Purpose Profile that aren't currently supported are
> confstr() and the  set. Could I ask, what is the thinking on
> those? The man page suggests that spawn was created with embedded
> systems in mind, but I'd guess a conscious decision was made to leave
> them out? How about confstr?
> 
> Thank you!
> 
> Matt
> 
Hi Matt
Confstr code is ready just under styling issues. 
So maybe you could count it as Present. 

Thanks 
- Eshan 
> 
>> On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
>> 
>> 
>> 
>>> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  wrote:
>>> 
>>> Hi Dr. Joel,
>>> 
>>> Thanks very much, that's a big help!  Correct, I've been updating the
>>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
>>> in rtems/cpukit and implemented in Newlib.
>>> 
>>> One additional question, please: I haven't yet looked into the source
>>> of NetBSD or FreeBSD, but I do see that Newlib already implements
>>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
>>> sockatmark (net.cc). None of them are defined in the rtems environment
>>> yet. Is there any reason why the NetBSD/FreeBSD version would be
>>> preferable to Newlib for these? Or is it just a matter of testing
>>> what's out there to find what works well in the rtems environment?
>> 
>> 
>> Without looking at the newlib git repo, I can tell you that the files
>> you cite are the implementation of those methods for Cygwin. Just
>> because they are in C++. :)
>> 
>> The parts of the newlib repo RTEMS uses are under the newlib/
>> subdirectory not the cygwin one. Within that, there is a libc/sys and
>> only libc/sys/rtems is used for RTEMS. The others are for different
>> operating systems. There are a few places with "machine" directory
>> structures. Only the ones for the architecture you are building for
>> is used.
>> 
>> As to why NetBSD for libdl, that is because portions of the code
>> originated there.
>> 
>> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
>> source as we can keep it.
>> 
>>> 
>>> 
>>> In my proposal I'll take your advice and work on some of the easier
>>> ones first in order to get the experience and process down.
>> 
>> 
>> There are tickets for a lot of methods. The rtems-docs repo has the
>> csv file (e.g. spreadsheet) which tracks RTEMS support against
>> various standards. The RTEMS POSIX Compliance Guide is generated
>> from that csv file. Between those, you can find other methods to ask
>> about. In general, if it is required by the Software Communications
>> Architecture (SCA) or FACE Technical Standard, then it is a method
>> someone expected to possibly be used in an embedded system.
>> SCA is a set of POSIX profiles focused on software defined radios and
>> the FACE Technical Standard was developed with avionics in mind.
>> 
>> But any are fair game if they are actually implementable. I don;t think
>> the Compliance Guide says it yet, but we decided last year that
>> wordexp() is likely not supportable on RTEMS. The newlib
>> implementation assumes the presence of a shell with wildcard expansion
>> and ability to fork a process.
>> 
>> --joel
>> 
>>> 
>>> 
>>> Thank you again for your time!
>>> 
>>> Matt
>>> 
>>> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
 
 Wow! Good work. There is a lot to digest here. Comments interspersed.
 
 I assume the spreadsheet is updated.
 
 On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  
 wrote:
> 
> Hi Dr. Joel,
> 
> I've gone over the list a few times now and see a few categories shaping 
> up:
> 
> 1) Already done (In Newlib source, defined in libc.a):
> a) reallocarray
> b) qsort_r
> c) memmem
> d) strlcat / strlcpy
> d) wcslcat / wcslcpy
> *Out of this group, strlcat and strlcpy also show up in
> src/rtems/cpukit. Why is that?
 
 
 The good news is that we support these. :)
 
 It looks to me that strlcat and strlcpy are used in cpukit but not 
 implemented
 there. Where do you think they are implemented.
 
 This is a good example where a source code browser is helpful. grep can
 often answer the question but a source code browser can be easier. 
 Personally,
 I use cscope but that is exceedingly old school. Any modern IDE should be
 helpful.
 
> 
> 2) Not done yet (Do not show up in Newlib source or RTEMS):
> a) getlocalename_l
> b) posix_getdents
> c) sem_clockwait
> d) sig2str / str2sig
> 
> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
> a) pthread_cond_clockwait
>

Re: Fw: Re: ticket #3889

2021-03-27 Thread zack_on_the_speed_chanel

with the -rtems-test=Yes when you build the bsp?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, March 28, 2021 12:37 AM, Joel Sherrill  wrote:

> Did you enable all the tests and try to run it before you made modifications?
>
> On Sat, Mar 27, 2021, 7:35 PM zack_on_the_speed_chanel 
>  wrote:
>
>> What file do i have to check in ? I thought posix was a standard so the code 
>> is platform agnostic? Is there code specific to the BSP? Also I tried to 
>> modify the psxtimer02 test file and change it the clock_monotonic to see 
>> what happens but when i run ./waf it does not reflect the changes I have 
>> made. I don't see a corresponding executable in 
>> /quick-start/src/rtems/build/sparc/erc32/testsuites/psxtests
>>
>> Thanks
>> Zack
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Saturday, March 27, 2021 9:22 PM, Joel Sherrill  wrote:
>>
>>> On Sat, Mar 27, 2021, 3:52 PM zack_on_the_speed_chanel 
>>>  wrote:
>>>
 I found a part of the assembly that says that the path is not called.

 if ( ( flags & POSIX_CONDITION_VARIABLES_CLOCK_MONOTONIC ) != 0 ) {

 40005594:   12 80 00 39 bne  40005678 
 <_POSIX_Condition_variables_Wait_support+0x118> <== NEVER TAKEN

 40005598:   f4 27 bf e8 st  %i2, [ %fp + -24 ]

 So if i'm correct The BSP supports this fuction of CLOCK_Monotonic 
 (because the assembly is archetcture specific)? Which means that there is 
 a need for the test I assume?

 Also does leon= the same as  the bsp  erc32-sis (or the one in the 
 tutorial)
>>>
>>> Please read the original source to confirm but I think you're right but it 
>>> supports it but doesn't have a test.
>>>
>>> The ERC32 what's the first space hardened sparc processor. The leon3 is a 
>>> later processor in the same family. Both use the same build of GCC and are 
>>> just different bsps. In fact both run on the same sis simulator. It's just 
>>> that a user starting today on a mission, is more likely to use the Leon3. 
>>> The leon3 also can support SMP
>>>
 Zack

 Sent with [ProtonMail](https://protonmail.com) Secure Email.

 ‐‐‐ Original Message ‐‐‐
 On Saturday, March 27, 2021 7:50 PM, Joel Sherrill  wrote:

> On Sat, Mar 27, 2021 at 2:33 PM zack_on_the_speed_chanel 
>  wrote:
>
>> Hello,
>> Last year I tried to do work and help to contribute to RTEMS. I didn't 
>> get too far but now I think I now I have a better shot at it! I was able 
>> to complete the BSP and tools build, and run the hello world examples. I 
>> want to work on small tickets first and work my way into the source 
>> code. The ticket is asking for a test clock_create with clock monotonic. 
>> here is the link for the ticket I'm referring to 
>> https://devel.rtems.org/ticket/3889 .My thinking is to look for code 
>> that does something similar. In the ticket it says that there is a test 
>> with clock_realtime. I was on the discord and someone suggested me to 
>> looking to the coverage tests. How come i don't see the function 
>> clock_create when looking at the annotated assembly code? Also I think 
>> the test should be based on this 
>> https://git.rtems.org/rtems/tree/testsuites/psxtests/psxtimer02/psxtimer.c
>
> That was me on Discord. :)
>
> Yep. psxtimer02 is a good test to start from since it is doing similar 
> cases on a different clock.
>
> The coverage I was suggesting to look at is here:
>
> https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/
>
> Drill down to leon3 and posix and look at the timer methods (create, 
> settime, gettime) for current coverage.
>
> But I warn you, it may or may not actually support the CLOCK_REALTIME and 
> CLOCK_MONOTONIC as required here:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html
>
> So coverage may be high because the implementation of the posix methods 
> themselves are missing something.
>
> Pull the thread a bit to see if the methods support the clock value in 
> question. If so, we just need tests. If not, some code gets added to the 
> timer manager and tests get added.
>
> --joel
>
>> Thanks
>> Zack
>>
>> ___
>> 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: [PATCH rtems-libbsd 1/2] racoon/session: Honor file descriptor maximum

2021-03-27 Thread Chris Johns



On 22/3/21 7:45 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> Am 19.03.21 um 02:11 schrieb Chris Johns:
>> On 3/3/21 7:41 pm, Christian MAUDERER wrote:
>>> Hello Chris,
>>>
>>> Am 03.03.21 um 02:17 schrieb Chris Johns:
 On 2/3/21 7:26 pm, Christian MAUDERER wrote:
> Hello Chris,
>
> Am 02.03.21 um 01:03 schrieb Chris Johns:
>> On 1/3/21 7:24 pm, Christian MAUDERER wrote:
>>> Hello Chris,
>>>
>>> thanks for the review.
>>>
>>> Am 26.02.21 um 19:04 schrieb Chris Johns:
 On 26/2/21 2:01 am, Christian Mauderer wrote:
> Dynamically allocate a big enough file descriptor set for select(). A
> better solution would be to use kqueue() instead of select().
> ---
>  .../racoon/rtems-bsd-racoon-session-data.h    |  6 +--
>  ipsec-tools/src/racoon/session.c  | 40
> +++
>  2 files changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
> b/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
> index b869a1518..196107a35 100644
> --- a/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
> +++ b/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
> @@ -2,11 +2,11 @@
>  #include 
>  #include "rtems-bsd-racoon-data.h"
>  /* session.c */
> -RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static fd_set 
> active_mask);
> -RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static fd_set 
> preset_mask);
> +RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static _types_fd_set
> *allocated_active_mask);
> +RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static _types_fd_set
> *allocated_preset_mask);
>  RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static int nfds);
>  RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static int 
> signals[]);
>  RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static sig_atomic_t
> volatile
> volatile sigreq[]);
> -RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct fd_monitor
> fd_monitors[]);
> +RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct fd_monitor
> *allocated_fd_monitors);
>  RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct
> fd_monitor_list
> fd_monitor_tree[]);
>  RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct sched
> scflushsa);
> diff --git a/ipsec-tools/src/racoon/session.c
> b/ipsec-tools/src/racoon/session.c
> index 65124c15e..90120c761 100644
> --- a/ipsec-tools/src/racoon/session.c
> +++ b/ipsec-tools/src/racoon/session.c
> @@ -65,6 +65,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef __rtems__
> +#include 
> +#include 
> +#endif /* __rtems__ */
>    #include 
>  #include 
> @@ -123,8 +127,16 @@ static void check_sigreq __P((void));
>  static void check_flushsa __P((void));
>  static int close_sockets __P((void));
>  +#ifndef __rtems__
>  static fd_set preset_mask, active_mask;
>  static struct fd_monitor fd_monitors[FD_SETSIZE];
> +#else /* __rtems__ */
> +static fd_set *allocated_preset_mask, *allocated_active_mask;
> +static struct fd_monitor *allocated_fd_monitors;
> +#define preset_mask (*allocated_preset_mask)
> +#define active_mask (*allocated_active_mask)
> +#define fd_monitors (allocated_fd_monitors)
> +#endif /* __rtems__ */
>  static TAILQ_HEAD(fd_monitor_list, fd_monitor)
> fd_monitor_tree[NUM_PRIORITIES];
>  static int nfds = 0;
>  @@ -134,7 +146,11 @@ static struct sched scflushsa =
> SCHED_INITIALIZER();
>  void
>  monitor_fd(int fd, int (*callback)(void *, int), void *ctx, int
> priority)
>  {
> +#ifndef __rtems__
>  if (fd < 0 || fd >= FD_SETSIZE) {
> +#else /* __rtems__ */
> +    if (fd < 0 || fd >= rtems_libio_number_iops) {
> +#endif /* __rtems__ */
>  plog(LLV_ERROR, LOCATION, NULL, "fd_set overrun");
>  exit(1);
>  }
> @@ -158,7 +174,11 @@ monitor_fd(int fd, int (*callback)(void *, int), 
> void
> *ctx, int priority)
>  void
>  unmonitor_fd(int fd)
>  {
> +#ifndef __rtems__
>  if (fd < 0 || fd >= FD_SETSIZE) {
> +#else /* __rtems__ */
> +    if (fd < 0 || fd >= rtems_libio_number_iops) {
> +#endif /* __rtems__ */
>  plog(LLV_ERROR, LOCATION, NULL, "fd_set

Re: [Beagle BSP] How to run all tests on a Beaglebone Black in an automated way

2021-03-27 Thread Chris Johns

On 28/3/21 6:16 am, Ahamed Husni wrote:
> Hi,
> 
> I ran the hello program on the BBB using a bootable SD card. The SD card has 
> two
> partitions.
> 
>  1. BOOT - primary, bootable, FAT32
>  2. ROOT - primary, ext4
> 
> The BOOT partition has the following files.
> 
>  1. uEnv.txt
>  2. rtems-app.img
>  3. Device Tree Blob (am335x-boneblack.dtb)
> 
> I want to run all the tests on the BBB. Is there any other way to do this?
> 
> You have to get the BBB to fetch exes from a ftftp server (provided inside
> rtems-test) and provide some automated power control to the board.
> - Dr. Joel (in Discord)
> 

Please have a look at ..

https://docs.rtems.org/branches/master/user/testing/configuration.html
https://docs.rtems.org/branches/master/user/testing/tftp.html

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: psim failure - dl06

2021-03-27 Thread Chris Johns

On 28/3/21 7:21 am, Joel Sherrill wrote:
> While the "multiple resource leaks" thread continues, I thought I would start
> threads for other failures that are not resource leaks. dl06 fails as 
> follows.  

There has been no work done on the RAP format and I currently do not have the
time to look into this.

I think dl06 should be a global `expected fail`. I think it fails on all BSPs.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fw: Re: ticket #3889

2021-03-27 Thread zack_on_the_speed_chanel

I found a part of the assembly that says that the path is not called.

if ( ( flags & POSIX_CONDITION_VARIABLES_CLOCK_MONOTONIC ) != 0 ) {

40005594:   12 80 00 39 bne  40005678 
<_POSIX_Condition_variables_Wait_support+0x118> <== NEVER TAKEN

40005598:   f4 27 bf e8 st  %i2, [ %fp + -24 ]

So if i'm correct The BSP supports this fuction of CLOCK_Monotonic (because the 
assembly is archetcture specific)? Which means that there is a need for the 
test I assume?

Also does leon= the same as  the bsp  erc32-sis (or the one in the tutorial)

Zack

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Saturday, March 27, 2021 7:50 PM, Joel Sherrill  wrote:

> On Sat, Mar 27, 2021 at 2:33 PM zack_on_the_speed_chanel 
>  wrote:
>
>> Hello,
>> Last year I tried to do work and help to contribute to RTEMS. I didn't get 
>> too far but now I think I now I have a better shot at it! I was able to 
>> complete the BSP and tools build, and run the hello world examples. I want 
>> to work on small tickets first and work my way into the source code. The 
>> ticket is asking for a test clock_create with clock monotonic. here is the 
>> link for the ticket I'm referring to https://devel.rtems.org/ticket/3889 .My 
>> thinking is to look for code that does something similar. In the ticket it 
>> says that there is a test with clock_realtime. I was on the discord and 
>> someone suggested me to looking to the coverage tests. How come i don't see 
>> the function clock_create when looking at the annotated assembly code? Also 
>> I think the test should be based on this 
>> https://git.rtems.org/rtems/tree/testsuites/psxtests/psxtimer02/psxtimer.c
>
> That was me on Discord. :)
>
> Yep. psxtimer02 is a good test to start from since it is doing similar cases 
> on a different clock.
>
> The coverage I was suggesting to look at is here:
>
> https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/
>
> Drill down to leon3 and posix and look at the timer methods (create, settime, 
> gettime) for current coverage.
>
> But I warn you, it may or may not actually support the CLOCK_REALTIME and 
> CLOCK_MONOTONIC as required here:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html
>
> So coverage may be high because the implementation of the posix methods 
> themselves are missing something.
>
> Pull the thread a bit to see if the methods support the clock value in 
> question. If so, we just need tests. If not, some code gets added to the 
> timer manager and tests get added.
>
> --joel
>
>> Thanks
>> Zack
>>
>> ___
>> 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

ticket #3889

2021-03-27 Thread zack_on_the_speed_chanel

Hello,
Last year I tried to do work and help to contribute to RTEMS. I didn't get too 
far but now I think I now I have a better shot at it! I was able to complete 
the BSP and tools build, and run the hello world examples. I want to work on 
small tickets first and work my way into the source code. The ticket is asking 
for a test clock_create with clock monotonic. here is the link for the ticket 
I'm referring to https://devel.rtems.org/ticket/3889 .My thinking is to look 
for code that does something similar. In the ticket it says that there is a 
test with clock_realtime. I was on the discord and someone suggested me to 
looking to the coverage tests. How come i don't see the function clock_create 
when looking at the annotated assembly code? Also I think the test should be 
based on this 
https://git.rtems.org/rtems/tree/testsuites/psxtests/psxtimer02/psxtimer.c

Thanks
Zack___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fw: Re: ticket #3889

2021-03-27 Thread Joel Sherrill

On Sat, Mar 27, 2021, 3:52 PM zack_on_the_speed_chanel <
zack_on_the_speed_cha...@protonmail.ch> wrote:

>
> I found a part of the assembly that says that the path is not called.
>
> if ( ( flags & POSIX_CONDITION_VARIABLES_CLOCK_MONOTONIC ) != 0 ) {
>
> 40005594:   12 80 00 39 bne  40005678 
> <_POSIX_Condition_variables_Wait_support+0x118> <== NEVER TAKEN
>
> 40005598:   f4 27 bf e8 st  %i2, [ %fp + -24 ]
>
> So if i'm correct The BSP supports this fuction of CLOCK_Monotonic (because 
> the assembly is archetcture specific)? Which means that there is a need for 
> the test I assume?
>
> Also does leon= the same as  the bsp  erc32-sis (or the one in the tutorial)
>
>
Please read the original source to confirm but I think you're right but it
supports it but doesn't have a test.

The ERC32 what's the first space hardened sparc processor. The leon3 is a
later processor in the same family. Both use the same build of GCC and are
just different bsps. In fact both run on the same sis simulator. It's just
that a user starting today on a mission, is more likely to use the Leon3.
The leon3 also can support SMP

>
> Zack
>
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, March 27, 2021 7:50 PM, Joel Sherrill  wrote:
>
>
>
> On Sat, Mar 27, 2021 at 2:33 PM zack_on_the_speed_chanel <
> zack_on_the_speed_cha...@protonmail.ch> wrote:
>
>> Hello,
>> Last year I tried to do work and help to contribute to RTEMS. I didn't
>> get too far but now I think I now I have a better shot at it! I was able to
>> complete the BSP and tools build, and run the hello world examples.  I want
>> to work on small tickets first and work my way into the source code. The
>> ticket is asking for a test  clock_create with clock monotonic.  here is
>> the link for the ticket I'm referring to
>> https://devel.rtems.org/ticket/3889 .My thinking is to look for code
>> that does something similar. In the ticket it says that there is a test
>> with clock_realtime. I was on the discord and someone suggested me to
>> looking to the coverage tests. How come i don't see the function
>> clock_create when looking at the annotated assembly code?  Also I think the
>> test should be based on this
>> https://git.rtems.org/rtems/tree/testsuites/psxtests/psxtimer02/psxtimer.c
>>
>
>  That was me on Discord. :)
>
> Yep. psxtimer02 is a good test to start from since it is doing similar
> cases on a different clock.
>
> The coverage I was suggesting to look at is here:
>
> https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/
>
> Drill down to leon3 and posix and look at the timer methods (create,
> settime, gettime) for current coverage.
>
> But I warn you, it may or may not actually support the CLOCK_REALTIME and
> CLOCK_MONOTONIC as required here:
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html
>
> So coverage may be high because the implementation of the posix methods
> themselves are missing something.
>
> Pull the thread a bit to see if the methods support the clock value in
> question. If so, we just need tests. If not, some code gets added to the
> timer manager and tests get added.
>
> --joel
>
>>
>> Thanks
>> Zack
>>
>> ___
>> 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

psim failure - dl06

2021-03-27 Thread Joel Sherrill

Hi

While the "multiple resource leaks" thread continues, I thought I would
start threads for other failures that are not resource leaks. dl06 fails as
follows.

===
*** BEGIN OF TEST libdl (RTL) 6 ***
*** TEST VERSION: 6.0.0.1e62e15f46283a3affb1e6dcceead0c382482287
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
*** TEST TOOLS: 10.2.1 20210308 (RTEMS 6, RSB
56cba3c6a34dae16271efb7b349cfce0e5e5b4c5, Newlib abc8acb)

load: /dl06.rap
dlopen failed: global symbol not found:

===
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

psim failure - psx12

2021-03-27 Thread Joel Sherrill

Hi

While the "multiple resource leaks" thread continues, I thought I would
start threads for other failures that are not resource leaks. psx12 fails
as follows. This could be as simple as the decrementer counts instructions
and it needs to allow more between clock ticks. But that would require
experimentation. And it assumes this test doesn't fail on another BSP.

  ===

*** BEGIN OF TEST PSX 12 ***
*** TEST VERSION: 6.0.0.1e62e15f46283a3affb1e6dcceead0c382482287
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
*** TEST TOOLS: 10.2.1 20210308 (RTEMS 6, RSB
56cba3c6a34dae16271efb7b349cfce0e5e5b4c5, Newlib abc8acb)
Init's ID is 0x0b010001
Init: pthread_attr_init - SUCCESSFUL
Init: pthread_create - EINVAL (invalid scheduling policy)
Init: pthread_attr_init - SUCCESSFUL
Init: set scheduling parameter attributes for sporadic server
Init: pthread_create - EINVAL (replenish < budget)
Init: pthread_create - EINVAL (invalid sched_ss_low_priority)
Init: pthread_create - SUCCESSFUL
Sporadic Server: exitting
[0] H  96ms
[0] L 196ms
../../../testsuites/psxtests/psx12/init.c: 224 ctx->samples[ i ].low /
SS_REPL_PERIOD_MS == i + 1

*** FATAL ***
===
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RTEMS] bsps/beagle: Refactored i2c driver

2021-03-27 Thread Vijay Kumar Banerjee

Hi Niteesh,

Thanks for the patch. I have some questions below.

On Mon, Mar 22, 2021 at 11:48 AM G S Niteesh Babu 
wrote:
>
> Refactored the i2c driver to parse register values from the device
> tree rather than hardcoding them. But still the clocks have to
> initialized manually.
> ---
>  bsps/arm/beagle/i2c/bbb-i2c.c | 100 --
>  bsps/arm/beagle/include/bsp.h |   4 ++
>  bsps/arm/beagle/include/bsp/i2c.h |  32 +-
>  bsps/arm/beagle/start/bspstart.c  |  53 +++-
>  4 files changed, 96 insertions(+), 93 deletions(-)
>
> diff --git a/bsps/arm/beagle/i2c/bbb-i2c.c b/bsps/arm/beagle/i2c/bbb-i2c.c
> index b2a7cf814d..c315b6fc3b 100644
> --- a/bsps/arm/beagle/i2c/bbb-i2c.c
> +++ b/bsps/arm/beagle/i2c/bbb-i2c.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  typedef struct bbb_i2c_bus {
>i2c_bus base;
> @@ -34,12 +35,6 @@ typedef struct bbb_i2c_bus {
>  volatile uint32_t *i2c_clkctrl;
>  volatile uint32_t *clkstctrl;
>} clkregs;
> -  struct {
> -volatile uint32_t *conf_sda;
> -uint32_t mmode_sda;
> -volatile uint32_t *conf_scl;
> -uint32_t mmode_scl;
> -  } pinregs;
>rtems_id task_id;
>rtems_vector_number irq;
>i2c_msg *buffer;
> @@ -56,19 +51,29 @@ typedef struct bbb_i2c_bus {
>  #else
>  #define debug_print(fmt, args...)
>  #endif
> +/*
> + * Here we assume the number of i2c nodes
> + * will be less than 100.
> + */
> +#define PATH_LEN strlen("/dev/i2c-xx")
>
>  static int am335x_i2c_fill_registers(
>bbb_i2c_bus *bus,
> -  uintptr_t register_base
> +  phandle_tnode
>  )
>  {
> -  /* FIXME: The pin handling should be replaced by a proper pin handling
during
> -   * initialization. This one is heavily board specific. */
> -#if ! IS_AM335X
> -  printk ("The I2C driver currently only works on Beagle Bone. Please
add your pin configs.");
> -  return EINVAL;
> -#endif
> -  bus->regs = (volatile bbb_i2c_regs *) register_base;
> +  ssize_t rv;
> +  rtems_ofw_memory_area reg;
> +
> +  rv = rtems_ofw_get_reg(node, , sizeof(reg));
> +  if (rv <= 0)
> +return EINVAL;
> +
> +  bus->regs = (volatile bbb_i2c_regs *)reg.start;
> +
> +  /*
> +   * FIXME: Implement a clock driver to parse and setup clocks
> +   */
>switch ((intptr_t) bus->regs) {
>case AM335X_I2C0_BASE:
>  bus->clkregs.ctrl_clkctrl = (AM335X_SOC_CM_WKUP_REGS +
> @@ -77,10 +82,6 @@ static int am335x_i2c_fill_registers(
>   AM335X_CM_WKUP_I2C0_CLKCTRL);
>  bus->clkregs.clkstctrl = (AM335X_SOC_CM_WKUP_REGS +
> AM335X_CM_WKUP_CLKSTCTRL);
> -bus->pinregs.conf_sda = (AM335X_PADCONF_BASE +
AM335X_CONF_I2C0_SDA);
> -bus->pinregs.mmode_sda = 0;
> -bus->pinregs.conf_scl = (AM335X_PADCONF_BASE +
AM335X_CONF_I2C0_SCL);
> -bus->pinregs.mmode_scl = 0;
>  break;
>case AM335X_I2C1_BASE:
>  bus->clkregs.ctrl_clkctrl = (AM335X_SOC_CM_WKUP_REGS +
> @@ -88,10 +89,6 @@ static int am335x_i2c_fill_registers(
>  bus->clkregs.i2c_clkctrl = (AM335X_CM_PER_ADDR +
>   AM335X_CM_PER_I2C1_CLKCTRL);
>  bus->clkregs.clkstctrl = NULL;
> -bus->pinregs.conf_sda = (AM335X_PADCONF_BASE +
AM335X_CONF_SPI0_D1);
> -bus->pinregs.mmode_sda = 2;
> -bus->pinregs.conf_scl = (AM335X_PADCONF_BASE +
AM335X_CONF_SPI0_CS0);
> -bus->pinregs.mmode_scl = 2;
>  break;
>case AM335X_I2C2_BASE:
>  bus->clkregs.ctrl_clkctrl = (AM335X_SOC_CM_WKUP_REGS +
> @@ -99,24 +96,12 @@ static int am335x_i2c_fill_registers(
>  bus->clkregs.i2c_clkctrl = (AM335X_CM_PER_ADDR +
>   AM335X_CM_PER_I2C2_CLKCTRL);
>  bus->clkregs.clkstctrl = NULL;
> -bus->pinregs.conf_sda = (AM335X_PADCONF_BASE +
AM335X_CONF_UART1_CTSN);
> -bus->pinregs.mmode_sda = 3;
> -bus->pinregs.conf_scl = (AM335X_PADCONF_BASE +
AM335X_CONF_UART1_RTSN);
> -bus->pinregs.mmode_scl = 3;
>  break;
>default:
>  return EINVAL;
>}
> -  return 0;
> -}
>
> -static void am335x_i2c_pinmux( bbb_i2c_bus *bus )
> -{
> -  *bus->pinregs.conf_sda =
> -( BBB_RXACTIVE | BBB_SLEWCTRL | bus->pinregs.mmode_sda);
> -
> -  *bus->pinregs.conf_scl =
> -( BBB_RXACTIVE | BBB_SLEWCTRL | bus->pinregs.mmode_scl);
> +  return 0;
>  }
>
>  static void am335x_i2c_module_clk_enable( bbb_i2c_bus *bus )
> @@ -453,18 +438,16 @@ static void am335x_i2c_destroy( i2c_bus *base )
>i2c_bus_destroy_and_free( >base );
>  }
>
> -int am335x_i2c_bus_register(
> -  const char *bus_path,
> -  uintptr_t   register_base,
> -  uint32_tinput_clock,
> -  rtems_vector_number irq
> +static int am335x_i2c_bus_register(
> +  phandle_t   node
>  )
This is method can be used by the application to register i2c device, why
is it being removed? It is also documented here:
https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#id2
If we really want to make it static, then it at least needs

Re: ticket #3889

2021-03-27 Thread Joel Sherrill

On Sat, Mar 27, 2021 at 2:33 PM zack_on_the_speed_chanel <
zack_on_the_speed_cha...@protonmail.ch> wrote:

> Hello,
> Last year I tried to do work and help to contribute to RTEMS. I didn't get
> too far but now I think I now I have a better shot at it! I was able to
> complete the BSP and tools build, and run the hello world examples.  I want
> to work on small tickets first and work my way into the source code. The
> ticket is asking for a test  clock_create with clock monotonic.  here is
> the link for the ticket I'm referring to
> https://devel.rtems.org/ticket/3889 .My thinking is to look for code that
> does something similar. In the ticket it says that there is a test with
> clock_realtime. I was on the discord and someone suggested me to looking to
> the coverage tests. How come i don't see the function clock_create when
> looking at the annotated assembly code?  Also I think the test should be
> based on this
> https://git.rtems.org/rtems/tree/testsuites/psxtests/psxtimer02/psxtimer.c
>

 That was me on Discord. :)

Yep. psxtimer02 is a good test to start from since it is doing similar
cases on a different clock.

The coverage I was suggesting to look at is here:

https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/

Drill down to leon3 and posix and look at the timer methods (create,
settime, gettime) for current coverage.

But I warn you, it may or may not actually support the CLOCK_REALTIME and
CLOCK_MONOTONIC as required here:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html

So coverage may be high because the implementation of the posix methods
themselves are missing something.

Pull the thread a bit to see if the methods support the clock value in
question. If so, we just need tests. If not, some code gets added to the
timer manager and tests get added.

--joel

>
> Thanks
> Zack
>
> ___
> 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

[Beagle BSP] How to run all tests on a Beaglebone Black in an automated way

2021-03-27 Thread Ahamed Husni

Hi,

I ran the hello program on the BBB using a bootable SD card. The SD card
has two partitions.

   1. BOOT - primary, bootable, FAT32
   2. ROOT - primary, ext4

The BOOT partition has the following files.

   1. uEnv.txt
   2. rtems-app.img
   3. Device Tree Blob (am335x-boneblack.dtb)

I want to run all the tests on the BBB. Is there any other way to do this?

You have to get the BBB to fetch exes from a ftftp server (provided inside
> rtems-test) and provide some automated power control to the board.
> - Dr. Joel (in Discord)
>

Best regards,
Husni.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Two Resource Leaks

2021-03-27 Thread Joel Sherrill

On Sat, Mar 27, 2021, 1:38 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 27/03/2021 17:20, Joel Sherrill wrote:
>
> >
> >
> > On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber
> >  > > wrote:
> >
> > On 27/03/2021 16:08, Joel Sherrill wrote:
> >
> > > The issue I found is different and won't happen on every
> > target or
> > > bsp.
> > >
> > > Psim has 6-9 failures even after freeing the right stack
> > address.
> > >
> > >
> > > The stack address and now (I think) size saved for later use are
> > wrong
> > > and this leads to multiple failures.
> > I work on a fix. psim seems to be a good platform for these tests.
> >
> >
> > I put a patch for the address issue but I think the fundamental issue
> > is you changed the semantics of what was stored in the stack
> > structure. You probably want a different approach but this is at least
> > a good temporary fix.
>
> I checked in a fix. However, I still get two unexpected failures:
>

Great.


> Failures:
>   fsimfsgeneric01.exe
>   psxkey08.exe
>
> A rtems_resource_snapshot_check() is not happy.
>

Did you manage to see what was leaking?

And did you try the non-network tests in libbsd. Those failing on beatnik
is what caused me to start looking at psim. Syscalls01 was a workspace
mismatch on the resource check.

--joel

>
> --
> 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: Two Resource Leaks

2021-03-27 Thread Sebastian Huber


On 27/03/2021 17:20, Joel Sherrill wrote:




On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber 
> wrote:


On 27/03/2021 16:08, Joel Sherrill wrote:

>     The issue I found is different and won't happen on every
target or
>     bsp.
>
>     Psim has 6-9 failures even after freeing the right stack
address.
>
>
> The stack address and now (I think) size saved for later use are
wrong
> and this leads to multiple failures.
I work on a fix. psim seems to be a good platform for these tests.


I put a patch for the address issue but I think the fundamental issue 
is you changed the semantics of what was stored in the stack 
structure. You probably want a different approach but this is at least 
a good temporary fix.


I checked in a fix. However, I still get two unexpected failures:

Failures:
 fsimfsgeneric01.exe
 psxkey08.exe

A rtems_resource_snapshot_check() is not happy.

--
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: Two Resource Leaks

2021-03-27 Thread Joel Sherrill

On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 27/03/2021 16:08, Joel Sherrill wrote:
>
> > The issue I found is different and won't happen on every target or
> > bsp.
> >
> > Psim has 6-9 failures even after freeing the right stack address.
> >
> >
> > The stack address and now (I think) size saved for later use are wrong
> > and this leads to multiple failures.
> I work on a fix. psim seems to be a good platform for these tests.
>

I put a patch for the address issue but I think the fundamental issue is
you changed the semantics of what was stored in the stack structure. You
probably want a different approach but this is at least a good
temporary fix.

And something different on Libbsd. But not sure.

I think Richi has raised the issue that there are some recently introduced
failures. Not sure how many are 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: Two Resource Leaks

2021-03-27 Thread Sebastian Huber


On 26/03/2021 22:51, Joel Sherrill wrote:

Jennifer has been working on a network driver and had some odd 
failures in libbsd. I suggested turning on rtems debug and that caused 
a number of libbsd tests to fail.


You can also enable the FreeBSD invariants support. In 
rtems-bsd-kernel-space.h:


#define INVARIANTS 1

#define INVARIANTS_SUPPORT 1

--
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: Two Resource Leaks

2021-03-27 Thread Sebastian Huber


On 27/03/2021 16:08, Joel Sherrill wrote:


The issue I found is different and won't happen on every target or
bsp.

Psim has 6-9 failures even after freeing the right stack address.


The stack address and now (I think) size saved for later use are wrong 
and this leads to multiple failures.

I work on a fix. psim seems to be a good platform for these tests.

--
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: Two Resource Leaks

2021-03-27 Thread Joel Sherrill

On Sat, Mar 27, 2021 at 8:53 AM Joel Sherrill  wrote:

>
>
> On Sat, Mar 27, 2021, 12:04 AM Richi Dubey  wrote:
>
>> I believe that cause of the recent commits in the last two months, these
>> are the tests that have started failing on master:
>> dl09.exe
>> psxpasswd02.exe
>> pwdgrp01.exe
>> shell01.exe
>> sptimecounter02.exe
>> ttest02.exe
>>
>> and a timeout:
>> smpmrsp01.ex
>>
>
> The password ones are for an incorrect change to pwdgrp.c to assert if
> mkdir fails creating /etc. That should account for pwdgrp, paxpasswd02, and
> shell01. This code needs to turn into a (void) rather than an assert.
>
> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/pwdgrp.c#n74
>
> And looking at git makes me realise that I didn't push the fix for that.
> It is in my tree. Sorry.
>

 pushed this and per rtems-test, psim has 9 failures.

>
> The issue I found is different and won't happen on every target or bsp.
>
> Psim has 6-9 failures even after freeing the right stack address.
>

The stack address and now (I think) size saved for later use are wrong and
this leads to multiple failures.



>
>
>>
>> On Sat, Mar 27, 2021 at 3:21 AM Joel Sherrill  wrote:
>>
>>> Hi
>>>
>>> Jennifer has been working on a network driver and had some odd failures
>>> in libbsd. I suggested turning on rtems debug and that caused a number of
>>> libbsd tests to fail. She pointed me in the right direction and I found
>>> that the following patch resulted in the stack address being freed
>>> including an "align up" adjustment in some cases. This looks to be from
>>> something Sebastian committed early this month.
>>>
>>>
>>> https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1
>>>
>>> I am not sure how that wasn't noticed since about 40 tests were failing
>>> on psim due to that.
>>>
>>> I have attached a straightforward patch to address this issue.
>>>
>>> Unfortunately, even with this patch and using the RTEMS hash just before
>>> this patch program01 and syscalls01 in libbsd fail. I debugged into
>>> syscalls01 enough to find that there are 7 blocks at the beginning of one
>>> of the tests and 5 after. There is another leak and I tried using the has
>>> before Sebastian's change above but it is still leaking.
>>>
>>> On top of that, psxconfig01 and spconfig01 are failing on psim which
>>> appears to be independent. I am not sure what these are but it is something
>>> about minimum stack size not matching. Since I was looking for stack memory
>>> issues, I started to investigate these but decided they were not
>>> allocation/free issues.
>>>
>>> Help really appreciated in addressing these leaks.
>>>
>>> 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

Re: [PATCH] coverage/symbol-sets.ini : Add libtrace

2021-03-27 Thread Gedare Bloom

On Fri, Mar 12, 2021 at 10:17 AM Alex White  wrote:
>
> ---
>  tester/rtems/testing/coverage/symbol-sets.ini | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini 
> b/tester/rtems/testing/coverage/symbol-sets.ini
> index 9617dd8..52e25ff 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
> +sets = 
> score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace
>
ok, but this is really ugly. is the comma-separated list with no
whitespace mandatory, or can it be reformatted in a follow-up patch?

>  [libraries]
>  score = @BUILD-TARGET@/@BSP@/cpukit/score/src
> @@ -76,4 +76,5 @@ libblock  = @BUILD-TARGET@/@BSP@/cpukit/libblock/src
>  libcrypt  = @BUILD-TARGET@/@BSP@/cpukit/libcrypt
>  libmd = @BUILD-TARGET@/@BSP@/cpukit/libmd
>  libstdthreads = @BUILD-TARGET@/@BSP@/cpukit/libstdthreads
> +libtrace  = @BUILD-TARGET@/@BSP@/cpukit/libtrace/record
>  #zlib  = @BUILD-TARGET@/@BSP@/cpukit/zlib
> --
> 2.27.0
>
> ___
> 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] coverage: Fix option processing on FreeBSD

2021-03-27 Thread Gedare Bloom

ok, but add a comment about the fragility of this ordering in the code

On Fri, Mar 12, 2021 at 10:18 AM Alex White  wrote:
>
> Covoar uses getopt() to process the command line options. If getopt() is
> POSIX-compliant, it will return -1 when it encounters the first
> non-option command line argument. It appears that it behaves this way on
> FreeBSD, but on Linux getopt() continues to process arguments while
> skipping any non-options. This changes the order of arguments passed to
> covoar by coverage.py to group all options at the beginning. This allows
> hosts with POSIX-compliant getopt() implementations to correctly process
> all command line options.
> ---
>  tester/rt/coverage.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> index a561d26..77e5b69 100644
> --- a/tester/rt/coverage.py
> +++ b/tester/rt/coverage.py
> @@ -361,8 +361,8 @@ class covoar(object):
>  exe = self._find_covoar()
>  command = exe + ' -O ' + covoar_result_dir + \
>' -p ' + self.project_name + \
> -  ' ' + self.executables + ' '
> -command += self.covoar_cmd
> +  ' ' + self.covoar_cmd + ' '
> +command += self.executables
>
>  log.notice()
>  log.notice('Running coverage analysis: %s (%s)' % (set_name, 
> covoar_result_dir))
> --
> 2.27.0
>
> ___
> 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] tester: Limit branch coverage percentage precision

2021-03-27 Thread Gedare Bloom

ok

On Fri, Mar 12, 2021 at 10:19 AM Alex White  wrote:
>
> ---
>  tester/rt/coverage.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> index 77e5b69..3de0bb5 100644
> --- a/tester/rt/coverage.py
> +++ b/tester/rt/coverage.py
> @@ -181,7 +181,7 @@ class report_gen_html:
>  + '" max="100">' + os.linesep
>  row += ' ' + summary.branches_uncovered + '' + 
> os.linesep
>  row += ' ' + summary.branches_total + '' + os.linesep
> -row += '  {:.3%} 
> '.format(summary.percentage_branches_covered)
> +row += '  {:.2%} 
> '.format(summary.percentage_branches_covered)
>  spbc = 100 * summary.percentage_branches_covered
>  row += '  max="100">'.format(spbc)
>  row += '' + os.linesep
> --
> 2.27.0
>
> ___
> 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 v4] covoar: Handle periods in symbols from objdump

2021-03-27 Thread Gedare Bloom

this one looks fine to me.

On Fri, Mar 26, 2021 at 3:21 PM Alex White  wrote:
>
> ping
>
> > -Original Message-
> > From: Alex White 
> > Sent: Friday, March 19, 2021 2:10 PM
> > To: devel@rtems.org
> > Cc: Alex White 
> > Subject: [PATCH v4] covoar: Handle periods in symbols from objdump
> >
> > Occasionally the compiler will generate symbols that look similar to symbols
> > defined in RTEMS code except that they contain some suffix.
> > These symbol suffixes are only found in the ELF symbol table; the symbols
> > appear to be normal in the DWARF info. This appears to be happening on all
> > architectures.
> >
> > For example, the function _Message_queue_Create from rtems appears as
> > "_Message_queue_Create.part.0". Other suffixes include ".isra.0",
> > ".constprop.0", and ".0".
> >
> > This looks to be related to compiler optimizations. Symbols with suffixes
> > were being treated as unique. For our purposes, they should be mapped to
> > the equivalent symbols in the DWARF info. This has been fixed.
> > ---
> >  tester/covoar/ExecutableInfo.cc   |  3 +--
> >  tester/covoar/ObjdumpProcessor.cc | 15 +++
> >  tester/covoar/SymbolTable.cc  | 12 +---
> >  3 files changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/tester/covoar/ExecutableInfo.cc
> > b/tester/covoar/ExecutableInfo.cc index c996d75..1e14721 100644
> > --- a/tester/covoar/ExecutableInfo.cc
> > +++ b/tester/covoar/ExecutableInfo.cc
> > @@ -118,8 +118,7 @@ namespace Coverage {
> >  // Obtain the coverage map containing the specified address.
> >  itsSymbol = theSymbolTable.getSymbol( address );
> >  if (itsSymbol != "") {
> > -  it = coverageMaps.find( itsSymbol );
> > -  aCoverageMap = (*it).second;
> > +  aCoverageMap = (itsSymbol);
> >  }
> >
> >  return aCoverageMap;
> > diff --git a/tester/covoar/ObjdumpProcessor.cc
> > b/tester/covoar/ObjdumpProcessor.cc
> > index 0647ff9..e19fa92 100644
> > --- a/tester/covoar/ObjdumpProcessor.cc
> > +++ b/tester/covoar/ObjdumpProcessor.cc
> > @@ -417,6 +417,21 @@ namespace Coverage {
> >  processSymbol = false;
> >  theInstructions.clear();
> >
> > +// Look for a '.' character and strip everything after it.
> > +// There is a chance that the compiler splits function bodies to 
> > improve
> > +// inlining. If there exists some inlinable function that contains 
> > a
> > +// branch where one path is more expensive and less likely to be 
> > taken
> > +// than the other, inlining only the branch instruction and the 
> > less
> > +// expensive path results in smaller code size while preserving 
> > most of
> > +// the performance improvement.
> > +// When this happens, the compiler will generate a function with a
> > +// ".part.n" suffix. For our purposes, this generated function 
> > part is
> > +// equivalent to the original function and should be treated as 
> > such.
> > +char *periodIndex = strstr(symbol, ".");
> > +if (periodIndex != NULL) {
> > +  *periodIndex = 0;
> > +}
> > +
> >  // See if the new symbol is one that we care about.
> >  if (SymbolsToAnalyze->isDesired( symbol )) {
> >currentSymbol = symbol;
> > diff --git a/tester/covoar/SymbolTable.cc b/tester/covoar/SymbolTable.cc
> > index 53bc8af..00062cc 100644
> > --- a/tester/covoar/SymbolTable.cc
> > +++ b/tester/covoar/SymbolTable.cc
> > @@ -46,12 +46,18 @@ namespace Coverage {
> >  symbolData.startingAddress = start;
> >  symbolData.length = length;
> >
> > -if ( info[ symbol ].empty() == false ) {
> > -  if ( info[ symbol ].front().length != length ) {
> > +for (auto& symData : info[ symbol ]) {
> > +  // The starting address could differ since we strip any suffixes 
> > beginning
> > +  // with a '.'
> > +  if (symData.startingAddress != start) {
> > +continue;
> > +  }
> > +
> > +  if (symData.length != length) {
> >  std::ostringstream what;
> >  what << "Different lengths for the symbol "
> >   << symbol
> > - << " (" << info[ symbol ].front().length
> > + << " (" << symData.length
> >   << " and " << length
> >   << ")";
> >  throw rld::error( what, "SymbolTable::addSymbol" );
> > --
> > 2.27.0
>
> ___
> 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: About scheduler entry point add_processor

2021-03-27 Thread Gedare Bloom

On Thu, Mar 25, 2021 at 11:11 PM Richi Dubey  wrote:
>
> Hi,
>
> I remember reading somewhere that the add_processor function is only used 
> when a processor is explicitly added during runtime of an application :p, Is 
> that correct?Please let me know which test tests/uses this function.
>

cd ~/rtems/rtems/testsuites$ grep -r add_processor
smptests/smpirqs01/init.c:  sc = rtems_scheduler_add_processor(scheduler_id, 1);
smptests/smpscheduler04/init.c:sc = rtems_scheduler_add_processor(
smptests/smpscheduler04/smpscheduler04.doc:  - rtems_scheduler_add_processor()
smptests/smpthreadpin01/init.c:  sc =
rtems_scheduler_add_processor(ctx->sched_b, 1);
smptests/smpscheduler02/init.c:  sc =
rtems_scheduler_add_processor(scheduler_c_id, 62);
smptests/smpscheduler02/init.c:  sc =
rtems_scheduler_add_processor(scheduler_c_id, 63);
smptests/smpscheduler02/init.c:sc =
rtems_scheduler_add_processor(scheduler_a_id, 1);
smptests/smpscheduler02/init.c:sc =
rtems_scheduler_add_processor(scheduler_a_id, 0);
smptests/smpscheduler02/init.c:sc =
rtems_scheduler_add_processor(scheduler_b_id, 1);
sptests/spscheduler01/init.c:  sc =
rtems_scheduler_add_processor(invalid_id, 0);
sptests/spscheduler01/init.c:  sc =
rtems_scheduler_add_processor(scheduler_id, 1);
sptests/spscheduler01/init.c:  sc =
rtems_scheduler_add_processor(scheduler_id, 0);

I guess you should start with one of those.

> Thanks.
> ___
> 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: Two Resource Leaks

2021-03-27 Thread Joel Sherrill

On Sat, Mar 27, 2021, 12:04 AM Richi Dubey  wrote:

> I believe that cause of the recent commits in the last two months, these
> are the tests that have started failing on master:
> dl09.exe
> psxpasswd02.exe
> pwdgrp01.exe
> shell01.exe
> sptimecounter02.exe
> ttest02.exe
>
> and a timeout:
> smpmrsp01.ex
>

The password ones are for an incorrect change to pwdgrp.c to assert if
mkdir fails creating /etc. That should account for pwdgrp, paxpasswd02, and
shell01. This code needs to turn into a (void) rather than an assert.

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/pwdgrp.c#n74

And looking at git makes me realise that I didn't push the fix for that. It
is in my tree. Sorry.

The issue I found is different and won't happen on every target or bsp.

Psim has 6-9 failures even after freeing the right stack address.



>
> On Sat, Mar 27, 2021 at 3:21 AM Joel Sherrill  wrote:
>
>> Hi
>>
>> Jennifer has been working on a network driver and had some odd failures
>> in libbsd. I suggested turning on rtems debug and that caused a number of
>> libbsd tests to fail. She pointed me in the right direction and I found
>> that the following patch resulted in the stack address being freed
>> including an "align up" adjustment in some cases. This looks to be from
>> something Sebastian committed early this month.
>>
>>
>> https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1
>>
>> I am not sure how that wasn't noticed since about 40 tests were failing
>> on psim due to that.
>>
>> I have attached a straightforward patch to address this issue.
>>
>> Unfortunately, even with this patch and using the RTEMS hash just before
>> this patch program01 and syscalls01 in libbsd fail. I debugged into
>> syscalls01 enough to find that there are 7 blocks at the beginning of one
>> of the tests and 5 after. There is another leak and I tried using the has
>> before Sebastian's change above but it is still leaking.
>>
>> On top of that, psxconfig01 and spconfig01 are failing on psim which
>> appears to be independent. I am not sure what these are but it is something
>> about minimum stack size not matching. Since I was looking for stack memory
>> issues, I started to investigate these but decided they were not
>> allocation/free issues.
>>
>> Help really appreciated in addressing these leaks.
>>
>> 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

Re: GSOC project: #4334 Replace Mongoose with Civetweb

2021-03-27 Thread Ayushman Mishra

Greetings to all the respected mentors,
1. I saw there has been a lot of discussion regarding replacing
mongoose with civetweb (
https://lists.rtems.org/pipermail/devel/2016-April/014661.html ).
I think the basic outline of the project is like this
a. Completely removing mongoose and replace it with civetweb and make
it configurable in rsb
b. check the parameters and options available in civetweb and make it
usable for users in rtems.
c. making test-cases for civetweb (should be similar to mongoose)
d. documentation of using civetweb and web-server in general.
I would be very grateful to know what is the actual current status of
this project and the coding involved in it enough for a summer of code
project or some extra things should be added in it.

Also,
2. I have build bsp on rtems6 and a simple application is working
correct, but while trying to build libbsd package in rtems6
(../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \
  --host=sparc-rtems6 --with-rtems-bsp=erc32 6/rtems-libbsd ) I am
constantly getting build failed
RTEMS Source Builder - Set Builder, 6 (ade089253e70)
Build Set: 6/rtems-libbsd
config: tools/rtems-libbsd-6.cfg
error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=cypress
-I/home/ayush/quick-start/rtems/6/sparc-rtems6/erc32/lib/include ==
Build FAILED
Build Set: Time 0:00:00.045392
Build FAILED

I also tried building all packages for bsp erc32
(../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \
--with-rtems-tests=yes bsps/erc32) but after building for more
than an hour it also gave build failed error.
building: sparc-rtems6-kernel-erc32-1
error: building sparc-rtems6-kernel-erc32-1
Build FAILED
  See error report: rsb-report-sparc-rtems6-kernel-erc32-1.txt
error: building sparc-rtems6-kernel-erc32-1
Build Set: Time 0:23:14.195494
error: building sparc-rtems6-kernel-erc32-1
Build Set: Time 3:55:05.826612
Build FAILED

Thanks, Ayushman

On Mon, Mar 22, 2021 at 6:37 AM Ayushman Mishra
 wrote:
>
> Thanks a lot for help and information , actually i am trying to setup
> mongoose on simple rtems application
> (https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server) and for
> that right now I am trying to configure networking and file-system in
> the application.
>
> On Sun, Mar 21, 2021 at 8:54 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Sun, Mar 21, 2021, 4:45 AM Christian Mauderer  wrote:
> >>
> >> Hello Ayushman,
> >>
> >> On 21/03/2021 04:15, Ayushman Mishra wrote:
> >> > Ayushman
> >> > Hello everyone , I am very much interested in taking
> >> > https://devel.rtems.org/ticket/4334
> >> > as a GSOC 2021 project. I know some basic networking concepts and would 
> >> > like to
> >> > learn more about it and how its applied to OS like RTEMS , regarding
> >> > this I have some questions.
> >>
> >> Note that the ticket will be more about integrating civetweb into a
> >> RTEMS Source Builder (RSB) recipe and finding a way to make it
> >> configurable there. Alternative could be some kind of stand alone repo
> >> like for littlevgl.
> >
> >
> > Making the civitweb configure options available to RTEMS user is a key 
> > point.
> >
> > It may make sense to do a repo with waf build system and config.ini that 
> > maps to their settings.
> >
> >>
> >> civetweb builds on RTEMS nearly out of the box. So don't expect too much
> >> C-Code.
> >
> >
> > I set it up recently on Linux for embedding in their application. As you 
> > turned on options, it had more dependencies. This would have to be managed 
> > with RTEMS.
> >
> >>
> >> I'm not yet sure how much work will be on that ticket. If it is too few
> >> for a whole GSoC, you might want to think about reviving the discussion
> >> about some useful civetweb parameters (for an embedded system) here:
> >>
> >>  https://github.com/civetweb/civetweb/pull/297
> >
> >
> > +1
> >
> > How to present the options to the user and manage their dependencies would 
> > be a key part of this.
> >>
> >>
> >>
> >>
> >> >
> >> > 1. After building a simple hello world application how and where should 
> >> > i write
> >> > configurations of
> >> > https://docs.rtems.org/branches/master/networking/using_networking_rtems_app.html
> >> > OR  
> >> > https://docs.rtems.org/branches/master/user/migration/v4_11-to-v5.html#networking
> >> > to start using networking stack in RTEMS .
> >>
> >> The documentation is currently mostly for the legacy stack. Please
> >> ignore most of that. You should focus on a BSP that uses libbsd. The
> >> legacy stack and it's documentation will be removed from the main repos
> >> soon.
> >>
> >> > Also I think a simple shell has to be spawned to use networking modules 
> >> > in RTEMS
> >> > and for getting it this
> >> > https://docs.rtems.org/branches/master/shell/configuration_and_init.html#attached-to-a-serial-port
> >> > I think could be a simple method and for doing so ( like executing
> >> > rtems_shell_init with parameters )
> >> > do i have to run the specific test in testsuite

Re: GSoC project: Memory protection (Ticket no: 2904)

2021-03-27 Thread Hesham Almatary

Hello Rajiv,

The project is a bit advanced. To be able to use MMU, RTEMS has to be
ported to RISC-V's S-Mode. I created a ticket for that a few years ago
[1]. This needs a decent understanding of RISC-V and non-trivial
efforts to refactor RTEMS and its exception/interrupt handling,
context-switching, emulation layers and calls to M-Mode, etc. I am not
sure that (porting to S-Mode and supporting MMU) could fit in a GSoC
project.

[1] https://devel.rtems.org/ticket/3337

On Fri, 26 Mar 2021 at 12:25, Rajiv Vaidyanathan
 wrote:
>
> Dear Hesham,
>
> Thank you for providing information about the RISC-V MMU. I want to know what 
> work has to be done in improving MMU in RISC-V and if it can be a GSoC 
> project. It would be great if you could provide the details regarding this.
>
> Thanks and regards,
> Rajiv
>
> On Wed, 24 Mar 2021 at 00:03, Hesham Almatary  
> wrote:
>>
>> On Tue, 23 Mar 2021 at 17:14, Gedare Bloom  wrote:
>> >
>> > CC: Hesham
>> > CC: devel
>> >
>> > On Tue, Mar 23, 2021 at 6:34 AM Rajiv Vaidyanathan
>> >  wrote:
>> > >
>> > > Dear Gedare,
>> > >
>> > > Thank you for providing information regarding the project. For risk-v 
>> > > MMU support, will I require to have hardware?
>> > >
>> > That's a good question. I don't know if the current risc-v simulators
>> > support the risc-v mmu. maybe, another expert could advise. I have
>> > CC'd someone with experience in both risc-v and memory protection.
>> >
>> Yes, both Spike and QEMU have MMU and PMP support.
>>
>> > Let's keep technical discussions on the mailing list. Thanks.
>> >
>> > > Thanks and regards,
>> > > Rajiv
>> > >
>> > > On Mon, 22 Mar 2021 at 21:54, Gedare Bloom  wrote:
>> > >>
>> > >> Hi Rajiv,
>> > >>
>> > >> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
>> > >>  wrote:
>> > >> >
>> > >> > Hello RTEMS community,
>> > >> >
>> > >> > I am interested in the ticket: Memory protection. I saw that this 
>> > >> > topic has been pursued a few times in GSoC. It would be great if 
>> > >> > someone can let me know the current status of this project and guide 
>> > >> > me about what are the contributions that can be done this year.
>> > >> >
>> > >> Yes, this is a frequently attempted project that slowly makes progress
>> > >> over time. I think that Utkarsh has gotten somewhat close to a
>> > >> workable solution, but there were some design flaws in his approach
>> > >> for task stack protection (mainly, iterating over all the tasks) that
>> > >> are still lingering.
>> > >>
>> > >> There could be enough work here to pick up from his progress. The
>> > >> major issue would be figuring out what  the final state of his code is
>> > >> in, and to dig in to the design and implementation details to write a
>> > >> concrete proposal how to bring task stack protection to a production
>> > >> state. There may be other directions to consider as well, such as
>> > >> improving the risc-v MMU support perhaps.
>> > >>
>> > >> > Thanks and regards,
>> > >> > Rajiv
>> > >> > ___
>> > >> > 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: GSoC Project- BSP Executable Conversion

2021-03-27 Thread Daman Bir Singh

Hello,

Another project I am interested in is ticket #3302
, Build System conversion of BSP
Config (.cfg) files to pkg-config (.pc) files. Please guide me which one is
more relevant for GSOC'21 and how to start working on it.

On Fri, Mar 19, 2021 at 7:52 AM Daman Bir Singh 
wrote:

> Hello  everyone,
>
> I am interested in pursuing ticket 4272
>  as my GSoC project. I have started
> going through the documentation to get to know more about RTEMS and its
> directory structure. Please guide me how to proceed and start working on
> this.
>
> Thanks & Regards,
> Daman
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #4328: New APIs added to POSIX Standard (2021)

Re: Fw: Re: ticket #3889

Re: [PATCH rtems-libbsd 1/2] racoon/session: Honor file descriptor maximum

Re: [Beagle BSP] How to run all tests on a Beaglebone Black in an automated way

Re: psim failure - dl06

Fw: Re: ticket #3889

ticket #3889

Re: Fw: Re: ticket #3889

psim failure - dl06

psim failure - psx12

Re: [PATCH RTEMS] bsps/beagle: Refactored i2c driver

Re: ticket #3889

[Beagle BSP] How to run all tests on a Beaglebone Black in an automated way

Re: Two Resource Leaks

Re: Two Resource Leaks

Re: Two Resource Leaks

Re: Two Resource Leaks

Re: Two Resource Leaks

Re: Two Resource Leaks

Re: [PATCH] coverage/symbol-sets.ini : Add libtrace

Re: [PATCH] coverage: Fix option processing on FreeBSD

Re: [PATCH] tester: Limit branch coverage percentage precision

Re: [PATCH v4] covoar: Handle periods in symbols from objdump

Re: About scheduler entry point add_processor

Re: Two Resource Leaks

Re: GSOC project: #4334 Replace Mongoose with Civetweb

Re: GSoC project: Memory protection (Ticket no: 2904)

Re: GSoC Project- BSP Executable Conversion

28 matches

Site Navigation

Mail list logo

Footer information