date:20210305

Re: About HEAP error

2021-03-05 Thread Richi Dubey

>
> breaking at _Terminate and doing a back trace will give
> you the exact line the error is raised from.

I don't know why I did not focus on this earlier!  So I put a breakpoint at
the line 
which detects a fault and now we know which is the corrupted address:
-
Continuing.

Thread 1 hit Breakpoint 9, _Heap_Protection_check_free_block (heap=0x202ba8
<_Workspace_Area>, block=0x206fec) at
/home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/score/src/heapfree.c:73
73_Heap_Protection_block_error( heap, block,
HEAP_ERROR_FREE_PATTERN );
(gdb) p current
$7 = (uintptr_t *) 0x207bac
-

but when I try to find which function actually changes its value by putting
a watchpoint, I get this:
-
(gdb) watch *(uintptr_t *) 0x207bac
Hardware watchpoint 7: *(uintptr_t *) 0x207bac
(gdb) reset
Loading section .start, size 0xa5c lma 0x10
...
Transfer rate: 3102 KB/sec, 1855 bytes/write.
(gdb) c
Continuing.

Thread 3 hit Hardware watchpoint 7: *(uintptr_t *) 0x207bac

Old value = 1134949
New value = 1050747
0x00102c06 in _SMP_Get_current_processor () at
/home/richi/quick-start/LatestStrong/src/rtems/cpukit/include/rtems/score/smp.h:65
65  {
(gdb)
Continuing.

Thread 3 hit Hardware watchpoint 7: *(uintptr_t *) 0x207bac

Old value = 1050747
New value = 2128816
0x00102bf6 in _ARM_Wait_for_event () at
/home/richi/quick-start/LatestStrong/src/rtems/cpukit/score/cpu/arm/include/rtems/score/cpu.h:505
505  {
(gdb)
Continuing.
[Switching to Thread 1.1]

Thread 1 hit Breakpoint 6, Init (argument=2107944) at
/home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:26
26  TEST_BEGIN();
(gdb)
Continuing.

Thread 1 hit Hardware watchpoint 7: *(uintptr_t *) 0x207bac

Old value = 2128816
New value = 3876142303
_Heap_Protection_delay_block_free (heap=0x202ba8 <_Workspace_Area>,
block=0x206fec) at
/home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/score/src/heapfree.c:55
55for ( current = pattern_begin; current != pattern_end; ++current ) {
(gdb)
Continuing.
[Switching to Thread 1.3]

Thread 3 hit Hardware watchpoint 7: *(uintptr_t *) 0x207bac

Old value = 3876142303
New value = 2128816
0x00102bf6 in _ARM_Wait_for_event () at
/home/richi/quick-start/LatestStrong/src/rtems/cpukit/score/cpu/arm/include/rtems/score/cpu.h:505
505  {
(gdb) bt
#0  0x00102bf6 in _ARM_Wait_for_event () at
/home/richi/quick-start/LatestStrong/src/rtems/cpukit/score/cpu/arm/include/rtems/score/cpu.h:505
#1  0x001008a8 in bsp_start_hook_0 () at
/home/richi/quick-start/LatestStrong/src/rtems/c/src/lib/libbsp/arm/realview-pbx-a9/../../../../../../bsps/arm/realview-pbx-a9/start/bspstarthooks.c:76
#2  0x00100244 in bsp_start_vector_table_end () at
/home/richi/quick-start/LatestStrong/src/rtems/c/src/lib/libbsp/arm/realview-pbx-a9/../../../../../../bsps/arm/shared/start/start.S:464
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
-

The value of HEAP_FREE_PATTERN is 3876142303. So I know that the
function _ARM_Wait_for_event is the one that actually corrupts this value.
But, the backtrace does not help much. Which function calls this function?
What is the trace of this function?

On Sat, Mar 6, 2021 at 10:28 AM Richi Dubey  wrote:

> This is just the detection point. The allocate is doing a validity check
>> and something is wrong from an overwrite.
>> FWIW this is pretty early in the test I think.
>
> Good point, the corruption has already happened earlier, and yes its quite
> early :
> ...
> #13 0x0010860e in rtems_task_create (name=1413558560, initial_priority=1,
> stack_size=4096, initial_modes=0, attribute_set=0, id=0x202444 )
> at
> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/rtems/src/taskcreate.c:84
> #14 0x001015fa in Init (argument=2107944) at
> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:101
>
>
>
> Look manually at say 32 bytes at that address at various points during the
>> program's execution. I think this is one where a binary search for the
>> corrupting action happens.
>>
> Yes, or maybe I would try to manually put a watchpoint at all the 32 bytes
> starting 0x202ba8 and see if it works.
>
> Is this using your scheduler as the default? If so, I'd be suspicious of
>> anything allocated for it and if you were riding outside an area allocated
>> for you.
>
> Yes! Maybe the scheduler access a variable outside its bound (maybe an
> array element outside its array size), but if that is true, there should be
> a lot more failure with HEAP_ERROR. I would still give it a look.
>
> Thanks again for your help.
>
> On Fri, Mar 5, 2021 at 7:01 PM Joel Sherrill  wrote:
>
>>
>>
>>

Re: About HEAP error

2021-03-05 Thread Richi Dubey

>
> This is just the detection point. The allocate is doing a validity check
> and something is wrong from an overwrite.
> FWIW this is pretty early in the test I think.

Good point, the corruption has already happened earlier, and yes its quite
early :
...
#13 0x0010860e in rtems_task_create (name=1413558560, initial_priority=1,
stack_size=4096, initial_modes=0, attribute_set=0, id=0x202444 )
at
/home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/rtems/src/taskcreate.c:84
#14 0x001015fa in Init (argument=2107944) at
/home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:101



Look manually at say 32 bytes at that address at various points during the
> program's execution. I think this is one where a binary search for the
> corrupting action happens.
>
Yes, or maybe I would try to manually put a watchpoint at all the 32 bytes
starting 0x202ba8 and see if it works.

Is this using your scheduler as the default? If so, I'd be suspicious of
> anything allocated for it and if you were riding outside an area allocated
> for you.

Yes! Maybe the scheduler access a variable outside its bound (maybe an
array element outside its array size), but if that is true, there should be
a lot more failure with HEAP_ERROR. I would still give it a look.

Thanks again for your help.

On Fri, Mar 5, 2021 at 7:01 PM Joel Sherrill  wrote:

>
>
> On Thu, Mar 4, 2021, 11:31 PM Richi Dubey  wrote:
>
>> Hi,
>>
>> Thanks to both of you for helping me out with this!
>>
>> When I backtrace on _Terminate: I get this:
>>
>> Init -> rtems_task_create -> ... -> _Heap_Allocate -> ...
>> ->_Heap_Protection_check_free_block -> _Heap_Protection_block_error
>> ->_Heap_Protection_block_error_default -> _Terminate
>> (the_source=RTEMS_FATAL_SOURCE_HEAP, the_error=2125180). So I will try to
>> debug this trace.
>>
>
> This is just the detection point. The allocate is doing a validity check
> and something is wrong from an overwrite.
>
> FWIW this is pretty early in the test I think.
>
>
>
>
>> Also, setting a watchpoint doesn't help:
>>
>
> Look manually at say 32 bytes at that address at various points during the
> program's execution. I think this is one where a binary search for the
> corrupting action happens.
>
> Is this using your scheduler as the default? If so, I'd be suspicious of
> anything allocated for it and if you were riding outside an area allocated
> for you.
>
>>
>> Thread 1 hit Breakpoint 6, Init (argument=2107944) at
>> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:26
>> 26  TEST_BEGIN();
>> (gdb) watch *(unsigned int)*  0x202ba8
>> Hardware watchpoint 13: *(unsigned int)*  0x202ba8
>> (gdb) c
>> Continuing.
>>
>> Thread 1 hit Breakpoint 5, _Terminate
>> (the_source=RTEMS_FATAL_SOURCE_HEAP, the_error=2125180) at
>> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/score/src/interr.c:38
>> 38  _User_extensions_Fatal( the_source, the_error );
>>
>>
>>
>> On Wed, Mar 3, 2021 at 10:20 PM Gedare Bloom  wrote:
>>
>>> On Wed, Mar 3, 2021 at 9:49 AM Gedare Bloom  wrote:
>>> >
>>> > On Wed, Mar 3, 2021 at 9:28 AM Joel Sherrill 
>>> wrote:
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Mar 3, 2021 at 9:50 AM Gedare Bloom 
>>> wrote:
>>> > >>
>>> > >> On Wed, Mar 3, 2021 at 12:08 AM Richi Dubey 
>>> wrote:
>>> > >> >
>>> > >> > What's the element written after the free? I set a watch at the
>>> exact block location, but it doesn't work:
>>> > >> >
>>> > >> > Hardware watchpoint 7: *0x202ba8
>>> > >> > (gdb) watch *0x206fec
>>> > >> > Hardware watchpoint 8: *0x206fec
>>> > >> That's just the first byte in the block. If you can figure out which
>>> > >> bytes/words in the block get accessed that would help you.
>>> > >
>>> > >
>>> > > What about watch *(unsigned int)*  0x202ba8?
>>> > >
>>> > > Won't that look at more bytes?
>>> >
>>> > And this is just the first byte of the workspace area.
>>> >
>>> 4 bytes :)
>>> > >
>>> > > In case you do need to look at more bytes in the fence...
>>> > > breaking at _Terminate and doing a back trace will give
>>> > > you the exact line the error is raised from. You can then set a
>>> > > breakpoint at that on the next line and look at local variables.
>>> > > The corruption may be in the fence somewhere beyond the
>>> > > first 32-bits.
>>> > >
>>> In the case of heap corruption, the corruption is detected after it
>>> already happened. Narrowing down when/where the corruption happens is
>>> necessary. The next thing to do would be to examine the pattern that
>>> triggers the violation, and see where it got modified. This might
>>> provide a byte address to set a watch on.
>>>
>>> > > Sometimes it is easy to binary search for an issue like this
>>> > > on a simulator. But with a watchpoint, you should be able to
>>> > > determine the precise word which is corrupted in the fence
>>> > > and break on that write.
>>> > >
>>> > > --joel
>>> > >>
>>> > >>
>>> > >> > (gdb) c
>>> > >> > Continuing.
>>> > >> >

RSB build issue with rtems-libbsd

2021-03-05 Thread Vijay Kumar Banerjee

Hello,

I'm getting the following error when trying to build rtems-libbsd from
RSB. Is there anything that I'm missing?

```
../source-builder/sb-set-builder --prefix=$RTEMS6_PREFIX
6/rtems-libbsd --host=powerpc-rtems6 --with-rtems-bsp=beatnik
RTEMS Source Builder - Set Builder, 6 (102cb1e6450f)
warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
Build Set: 6/rtems-libbsd
config: tools/rtems-libbsd-6.cfg
error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=7400
-I/home/vijay/development/rtems/6/powerpc-rtems6/beatnik/lib/include
==
Build FAILED
Build Set: Time 0:00:00.046141
Build FAILED

```

Commenting these checks from rtems-bsp.cfg gets it building.

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

Re: [PATCH] main_edit.c: Fix Unchecked return value (CID #1255318)

2021-03-05 Thread Gedare Bloom

ok

On Fri, Mar 5, 2021 at 1:55 PM Ryan Long  wrote:
>
> CID 1255318: Unchecked return value in display_line().
>
> Updates #4257
> ---
>  cpukit/libmisc/shell/main_edit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libmisc/shell/main_edit.c 
> b/cpukit/libmisc/shell/main_edit.c
> index a011049..8ac7eee 100644
> --- a/cpukit/libmisc/shell/main_edit.c
> +++ b/cpukit/libmisc/shell/main_edit.c
> @@ -1089,7 +1089,7 @@ static void display_line(struct editor *ed, int pos, 
> int fullline) {
>int selstart, selend, ch;
>char *s;
>
> -  get_selection(ed, , );
> +  (void) get_selection(ed, , );
>while (col < maxcol) {
>  if (margin == 0) {
>if (!hilite && pos >= selstart && pos < selend) {
> --
> 1.8.3.1
>
> ___
> 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 v3 0/4] Fix Unchecked return value from libarary

2021-03-05 Thread Gedare Bloom

This set is ok

On Fri, Mar 5, 2021 at 1:42 PM Ryan Long  wrote:
>
> Hi,
>
> Here are the patches with the fix to main_chmod.c.
>
> Thanks,
> Ryan
>
> Ryan Long (4):
>   gen_uuid.c: Fix two Unchecked return value from library errors
>   main_chmod.c: Fix Unchecked return value from library (CID #1063856)
>   pwdgrp.c: Fix Unchecked return value from library (CID #1255518)
>   main_help.c: Unchecked return value from library (CID #1437650)
>
>  cpukit/libcsupport/src/pwdgrp.c   |  6 +-
>  cpukit/libmisc/shell/main_chmod.c |  7 +--
>  cpukit/libmisc/shell/main_help.c  |  3 ++-
>  cpukit/libmisc/uuid/gen_uuid.c| 11 ---
>  4 files changed, 20 insertions(+), 7 deletions(-)
>
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Fix Unchecked return value issue

2021-03-05 Thread Ryan Long

Hi,

Here's the fix for main_edit.c. I just just needed to add a space
between (void) and the function call.

Thanks,
Ryan

Ryan Long (1):
  main_edit.c: Fix Unchecked return value (CID #1255318)

 cpukit/libmisc/shell/main_edit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.8.3.1

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

[PATCH] main_edit.c: Fix Unchecked return value (CID #1255318)

2021-03-05 Thread Ryan Long

CID 1255318: Unchecked return value in display_line().

Updates #4257
---
 cpukit/libmisc/shell/main_edit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index a011049..8ac7eee 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -1089,7 +1089,7 @@ static void display_line(struct editor *ed, int pos, int 
fullline) {
   int selstart, selend, ch;
   char *s;
 
-  get_selection(ed, , );
+  (void) get_selection(ed, , );
   while (col < maxcol) {
 if (margin == 0) {
   if (!hilite && pos >= selstart && pos < selend) {
-- 
1.8.3.1

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

[PATCH v3 0/4] Fix Unchecked return value from libarary

2021-03-05 Thread Ryan Long

Hi,

Here are the patches with the fix to main_chmod.c.

Thanks,
Ryan

Ryan Long (4):
  gen_uuid.c: Fix two Unchecked return value from library errors
  main_chmod.c: Fix Unchecked return value from library (CID #1063856)
  pwdgrp.c: Fix Unchecked return value from library (CID #1255518)
  main_help.c: Unchecked return value from library (CID #1437650)

 cpukit/libcsupport/src/pwdgrp.c   |  6 +-
 cpukit/libmisc/shell/main_chmod.c |  7 +--
 cpukit/libmisc/shell/main_help.c  |  3 ++-
 cpukit/libmisc/uuid/gen_uuid.c| 11 ---
 4 files changed, 20 insertions(+), 7 deletions(-)

-- 
1.8.3.1

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

[PATCH v3 4/4] main_help.c: Unchecked return value from library (CID #1437650)

2021-03-05 Thread Ryan Long

CID 1437650: Unchecked return value from library in rtems_shell_help().

Closes #4291
---
 cpukit/libmisc/shell/main_help.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_help.c b/cpukit/libmisc/shell/main_help.c
index 611f2e0..9f59e9d 100644
--- a/cpukit/libmisc/shell/main_help.c
+++ b/cpukit/libmisc/shell/main_help.c
@@ -119,7 +119,8 @@ static int rtems_shell_help(
 rtems_shell_cmd_t *shell_cmd;
 
 if (lines && (line > lines)) {
-  printf("Press any key to continue...");getchar();
+  printf("Press any key to continue...");
+  (void) getchar(); /* we only want to know a character was pressed */
   printf("\n");
   line = 0;
 }
-- 
1.8.3.1

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

[PATCH v3 1/4] gen_uuid.c: Fix two Unchecked return value from library errors

2021-03-05 Thread Ryan Long

CID 1049146: Unchecked return value from library in get_clock().
CID 1049147: Unchecked return value from library in get_random_fd().

Closes #4280
---
 cpukit/libmisc/uuid/gen_uuid.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/cpukit/libmisc/uuid/gen_uuid.c b/cpukit/libmisc/uuid/gen_uuid.c
index 3ca75a0..5bb34c0 100644
--- a/cpukit/libmisc/uuid/gen_uuid.c
+++ b/cpukit/libmisc/uuid/gen_uuid.c
@@ -155,6 +155,7 @@ static int get_random_fd(void)
struct timeval  tv;
static int  fd = -2;
int i;
+   int sc;
 
if (fd == -2) {
gettimeofday(, 0);
@@ -164,8 +165,10 @@ static int get_random_fd(void)
fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
if (fd >= 0) {
i = fcntl(fd, F_GETFD);
-   if (i >= 0)
-   fcntl(fd, F_SETFD, i | FD_CLOEXEC);
+   if (i >= 0) {
+   sc = fcntl(fd, F_SETFD, i | FD_CLOEXEC);
+   _Assert_Unused_variable_unequal(sc, -1);
+   }
}
 #endif
srand((getpid() << ((sizeof(pid_t)*CHAR_BIT)>>1)) ^ getuid() ^ 
tv.tv_sec ^ tv.tv_usec);
@@ -334,6 +337,7 @@ static int get_clock(uint32_t *clock_high, uint32_t 
*clock_low,
uint64_tclock_reg;
mode_t  save_umask;
int len;
+   int sc;
 
if (state_fd == -2) {
save_umask = umask(0);
@@ -426,7 +430,8 @@ try_again:
}
rewind(state_f);
fl.l_type = F_UNLCK;
-   fcntl(state_fd, F_SETLK, );
+   sc = fcntl(state_fd, F_SETLK, );
+   _Assert_Unused_variable_unequal(sc, -1);
}
 
*clock_high = clock_reg >> 32;
-- 
1.8.3.1

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

[PATCH v3 3/4] pwdgrp.c: Fix Unchecked return value from library (CID #1255518)

2021-03-05 Thread Ryan Long

CID 1255518: Unchecked return value from library in pwdgrp_init().

Closes #4282
---
 cpukit/libcsupport/src/pwdgrp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/cpukit/libcsupport/src/pwdgrp.c b/cpukit/libcsupport/src/pwdgrp.c
index a97d397..f4a10f7 100644
--- a/cpukit/libcsupport/src/pwdgrp.c
+++ b/cpukit/libcsupport/src/pwdgrp.c
@@ -36,6 +36,7 @@
 #include 
 
 #include 
+#include 
 
 #include "pwdgrp.h"
 
@@ -62,10 +63,13 @@ static void init_file(const char *name, const char *content)
  */
 static void pwdgrp_init(void)
 {
+  int sc;
+
   /*
* Do the best to create this directory.
*/
-  mkdir("/etc", S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
+  sc = mkdir("/etc", S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
+  _Assert_Unused_variable_equals(sc, 0);
 
   /*
*  Initialize /etc/passwd
-- 
1.8.3.1

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

[PATCH v3 2/4] main_chmod.c: Fix Unchecked return value from library (CID #1063856)

2021-03-05 Thread Ryan Long

CID 1063856: Unchecked return value from library in
rtems_shell_main_chmod().

Closes #4281
---
 cpukit/libmisc/shell/main_chmod.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/cpukit/libmisc/shell/main_chmod.c 
b/cpukit/libmisc/shell/main_chmod.c
index 0c39072..8b932fa 100644
--- a/cpukit/libmisc/shell/main_chmod.c
+++ b/cpukit/libmisc/shell/main_chmod.c
@@ -34,6 +34,7 @@ static int rtems_shell_main_chmod(
   int   n;
   mode_tmode;
   unsigned long tmp;
+  int   sc;
 
   if (argc < 2) {
 fprintf(stderr,"%s: too few arguments\n", argv[0]);
@@ -52,8 +53,10 @@ static int rtems_shell_main_chmod(
   /*
*  Now change the files modes
*/
-  for (n=2 ; n < argc ; n++)
-chmod(argv[n++], mode);
+  for (n=2 ; n < argc ; n++) {
+sc = chmod(argv[n++], mode);
+_Assert_Unused_variable_unequal(sc, -1);
+  }
 
   return 0;
 }
-- 
1.8.3.1

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

Fwd: Makefile.in not regenerated for libc/posix

2021-03-05 Thread Joel Sherrill

Unfortunately newlib needs to bump again to catch the minor fix

-- Forwarded message -
From: Eshan Dhawan via Newlib 
Date: Fri, Mar 5, 2021, 1:27 PM
Subject: Makefile.in not regenerated for libc/posix
To: Newlib 


Hello,
Makefile.in wasn’t regenerated for libc/posix
For the commit:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=d8ee634506424ce8b3bea057b84ec82dfdd7a821
So the changes from the commit are not building

Thanks
- Eshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/4] Fix Unchecked return value from library issues

2021-03-05 Thread Gedare Bloom

1, 3, 4 are fine. 2 needs to be fixed.

On Fri, Mar 5, 2021 at 12:47 PM Ryan Long  wrote:
>
> Hi,
>
> Here are the patches with the recommended fixes.
>
> Thanks,
> Ryan
>
> Ryan Long (4):
>   gen_uuid.c: Fix two Unchecked return value from library errors
>   main_chmod.c: Fix Unchecked return value from library (CID #1063856)
>   pwdgrp.c: Fix Unchecked return value from library (CID #1255518)
>   main_help.c: Unchecked return value from library (CID #1437650)
>
>  cpukit/libcsupport/src/pwdgrp.c   |  6 +-
>  cpukit/libmisc/shell/main_chmod.c |  5 -
>  cpukit/libmisc/shell/main_help.c  |  3 ++-
>  cpukit/libmisc/uuid/gen_uuid.c| 11 ---
>  4 files changed, 19 insertions(+), 6 deletions(-)
>
> --
> 1.8.3.1
>
> ___
> 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 v2 2/4] main_chmod.c: Fix Unchecked return value from library (CID #1063856)

2021-03-05 Thread Gedare Bloom

On Fri, Mar 5, 2021 at 12:47 PM Ryan Long  wrote:
>
> CID 1063856: Unchecked return value from library in
> rtems_shell_main_chmod().
>
> Closes #4281
> ---
>  cpukit/libmisc/shell/main_chmod.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/cpukit/libmisc/shell/main_chmod.c 
> b/cpukit/libmisc/shell/main_chmod.c
> index 0c39072..df18ef1 100644
> --- a/cpukit/libmisc/shell/main_chmod.c
> +++ b/cpukit/libmisc/shell/main_chmod.c
> @@ -34,6 +34,7 @@ static int rtems_shell_main_chmod(
>int   n;
>mode_tmode;
>unsigned long tmp;
> +  int   sc;
>
>if (argc < 2) {
>  fprintf(stderr,"%s: too few arguments\n", argv[0]);
> @@ -53,7 +54,9 @@ static int rtems_shell_main_chmod(
> *  Now change the files modes
> */
>for (n=2 ; n < argc ; n++)
> -chmod(argv[n++], mode);
> +sc = chmod(argv[n++], mode);
> +_Assert_Unused_variable_unequal(sc, -1);

This one has a problem, the for loop doesn't have { }.

> +
>
>return 0;
>  }
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 4/4] main_help.c: Unchecked return value from library (CID #1437650)

2021-03-05 Thread Ryan Long

CID 1437650: Unchecked return value from library in rtems_shell_help().

Closes #4291
---
 cpukit/libmisc/shell/main_help.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_help.c b/cpukit/libmisc/shell/main_help.c
index 611f2e0..9f59e9d 100644
--- a/cpukit/libmisc/shell/main_help.c
+++ b/cpukit/libmisc/shell/main_help.c
@@ -119,7 +119,8 @@ static int rtems_shell_help(
 rtems_shell_cmd_t *shell_cmd;
 
 if (lines && (line > lines)) {
-  printf("Press any key to continue...");getchar();
+  printf("Press any key to continue...");
+  (void) getchar(); /* we only want to know a character was pressed */
   printf("\n");
   line = 0;
 }
-- 
1.8.3.1

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

[PATCH v2 3/4] pwdgrp.c: Fix Unchecked return value from library (CID #1255518)

2021-03-05 Thread Ryan Long

CID 1255518: Unchecked return value from library in pwdgrp_init().

Closes #4282
---
 cpukit/libcsupport/src/pwdgrp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/cpukit/libcsupport/src/pwdgrp.c b/cpukit/libcsupport/src/pwdgrp.c
index a97d397..f4a10f7 100644
--- a/cpukit/libcsupport/src/pwdgrp.c
+++ b/cpukit/libcsupport/src/pwdgrp.c
@@ -36,6 +36,7 @@
 #include 
 
 #include 
+#include 
 
 #include "pwdgrp.h"
 
@@ -62,10 +63,13 @@ static void init_file(const char *name, const char *content)
  */
 static void pwdgrp_init(void)
 {
+  int sc;
+
   /*
* Do the best to create this directory.
*/
-  mkdir("/etc", S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
+  sc = mkdir("/etc", S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
+  _Assert_Unused_variable_equals(sc, 0);
 
   /*
*  Initialize /etc/passwd
-- 
1.8.3.1

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

[PATCH v2 2/4] main_chmod.c: Fix Unchecked return value from library (CID #1063856)

2021-03-05 Thread Ryan Long

CID 1063856: Unchecked return value from library in
rtems_shell_main_chmod().

Closes #4281
---
 cpukit/libmisc/shell/main_chmod.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_chmod.c 
b/cpukit/libmisc/shell/main_chmod.c
index 0c39072..df18ef1 100644
--- a/cpukit/libmisc/shell/main_chmod.c
+++ b/cpukit/libmisc/shell/main_chmod.c
@@ -34,6 +34,7 @@ static int rtems_shell_main_chmod(
   int   n;
   mode_tmode;
   unsigned long tmp;
+  int   sc; 
 
   if (argc < 2) {
 fprintf(stderr,"%s: too few arguments\n", argv[0]);
@@ -53,7 +54,9 @@ static int rtems_shell_main_chmod(
*  Now change the files modes
*/
   for (n=2 ; n < argc ; n++)
-chmod(argv[n++], mode);
+sc = chmod(argv[n++], mode);
+_Assert_Unused_variable_unequal(sc, -1);
+
 
   return 0;
 }
-- 
1.8.3.1

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

[PATCH v2 0/4] Fix Unchecked return value from library issues

2021-03-05 Thread Ryan Long

Hi,

Here are the patches with the recommended fixes.

Thanks,
Ryan

Ryan Long (4):
  gen_uuid.c: Fix two Unchecked return value from library errors
  main_chmod.c: Fix Unchecked return value from library (CID #1063856)
  pwdgrp.c: Fix Unchecked return value from library (CID #1255518)
  main_help.c: Unchecked return value from library (CID #1437650)

 cpukit/libcsupport/src/pwdgrp.c   |  6 +-
 cpukit/libmisc/shell/main_chmod.c |  5 -
 cpukit/libmisc/shell/main_help.c  |  3 ++-
 cpukit/libmisc/uuid/gen_uuid.c| 11 ---
 4 files changed, 19 insertions(+), 6 deletions(-)

-- 
1.8.3.1

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

[PATCH v2 1/4] gen_uuid.c: Fix two Unchecked return value from library errors

2021-03-05 Thread Ryan Long

CID 1049146: Unchecked return value from library in get_clock().
CID 1049147: Unchecked return value from library in get_random_fd().

Closes #4280
---
 cpukit/libmisc/uuid/gen_uuid.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/cpukit/libmisc/uuid/gen_uuid.c b/cpukit/libmisc/uuid/gen_uuid.c
index 3ca75a0..5bb34c0 100644
--- a/cpukit/libmisc/uuid/gen_uuid.c
+++ b/cpukit/libmisc/uuid/gen_uuid.c
@@ -155,6 +155,7 @@ static int get_random_fd(void)
struct timeval  tv;
static int  fd = -2;
int i;
+   int sc;
 
if (fd == -2) {
gettimeofday(, 0);
@@ -164,8 +165,10 @@ static int get_random_fd(void)
fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
if (fd >= 0) {
i = fcntl(fd, F_GETFD);
-   if (i >= 0)
-   fcntl(fd, F_SETFD, i | FD_CLOEXEC);
+   if (i >= 0) {
+   sc = fcntl(fd, F_SETFD, i | FD_CLOEXEC);
+   _Assert_Unused_variable_unequal(sc, -1);
+   }
}
 #endif
srand((getpid() << ((sizeof(pid_t)*CHAR_BIT)>>1)) ^ getuid() ^ 
tv.tv_sec ^ tv.tv_usec);
@@ -334,6 +337,7 @@ static int get_clock(uint32_t *clock_high, uint32_t 
*clock_low,
uint64_tclock_reg;
mode_t  save_umask;
int len;
+   int sc;
 
if (state_fd == -2) {
save_umask = umask(0);
@@ -426,7 +430,8 @@ try_again:
}
rewind(state_f);
fl.l_type = F_UNLCK;
-   fcntl(state_fd, F_SETLK, );
+   sc = fcntl(state_fd, F_SETLK, );
+   _Assert_Unused_variable_unequal(sc, -1);
}
 
*clock_high = clock_reg >> 32;
-- 
1.8.3.1

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

Re: [PATCH rtems-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-05 Thread Vijay Kumar Banerjee

On Fri, Mar 5, 2021 at 12:08 PM Vijay Kumar Banerjee  wrote:
>
> On Fri, Mar 5, 2021 at 12:07 PM Gedare Bloom  wrote:
> >
> > On Fri, Mar 5, 2021 at 11:42 AM Vijay Kumar Banerjee  
> > wrote:
> > >
> > > ---
> > >  netlegacy.py | 27 +--
> > >  testsuites/telnetd01/wscript |  2 +-
> > >  2 files changed, 22 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/netlegacy.py b/netlegacy.py
> > > index 037e2ee..0889548 100644
> > > --- a/netlegacy.py
> > > +++ b/netlegacy.py
> > > @@ -31,7 +31,8 @@ import os
> > >
> > >  source_files = []
> > >  include_files = {}
> > > -exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 
> > > 'bsps']
> > > +exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 
> > > 'bsps',
> > > +'telnetd']
> > >  exclude_headers = ['rtems-bsd-user-space.h', 'rtems-bsd-kernel-space.h']
> > >
> > >  for root, dirs, files in os.walk("."):
> > > @@ -51,6 +52,8 @@ def build(bld):
> > >  bsp = bld.env.RTEMS_ARCH_BSP.split('-')[-1]
> > >  pppd_source = [os.path.join('./pppd', s)
> > > for s in os.listdir('./pppd') if s[-2:] == '.c']
> > > +telnetd_source = [os.path.join('./telnetd', s)
> > > +  for s in os.listdir('telnetd') if s[-2:] == '.c']
> > >
> > >  bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
> > >
> > > @@ -98,12 +101,24 @@ def build(bld):
> > >use='networking',
> > >source=pppd_source)
> > >
> > > +bld.stlib(target='telnetd',
> > > +  features='c',
> > > +  includes=ip,
> > > +  use='networking',
> > > +  source=telnetd_source)
> > > +
> > >  bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> > > -  ["libnetworking.a"])
> > > -bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> > > +  ["libnetworking.a", 'libpppd.a', 'libtelnetd.a'])
> > > +bld.install_files(os.path.join('${PREFIX}', arch_lib_path,
> > > +   'include', 'libchip'),
> > >[os.path.join('./bsps/include/libchip/', f)
> > >for f in os.listdir('./bsps/include/libchip/')])
> > >  for i in include_files:
> > > -bld.install_files(os.path.join('${PREFIX}',
> > > -  arch_lib_path, i),
> > > -  include_files[i])
> > > +if 'include' in i.split('/'):
> > > +bld.install_files(os.path.join('${PREFIX}',
> > > +   arch_lib_path, i),
> > > +  include_files[i])
> > > +else:
> > > +bld.install_files(os.path.join('${PREFIX}',
> > > +   arch_lib_path, 'include', i),
> > > +  include_files[i])
> > > diff --git a/testsuites/telnetd01/wscript b/testsuites/telnetd01/wscript
> > > index 8a48b90..fd573be 100644
> > > --- a/testsuites/telnetd01/wscript
> > > +++ b/testsuites/telnetd01/wscript
> > > @@ -42,5 +42,5 @@ def build(bld):
> > >  features='c cprogram',
> > >  cfags=['-O2', '-g'],
> > unrelated: should this be cflags?
> >
> Thanks, I'll push with this one fixed.
>
Pushed. :)

> Best regards,
> Vijay
> > go ahead and push the fix, you can be a little bit aggressive for a
> > few days to get this repo "stable"
> >
> > >  includes='. .. ../include ../../ ../../include',
> > > -use=['networking'],
> > > +use=['telnetd', 'networking'],
> > >  source='init.c')
> > > --
> > > 2.26.2
> > >
> > > ___
> > > 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-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-05 Thread Vijay Kumar Banerjee

On Fri, Mar 5, 2021 at 12:07 PM Gedare Bloom  wrote:
>
> On Fri, Mar 5, 2021 at 11:42 AM Vijay Kumar Banerjee  wrote:
> >
> > ---
> >  netlegacy.py | 27 +--
> >  testsuites/telnetd01/wscript |  2 +-
> >  2 files changed, 22 insertions(+), 7 deletions(-)
> >
> > diff --git a/netlegacy.py b/netlegacy.py
> > index 037e2ee..0889548 100644
> > --- a/netlegacy.py
> > +++ b/netlegacy.py
> > @@ -31,7 +31,8 @@ import os
> >
> >  source_files = []
> >  include_files = {}
> > -exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 
> > 'bsps']
> > +exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 
> > 'bsps',
> > +'telnetd']
> >  exclude_headers = ['rtems-bsd-user-space.h', 'rtems-bsd-kernel-space.h']
> >
> >  for root, dirs, files in os.walk("."):
> > @@ -51,6 +52,8 @@ def build(bld):
> >  bsp = bld.env.RTEMS_ARCH_BSP.split('-')[-1]
> >  pppd_source = [os.path.join('./pppd', s)
> > for s in os.listdir('./pppd') if s[-2:] == '.c']
> > +telnetd_source = [os.path.join('./telnetd', s)
> > +  for s in os.listdir('telnetd') if s[-2:] == '.c']
> >
> >  bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
> >
> > @@ -98,12 +101,24 @@ def build(bld):
> >use='networking',
> >source=pppd_source)
> >
> > +bld.stlib(target='telnetd',
> > +  features='c',
> > +  includes=ip,
> > +  use='networking',
> > +  source=telnetd_source)
> > +
> >  bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> > -  ["libnetworking.a"])
> > -bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> > +  ["libnetworking.a", 'libpppd.a', 'libtelnetd.a'])
> > +bld.install_files(os.path.join('${PREFIX}', arch_lib_path,
> > +   'include', 'libchip'),
> >[os.path.join('./bsps/include/libchip/', f)
> >for f in os.listdir('./bsps/include/libchip/')])
> >  for i in include_files:
> > -bld.install_files(os.path.join('${PREFIX}',
> > -  arch_lib_path, i),
> > -  include_files[i])
> > +if 'include' in i.split('/'):
> > +bld.install_files(os.path.join('${PREFIX}',
> > +   arch_lib_path, i),
> > +  include_files[i])
> > +else:
> > +bld.install_files(os.path.join('${PREFIX}',
> > +   arch_lib_path, 'include', i),
> > +  include_files[i])
> > diff --git a/testsuites/telnetd01/wscript b/testsuites/telnetd01/wscript
> > index 8a48b90..fd573be 100644
> > --- a/testsuites/telnetd01/wscript
> > +++ b/testsuites/telnetd01/wscript
> > @@ -42,5 +42,5 @@ def build(bld):
> >  features='c cprogram',
> >  cfags=['-O2', '-g'],
> unrelated: should this be cflags?
>
Thanks, I'll push with this one fixed.

Best regards,
Vijay
> go ahead and push the fix, you can be a little bit aggressive for a
> few days to get this repo "stable"
>
> >  includes='. .. ../include ../../ ../../include',
> > -use=['networking'],
> > +use=['telnetd', 'networking'],
> >  source='init.c')
> > --
> > 2.26.2
> >
> > ___
> > 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-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-05 Thread Gedare Bloom

On Fri, Mar 5, 2021 at 11:42 AM Vijay Kumar Banerjee  wrote:
>
> ---
>  netlegacy.py | 27 +--
>  testsuites/telnetd01/wscript |  2 +-
>  2 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/netlegacy.py b/netlegacy.py
> index 037e2ee..0889548 100644
> --- a/netlegacy.py
> +++ b/netlegacy.py
> @@ -31,7 +31,8 @@ import os
>
>  source_files = []
>  include_files = {}
> -exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 'bsps']
> +exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 'bsps',
> +'telnetd']
>  exclude_headers = ['rtems-bsd-user-space.h', 'rtems-bsd-kernel-space.h']
>
>  for root, dirs, files in os.walk("."):
> @@ -51,6 +52,8 @@ def build(bld):
>  bsp = bld.env.RTEMS_ARCH_BSP.split('-')[-1]
>  pppd_source = [os.path.join('./pppd', s)
> for s in os.listdir('./pppd') if s[-2:] == '.c']
> +telnetd_source = [os.path.join('./telnetd', s)
> +  for s in os.listdir('telnetd') if s[-2:] == '.c']
>
>  bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
>
> @@ -98,12 +101,24 @@ def build(bld):
>use='networking',
>source=pppd_source)
>
> +bld.stlib(target='telnetd',
> +  features='c',
> +  includes=ip,
> +  use='networking',
> +  source=telnetd_source)
> +
>  bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> -  ["libnetworking.a"])
> -bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> +  ["libnetworking.a", 'libpppd.a', 'libtelnetd.a'])
> +bld.install_files(os.path.join('${PREFIX}', arch_lib_path,
> +   'include', 'libchip'),
>[os.path.join('./bsps/include/libchip/', f)
>for f in os.listdir('./bsps/include/libchip/')])
>  for i in include_files:
> -bld.install_files(os.path.join('${PREFIX}',
> -  arch_lib_path, i),
> -  include_files[i])
> +if 'include' in i.split('/'):
> +bld.install_files(os.path.join('${PREFIX}',
> +   arch_lib_path, i),
> +  include_files[i])
> +else:
> +bld.install_files(os.path.join('${PREFIX}',
> +   arch_lib_path, 'include', i),
> +  include_files[i])
> diff --git a/testsuites/telnetd01/wscript b/testsuites/telnetd01/wscript
> index 8a48b90..fd573be 100644
> --- a/testsuites/telnetd01/wscript
> +++ b/testsuites/telnetd01/wscript
> @@ -42,5 +42,5 @@ def build(bld):
>  features='c cprogram',
>  cfags=['-O2', '-g'],
unrelated: should this be cflags?

go ahead and push the fix, you can be a little bit aggressive for a
few days to get this repo "stable"

>  includes='. .. ../include ../../ ../../include',
> -use=['networking'],
> +use=['telnetd', 'networking'],
>  source='init.c')
> --
> 2.26.2
>
> ___
> 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 0/3] Fix Missing break in switch Coverity issues

2021-03-05 Thread Gedare Bloom

On Fri, Mar 5, 2021 at 11:48 AM Sebastian Huber
 wrote:
>
> On 05/03/2021 19:40, Joel Sherrill wrote:
>
> > On Fri, Mar 5, 2021, 12:25 PM Sebastian Huber
> >  > > wrote:
> >
> > On 05/03/2021 16:27, Gedare Bloom wrote:
> >
> > > Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so
> > that we
> > > can update them in future if needed for other tools?
> > I would just pick a name which is understood by GCC, clang, and
> > Coverity. I guess other tools will understand this or why did you
> > buy them?
> >
> >
> > Well we didn't pay for any of those but are you wanting a macro or
> > just the comment?
>
> I would just use a comment which is understood by GCC, clang, and
> Coverity. What does Linux use?
>
That's fine, if there is a de facto standard to use, we can go for it.

> --
> 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: Checking Status of My Outstanding Patches

2021-03-05 Thread Gedare Bloom

Yes, that looks right. Joel, you can push his grlib patches and the
case fall-throughs.

On Fri, Mar 5, 2021 at 11:19 AM Ryan Long  wrote:
>
> Hi,
>
>
>
> Since I’ve sent a lot of patches this week, I just want to verify which are 
> ready to be merged and what needs to be resubmitted.
>
>
>
> Ready to be merged:
>
>
>
> Grlib patches:
>
> grspw.c
> gr_rasta_spw_router.c
> gr_rasta_tmtc.c
> gr_leon4_n2x.c
> gr_701.c
> gr_cpci_gr740.c
> satcan.c
> b1553brm.c
> grcan.c
> gr_rasta_adcdac.c (was accidentally labeled as gr_rasta_tmtc.c in commit 
> message)
> gr_tmtc_1553.c
> grtc.c
>
>
>
> Other:
>
> Missing break in switch
>
> pci_cfg_read.c
> cpuusagetop.c
>
>
>
> What needs to be resubmitted:
>
> Unchecked return value from library
>
> gen_uuid.c
> cpuusagetop.c
>
> Unchecked return value
>
> main_edit.c
>
>
>
> Thanks,
>
> Ryan
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] bsps/shared: Allow setting baud rate for zynq uart

2021-03-05 Thread Jan Sommer

Closes #4236
---
 bsps/arm/shared/serial/zynq-uart.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/bsps/arm/shared/serial/zynq-uart.c 
b/bsps/arm/shared/serial/zynq-uart.c
index a0dfc0c929..f298719fde 100644
--- a/bsps/arm/shared/serial/zynq-uart.c
+++ b/bsps/arm/shared/serial/zynq-uart.c
@@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(
 {
   zynq_uart_context *ctx = (zynq_uart_context *) context;
   volatile zynq_uart *regs = ctx->regs;
+  int32_t baud;
   uint32_t brgr = 0;
   uint32_t bauddiv = 0;
   uint32_t mode = 0;
   int rc;
 
-  rc = zynq_cal_baud_rate(115200, , , regs->mode);
-  if (rc != 0)
-return rc;
+  /*
+   * Determine the baud rate
+   */
+  baud = rtems_termios_baud_to_number(term->c_ospeed);
+
+  if (baud > 0) {
+rc = zynq_cal_baud_rate(baud, , , regs->mode);
+if (rc != 0)
+  return rc;
+  }
 
   /*
* Configure the mode register
@@ -202,8 +210,11 @@ static bool zynq_uart_set_attributes(
 
   regs->control &= ~(ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN);
   regs->mode = mode;
-  regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
-  regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
+  /* Ignore baud rate of B0. There are no modem control lines to de-assert */
+  if (baud > 0) {
+regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
+regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
+  }
   regs->control |= ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
 
   return true;
-- 
2.17.1

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

[5 PATCH 0/2] Backport fixes to zynq uart to RTEMS5

2021-03-05 Thread Jan Sommer

This patchset backports the commits of Kinsey Moore and myself, which
fix the stdin behavior for the zynq-uart based console driver.
I checked the behavior on hardware with the termios.exe application.
Before, the scanf and similar functions do not wait for user input and return
immediately. With the patches the application behaves as expected.

A corresponding ticket can be found here: https://devel.rtems.org/ticket/4236

Small side note:
I noticed that the ARM BSP docs for RTEMS5 list mostly TODO.
Should I create a patchset backporting the BSP documentation or do you
want to do that in one go as part of the 5.2 release preparation?

Best regards,

Jan

Jan Sommer (1):
  bsps/shared: Allow setting baud rate for zynq uart

Kinsey Moore (1):
  zynq-uart: Fix set_attributes implementation

 bsps/arm/include/bsp/zynq-uart.h  |  7 +++
 bsps/arm/shared/serial/zynq-uart-polled.c |  2 +-
 bsps/arm/shared/serial/zynq-uart.c| 77 ---
 3 files changed, 75 insertions(+), 11 deletions(-)

-- 
2.17.1

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

[PATCH 1/2] zynq-uart: Fix set_attributes implementation

2021-03-05 Thread Jan Sommer

From: Kinsey Moore 

The zynq-uart set_attributes implementation was configured to always
return false which causes spconsole01 to fail. This restores the
disabled implementation which sets the baud rate registers
appropriately and allows spconsole01 to pass. This also expands the
set_attributes functionality to allow setting of the stop bits,
character width, and parity.

Updates #4236
---
 bsps/arm/include/bsp/zynq-uart.h  |  7 +++
 bsps/arm/shared/serial/zynq-uart-polled.c |  2 +-
 bsps/arm/shared/serial/zynq-uart.c| 56 +--
 3 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/bsps/arm/include/bsp/zynq-uart.h b/bsps/arm/include/bsp/zynq-uart.h
index 20c3c9b653..5a6c926bec 100644
--- a/bsps/arm/include/bsp/zynq-uart.h
+++ b/bsps/arm/include/bsp/zynq-uart.h
@@ -71,6 +71,13 @@ void zynq_uart_write_polled(
   */
 void zynq_uart_reset_tx_flush(zynq_uart_context *ctx);
 
+int zynq_cal_baud_rate(
+  uint32_t  baudrate,
+  uint32_t* brgr,
+  uint32_t* bauddiv,
+  uint32_t  modereg
+);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/bsps/arm/shared/serial/zynq-uart-polled.c 
b/bsps/arm/shared/serial/zynq-uart-polled.c
index e6f478ee07..7fc9590832 100644
--- a/bsps/arm/shared/serial/zynq-uart-polled.c
+++ b/bsps/arm/shared/serial/zynq-uart-polled.c
@@ -40,7 +40,7 @@ uint32_t zynq_uart_input_clock(void)
   return ZYNQ_CLOCK_UART;
 }
 
-static int zynq_cal_baud_rate(uint32_t  baudrate,
+int zynq_cal_baud_rate(uint32_t  baudrate,
   uint32_t* brgr,
   uint32_t* bauddiv,
   uint32_t  modereg)
diff --git a/bsps/arm/shared/serial/zynq-uart.c 
b/bsps/arm/shared/serial/zynq-uart.c
index fc670441b8..a0dfc0c929 100644
--- a/bsps/arm/shared/serial/zynq-uart.c
+++ b/bsps/arm/shared/serial/zynq-uart.c
@@ -142,25 +142,71 @@ static bool zynq_uart_set_attributes(
   const struct termios *term
 )
 {
-#if 0
-  volatile zynq_uart *regs = zynq_uart_get_regs(minor);
+  zynq_uart_context *ctx = (zynq_uart_context *) context;
+  volatile zynq_uart *regs = ctx->regs;
   uint32_t brgr = 0;
   uint32_t bauddiv = 0;
+  uint32_t mode = 0;
   int rc;
 
   rc = zynq_cal_baud_rate(115200, , , regs->mode);
   if (rc != 0)
 return rc;
 
+  /*
+   * Configure the mode register
+   */
+  mode |= ZYNQ_UART_MODE_CHMODE(ZYNQ_UART_MODE_CHMODE_NORMAL);
+
+  /*
+   * Parity
+   */
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_NONE);
+  if (term->c_cflag & PARENB) {
+if (!(term->c_cflag & PARODD)) {
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_ODD);
+} else {
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_EVEN);
+}
+  }
+
+  /*
+   * Character Size
+   */
+  switch (term->c_cflag & CSIZE)
+  {
+  case CS5:
+return false;
+  case CS6:
+mode |= ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_6);
+break;
+  case CS7:
+mode |= ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_7);
+break;
+  case CS8:
+  default:
+mode |= ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_8);
+break;
+  }
+
+  /*
+   * Stop Bits
+   */
+  if (term->c_cflag & CSTOPB) {
+/* 2 stop bits */
+mode |= ZYNQ_UART_MODE_NBSTOP(ZYNQ_UART_MODE_NBSTOP_STOP_2);
+  } else {
+/* 1 stop bit */
+mode |= ZYNQ_UART_MODE_NBSTOP(ZYNQ_UART_MODE_NBSTOP_STOP_1);
+  }
+
   regs->control &= ~(ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN);
+  regs->mode = mode;
   regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
   regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
   regs->control |= ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
 
   return true;
-#else
-  return false;
-#endif
 }
 
 const rtems_termios_device_handler zynq_uart_handler = {
-- 
2.17.1

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

Re: [PATCH 0/3] Fix Missing break in switch Coverity issues

2021-03-05 Thread Sebastian Huber


On 05/03/2021 19:40, Joel Sherrill wrote:

On Fri, Mar 5, 2021, 12:25 PM Sebastian Huber 
> wrote:


On 05/03/2021 16:27, Gedare Bloom wrote:

> Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so
that we
> can update them in future if needed for other tools?
I would just pick a name which is understood by GCC, clang, and
Coverity. I guess other tools will understand this or why did you
buy them?


Well we didn't pay for any of those but are you wanting a macro or 
just the comment?


I would just use a comment which is understood by GCC, clang, and 
Coverity. What does Linux use?


--
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 rtems-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-05 Thread Vijay Kumar Banerjee

---
 netlegacy.py | 27 +--
 testsuites/telnetd01/wscript |  2 +-
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/netlegacy.py b/netlegacy.py
index 037e2ee..0889548 100644
--- a/netlegacy.py
+++ b/netlegacy.py
@@ -31,7 +31,8 @@ import os
 
 source_files = []
 include_files = {}
-exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 'bsps']
+exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include', 'bsps',
+'telnetd']
 exclude_headers = ['rtems-bsd-user-space.h', 'rtems-bsd-kernel-space.h']
 
 for root, dirs, files in os.walk("."):
@@ -51,6 +52,8 @@ def build(bld):
 bsp = bld.env.RTEMS_ARCH_BSP.split('-')[-1]
 pppd_source = [os.path.join('./pppd', s)
for s in os.listdir('./pppd') if s[-2:] == '.c']
+telnetd_source = [os.path.join('./telnetd', s)
+  for s in os.listdir('telnetd') if s[-2:] == '.c']
 
 bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
 
@@ -98,12 +101,24 @@ def build(bld):
   use='networking',
   source=pppd_source)
 
+bld.stlib(target='telnetd',
+  features='c',
+  includes=ip,
+  use='networking',
+  source=telnetd_source)
+
 bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
-  ["libnetworking.a"])
-bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
+  ["libnetworking.a", 'libpppd.a', 'libtelnetd.a'])
+bld.install_files(os.path.join('${PREFIX}', arch_lib_path,
+   'include', 'libchip'),
   [os.path.join('./bsps/include/libchip/', f)
   for f in os.listdir('./bsps/include/libchip/')])
 for i in include_files:
-bld.install_files(os.path.join('${PREFIX}',
-  arch_lib_path, i),
-  include_files[i])
+if 'include' in i.split('/'):
+bld.install_files(os.path.join('${PREFIX}',
+   arch_lib_path, i),
+  include_files[i])
+else:
+bld.install_files(os.path.join('${PREFIX}',
+   arch_lib_path, 'include', i),
+  include_files[i])
diff --git a/testsuites/telnetd01/wscript b/testsuites/telnetd01/wscript
index 8a48b90..fd573be 100644
--- a/testsuites/telnetd01/wscript
+++ b/testsuites/telnetd01/wscript
@@ -42,5 +42,5 @@ def build(bld):
 features='c cprogram',
 cfags=['-O2', '-g'],
 includes='. .. ../include ../../ ../../include',
-use=['networking'],
+use=['telnetd', 'networking'],
 source='init.c')
-- 
2.26.2

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

Re: [PATCH 0/3] Fix Missing break in switch Coverity issues

2021-03-05 Thread Joel Sherrill

On Fri, Mar 5, 2021, 12:25 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/03/2021 16:27, Gedare Bloom wrote:
>
> > Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so that we
> > can update them in future if needed for other tools?
> I would just pick a name which is understood by GCC, clang, and
> Coverity. I guess other tools will understand this or why did you buy them?
>

Well we didn't pay for any of those but are you wanting a macro or just the
comment?

>
> --
> 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

Re: [PATCH 0/3] Fix Missing break in switch Coverity issues

2021-03-05 Thread Sebastian Huber


On 05/03/2021 16:27, Gedare Bloom wrote:


Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so that we
can update them in future if needed for other tools?
I would just pick a name which is understood by GCC, clang, and 
Coverity. I guess other tools will understand this or why did you buy them?


--
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

Checking Status of My Outstanding Patches

2021-03-05 Thread Ryan Long

Hi,

Since I've sent a lot of patches this week, I just want to verify which are 
ready to be merged and what needs to be resubmitted.

Ready to be merged:

Grlib patches:

  *   grspw.c
  *   gr_rasta_spw_router.c
  *   gr_rasta_tmtc.c
  *   gr_leon4_n2x.c
  *   gr_701.c
  *   gr_cpci_gr740.c
  *   satcan.c
  *   b1553brm.c
  *   grcan.c
  *   gr_rasta_adcdac.c (was accidentally labeled as gr_rasta_tmtc.c in commit 
message)
  *   gr_tmtc_1553.c
  *   grtc.c

Other:
Missing break in switch

 *   pci_cfg_read.c
 *   cpuusagetop.c

What needs to be resubmitted:

  *   Unchecked return value from library
 *   gen_uuid.c
 *   cpuusagetop.c
  *   Unchecked return value
 *   main_edit.c

Thanks,
Ryan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v3 1/1] bsps/shared: Allow setting baud rate for zynq uart

2021-03-05 Thread Jan.Sommer

Thanks. Pushed to master.

> -Original Message-
> From: Gedare Bloom 
> Sent: Friday, March 5, 2021 6:48 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v3 1/1] bsps/shared: Allow setting baud rate for zynq
> uart
> 
> Looks good to me.
> 
> On Fri, Mar 5, 2021 at 10:42 AM Jan Sommer  wrote:
> >
> > ---
> >  bsps/shared/dev/serial/zynq-uart.c | 21 -
> >  1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/bsps/shared/dev/serial/zynq-uart.c
> > b/bsps/shared/dev/serial/zynq-uart.c
> > index 8f17d3ca65..cd0d0e7584 100644
> > --- a/bsps/shared/dev/serial/zynq-uart.c
> > +++ b/bsps/shared/dev/serial/zynq-uart.c
> > @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(  {
> >zynq_uart_context *ctx = (zynq_uart_context *) context;
> >volatile zynq_uart *regs = ctx->regs;
> > +  int32_t baud;
> >uint32_t brgr = 0;
> >uint32_t bauddiv = 0;
> >uint32_t mode = 0;
> >int rc;
> >
> > -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> > -  if (rc != 0)
> > -return rc;
> > +  /*
> > +   * Determine the baud rate
> > +   */
> > +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> > +
> > +  if (baud > 0) {
> > +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> > +if (rc != 0)
> > +  return rc;
> > +  }
> >
> >/*
> > * Configure the mode register
> > @@ -202,8 +210,11 @@ static bool zynq_uart_set_attributes(
> >
> >regs->control &= ~(ZYNQ_UART_CONTROL_RXEN |
> ZYNQ_UART_CONTROL_TXEN);
> >regs->mode = mode;
> > -  regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
> > -  regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
> > +  /* Ignore baud rate of B0. There are no modem control lines to
> > + de-assert */  if (baud > 0) {
> > +regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
> > +regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
> > +  }
> >regs->control |= ZYNQ_UART_CONTROL_RXEN |
> ZYNQ_UART_CONTROL_TXEN;
> >
> >return true;
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] user/bsps: Mention fixed console baud rate for zynq

2021-03-05 Thread Jan Sommer

---
 user/bsps/arm/xilinx-zynq.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/arm/xilinx-zynq.rst
index 365c336..29f9cb0 100644
--- a/user/bsps/arm/xilinx-zynq.rst
+++ b/user/bsps/arm/xilinx-zynq.rst
@@ -37,6 +37,18 @@ to return the peripheral clock. Normally this is half the CPU
 clock. This function is declared ``weak`` so you can override the
 default behaviour by providing it in your application.
 
+Console
+---
+
+The console driver for the UARTs will always be initialized to a 
+baud rate of 115200 with 8 bit characters, 1 stop bit and no parity
+bits during start up.
+Previous configurations programmed into the hardware by the Xilinx
+tools or a bootloader will be overwritten.
+
+The settings for the console driver can be changed by the user
+application through the termios API afterwards.
+
 Debugging with xilinx_zynq_a9_qemu
 --
 
-- 
2.17.1

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

RE: [PATCH v3 0/1] Enable baud rate selection for zynq uart

2021-03-05 Thread Jan.Sommer

Thanks. To be honest, I wasn’t really sure what to do with B0 since there 
aren’t any modem control lines.
I just grepped for B0 and looked what other BSPs are doing and they do nothing, 
so I copied that to have at least common behavior among RTEMS.

From: Joel Sherrill 
Sent: Friday, March 5, 2021 6:54 PM
To: Sommer, Jan 
Cc: rtems-de...@rtems.org 
Subject: Re: [PATCH v3 0/1] Enable baud rate selection for zynq uart

On Fri, Mar 5, 2021 at 11:42 AM Jan Sommer 
mailto:jan.som...@dlr.de>> wrote:
v3:
- Make sure the baud registers are not modified for baud rate B0

B0 is an odd bird. It indicates hang up. From 
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/tcsetattr.html:

If the output baud rate stored in the termios structure pointed to by termios_p 
is the zero baud rate, B0, the modem control lines shall no longer be asserted. 
Normally, this shall disconnect the line.

If the input baud rate stored in the termios structure pointed to by termios_p 
is 0, the input baud rate given to the hardware is the same as the output baud 
rate stored in the termios structure.

Since we don't likely have any BSPs which have real modem control
lines on the serial ports, that usually means to ignore it so you don't
end up with a divide by 0 on the baud rate divisor calculations.

I'm not saying anything negative about your patches. Just that B0 is
a weird corner of POSIX and computing history.

v2:
- Use rtems_baud_to_number instead of duplicating baud table

This patch allows to set the baud rate of the zynq-uart using the termios API.
I could change the baud rate successfully on hardware using the termios 
application.

Best regards,

Jan

Jan Sommer (1):
  bsps/shared: Allow setting baud rate for zynq uart

 bsps/shared/dev/serial/zynq-uart.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

--
2.17.1

___
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 v3 0/1] Enable baud rate selection for zynq uart

2021-03-05 Thread Joel Sherrill

On Fri, Mar 5, 2021 at 11:42 AM Jan Sommer  wrote:

> v3:
> - Make sure the baud registers are not modified for baud rate B0
>

B0 is an odd bird. It indicates hang up. From
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/tcsetattr.html
:

If the output baud rate stored in the *termios* structure pointed to by
*termios_p* is the zero baud rate, B0, the modem control lines shall no
longer be asserted. Normally, this shall disconnect the line.

If the input baud rate stored in the *termios* structure pointed to by
*termios_p* is 0, the input baud rate given to the hardware is the same as
the output baud rate stored in the *termios* structure.

Since we don't likely have any BSPs which have real modem control
lines on the serial ports, that usually means to ignore it so you don't
end up with a divide by 0 on the baud rate divisor calculations.

I'm not saying anything negative about your patches. Just that B0 is
a weird corner of POSIX and computing history.

>
> v2:
> - Use rtems_baud_to_number instead of duplicating baud table
>
> This patch allows to set the baud rate of the zynq-uart using the termios
> API.
> I could change the baud rate successfully on hardware using the termios
> application.
>
> Best regards,
>
> Jan
>
>
> Jan Sommer (1):
>   bsps/shared: Allow setting baud rate for zynq uart
>
>  bsps/shared/dev/serial/zynq-uart.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
>
> --
> 2.17.1
>
> ___
> 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 v3 1/1] bsps/shared: Allow setting baud rate for zynq uart

2021-03-05 Thread Gedare Bloom

Looks good to me.

On Fri, Mar 5, 2021 at 10:42 AM Jan Sommer  wrote:
>
> ---
>  bsps/shared/dev/serial/zynq-uart.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/bsps/shared/dev/serial/zynq-uart.c 
> b/bsps/shared/dev/serial/zynq-uart.c
> index 8f17d3ca65..cd0d0e7584 100644
> --- a/bsps/shared/dev/serial/zynq-uart.c
> +++ b/bsps/shared/dev/serial/zynq-uart.c
> @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(
>  {
>zynq_uart_context *ctx = (zynq_uart_context *) context;
>volatile zynq_uart *regs = ctx->regs;
> +  int32_t baud;
>uint32_t brgr = 0;
>uint32_t bauddiv = 0;
>uint32_t mode = 0;
>int rc;
>
> -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> -  if (rc != 0)
> -return rc;
> +  /*
> +   * Determine the baud rate
> +   */
> +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> +
> +  if (baud > 0) {
> +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> +if (rc != 0)
> +  return rc;
> +  }
>
>/*
> * Configure the mode register
> @@ -202,8 +210,11 @@ static bool zynq_uart_set_attributes(
>
>regs->control &= ~(ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN);
>regs->mode = mode;
> -  regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
> -  regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
> +  /* Ignore baud rate of B0. There are no modem control lines to de-assert */
> +  if (baud > 0) {
> +regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
> +regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
> +  }
>regs->control |= ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
>
>return true;
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3 0/1] Enable baud rate selection for zynq uart

2021-03-05 Thread Jan Sommer

v3:
- Make sure the baud registers are not modified for baud rate B0

v2:
- Use rtems_baud_to_number instead of duplicating baud table

This patch allows to set the baud rate of the zynq-uart using the termios API.
I could change the baud rate successfully on hardware using the termios 
application.

Best regards,

Jan


Jan Sommer (1):
  bsps/shared: Allow setting baud rate for zynq uart

 bsps/shared/dev/serial/zynq-uart.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

-- 
2.17.1

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

[PATCH v3 1/1] bsps/shared: Allow setting baud rate for zynq uart

2021-03-05 Thread Jan Sommer

---
 bsps/shared/dev/serial/zynq-uart.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/bsps/shared/dev/serial/zynq-uart.c 
b/bsps/shared/dev/serial/zynq-uart.c
index 8f17d3ca65..cd0d0e7584 100644
--- a/bsps/shared/dev/serial/zynq-uart.c
+++ b/bsps/shared/dev/serial/zynq-uart.c
@@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(
 {
   zynq_uart_context *ctx = (zynq_uart_context *) context;
   volatile zynq_uart *regs = ctx->regs;
+  int32_t baud;
   uint32_t brgr = 0;
   uint32_t bauddiv = 0;
   uint32_t mode = 0;
   int rc;
 
-  rc = zynq_cal_baud_rate(115200, , , regs->mode);
-  if (rc != 0)
-return rc;
+  /*
+   * Determine the baud rate
+   */
+  baud = rtems_termios_baud_to_number(term->c_ospeed);
+
+  if (baud > 0) {
+rc = zynq_cal_baud_rate(baud, , , regs->mode);
+if (rc != 0)
+  return rc;
+  }
 
   /*
* Configure the mode register
@@ -202,8 +210,11 @@ static bool zynq_uart_set_attributes(
 
   regs->control &= ~(ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN);
   regs->mode = mode;
-  regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
-  regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
+  /* Ignore baud rate of B0. There are no modem control lines to de-assert */
+  if (baud > 0) {
+regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
+regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
+  }
   regs->control |= ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
 
   return true;
-- 
2.17.1

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

RE: [PATCH v4 0/3] Add cadence-SPI driver

2021-03-05 Thread Jan.Sommer

Thanks, I got some test feedback from Rick van der Wal.
I will prepare a new patch set with some modifications.

The zynq-uart issue is currently more pressing for me.

Best regards,

   Jan

> -Original Message-
> From: Gedare Bloom 
> Sent: Friday, March 5, 2021 4:41 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v4 0/3] Add cadence-SPI driver
> 
> Jan, I think this driver is fine to go in if you're happy with it.
> 
> On Fri, Feb 19, 2021 at 6:06 AM Jan Sommer  wrote:
> >
> > v4:
> > - Use copyright information without UTF-8 characters
> >
> > v3:
> > - Fix wrong changes to spec/build/bsps/arm/xilinx-zynq/obj.yml
> >
> > v2:
> > - Moved source file to bsps/shared/dev/spi
> > - Moved include files to bsps/include/dev/spi
> > - Enabled build in aarch64 BSPs
> >
> > v1:
> >
> > This patchset implements a driver for the cadence-spi device of the Xilinx
> Zynq-7000 based SoCs  using the spidev API.
> >
> >
> > Jan Sommer (3):
> >   bsps/xilinx_zynq: Add SPI driver for cadence-spi
> >   bsps/xilinx_zynq: Add SPI driver to waf
> >   bsps/xilinx_zynq: Add SPI driver to autotools build
> >
> >  bsps/headers.am   |   5 +
> >  bsps/include/dev/spi/cadence-spi-regs.h   |  84 
> >  bsps/include/dev/spi/cadence-spi.h|  48 ++
> >  bsps/shared/dev/spi/cadence-spi.c | 437 ++
> >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   3 +
> >  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   3 +
> >  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
> >  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
> >  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
> >  spec/build/bsps/objdevspizynq.yml |  18 +
> >  10 files changed, 604 insertions(+)
> >  create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
> >  create mode 100644 bsps/include/dev/spi/cadence-spi.h
> >  create mode 100644 bsps/shared/dev/spi/cadence-spi.c  create mode
> > 100644 spec/build/bsps/objdevspizynq.yml
> >
> > --
> > 2.17.1
> >
> > ___
> > 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 v2 1/1] bsps/shared: Allow setting baud rate for zynq uart

2021-03-05 Thread Jan.Sommer




> -Original Message-
> From: Gedare Bloom 
> Sent: Friday, March 5, 2021 4:36 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v2 1/1] bsps/shared: Allow setting baud rate for zynq
> uart
> 
> On Mon, Feb 22, 2021 at 9:23 AM Jan Sommer  wrote:
> >
> > ---
> >  bsps/shared/dev/serial/zynq-uart.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/bsps/shared/dev/serial/zynq-uart.c
> > b/bsps/shared/dev/serial/zynq-uart.c
> > index 8f17d3ca65..dd5a6e1cb8 100644
> > --- a/bsps/shared/dev/serial/zynq-uart.c
> > +++ b/bsps/shared/dev/serial/zynq-uart.c
> > @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(  {
> >zynq_uart_context *ctx = (zynq_uart_context *) context;
> >volatile zynq_uart *regs = ctx->regs;
> > +  int32_t baud;
> >uint32_t brgr = 0;
> >uint32_t bauddiv = 0;
> >uint32_t mode = 0;
> >int rc;
> >
> > -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> > -  if (rc != 0)
> > -return rc;
> > +  /*
> > +   * Determine the baud rate
> > +   */
> > +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> > +
> > +  if (baud > 0) {
> > +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> > +if (rc != 0)
> > +  return rc;
> > +  }
> What happens if baud == 0?
> 

Ah, you are right. My initial goal was to leave it unchanged (because there are 
no modem control lines to deassert), but forgot that the baud rate registers 
are set below with then 0. That is not what it should be.
I will prepare a new patch with a condition.

Thanks.

> >
> >/*
> > * Configure the mode register
> > --
> > 2.17.1
> >
> > ___
> > 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: Standalone repository for libnetworking stack

2021-03-05 Thread Vijay Kumar Banerjee

On Fri, Mar 5, 2021 at 9:37 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Mar 5, 2021 at 9:48 AM Vijay Kumar Banerjee  wrote:
>>
>> Hi all,
>>
>> If no one has any objections, I would like to push the RTEMS patches to 
>> remove libnetworking.
>>
>> The patches are in this repo:
>> https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
>
>
> I do not object but this is an impactful thing to do and it would
> be my preference to get concurrence from multiple core
> developers.
>
Thanks for reviewing! I'll wait for some more comments from other core
developers before pushing.

Best regards,
Vijay
> --joel
>>
>>
>>
>>
>> Best regards,
>> Vijay
>>
>>
>> On Mon, Mar 1, 2021, 14:48 Vijay Kumar Banerjee  wrote:
>>>
>>> On Mon, Mar 1, 2021 at 1:24 PM Gedare Bloom  wrote:
>>> >
>>> > On Mon, Mar 1, 2021 at 1:16 PM Vijay Kumar Banerjee  
>>> > wrote:
>>> > >
>>> > > On Mon, Mar 1, 2021 at 12:20 PM Joel Sherrill  wrote:
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Mon, Mar 1, 2021 at 1:05 PM Gedare Bloom  wrote:
>>> > > >>
>>> > > >> On Mon, Mar 1, 2021 at 11:28 AM Vijay Kumar Banerjee 
>>> > > >>  wrote:
>>> > > >> >
>>> > > >> > Hi,
>>> > > >> >
>>> > > >> > I have shifted the testsuites and have checked that all the tests 
>>> > > >> > run successfully with pc-qemu. I have also updated the README.waf 
>>> > > >> > as per the review and have fixed formatting according to PEP8. 
>>> > > >> > Please review the repos and let me know if there's something else 
>>> > > >> > that needs to be improved to make it mergeable.
>>> > > >> > RTEMS: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
>>> > > >> > rtems-net-legacy: 
>>> > > >> > https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main
>>> > > >> >
>>> > > >> > I have also made a patch for rtems-docs to rename networking to 
>>> > > >> > legacy networking:
>>> > > >> > https://git.rtems.org/vijay/rtems-docs.git/commit/?id=92b53d211b4d9ad795ef8b2ad1ac0deed5a25f9a
>>> > > >
>>> > > >
>>> > > > This looks good. If it can easily be moved to the bottom of the list 
>>> > > > of docs, that would be great.
>>> > > >
>>> > > Great. I'll check it and create a patch for it (Assuming it can be
>>> > > done from the docs and doesn't need anything to be done from the
>>> > > website front end).
>>> > > >>
>>> > > >>
>>> > > >> >
>>> > > >> > I haven't added any LICENSE file as I really didn't understand 
>>> > > >> > what we can put in there. I can add the RTEMS LICENSE file from 
>>> > > >> > https://www.rtems.org/license/LICENSE as it was discussed in the 
>>> > > >> > list before. Please let me know what is desirable.
>>> > > >> >
>>> > > >> I don't think we should have a LICENSE file, instead I think there
>>> > > >> should be a section of the README that discusses the licensing
>>> > > >> situation.
>>> > > >>
>>> > > >> The code is licensed under a mix of the rtems.org/LICENSE and various
>>> > > >> BSD licenses. That is all that needs to be said, if anything.
>>> > > >
>>> > > >
>>> > > > +1 It is what is always has been.
>>> > > Great, I'll add a section in the README file.
>>> > >
>>> > > Regarding the README file in general: Is the current text suitable or
>>> > > should we add some information like this is the separate rtems legacy
>>> > > networking stack etc. ?
>>> > >
>>> >
>>> > Add a brief note, and identify where further  guidance is located
>>> > (README.waf, docs.rtems.org) and keep the historical stuff I suppose,
>>> > but provide a segue to it.
>>> >
>>> Thanks, I added it. I'll soon post an announcement to the devel (and
>>> users) about the separate repo, requesting testing from concerned
>>> users.
>>>
>>> > > >>
>>> > > >>
>>> > > >> Do we need to put out a call for anyone to step up to deal with
>>> > > >> anything in BSPs?
>>> > > >
>>> > > >
>>> > > > To be completely above board and proper, I think so. please post to
>>> > > > both devel@ and users@ that your repo needs testing and that the
>>> > > > legacy stack is soon to be removed from the main rtems.git.
>>> > > >
>>> > > > And make it VERY clear that anyone who plans to test, please
>>> > > > speak up. We can't demand they do it immediately but it would
>>> > > > be helpful to know someone is going to do it.
>>> > > >
>>> > > Sure, I'll post in user and devel.
>>> > >
>>> > > > Which NIC did you test the PC with?
>>> > > >
>>> > >
>>> > > virtio
>>> > >
>>> > > >>
>>> > > >>
>>> > > >> > Best regards,
>>> > > >> > Vijay
>>> > > >> >
>>> > > >> > On Fri, Feb 26, 2021 at 12:30 PM Joel Sherrill  
>>> > > >> > wrote:
>>> > > >> > >
>>> > > >> > >
>>> > > >> > >
>>> > > >> > > On Fri, Feb 26, 2021, 11:49 AM Chris Johns  
>>> > > >> > > wrote:
>>> > > >> > >>
>>> > > >> > >> On 27/2/21 4:40 am, Vijay Kumar Banerjee wrote:
>>> > > >> > >> > Hi all,
>>> > > >> > >> >
>>> > > >> > >> > Thanks for reviewing
>>> > > >> > >> >
>>> > > >> > >> > On Fri, Feb 26, 2021 at 10:13 AM Joel Sherrill 
>>> > > >> > >> >  wrote:
>>> > > >> > >> >>
>>> > > >> > >> >> Some odd questions that are mostly

Re: Standalone repository for libnetworking stack

2021-03-05 Thread Joel Sherrill

On Fri, Mar 5, 2021 at 9:48 AM Vijay Kumar Banerjee  wrote:

> Hi all,
>
> If no one has any objections, I would like to push the RTEMS patches to
> remove libnetworking.
>
> The patches are in this repo:
> https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
>

I do not object but this is an impactful thing to do and it would
be my preference to get concurrence from multiple core
developers.

--joel

>
>
>
> Best regards,
> Vijay
>
>
> On Mon, Mar 1, 2021, 14:48 Vijay Kumar Banerjee  wrote:
>
>> On Mon, Mar 1, 2021 at 1:24 PM Gedare Bloom  wrote:
>> >
>> > On Mon, Mar 1, 2021 at 1:16 PM Vijay Kumar Banerjee 
>> wrote:
>> > >
>> > > On Mon, Mar 1, 2021 at 12:20 PM Joel Sherrill  wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Mar 1, 2021 at 1:05 PM Gedare Bloom 
>> wrote:
>> > > >>
>> > > >> On Mon, Mar 1, 2021 at 11:28 AM Vijay Kumar Banerjee <
>> vi...@rtems.org> wrote:
>> > > >> >
>> > > >> > Hi,
>> > > >> >
>> > > >> > I have shifted the testsuites and have checked that all the
>> tests run successfully with pc-qemu. I have also updated the README.waf as
>> per the review and have fixed formatting according to PEP8. Please review
>> the repos and let me know if there's something else that needs to be
>> improved to make it mergeable.
>> > > >> > RTEMS:
>> https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
>> > > >> > rtems-net-legacy:
>> https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main
>> > > >> >
>> > > >> > I have also made a patch for rtems-docs to rename networking to
>> legacy networking:
>> > > >> >
>> https://git.rtems.org/vijay/rtems-docs.git/commit/?id=92b53d211b4d9ad795ef8b2ad1ac0deed5a25f9a
>> > > >
>> > > >
>> > > > This looks good. If it can easily be moved to the bottom of the
>> list of docs, that would be great.
>> > > >
>> > > Great. I'll check it and create a patch for it (Assuming it can be
>> > > done from the docs and doesn't need anything to be done from the
>> > > website front end).
>> > > >>
>> > > >>
>> > > >> >
>> > > >> > I haven't added any LICENSE file as I really didn't understand
>> what we can put in there. I can add the RTEMS LICENSE file from
>> https://www.rtems.org/license/LICENSE as it was discussed in the list
>> before. Please let me know what is desirable.
>> > > >> >
>> > > >> I don't think we should have a LICENSE file, instead I think there
>> > > >> should be a section of the README that discusses the licensing
>> > > >> situation.
>> > > >>
>> > > >> The code is licensed under a mix of the rtems.org/LICENSE and
>> various
>> > > >> BSD licenses. That is all that needs to be said, if anything.
>> > > >
>> > > >
>> > > > +1 It is what is always has been.
>> > > Great, I'll add a section in the README file.
>> > >
>> > > Regarding the README file in general: Is the current text suitable or
>> > > should we add some information like this is the separate rtems legacy
>> > > networking stack etc. ?
>> > >
>> >
>> > Add a brief note, and identify where further  guidance is located
>> > (README.waf, docs.rtems.org) and keep the historical stuff I suppose,
>> > but provide a segue to it.
>> >
>> Thanks, I added it. I'll soon post an announcement to the devel (and
>> users) about the separate repo, requesting testing from concerned
>> users.
>>
>> > > >>
>> > > >>
>> > > >> Do we need to put out a call for anyone to step up to deal with
>> > > >> anything in BSPs?
>> > > >
>> > > >
>> > > > To be completely above board and proper, I think so. please post to
>> > > > both devel@ and users@ that your repo needs testing and that the
>> > > > legacy stack is soon to be removed from the main rtems.git.
>> > > >
>> > > > And make it VERY clear that anyone who plans to test, please
>> > > > speak up. We can't demand they do it immediately but it would
>> > > > be helpful to know someone is going to do it.
>> > > >
>> > > Sure, I'll post in user and devel.
>> > >
>> > > > Which NIC did you test the PC with?
>> > > >
>> > >
>> > > virtio
>> > >
>> > > >>
>> > > >>
>> > > >> > Best regards,
>> > > >> > Vijay
>> > > >> >
>> > > >> > On Fri, Feb 26, 2021 at 12:30 PM Joel Sherrill 
>> wrote:
>> > > >> > >
>> > > >> > >
>> > > >> > >
>> > > >> > > On Fri, Feb 26, 2021, 11:49 AM Chris Johns 
>> wrote:
>> > > >> > >>
>> > > >> > >> On 27/2/21 4:40 am, Vijay Kumar Banerjee wrote:
>> > > >> > >> > Hi all,
>> > > >> > >> >
>> > > >> > >> > Thanks for reviewing
>> > > >> > >> >
>> > > >> > >> > On Fri, Feb 26, 2021 at 10:13 AM Joel Sherrill <
>> j...@rtems.org> wrote:
>> > > >> > >> >>
>> > > >> > >> >> Some odd questions that are mostly about making this a
>> self-contained entity with no loose ends.
>> > > >> > >> >>
>> > > >> > >> >> + Can the network demos be merged also?
>> > > >> > >> >>
>> > > >> > >> > Are we talking about testsuites tests that use legacy
>> networking? If
>> > > >> > >> > so, then I have already shifted the networking01.exe and
>> will shift
>> > > >> > >> > other tests using the same approach.
>> > > >> > >> >
>> > > >> > >>

Re: Standalone repository for libnetworking stack

2021-03-05 Thread Vijay Kumar Banerjee

Hi all,

If no one has any objections, I would like to push the RTEMS patches to
remove libnetworking.

The patches are in this repo:
https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet


Best regards,
Vijay


On Mon, Mar 1, 2021, 14:48 Vijay Kumar Banerjee  wrote:

> On Mon, Mar 1, 2021 at 1:24 PM Gedare Bloom  wrote:
> >
> > On Mon, Mar 1, 2021 at 1:16 PM Vijay Kumar Banerjee 
> wrote:
> > >
> > > On Mon, Mar 1, 2021 at 12:20 PM Joel Sherrill  wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Mar 1, 2021 at 1:05 PM Gedare Bloom 
> wrote:
> > > >>
> > > >> On Mon, Mar 1, 2021 at 11:28 AM Vijay Kumar Banerjee <
> vi...@rtems.org> wrote:
> > > >> >
> > > >> > Hi,
> > > >> >
> > > >> > I have shifted the testsuites and have checked that all the tests
> run successfully with pc-qemu. I have also updated the README.waf as per
> the review and have fixed formatting according to PEP8. Please review the
> repos and let me know if there's something else that needs to be improved
> to make it mergeable.
> > > >> > RTEMS:
> https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
> > > >> > rtems-net-legacy:
> https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main
> > > >> >
> > > >> > I have also made a patch for rtems-docs to rename networking to
> legacy networking:
> > > >> >
> https://git.rtems.org/vijay/rtems-docs.git/commit/?id=92b53d211b4d9ad795ef8b2ad1ac0deed5a25f9a
> > > >
> > > >
> > > > This looks good. If it can easily be moved to the bottom of the list
> of docs, that would be great.
> > > >
> > > Great. I'll check it and create a patch for it (Assuming it can be
> > > done from the docs and doesn't need anything to be done from the
> > > website front end).
> > > >>
> > > >>
> > > >> >
> > > >> > I haven't added any LICENSE file as I really didn't understand
> what we can put in there. I can add the RTEMS LICENSE file from
> https://www.rtems.org/license/LICENSE as it was discussed in the list
> before. Please let me know what is desirable.
> > > >> >
> > > >> I don't think we should have a LICENSE file, instead I think there
> > > >> should be a section of the README that discusses the licensing
> > > >> situation.
> > > >>
> > > >> The code is licensed under a mix of the rtems.org/LICENSE and
> various
> > > >> BSD licenses. That is all that needs to be said, if anything.
> > > >
> > > >
> > > > +1 It is what is always has been.
> > > Great, I'll add a section in the README file.
> > >
> > > Regarding the README file in general: Is the current text suitable or
> > > should we add some information like this is the separate rtems legacy
> > > networking stack etc. ?
> > >
> >
> > Add a brief note, and identify where further  guidance is located
> > (README.waf, docs.rtems.org) and keep the historical stuff I suppose,
> > but provide a segue to it.
> >
> Thanks, I added it. I'll soon post an announcement to the devel (and
> users) about the separate repo, requesting testing from concerned
> users.
>
> > > >>
> > > >>
> > > >> Do we need to put out a call for anyone to step up to deal with
> > > >> anything in BSPs?
> > > >
> > > >
> > > > To be completely above board and proper, I think so. please post to
> > > > both devel@ and users@ that your repo needs testing and that the
> > > > legacy stack is soon to be removed from the main rtems.git.
> > > >
> > > > And make it VERY clear that anyone who plans to test, please
> > > > speak up. We can't demand they do it immediately but it would
> > > > be helpful to know someone is going to do it.
> > > >
> > > Sure, I'll post in user and devel.
> > >
> > > > Which NIC did you test the PC with?
> > > >
> > >
> > > virtio
> > >
> > > >>
> > > >>
> > > >> > Best regards,
> > > >> > Vijay
> > > >> >
> > > >> > On Fri, Feb 26, 2021 at 12:30 PM Joel Sherrill 
> wrote:
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Feb 26, 2021, 11:49 AM Chris Johns 
> wrote:
> > > >> > >>
> > > >> > >> On 27/2/21 4:40 am, Vijay Kumar Banerjee wrote:
> > > >> > >> > Hi all,
> > > >> > >> >
> > > >> > >> > Thanks for reviewing
> > > >> > >> >
> > > >> > >> > On Fri, Feb 26, 2021 at 10:13 AM Joel Sherrill <
> j...@rtems.org> wrote:
> > > >> > >> >>
> > > >> > >> >> Some odd questions that are mostly about making this a
> self-contained entity with no loose ends.
> > > >> > >> >>
> > > >> > >> >> + Can the network demos be merged also?
> > > >> > >> >>
> > > >> > >> > Are we talking about testsuites tests that use legacy
> networking? If
> > > >> > >> > so, then I have already shifted the networking01.exe and
> will shift
> > > >> > >> > other tests using the same approach.
> > > >> > >> >
> > > >> > >> >> + rtems-docs has the Network Users Guide which is legacy
> only. As a minimum, it needs to be renamed to have Legacy in the title.
> Better would be to convert it to markdown/asciidoc and just toss it in the
> legacy repo.
> > > >> > >> >>
> > > >> > >> > This is a good point! I'll probably just keep it as a README
> in the
> > > >> > >> > net-legacy

Re: [PATCH v4 0/3] Add cadence-SPI driver

2021-03-05 Thread Gedare Bloom

Jan, I think this driver is fine to go in if you're happy with it.

On Fri, Feb 19, 2021 at 6:06 AM Jan Sommer  wrote:
>
> v4:
> - Use copyright information without UTF-8 characters
>
> v3:
> - Fix wrong changes to spec/build/bsps/arm/xilinx-zynq/obj.yml
>
> v2:
> - Moved source file to bsps/shared/dev/spi
> - Moved include files to bsps/include/dev/spi
> - Enabled build in aarch64 BSPs
>
> v1:
>
> This patchset implements a driver for the cadence-spi device of the Xilinx 
> Zynq-7000 based SoCs  using the spidev API.
>
>
> Jan Sommer (3):
>   bsps/xilinx_zynq: Add SPI driver for cadence-spi
>   bsps/xilinx_zynq: Add SPI driver to waf
>   bsps/xilinx_zynq: Add SPI driver to autotools build
>
>  bsps/headers.am   |   5 +
>  bsps/include/dev/spi/cadence-spi-regs.h   |  84 
>  bsps/include/dev/spi/cadence-spi.h|  48 ++
>  bsps/shared/dev/spi/cadence-spi.c | 437 ++
>  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   3 +
>  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   3 +
>  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
>  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
>  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
>  spec/build/bsps/objdevspizynq.yml |  18 +
>  10 files changed, 604 insertions(+)
>  create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
>  create mode 100644 bsps/include/dev/spi/cadence-spi.h
>  create mode 100644 bsps/shared/dev/spi/cadence-spi.c
>  create mode 100644 spec/build/bsps/objdevspizynq.yml
>
> --
> 2.17.1
>
> ___
> 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 v2 1/1] bsps/shared: Allow setting baud rate for zynq uart

2021-03-05 Thread Gedare Bloom

On Thu, Mar 4, 2021 at 1:11 AM  wrote:
>
> Could someone please have a look a this patch and approve it?
> Should I then still add a new section to the docs regarding the console 
> behavior for the zynq?
Please do prepare an addition for the docs, that would be great.

> With this patch applied it would be that the baud rate of the fsbl is 
> overwritten by default to 115200, but can be changed using the termios API 
> (compared to the currently unchangeable baud rate).
> I am not sure if that information is that useful or if people will figure 
> that out in 2 min anyways.

It is always best to be explicit when we can. This is most useful for
junior engineers, but even experts can get confused by some hidden
details.

>
> Best regards,
>
> Jan
>
> > -Original Message-
> > From: Sommer, Jan
> > Sent: Monday, February 22, 2021 5:23 PM
> > To: devel@rtems.org
> > Cc: Sommer, Jan 
> > Subject: [PATCH v2 1/1] bsps/shared: Allow setting baud rate for zynq uart
> >
> > ---
> >  bsps/shared/dev/serial/zynq-uart.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/bsps/shared/dev/serial/zynq-uart.c
> > b/bsps/shared/dev/serial/zynq-uart.c
> > index 8f17d3ca65..dd5a6e1cb8 100644
> > --- a/bsps/shared/dev/serial/zynq-uart.c
> > +++ b/bsps/shared/dev/serial/zynq-uart.c
> > @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(  {
> >zynq_uart_context *ctx = (zynq_uart_context *) context;
> >volatile zynq_uart *regs = ctx->regs;
> > +  int32_t baud;
> >uint32_t brgr = 0;
> >uint32_t bauddiv = 0;
> >uint32_t mode = 0;
> >int rc;
> >
> > -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> > -  if (rc != 0)
> > -return rc;
> > +  /*
> > +   * Determine the baud rate
> > +   */
> > +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> > +
> > +  if (baud > 0) {
> > +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> > +if (rc != 0)
> > +  return rc;
> > +  }
> >
> >/*
> > * Configure the mode register
> > --
> > 2.17.1
>
> ___
> 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 v2 1/1] bsps/shared: Allow setting baud rate for zynq uart

2021-03-05 Thread Gedare Bloom

On Mon, Feb 22, 2021 at 9:23 AM Jan Sommer  wrote:
>
> ---
>  bsps/shared/dev/serial/zynq-uart.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/bsps/shared/dev/serial/zynq-uart.c 
> b/bsps/shared/dev/serial/zynq-uart.c
> index 8f17d3ca65..dd5a6e1cb8 100644
> --- a/bsps/shared/dev/serial/zynq-uart.c
> +++ b/bsps/shared/dev/serial/zynq-uart.c
> @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(
>  {
>zynq_uart_context *ctx = (zynq_uart_context *) context;
>volatile zynq_uart *regs = ctx->regs;
> +  int32_t baud;
>uint32_t brgr = 0;
>uint32_t bauddiv = 0;
>uint32_t mode = 0;
>int rc;
>
> -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> -  if (rc != 0)
> -return rc;
> +  /*
> +   * Determine the baud rate
> +   */
> +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> +
> +  if (baud > 0) {
> +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> +if (rc != 0)
> +  return rc;
> +  }
What happens if baud == 0?

>
>/*
> * Configure the mode register
> --
> 2.17.1
>
> ___
> 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 0/3] Fix Missing break in switch Coverity issues

2021-03-05 Thread Gedare Bloom

Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so that we
can update them in future if needed for other tools?

Regardless of the addition of a macro these are fine, the grlib one
came through separately I think. But I'd like to see a macro proposed.

On Wed, Mar 3, 2021 at 2:26 PM Ryan Long  wrote:
>
> Hi,
>
> To fix these Coverity issues, I just needed to add a comment to tell
> Coverity to ignore the error. I did this using the same method as shown
> in this article
> https://www.synopsys.com/blogs/software-security/gimme-a-break/.
>
> Thanks,
> Ryan
>
> Ryan Long (3):
>   grtc.c: Fix four Missing break in switch Coverity errors
>   cpuusagetop.c: Fix three Missing break in switch Coverity errors
>   pci_cfg_read.c: Fix Missing break in switch (CID #1399723)
>
>  bsps/shared/grlib/tmtc/grtc.c   | 4 
>  cpukit/libmisc/cpuuse/cpuusagetop.c | 3 +++
>  cpukit/libpci/pci_cfg_read.c| 1 +
>  3 files changed, 8 insertions(+)
>
> --
> 1.8.3.1
>
> ___
> 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] user: Update ZynqMP QEMU BSP name

2021-03-05 Thread Gedare Bloom

ok

On Thu, Mar 4, 2021 at 10:03 AM Kinsey Moore  wrote:
>
> The ZynqMP QEMU BSPs have had _qemu added to their names to better
> identify them as QEMU BSPs similar to other BSPs which are meant to run
> exclusively on QEMU and not hardware.
> ---
>  user/bsps/aarch64/xilinx-zynqmp.rst | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst 
> b/user/bsps/aarch64/xilinx-zynqmp.rst
> index 7c8ecdf..7401e84 100644
> --- a/user/bsps/aarch64/xilinx-zynqmp.rst
> +++ b/user/bsps/aarch64/xilinx-zynqmp.rst
> @@ -2,15 +2,16 @@
>
>  .. Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
>
> -.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32:
> -.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64:
> +.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_qemu:
> +.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_qemu:
>
>  Qemu Xilinx ZynqMP
>  ==
>
> -This BSP supports two variants, `xilinx-zynqmp-ilp32` and 
> `xilinx-zynqmp-lp64`.
> -The basic hardware initialization is performed by the BSP. These BSPs support
> -the GICv2 interrupt controller present in all ZynqMP systems.
> +This BSP supports two variants, `xilinx-zynqmp-ilp32-qemu` and
> +`xilinx-zynqmp-lp64-qemu`. The basic hardware initialization is performed by 
> the
> +BSP. These BSPs support the GICv2 interrupt controller present in all ZynqMP
> +systems.
>
>  Boot via ELF
>  
> --
> 2.20.1
>
> ___
> 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] spec/aarch64: Rename ZynqMP QEMU BSPs

2021-03-05 Thread Gedare Bloom

ok

On Thu, Mar 4, 2021 at 10:03 AM Kinsey Moore  wrote:
>
> The current ZynqMP BSPs don't have _qemu in their name as do all other
> RTEMS BSPs that are specifically made to run on QEMU. This fixes the
> naming for those ZynqMP BSP variants for easier identification.
> ---
>  spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml  | 2 +-
>  spec/build/bsps/aarch64/xilinx-zynqmp/bspqemuilp32.yml | 2 +-
>  spec/build/bsps/aarch64/xilinx-zynqmp/bspqemulp64.yml  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
> index 5589b6f893..14b4ad56a0 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
> @@ -15,7 +15,7 @@ default-by-variant:
>- -mabi=ilp32
>- -mstrict-align
>variants:
> -  - aarch64/xilinx_zynqmp_ilp32
> +  - aarch64/xilinx_zynqmp_ilp32_qemu
>  description: |
>ABI flags
>  enabled-by: true
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemuilp32.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemuilp32.yml
> index 90979b7822..6e0eafc871 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemuilp32.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemuilp32.yml
> @@ -1,6 +1,6 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  arch: aarch64
> -bsp: xilinx_zynqmp_ilp32
> +bsp: xilinx_zynqmp_ilp32_qemu
>  build-type: bsp
>  cflags: []
>  copyrights:
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemulp64.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemulp64.yml
> index 5e3c561f06..0d047e263c 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemulp64.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspqemulp64.yml
> @@ -1,6 +1,6 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  arch: aarch64
> -bsp: xilinx_zynqmp_lp64
> +bsp: xilinx_zynqmp_lp64_qemu
>  build-type: bsp
>  cflags: []
>  copyrights:
> --
> 2.20.1
>
> ___
> 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 v3 2/2] bsps/aarch64: Resolve usage of SUBALIGN()

2021-03-05 Thread Gedare Bloom

This one seems fine to me based on my understanding of the rtemsr*set
explicit alignment change.

On Wed, Mar 3, 2021 at 6:37 AM Kinsey Moore  wrote:
>
> Remove usage of SUBALIGN() in aarch64 linkcmds which works around a
> difference in behavior on AArch64 platforms. This is no longer necessary
> since alignment is now enforced explicitly.
>
> Closes #4178.
> ---
>  bsps/aarch64/shared/start/linkcmds.base | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/aarch64/shared/start/linkcmds.base 
> b/bsps/aarch64/shared/start/linkcmds.base
> index 294390870a..1768ed001a 100644
> --- a/bsps/aarch64/shared/start/linkcmds.base
> +++ b/bsps/aarch64/shared/start/linkcmds.base
> @@ -245,7 +245,7 @@ SECTIONS {
> .got : ALIGN_WITH_INPUT {
> *(.got.plt) *(.igot.plt) *(.got) *(.igot)
> } > REGION_RODATA AT > REGION_RODATA_LOAD
> -   .rtemsroset : ALIGN_WITH_INPUT SUBALIGN(bsp_set_align) {
> +   .rtemsroset : ALIGN_WITH_INPUT {
> /* Special FreeBSD linker set sections */
> __start_set_sysctl_set = .;
> *(set_sysctl_*);
> @@ -299,7 +299,7 @@ SECTIONS {
> .data1 : ALIGN_WITH_INPUT {
> *(.data1)
> } > REGION_DATA AT > REGION_DATA_LOAD
> -   .rtemsrwset : ALIGN_WITH_INPUT SUBALIGN(bsp_set_align) {
> +   .rtemsrwset : ALIGN_WITH_INPUT {
> KEEP (*(SORT(.rtemsrwset.*)))
> bsp_section_data_end = .;
> } > REGION_DATA AT > REGION_DATA_LOAD
> --
> 2.20.1
>
> ___
> 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 10/12] satcan.c: Fix Unsigned compared against 0 (CID #1399768)

2021-03-05 Thread Gedare Bloom

On Fri, Mar 5, 2021 at 8:13 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Mar 5, 2021, 9:08 AM Gedare Bloom  wrote:
>>
>> On Thu, Mar 4, 2021 at 12:50 PM Ryan Long  wrote:
>> >
>> > CID 1399768: Unsigned compared against 0 in satcan_ioctl().
>> >
>> > Closes #4294
>> > ---
>> >  bsps/shared/grlib/can/satcan.c | 16 
>> >  1 file changed, 4 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/bsps/shared/grlib/can/satcan.c 
>> > b/bsps/shared/grlib/can/satcan.c
>> > index c3fdc15..52e674c 100644
>> > --- a/bsps/shared/grlib/can/satcan.c
>> > +++ b/bsps/shared/grlib/can/satcan.c
>> > @@ -239,9 +239,7 @@ static rtems_device_driver 
>> > satcan_ioctl(rtems_device_major_number major, rtems_d
>> > /* Get regmod structure from argument */
>> > regmod = (satcan_regmod*)ioarg->buffer;
>> > DBG("SatCAN: ioctl: getting register %d\n\r", regmod->reg);
>> should these DBG prints also be changed to %u?
>
>
> Probably. Can this be put on his todo list? Enable the debug prints in grlib 
> and see what printf format specifier warnings come out?
>
> This would seem to be the most reliable way to catch them all.

Yes, I'm ok with the various grlib patches, but make notes to
follow-up on this and perhaps the question whether one can call
brm_write() with rw_args->count = 0, and if so what the behavior
should be.

>>
>>
>> > -   if (regmod->reg < 0)
>> > -   return RTEMS_INVALID_NAME;
>> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
>> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
>> > regmod->val = regs->satcan[regmod->reg];
>> > else if (regmod->reg == SATCAN_WCTRL)
>> > regmod->val = regs->ctrl;
>> > @@ -260,9 +258,7 @@ static rtems_device_driver 
>> > satcan_ioctl(rtems_device_major_number major, rtems_d
>> > regmod = (satcan_regmod*)ioarg->buffer;
>> > DBG("SatCAN: ioctl: setting register %d, value %x\n\r",
>> > regmod->reg, regmod->val);
>> > -   if (regmod->reg < 0)
>> > -   return RTEMS_INVALID_NAME;
>> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
>> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
>> > regs->satcan[regmod->reg] = regmod->val;
>> > else if (regmod->reg == SATCAN_WCTRL)
>> > regs->ctrl = regmod->val;
>> > @@ -281,9 +277,7 @@ static rtems_device_driver 
>> > satcan_ioctl(rtems_device_major_number major, rtems_d
>> > regmod = (satcan_regmod*)ioarg->buffer;
>> > DBG("SatCAN: ioctl: or:ing register %d, with value %x\n\r",
>> > regmod->reg, regmod->val);
>> > -   if (regmod->reg < 0)
>> > -   return RTEMS_INVALID_NAME;
>> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
>> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
>> > regs->satcan[regmod->reg] |= regmod->val;
>> > else if (regmod->reg == SATCAN_WCTRL)
>> > regs->ctrl |= regmod->val;
>> > @@ -302,9 +296,7 @@ static rtems_device_driver 
>> > satcan_ioctl(rtems_device_major_number major, rtems_d
>> > regmod = (satcan_regmod*)ioarg->buffer;
>> > DBG("SatCAN: ioctl: masking register %d, with value 
>> > %x\n\r",
>> > regmod->reg, regmod->val);
>> > -   if (regmod->reg < 0)
>> > -   return RTEMS_INVALID_NAME;
>> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
>> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
>> > regs->satcan[regmod->reg] &= regmod->val;
>> > else if (regmod->reg == SATCAN_WCTRL)
>> > regs->ctrl &= regmod->val;
>> > --
>> > 1.8.3.1
>> >
>> > ___
>> > 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 10/12] satcan.c: Fix Unsigned compared against 0 (CID #1399768)

2021-03-05 Thread Joel Sherrill

On Fri, Mar 5, 2021, 9:08 AM Gedare Bloom  wrote:

> On Thu, Mar 4, 2021 at 12:50 PM Ryan Long 
> wrote:
> >
> > CID 1399768: Unsigned compared against 0 in satcan_ioctl().
> >
> > Closes #4294
> > ---
> >  bsps/shared/grlib/can/satcan.c | 16 
> >  1 file changed, 4 insertions(+), 12 deletions(-)
> >
> > diff --git a/bsps/shared/grlib/can/satcan.c
> b/bsps/shared/grlib/can/satcan.c
> > index c3fdc15..52e674c 100644
> > --- a/bsps/shared/grlib/can/satcan.c
> > +++ b/bsps/shared/grlib/can/satcan.c
> > @@ -239,9 +239,7 @@ static rtems_device_driver
> satcan_ioctl(rtems_device_major_number major, rtems_d
> > /* Get regmod structure from argument */
> > regmod = (satcan_regmod*)ioarg->buffer;
> > DBG("SatCAN: ioctl: getting register %d\n\r",
> regmod->reg);
> should these DBG prints also be changed to %u?
>

Probably. Can this be put on his todo list? Enable the debug prints in
grlib and see what printf format specifier warnings come out?

This would seem to be the most reliable way to catch them all.

>
> > -   if (regmod->reg < 0)
> > -   return RTEMS_INVALID_NAME;
> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
> > regmod->val = regs->satcan[regmod->reg];
> > else if (regmod->reg == SATCAN_WCTRL)
> > regmod->val = regs->ctrl;
> > @@ -260,9 +258,7 @@ static rtems_device_driver
> satcan_ioctl(rtems_device_major_number major, rtems_d
> > regmod = (satcan_regmod*)ioarg->buffer;
> > DBG("SatCAN: ioctl: setting register %d, value %x\n\r",
> > regmod->reg, regmod->val);
> > -   if (regmod->reg < 0)
> > -   return RTEMS_INVALID_NAME;
> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
> > regs->satcan[regmod->reg] = regmod->val;
> > else if (regmod->reg == SATCAN_WCTRL)
> > regs->ctrl = regmod->val;
> > @@ -281,9 +277,7 @@ static rtems_device_driver
> satcan_ioctl(rtems_device_major_number major, rtems_d
> > regmod = (satcan_regmod*)ioarg->buffer;
> > DBG("SatCAN: ioctl: or:ing register %d, with value
> %x\n\r",
> > regmod->reg, regmod->val);
> > -   if (regmod->reg < 0)
> > -   return RTEMS_INVALID_NAME;
> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
> > regs->satcan[regmod->reg] |= regmod->val;
> > else if (regmod->reg == SATCAN_WCTRL)
> > regs->ctrl |= regmod->val;
> > @@ -302,9 +296,7 @@ static rtems_device_driver
> satcan_ioctl(rtems_device_major_number major, rtems_d
> > regmod = (satcan_regmod*)ioarg->buffer;
> > DBG("SatCAN: ioctl: masking register %d, with value
> %x\n\r",
> > regmod->reg, regmod->val);
> > -   if (regmod->reg < 0)
> > -   return RTEMS_INVALID_NAME;
> > -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> > +   if (regmod->reg <= SATCAN_FILTER_STOP)
> > regs->satcan[regmod->reg] &= regmod->val;
> > else if (regmod->reg == SATCAN_WCTRL)
> > regs->ctrl &= regmod->val;
> > --
> > 1.8.3.1
> >
> > ___
> > 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 11/12] b1553brm.c: Fix Unsigned compared against 0 (CID #1399773)

2021-03-05 Thread Gedare Bloom

On Thu, Mar 4, 2021 at 12:50 PM Ryan Long  wrote:
>
> CID 1399773: Unsigned compared against 0 in brm_write().
>
> Closes #4295
> ---
>  bsps/shared/grlib/1553/b1553brm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bsps/shared/grlib/1553/b1553brm.c 
> b/bsps/shared/grlib/1553/b1553brm.c
> index 694f585..484ee6d 100644
> --- a/bsps/shared/grlib/1553/b1553brm.c
> +++ b/bsps/shared/grlib/1553/b1553brm.c
> @@ -982,7 +982,7 @@ static rtems_device_driver 
> brm_write(rtems_device_major_number major, rtems_devi
>
> rw_args->bytes_moved = count;
>
> -   if (count >= 0) {
> +   if (count > 0) {
> return RTEMS_SUCCESSFUL;
> }
I guess this code assumes the requested count to write is > 0 too?
(A request to write 0 bytes is successful if one writes 0 bytes.)

> return RTEMS_UNSATISFIED;
> --
> 1.8.3.1
>
> ___
> 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 10/12] satcan.c: Fix Unsigned compared against 0 (CID #1399768)

2021-03-05 Thread Gedare Bloom

On Thu, Mar 4, 2021 at 12:50 PM Ryan Long  wrote:
>
> CID 1399768: Unsigned compared against 0 in satcan_ioctl().
>
> Closes #4294
> ---
>  bsps/shared/grlib/can/satcan.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/bsps/shared/grlib/can/satcan.c b/bsps/shared/grlib/can/satcan.c
> index c3fdc15..52e674c 100644
> --- a/bsps/shared/grlib/can/satcan.c
> +++ b/bsps/shared/grlib/can/satcan.c
> @@ -239,9 +239,7 @@ static rtems_device_driver 
> satcan_ioctl(rtems_device_major_number major, rtems_d
> /* Get regmod structure from argument */
> regmod = (satcan_regmod*)ioarg->buffer;
> DBG("SatCAN: ioctl: getting register %d\n\r", regmod->reg);
should these DBG prints also be changed to %u?

> -   if (regmod->reg < 0)
> -   return RTEMS_INVALID_NAME;
> -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> +   if (regmod->reg <= SATCAN_FILTER_STOP)
> regmod->val = regs->satcan[regmod->reg];
> else if (regmod->reg == SATCAN_WCTRL)
> regmod->val = regs->ctrl;
> @@ -260,9 +258,7 @@ static rtems_device_driver 
> satcan_ioctl(rtems_device_major_number major, rtems_d
> regmod = (satcan_regmod*)ioarg->buffer;
> DBG("SatCAN: ioctl: setting register %d, value %x\n\r",
> regmod->reg, regmod->val);
> -   if (regmod->reg < 0)
> -   return RTEMS_INVALID_NAME;
> -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> +   if (regmod->reg <= SATCAN_FILTER_STOP)
> regs->satcan[regmod->reg] = regmod->val;
> else if (regmod->reg == SATCAN_WCTRL)
> regs->ctrl = regmod->val;
> @@ -281,9 +277,7 @@ static rtems_device_driver 
> satcan_ioctl(rtems_device_major_number major, rtems_d
> regmod = (satcan_regmod*)ioarg->buffer;
> DBG("SatCAN: ioctl: or:ing register %d, with value %x\n\r",
> regmod->reg, regmod->val);
> -   if (regmod->reg < 0)
> -   return RTEMS_INVALID_NAME;
> -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> +   if (regmod->reg <= SATCAN_FILTER_STOP)
> regs->satcan[regmod->reg] |= regmod->val;
> else if (regmod->reg == SATCAN_WCTRL)
> regs->ctrl |= regmod->val;
> @@ -302,9 +296,7 @@ static rtems_device_driver 
> satcan_ioctl(rtems_device_major_number major, rtems_d
> regmod = (satcan_regmod*)ioarg->buffer;
> DBG("SatCAN: ioctl: masking register %d, with value %x\n\r",
> regmod->reg, regmod->val);
> -   if (regmod->reg < 0)
> -   return RTEMS_INVALID_NAME;
> -   else if (regmod->reg <= SATCAN_FILTER_STOP)
> +   if (regmod->reg <= SATCAN_FILTER_STOP)
> regs->satcan[regmod->reg] &= regmod->val;
> else if (regmod->reg == SATCAN_WCTRL)
> regs->ctrl &= regmod->val;
> --
> 1.8.3.1
>
> ___
> 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 HEAP error

2021-03-05 Thread Joel Sherrill

On Thu, Mar 4, 2021, 11:31 PM Richi Dubey  wrote:

> Hi,
>
> Thanks to both of you for helping me out with this!
>
> When I backtrace on _Terminate: I get this:
>
> Init -> rtems_task_create -> ... -> _Heap_Allocate -> ...
> ->_Heap_Protection_check_free_block -> _Heap_Protection_block_error
> ->_Heap_Protection_block_error_default -> _Terminate
> (the_source=RTEMS_FATAL_SOURCE_HEAP, the_error=2125180). So I will try to
> debug this trace.
>

This is just the detection point. The allocate is doing a validity check
and something is wrong from an overwrite.

FWIW this is pretty early in the test I think.




> Also, setting a watchpoint doesn't help:
>

Look manually at say 32 bytes at that address at various points during the
program's execution. I think this is one where a binary search for the
corrupting action happens.

Is this using your scheduler as the default? If so, I'd be suspicious of
anything allocated for it and if you were riding outside an area allocated
for you.

>
> Thread 1 hit Breakpoint 6, Init (argument=2107944) at
> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:26
> 26  TEST_BEGIN();
> (gdb) watch *(unsigned int)*  0x202ba8
> Hardware watchpoint 13: *(unsigned int)*  0x202ba8
> (gdb) c
> Continuing.
>
> Thread 1 hit Breakpoint 5, _Terminate (the_source=RTEMS_FATAL_SOURCE_HEAP,
> the_error=2125180) at
> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/score/src/interr.c:38
> 38  _User_extensions_Fatal( the_source, the_error );
>
>
>
> On Wed, Mar 3, 2021 at 10:20 PM Gedare Bloom  wrote:
>
>> On Wed, Mar 3, 2021 at 9:49 AM Gedare Bloom  wrote:
>> >
>> > On Wed, Mar 3, 2021 at 9:28 AM Joel Sherrill 
>> wrote:
>> > >
>> > >
>> > >
>> > > On Wed, Mar 3, 2021 at 9:50 AM Gedare Bloom  wrote:
>> > >>
>> > >> On Wed, Mar 3, 2021 at 12:08 AM Richi Dubey 
>> wrote:
>> > >> >
>> > >> > What's the element written after the free? I set a watch at the
>> exact block location, but it doesn't work:
>> > >> >
>> > >> > Hardware watchpoint 7: *0x202ba8
>> > >> > (gdb) watch *0x206fec
>> > >> > Hardware watchpoint 8: *0x206fec
>> > >> That's just the first byte in the block. If you can figure out which
>> > >> bytes/words in the block get accessed that would help you.
>> > >
>> > >
>> > > What about watch *(unsigned int)*  0x202ba8?
>> > >
>> > > Won't that look at more bytes?
>> >
>> > And this is just the first byte of the workspace area.
>> >
>> 4 bytes :)
>> > >
>> > > In case you do need to look at more bytes in the fence...
>> > > breaking at _Terminate and doing a back trace will give
>> > > you the exact line the error is raised from. You can then set a
>> > > breakpoint at that on the next line and look at local variables.
>> > > The corruption may be in the fence somewhere beyond the
>> > > first 32-bits.
>> > >
>> In the case of heap corruption, the corruption is detected after it
>> already happened. Narrowing down when/where the corruption happens is
>> necessary. The next thing to do would be to examine the pattern that
>> triggers the violation, and see where it got modified. This might
>> provide a byte address to set a watch on.
>>
>> > > Sometimes it is easy to binary search for an issue like this
>> > > on a simulator. But with a watchpoint, you should be able to
>> > > determine the precise word which is corrupted in the fence
>> > > and break on that write.
>> > >
>> > > --joel
>> > >>
>> > >>
>> > >> > (gdb) c
>> > >> > Continuing.
>> > >> >
>> > >> > Thread 1 hit Breakpoint 6, Init (argument=2107944) at
>> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:26
>> > >> > 26  TEST_BEGIN();
>> > >> > (gdb)
>> > >> > Continuing.
>> > >> >
>> > >> > Thread 1 hit Breakpoint 5, _Terminate
>> (the_source=RTEMS_FATAL_SOURCE_HEAP, the_error=2125180) at
>> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/score/src/interr.c:38
>> > >> > 38  _User_extensions_Fatal( the_source, the_error );
>> > >> > (gdb)
>> > >> > Continuing.
>> > >> >
>> > >> > Thread 1 hit Breakpoint 4, bsp_reset () at
>> /home/richi/quick-start/LatestStrong/src/rtems/c/src/lib/libbsp/arm/realview-pbx-a9/../../../../../../bsps/arm/realview-pbx-a9/start/bspreset.c:19
>> > >> > 19  volatile uint32_t *sys_lock = (volatile uint32_t *) 0x1020;
>> > >> > (gdb)
>> > >> >
>> > >> > On Wed, Mar 3, 2021 at 12:31 PM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>> > >> >>
>> > >> >> On 02/03/2021 05:44, Richi Dubey wrote:
>> > >> >>
>> > >> >> >
>> > >> >> > (gdb) p *(Heap_Error_context*)(0x00206d7c)
>> > >> >> > $5 = {
>> > >> >> >   heap = 0x202ba8 <_Workspace_Area>,
>> > >> >> >   block = 0x206fec,
>> > >> >> >   reason = HEAP_ERROR_FREE_PATTERN
>> > >> >> > }
>> > >> >>
>> > >> >> If it is always the same address, then you can set a watch point
>> to an
>> > >> >> element which is written after the free to catch the function
>> which
>> > >> >> writes into this area.
>> > >> >>
>> > >> >> --
>> >

FTW tests Re: [rtems-source-builder commit] 6: Update tool chain

2021-03-05 Thread Joel Sherrill

Thanks Sebastian. I built this newlib hash yesterday for all targets on
Centos and was about to test Eshan's ftw test patches.

I'm hoping an our of date toolset causes test failures and not build
failures.

Are we at a point where a forced tool upgrade might be acceptable?

--joel

On Fri, Mar 5, 2021, 6:24 AM Sebastian Huber  wrote:

> Module:rtems-source-builder
> Branch:master
> Commit:d1567073ed6812407e59044558a916d0a22e12a0
> Changeset:
> http://git.rtems.org/rtems-source-builder/commit/?id=d1567073ed6812407e59044558a916d0a22e12a0
>
> Author:Sebastian Huber 
> Date:  Fri Mar  5 07:15:58 2021 +0100
>
> 6: Update tool chain
>
> ---
>
>  rtems/config/tools/rtems-binutils-2.36.cfg  | 4 ++--
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 8 
>  rtems/config/tools/rtems-gdb-10.cfg | 4 ++--
>  3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-binutils-2.36.cfg
> b/rtems/config/tools/rtems-binutils-2.36.cfg
> index d432461..a821ed7 100644
> --- a/rtems/config/tools/rtems-binutils-2.36.cfg
> +++ b/rtems/config/tools/rtems-binutils-2.36.cfg
> @@ -1,11 +1,11 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>
> -%define binutils_version c0034ac
> +%define binutils_version c60a71c
>  %define binutils_external 1
>  %define binutils_expand_name
> sourceware-mirror-binutils-gdb-%{binutils_version}
>  %source set binutils --rsb-file=%{binutils_expand_name}.tar.gz
> https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{binutils_version}
> -%hash sha512 %{binutils_expand_name}.tar.gz
> 10a31f7cd4b0f42d39be2b94bee4b87fba7b8d0474eed0006b8dde0ff0cda9153066d4e3c3c81824bf31bf439299ca0c49d6721d4431525fab98fb87586595ba
> +%hash sha512 %{binutils_expand_name}.tar.gz
> 3d094449ad4b97b489f49e7209bd1ea160c88de619b548c5da35ed8f5b6450178c74999f91284b41c4f9451f54b2a8c04664e8a3432e352d3a54be0e8f84db38
>
>  %define with_deterministic_archives 1
>  %define with_64_bit_bfd 1
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index 40fc240..7be5a2e 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -1,11 +1,11 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>
> -%define gcc_version eb15f76
> +%define gcc_version b50a2ea
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
> -%hash sha512 %{gcc_expand_name}.tar.gz
> f6a22afa66f641bcd97aed8b94e0deedcf845d3aab5c6c4c7daa8a6d78160cc3c01f89abea904b4e2327f07da9f422ad16a59a716b9dffe78968c1014b8a8d08
> +%hash sha512 %{gcc_expand_name}.tar.gz
> a5f344980577989acca1a01551349150c66e802f86982518f88371579fccf0002ff8d08f79dfd318e05d1409d8cc203c5b8a8ece95fbdf90333fca2739be5532
>
>  %patch add gcc -p1
> https://devel.rtems.org/raw-attachment/ticket/4196/0001-gcov-Add-fprofile-info-section-support.patch
>  %hash sha512 0001-gcov-Add-fprofile-info-section-support.patch
> 284c4eb2180e8a7dac600b5833da5d2f99568b7fc2f873c145665ef56ab72ca3e9ac3da1e8bc88e72dd229f02a28402770d82ddd7a1b836836ae00cdfd1d400f
> @@ -13,11 +13,11 @@
>  %patch add gcc -p1
> https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
>  %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch
> afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
>
> -%define newlib_version d4a756f
> +%define newlib_version 182ba1f
>  %define newlib_external 1
>  %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> -%hash sha512 newlib-%{newlib_version}.tar.gz
> fe2b03f6ae460124028d799cd591e6702ef2090f81e954ee54f51f6ccad758af22d7611c351591378250b35111ee482dec9f0dea0c34abd9a31404e427ea7082
> +%hash sha512 newlib-%{newlib_version}.tar.gz
> a84112ffde27ef31ad9702fef2afcc61cdb144055ed6d1fe6b7885eea8c38cf5e5b5933b4e315bd34930db66509d292fd5ed2abface777073e5c7d4d032d37c2
>
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gdb-10.cfg
> b/rtems/config/tools/rtems-gdb-10.cfg
> index 93365ff..d838f76 100644
> --- a/rtems/config/tools/rtems-gdb-10.cfg
> +++ b/rtems/config/tools/rtems-gdb-10.cfg
> @@ -1,10 +1,10 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>
> -%define gdb_version e1a808d
> +%define gdb_version b507c0e
>  %define gdb_external 1
>  %define gdb_expand_name sourceware-mirror-binutils-gdb-%{gdb_version}
>  %source set gdb --rsb-file=%{gdb_expand_name}.tar.gz
>

RE: [PATCH] aarch64: Fix context switch

2021-03-05 Thread Kinsey Moore

Sorry, I though this had already been committed. I had a patch in my
private branch that lines up exactly with this one which I skipped when
pushing my other patch set to the list. This looks good.

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Thursday, March 4, 2021 23:56
To: devel@rtems.org; Kinsey Moore 
Subject: Re: [PATCH] aarch64: Fix context switch

Hello Kinsey,

On 04/03/2021 08:17, Sebastian Huber wrote:
> The Per_CPU_Control::isr_dispatch_disable is a 32-bit integer.
>
> Close #4206.
could you please have a look at this. I think it is a serious bug. Maybe 
you should also review the aarch64 assembler files in general for 
invalid load/store instructions.

-- 
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 v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

2021-03-05 Thread Kinsey Moore

Hi Sebastian,
For AArch64, that would be SCTLR_EL1.A (bit 1). Even with that alignment
checking disabled, I still see data aborts on misaligned accesses. The MMU is
disabled during operation, so that wouldn't be the issue, either. From reading
the spec on that bit, it would seem that AArch64 is accepting of misaligned
writes by default, but that's not the behavior I've seen with the two ZynqMP
boards I have on hand.

There is also SCTLR_EL1.nAA which toggles allowance of accesses spanning
16-byte boundaries, but the feature controlling whether that bit functions is
only mandatory from ARMv8.4 onward and is optional from ARMv8.2. Even
so, the nAA bit only affects a small subset of load and store instructions.

The section on unaligned accesses in the manual only references these two
bits and the LSE2 feature that controls whether the nAA bit is functional.

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Thursday, March 4, 2021 23:54
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

On 04/03/2021 23:15, Kinsey Moore wrote:

> Real hardware running AArch64 does not appreciate accesses misaligned
> relative to the data size. This prevents generation of misaligned writes
> which would throw exceptions.

The patch set is fine independent of the following comment.

To me this problem with misaligned access looks like an MMU/system 
configuration issue. For example in AArch32, you have to enable 
misaligned access in SCTL[A].

-- 
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

60 matches

Mail list logo