[PATCH v2] libcsupport: Add sbrk greedy support to consume all sbrk memory

[chrisj]

From: Chris Johns 

- Move the heap sbrk code into a separate routnine.

- Update heap and workspace greedy allocators to use the common
  sbrk greedy support.

Closes #3982
---
 cpukit/Makefile.am|  1 +
 cpukit/include/rtems/malloc.h | 13 
 cpukit/libcsupport/src/rtems_heap_greedy.c| 19 +++---
 .../libcsupport/src/rtems_heap_sbrk_greedy.c  | 63 +++
 cpukit/rtems/src/workspacegreedy.c| 12 +++-
 spec/build/cpukit/librtemscpu.yml |  1 +
 6 files changed, 95 insertions(+), 14 deletions(-)
 create mode 100644 cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 565aa66ce1..14abc8bb6a 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -217,6 +217,7 @@ librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_extend.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_extend_via_sbrk.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_greedy.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_null_extend.c
+librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_sbrk_greedy.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_memalign.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_mkdir.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_putc.c
diff --git a/cpukit/include/rtems/malloc.h b/cpukit/include/rtems/malloc.h
index 13e94ac38a..ec6473a703 100644
--- a/cpukit/include/rtems/malloc.h
+++ b/cpukit/include/rtems/malloc.h
@@ -68,6 +68,19 @@ void *rtems_heap_extend_via_sbrk(
   size_t alloc_size
 );
 
+/**
+ * @brief Greedy allocate that empties the sbrk memory
+ *
+ * Afterwards all the sbrk avialable memory will have been allocated
+ * to the provided heap.
+ *
+ * @see rtems_heap_extend_via_sbrk().
+ */
+void rtems_heap_sbrk_greedy_allocate(
+  Heap_Control *heap,
+  size_t alloc_size
+);
+
 void *rtems_heap_null_extend(
   Heap_Control *heap,
   size_t alloc_size
diff --git a/cpukit/libcsupport/src/rtems_heap_greedy.c 
b/cpukit/libcsupport/src/rtems_heap_greedy.c
index c02e48d962..94c28d7f16 100644
--- a/cpukit/libcsupport/src/rtems_heap_greedy.c
+++ b/cpukit/libcsupport/src/rtems_heap_greedy.c
@@ -25,25 +25,17 @@
 
 #include "malloc_p.h"
 
+#define SBRK_ALLOC_SIZE (128 * 1024UL * 1024UL)
+
 void *rtems_heap_greedy_allocate(
   const uintptr_t *block_sizes,
   size_t block_count
 )
 {
   Heap_Control *heap = RTEMS_Malloc_Heap;
-  size_t size = 128 * 1024 * 1024;
   void *opaque;
 
-  while ( size > 0 ) {
-opaque = (*rtems_malloc_extend_handler)( heap, size );
-if ( opaque == NULL ) {
-  size >>= 1;
-} else {
-  if ( rtems_malloc_dirty_helper != NULL ) {
-   (*rtems_malloc_dirty_helper)( opaque, size );
-  }
-}
-  }
+  rtems_heap_sbrk_greedy_allocate( heap, SBRK_ALLOC_SIZE );
 
   _RTEMS_Lock_allocator();
   opaque = _Heap_Greedy_allocate( RTEMS_Malloc_Heap, block_sizes, block_count 
);
@@ -56,11 +48,14 @@ void *rtems_heap_greedy_allocate_all_except_largest(
   uintptr_t *allocatable_size
 )
 {
+  Heap_Control *heap = RTEMS_Malloc_Heap;
   void *opaque;
 
+  rtems_heap_sbrk_greedy_allocate( heap, SBRK_ALLOC_SIZE );
+
   _RTEMS_Lock_allocator();
   opaque = _Heap_Greedy_allocate_all_except_largest(
-RTEMS_Malloc_Heap,
+heap,
 allocatable_size
   );
   _RTEMS_Unlock_allocator();
diff --git a/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c 
b/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c
new file mode 100644
index 00..aad3188ac5
--- /dev/null
+++ b/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @brief Greedy Allocate that Empties the sbrk system call
+ *
+ * @ingroup MallocSupport
+ *
+ * @brief Greedy allocation os sbrk system call memory
+ *
+ * The call consumes all the avialable sbrk memory extending
+ * the supplied heap with it. There is free as sbrk memory is
+ * only ever allocated.
+ */
+
+/*
+ * Copyright (c) 2021 Chris Johns.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT 

Re: [PATCH] libcsupport: Add sbrk greedy support to consume all sbrk memory

[Chris Johns]

On 9/2/21 3:58 pm, Sebastian Huber wrote:
> On 09/02/2021 03:31, chr...@rtems.org wrote:
> 
>> +++ b/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c
>> @@ -0,0 +1,37 @@
>> +/**
>> + *  @file
>> + *
>> + *  @brief Greedy Allocate that Empties the sbrk system call
>> + *  @ingroup MallocSupport
>> + */
>> +
>> +/*
>> + * Copyright (c) 2021 Chris Johns.  All rights reserved.
>> + *
>> + * The license and distribution terms for this file may be
>> + * found in the file LICENSE in this distribution or at
>> + *http://www.rtems.org/license/LICENSE.
>> + */
> 
> Could you please use the standard header for new files:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-assembler-source-file-template

Yes of course. I copied the existing file across.

Do we have a list of files that could be migrated?

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

Re: [PATCH 2/4] bsp/riscv: Add NOEL-V BSP

[Sebastian Huber]

On 08/02/2021 20:44, Daniel Hellstrom wrote:


+/*
+ * Copyright (c) 2021 Cobham Gaisler AB.
+ *
+ * Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ *http://www.rtems.org/license/LICENSE.
+ */
+
We should first change the license of the original file to BSD-2-Clause. 
New files should use BSD-2-Clause.


--
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 4/4] bsp/riscv: Add NOEL-V BSP build specification

[Sebastian Huber]

On 08/02/2021 20:44, Daniel Hellstrom wrote:


  spec/build/bsps/riscv/noel/abi.yml | 48 ++
  spec/build/bsps/riscv/noel/bspnoel32im.yml | 19 +
  spec/build/bsps/riscv/noel/bspnoel32imafd.yml  | 19 +
  spec/build/bsps/riscv/noel/bspnoel64imac.yml   | 19 +
  spec/build/bsps/riscv/noel/bspnoel64imafd.yml  | 19 +
  spec/build/bsps/riscv/noel/bspnoel64imafdc.yml | 19 +
  spec/build/bsps/riscv/noel/grp.yml | 56 ++
  spec/build/bsps/riscv/noel/obj.yml | 37 +
  spec/build/bsps/riscv/noel/objsmp.yml  | 15 +++
  spec/build/bsps/riscv/noel/optconirq.yml   | 16 
  spec/build/bsps/riscv/noel/optextirqmax.yml| 16 
  spec/build/bsps/riscv/noel/optfdtcpyro.yml | 15 +++
  spec/build/bsps/riscv/noel/optfdtmxsz.yml  | 16 
  spec/build/bsps/riscv/noel/optfdtro.yml| 15 +++
  spec/build/bsps/riscv/noel/optfdtuboot.yml | 15 +++
  spec/build/bsps/riscv/noel/opthtif.yml | 15 +++
  spec/build/bsps/riscv/optrambegin.yml  |  3 ++
  spec/build/cpukit/optarchbits.yml  |  2 +
  spec/build/cpukit/optnet.yml   |  1 +
  spec/build/cpukit/optsmp.yml   |  4 ++
  20 files changed, 369 insertions(+)
Could you please move all copy and paste files one level up and share 
them with the existing BSP.


--
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 3/4] bsp/riscv: work area size based on stack pointer

[Sebastian Huber]

On 08/02/2021 20:44, Daniel Hellstrom wrote:


+
+   .section.data, "aw"
+   .align  3
+
+   .globl  bsp_sp_at_entry
+   .type   bsp_sp_at_entry, @object
+   .size   bsp_sp_at_entry, 8
+bsp_sp_at_entry:
+   .dword  0


The size of this object should match uintptr_t. I would name this 
variable riscv_start_stack_pointer. It should be declared in a new 
header file "bsps/riscv/include/bsp/start.h".


--
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] libcsupport: Add sbrk greedy support to consume all sbrk memory

[Sebastian Huber]

On 09/02/2021 03:31, chr...@rtems.org wrote:


+++ b/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c
@@ -0,0 +1,37 @@
+/**
+ *  @file
+ *
+ *  @brief Greedy Allocate that Empties the sbrk system call
+ *  @ingroup MallocSupport
+ */
+
+/*
+ * Copyright (c) 2021 Chris Johns.  All rights reserved.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ *http://www.rtems.org/license/LICENSE.
+ */


Could you please use the standard header for new files:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-assembler-source-file-template

--
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] libcsupport: Add sbrk greedy support to consume all sbrk memory

[chrisj]

From: Chris Johns 

- Move the heap sbrk code into a separate routnine.

- Update heap and workspace greedy allocators to use the common
  sbrk greedy support.

Closes #3982
---
 cpukit/Makefile.am|  1 +
 cpukit/include/rtems/malloc.h | 13 +++
 cpukit/libcsupport/src/rtems_heap_greedy.c| 19 --
 .../libcsupport/src/rtems_heap_sbrk_greedy.c  | 37 +++
 cpukit/rtems/src/workspacegreedy.c| 12 +-
 spec/build/cpukit/librtemscpu.yml |  1 +
 6 files changed, 69 insertions(+), 14 deletions(-)
 create mode 100644 cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 565aa66ce1..14abc8bb6a 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -217,6 +217,7 @@ librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_extend.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_extend_via_sbrk.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_greedy.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_null_extend.c
+librtemscpu_a_SOURCES += libcsupport/src/rtems_heap_sbrk_greedy.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_memalign.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_mkdir.c
 librtemscpu_a_SOURCES += libcsupport/src/rtems_putc.c
diff --git a/cpukit/include/rtems/malloc.h b/cpukit/include/rtems/malloc.h
index 13e94ac38a..ec6473a703 100644
--- a/cpukit/include/rtems/malloc.h
+++ b/cpukit/include/rtems/malloc.h
@@ -68,6 +68,19 @@ void *rtems_heap_extend_via_sbrk(
   size_t alloc_size
 );
 
+/**
+ * @brief Greedy allocate that empties the sbrk memory
+ *
+ * Afterwards all the sbrk avialable memory will have been allocated
+ * to the provided heap.
+ *
+ * @see rtems_heap_extend_via_sbrk().
+ */
+void rtems_heap_sbrk_greedy_allocate(
+  Heap_Control *heap,
+  size_t alloc_size
+);
+
 void *rtems_heap_null_extend(
   Heap_Control *heap,
   size_t alloc_size
diff --git a/cpukit/libcsupport/src/rtems_heap_greedy.c 
b/cpukit/libcsupport/src/rtems_heap_greedy.c
index c02e48d962..94c28d7f16 100644
--- a/cpukit/libcsupport/src/rtems_heap_greedy.c
+++ b/cpukit/libcsupport/src/rtems_heap_greedy.c
@@ -25,25 +25,17 @@
 
 #include "malloc_p.h"
 
+#define SBRK_ALLOC_SIZE (128 * 1024UL * 1024UL)
+
 void *rtems_heap_greedy_allocate(
   const uintptr_t *block_sizes,
   size_t block_count
 )
 {
   Heap_Control *heap = RTEMS_Malloc_Heap;
-  size_t size = 128 * 1024 * 1024;
   void *opaque;
 
-  while ( size > 0 ) {
-opaque = (*rtems_malloc_extend_handler)( heap, size );
-if ( opaque == NULL ) {
-  size >>= 1;
-} else {
-  if ( rtems_malloc_dirty_helper != NULL ) {
-   (*rtems_malloc_dirty_helper)( opaque, size );
-  }
-}
-  }
+  rtems_heap_sbrk_greedy_allocate( heap, SBRK_ALLOC_SIZE );
 
   _RTEMS_Lock_allocator();
   opaque = _Heap_Greedy_allocate( RTEMS_Malloc_Heap, block_sizes, block_count 
);
@@ -56,11 +48,14 @@ void *rtems_heap_greedy_allocate_all_except_largest(
   uintptr_t *allocatable_size
 )
 {
+  Heap_Control *heap = RTEMS_Malloc_Heap;
   void *opaque;
 
+  rtems_heap_sbrk_greedy_allocate( heap, SBRK_ALLOC_SIZE );
+
   _RTEMS_Lock_allocator();
   opaque = _Heap_Greedy_allocate_all_except_largest(
-RTEMS_Malloc_Heap,
+heap,
 allocatable_size
   );
   _RTEMS_Unlock_allocator();
diff --git a/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c 
b/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c
new file mode 100644
index 00..1fd82eed4f
--- /dev/null
+++ b/cpukit/libcsupport/src/rtems_heap_sbrk_greedy.c
@@ -0,0 +1,37 @@
+/**
+ *  @file
+ *
+ *  @brief Greedy Allocate that Empties the sbrk system call
+ *  @ingroup MallocSupport
+ */
+
+/*
+ * Copyright (c) 2021 Chris Johns.  All rights reserved.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "malloc_p.h"
+
+void rtems_heap_sbrk_greedy_allocate(
+  Heap_Control *heap,
+  size_t alloc_size
+)
+{
+  while ( alloc_size > 0 ) {
+void *p = (*rtems_malloc_extend_handler)( heap, alloc_size );
+if ( p == NULL ) {
+  alloc_size >>= 1;
+} else {
+  if ( rtems_malloc_dirty_helper != NULL ) {
+   (*rtems_malloc_dirty_helper)( p, alloc_size );
+  }
+}
+  }
+}
diff --git a/cpukit/rtems/src/workspacegreedy.c 
b/cpukit/rtems/src/workspacegreedy.c
index 09204c2833..5ddf004787 100644
--- a/cpukit/rtems/src/workspacegreedy.c
+++ b/cpukit/rtems/src/workspacegreedy.c
@@ -33,15 +33,20 @@
 #include 
 #include 
 
+#define SBRK_ALLOC_SIZE (128 * 1024UL * 1024UL)
+
 void *rtems_workspace_greedy_allocate(
   const uintptr_t *block_sizes,
   size_t block_count
 )
 {
+  Heap_Control *heap = &_Workspace_Area;
   void *opaque;
 
+  rtems_heap_sbrk_greedy_allocate( heap, SBRK_ALLOC_SIZE );
+
   _RTEMS_Lock_allocator();
-  opaque = _Heap_Greedy_allocate( &_Workspace_Area, 

Re: test for rtems_workspace_greedy_allocate

[Chris Johns]

On 8/2/21 4:50 pm, Chris Johns wrote:
> On 8/2/21 4:31 pm, Sebastian Huber wrote:
>> On 08/02/2021 06:14, Sebastian Huber wrote:
>>>
>>> We already have a ticket for this:
>>>
>>>
>>> https://devel.rtems.org/ticket/3982
> 
> Thanks. I am working on a solution. It is working but there is a small pause I
> think needs more investigation.
> 
>>> I am not sure how to fix this. Maybe we should force the sbrk() support to
>>> first give us all the memory of the system. Another approach is to remove 
>>> the
>>> sbrk() support. What is the benefit of it? 
> 
> This is a reasonable question but beyond where I can current look. I suspect 
> the
> reason is historical and if the call is still in use else where maybe it helps
> someone port a BSP to RTEMS. I do not know.

Just to follow up ...

sbrk() cannot be removed and we need to maintained and test it as a BSP level
interface.

I have found the libbsd test `thread01` fails on the PowwerPC because the
workspace greedy call (a copy of the heap version in rtems/src) fails the out of
memory check for the `rtems_bsd_get_curthread_or_null()` call. I now assume the
workspace on a shared powerpc BSP is being extended by sbrk().

This is an nice design idea where the sbrk() pool of memory can be given out to
the heap or workspace depending on the demands of the application. I can see
this being important to application frameworks like EPICS and so something we
should look to add to all architectures.

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

Re: [RTEMS 5 PATCH] bsp/motorola_powerp: Print RTEMS_VERSION from the bootloader

[Gedare Bloom]

On Mon, Feb 8, 2021 at 2:45 PM Gedare Bloom  wrote:

>
> On Mon, Feb 8, 2021 at 2:04 PM Chris Johns  wrote:
>
>> On 9/2/21 5:18 am, Gedare Bloom wrote:
>> > If you put this on master/6, you can switch that align to use
>> > RTEMS_ALIGN_UP(addr, PAGE_SIZE) -- not PAGE_MASK
>>
>> Sorry, I had already pushed the patch.
>>
>> A quick grep shows there are a few of these ...
>>
>>  $ grep -r PAGE_MASK *
>> 0001-bsp-motorola_powerp-Print-RTEMS_VERSION-from-the-boo.patch: #define
>> PAGE_ALIGN(addr)   (((addr) + PAGE_MASK) & ~PAGE_MASK)
>> 0002-bsp-motorola_powerp-Print-RTEMS_VERSION-from-the-boo.patch: #define
>> PAGE_ALIGN(addr)   (((addr) + PAGE_MASK) & ~PAGE_MASK)
>> bsps/powerpc/motorola_powerpc/bootloader/mm.c:#define PAGE_ALIGN(addr)
>> (((addr)
>> + PAGE_MASK) & ~PAGE_MASK)
>> bsps/powerpc/motorola_powerpc/bootloader/mm.c:  rpn =
>> (vaddr_MASK)-area->base+area->firstpte;
>> bsps/powerpc/motorola_powerpc/bootloader/mm.c:  if (mask_MASK) {
>> bsps/powerpc/motorola_powerpc/bootloader/misc.c:#define PAGE_ALIGN(addr)
>> (((addr) + PAGE_MASK) & ~PAGE_MASK)
>> bsps/powerpc/include/libcpu/pgtable.h:#define _PAGE_CHG_MASK
>> (PAGE_MASK |
>> _PAGE_ACCESSED | _PAGE_DIRTY)
>>
> This is suspect. PAGE_MASK coming through newlib is 0xFFF. the ORs are
redundant.



> bsps/powerpc/shared/start/pgtbl_setup.c:#define PAGE_ALIGN(addr)
>> (((addr)
>> + PAGE_MASK) & ~PAGE_MASK)
>> cpukit/libnetworking/vm/vm_param.h:
>>  ((vm_offset_t)vm_offset_t)(x)) +
>> PAGE_MASK) >> PAGE_SHIFT))
>>
> ignore networking


> cpukit/posix/src/mmap.c:if ((uintptr_t)addr & PAGE_MASK) {
>
>
>> Do all these needs to be looked at as well?
>>
>> Probably should. This is only for 6+ version, to help with consistency.
> Some of those appear to be actual PAGE_MASK uses, but the alignment macros
> should use the shared RTEMS_ALIGN* for easier validation.
>
>

FWIW, we also have round_page() defined in newlib.


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

Re: [RTEMS 5 PATCH] bsp/motorola_powerp: Print RTEMS_VERSION from the bootloader

[Gedare Bloom]

On Mon, Feb 8, 2021 at 2:04 PM Chris Johns  wrote:

> On 9/2/21 5:18 am, Gedare Bloom wrote:
> > If you put this on master/6, you can switch that align to use
> > RTEMS_ALIGN_UP(addr, PAGE_SIZE) -- not PAGE_MASK
>
> Sorry, I had already pushed the patch.
>
> A quick grep shows there are a few of these ...
>
>  $ grep -r PAGE_MASK *
> 0001-bsp-motorola_powerp-Print-RTEMS_VERSION-from-the-boo.patch: #define
> PAGE_ALIGN(addr)   (((addr) + PAGE_MASK) & ~PAGE_MASK)
> 0002-bsp-motorola_powerp-Print-RTEMS_VERSION-from-the-boo.patch: #define
> PAGE_ALIGN(addr)   (((addr) + PAGE_MASK) & ~PAGE_MASK)
> bsps/powerpc/motorola_powerpc/bootloader/mm.c:#define PAGE_ALIGN(addr)
> (((addr)
> + PAGE_MASK) & ~PAGE_MASK)
> bsps/powerpc/motorola_powerpc/bootloader/mm.c:  rpn =
> (vaddr_MASK)-area->base+area->firstpte;
> bsps/powerpc/motorola_powerpc/bootloader/mm.c:  if (mask_MASK) {
> bsps/powerpc/motorola_powerpc/bootloader/misc.c:#define PAGE_ALIGN(addr)
> (((addr) + PAGE_MASK) & ~PAGE_MASK)
> bsps/powerpc/include/libcpu/pgtable.h:#define _PAGE_CHG_MASK(PAGE_MASK
> |
> _PAGE_ACCESSED | _PAGE_DIRTY)
> bsps/powerpc/shared/start/pgtbl_setup.c:#define PAGE_ALIGN(addr)
> (((addr)
> + PAGE_MASK) & ~PAGE_MASK)
> cpukit/libnetworking/vm/vm_param.h: ((vm_offset_t)vm_offset_t)(x))
> +
> PAGE_MASK) >> PAGE_SHIFT))
> cpukit/posix/src/mmap.c:if ((uintptr_t)addr & PAGE_MASK) {
>
> Do all these needs to be looked at as well?
>
> Probably should. This is only for 6+ version, to help with consistency.
Some of those appear to be actual PAGE_MASK uses, but the alignment macros
should use the shared RTEMS_ALIGN* for easier validation.


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

Re: Coverity Unchecked Return Value Issues

[Gedare Bloom]

On Mon, Feb 8, 2021 at 1:53 PM Joel Sherrill  wrote:

>
>
> On Mon, Feb 8, 2021 at 2:18 PM Joel Sherrill  wrote:
>
>>
>>
>> On Mon, Feb 8, 2021 at 1:53 PM Gedare Bloom  wrote:
>>
>>>
>>>
>>> On Mon, Feb 8, 2021 at 11:59 AM Joel Sherrill  wrote:
>>>


 On Mon, Feb 8, 2021 at 12:39 PM Gedare Bloom  wrote:

>
>
> On Mon, Feb 8, 2021 at 11:24 AM Joel Sherrill  wrote:
>
>> Hi
>>
>> There are more than a couple of these. in our set of CIDs. I am
>> wondering if these can be addressed with a macro like this:
>>
>> #define _IGNORED_RETURN_STATUS(_status, _ok) \
>>   do { \
>> _Assert((_status) == (_ok)); \
>>
>
> Can you also pass the comparison? I guess it would usually be ==, but
> it could be != sometimes? I think that is the main challenge here.
>

 How about 2 macro names? One for positive and one for negative

 _IGNORE_RETURN_STATUS_EQ
 _IGNORE_RETURN_STATUS_NEQ

 Or even _Assert_Return_status_eq and _neq. I'd like these to be
 candidates for our internal assert.h

>>>
>>> I prefer to use the assert part. The wording is a little awkward. I
>>> guess it doesn't hurt to put the (void) (_status); and still use the status
>>> later? so we don't have to specifically indicate ignored/unused in the
>>> macro name?
>>>
>>> Then:
>>> _Assert_Return_value_equals(_return_value, _expected_value)
>>> _Assert_Return_not_equals(_return_value, _not_expected_value)
>>>
>>> or so would be my preference.
>>>
>>
>> OK.
>>
>>>
>>> We should also have
>>> RTEMS_IGNORE_RETURN_VALUE(_return_value)
>>> maybe.
>>>
>>
>>
>> Is this what you want?
>>
>>   _Assert_Return_value_equals (x, OK);
>>   RTEMS_IGNORE_RETURN_VALUE(x);
>>
>
> Hmm... this had degenerated to the same as
>
> _Assert( x == OK );
> (void) x;
>
> Unless these are in one macro, there isn't any much point in adding any
> more macros.
>
>

No. Maybe:
_Assert_Unused_return_value_equals()
_Assert_Unused_return_value_not_equals()

Unused or Ignored, I don't really care, but I think calling it unused is
more clear.

My point about RTEMS_IGNORE_VARIABLE(x) is more about encoding this
syntactic trick (void)(x); as something a little more obvious, although
once you know what this (void) thing means, it is also obvious.

I keep changing my mind what to call things :)


>
>> Add the _Assert_xxx to rtems/score/assert.h and RTEMS_IGNORE_xxx where?
>>
>> basedefs


> Because the only time x is used is when assert is enabled.
>>
>> But ignored parameter vs ignored return variable is not worth a macro IMO
>>
>> yeah, call it RTEMS_IGNORE_VARIABLE(x) if we decide to add it. or maybe
RTEMS_IGNORE_VALUE_OF(x)


> --joel
>>
>>
>>>
>>>
 It will end up being three arguments otherwise. It would be nice to
 keep it reliably to one line.

>>> Embedding the condition in the name will be easier to spot check anyway.
>>> (Like catch == vs = problem)
>>>
>>>


>
>
>>(void) (_status);
>>   } while (0);
>>
>> Or _Assert_Ignored_return?
>>
>> The ones I have looked at, the return value should always be
>> successful but there isn't any reason we can't be defensive about them.
>>
>> Thoughts.
>>
>> --joel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libcsupport: Have greedy allocations use consume extended memory

[Chris Johns]

On 9/2/21 8:09 am, Joel Sherrill wrote:
> 
> 
> On Mon, Feb 8, 2021, 3:00 PM Chris Johns  > wrote:
> 
> On 9/2/21 12:37 am, Joel Sherrill wrote:
> > On Mon, Feb 8, 2021 at 12:44 AM Chris Johns  
> > >> wrote:
> >
> >     On 8/2/21 5:38 pm, Sebastian Huber wrote:
> >     >
> >     > On 08/02/2021 07:30, chr...@rtems.org 
> > wrote:
> >     >> diff --git a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >     >> b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >     >> index 4dda39873f..2361f17d2e 100644
> >     >> --- a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >     >> +++ b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >     >> @@ -30,8 +30,20 @@ void *rtems_heap_greedy_allocate(
> >     >>     size_t block_count
> >     >>   )
> >     >>   {
> >     >> +  Heap_Control *heap = RTEMS_Malloc_Heap;
> >     >> +  size_t size = 128 * 1024 * 1024;
> >     >>     void *opaque;
> >     >>   +  while (size > 0) {
> >     >> +    opaque = (*rtems_malloc_extend_handler)( heap, size );
> >     >> +    if (opaque == NULL) {
> >     >> +  size >>= 1;
> >     >> +    } else {
> >     >> +  if ( rtems_malloc_dirty_helper != NULL )
> >     >> +    (*rtems_malloc_dirty_helper)( opaque, size );
> >     >> +    }
> >     >> +  }
> >     > You need a couple of more ' ' after and before the braces. Each if
> should
> >     have a
> >     > { }. Apart from the formatting it looks good.
> >
> >     Thanks, I will fix the formatting and push.
> >
> >     And there is no performance issue on hardware so that must be a psim
> thing.
> >
> >
> > What performance issue do you think there could have been?
> 
> I do not know. I have never looked at how psim is implemented. I believe 
> the
> slow down inside the simulator.
> 
> > This must just be a side-effect of the PowerPC BSPs which have more 
> than 32MB 
> > RAM and want to support dynamically loading code. They must ensure that 
> no
> > branches or calls exceed 32MB from the current location. Thus it has to 
> be
> loaded 
> > early in program life before the heap is extended.
> 
> This is inside the simulator?
> 
> 
> No. This is BSP behavior for a number of the PowerPC BSPs. 

I am aware of this.

> If less than 32mb or no one ever used dynamic loading on it, then it doesn't
> have sbrk support. And since dynamic loading was only available with Till's 
> cexp
> until you added dynamic loading, this tends to only show up in bsps which are
> used with EPICS.

I am sorry I am lost. This is related to extending the heap to use all memory
when testing env error codes. I have not seen a performance issue on real
hardware. When run on psim under gdb I saw some time being taken up in the
static call _Heap_Free_Block. The code looks linear to me so I moved on ...

https://git.rtems.org/rtems/tree/cpukit/score/src/heapextend.c#n27

I did not check if _Heap_Protection_free_all_delayed_blocks is looping on psim
and not in real hardware. I did not think this was likely, it would loop on 
both.

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

Re: [PATCH] libcsupport: Have greedy allocations use consume extended memory

[Joel Sherrill]

On Mon, Feb 8, 2021, 3:00 PM Chris Johns  wrote:

> On 9/2/21 12:37 am, Joel Sherrill wrote:
> > On Mon, Feb 8, 2021 at 12:44 AM Chris Johns  > > wrote:
> >
> > On 8/2/21 5:38 pm, Sebastian Huber wrote:
> > >
> > > On 08/02/2021 07:30, chr...@rtems.org 
> wrote:
> > >> diff --git a/cpukit/libcsupport/src/rtems_heap_greedy.c
> > >> b/cpukit/libcsupport/src/rtems_heap_greedy.c
> > >> index 4dda39873f..2361f17d2e 100644
> > >> --- a/cpukit/libcsupport/src/rtems_heap_greedy.c
> > >> +++ b/cpukit/libcsupport/src/rtems_heap_greedy.c
> > >> @@ -30,8 +30,20 @@ void *rtems_heap_greedy_allocate(
> > >> size_t block_count
> > >>   )
> > >>   {
> > >> +  Heap_Control *heap = RTEMS_Malloc_Heap;
> > >> +  size_t size = 128 * 1024 * 1024;
> > >> void *opaque;
> > >>   +  while (size > 0) {
> > >> +opaque = (*rtems_malloc_extend_handler)( heap, size );
> > >> +if (opaque == NULL) {
> > >> +  size >>= 1;
> > >> +} else {
> > >> +  if ( rtems_malloc_dirty_helper != NULL )
> > >> +(*rtems_malloc_dirty_helper)( opaque, size );
> > >> +}
> > >> +  }
> > > You need a couple of more ' ' after and before the braces. Each if
> should
> > have a
> > > { }. Apart from the formatting it looks good.
> >
> > Thanks, I will fix the formatting and push.
> >
> > And there is no performance issue on hardware so that must be a psim
> thing.
> >
> >
> > What performance issue do you think there could have been?
>
> I do not know. I have never looked at how psim is implemented. I believe
> the
> slow down inside the simulator.
>
> > This must just be a side-effect of the PowerPC BSPs which have more than
> 32MB
> > RAM and want to support dynamically loading code. They must ensure that
> no
> > branches or calls exceed 32MB from the current location. Thus it has to
> be loaded
> > early in program life before the heap is extended.
>
> This is inside the simulator?
>

No. This is BSP behavior for a number of the PowerPC BSPs.

If less than 32mb or no one ever used dynamic loading on it, then it
doesn't have sbrk support. And since dynamic loading was only available
with Till's cexp until you added dynamic loading, this tends to only show
up in bsps which are used with EPICS.


> > Are there other supported architectures where code must fit into a
> subset of the
> > address space where it could negatively impact dynamic loading?
>
> ARM.
>
> > How does the DL code deal with PPC code that is built without the
> -mlongcall
> > option?
>
> libdl adds a trampoline ...
>
> https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-mdreloc-powerpc.c#n184
>
> Chris
>
> > EPICS discusses this here:
> >
> > https://epics.anl.gov/base/ppc.php 
> >
> > --joel
> >
> >
> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RTEMS 5 PATCH] bsp/motorola_powerp: Print RTEMS_VERSION from the bootloader

[Chris Johns]

On 9/2/21 5:18 am, Gedare Bloom wrote:
> If you put this on master/6, you can switch that align to use
> RTEMS_ALIGN_UP(addr, PAGE_SIZE) -- not PAGE_MASK

Sorry, I had already pushed the patch.

A quick grep shows there are a few of these ...

 $ grep -r PAGE_MASK *
0001-bsp-motorola_powerp-Print-RTEMS_VERSION-from-the-boo.patch: #define
PAGE_ALIGN(addr)   (((addr) + PAGE_MASK) & ~PAGE_MASK)
0002-bsp-motorola_powerp-Print-RTEMS_VERSION-from-the-boo.patch: #define
PAGE_ALIGN(addr)   (((addr) + PAGE_MASK) & ~PAGE_MASK)
bsps/powerpc/motorola_powerpc/bootloader/mm.c:#define PAGE_ALIGN(addr)  (((addr)
+ PAGE_MASK) & ~PAGE_MASK)
bsps/powerpc/motorola_powerpc/bootloader/mm.c:  rpn =
(vaddr_MASK)-area->base+area->firstpte;
bsps/powerpc/motorola_powerpc/bootloader/mm.c:  if (mask_MASK) {
bsps/powerpc/motorola_powerpc/bootloader/misc.c:#define PAGE_ALIGN(addr)
(((addr) + PAGE_MASK) & ~PAGE_MASK)
bsps/powerpc/include/libcpu/pgtable.h:#define _PAGE_CHG_MASK(PAGE_MASK |
_PAGE_ACCESSED | _PAGE_DIRTY)
bsps/powerpc/shared/start/pgtbl_setup.c:#define PAGE_ALIGN(addr)(((addr)
+ PAGE_MASK) & ~PAGE_MASK)
cpukit/libnetworking/vm/vm_param.h: ((vm_offset_t)vm_offset_t)(x)) +
PAGE_MASK) >> PAGE_SHIFT))
cpukit/posix/src/mmap.c:if ((uintptr_t)addr & PAGE_MASK) {

Do all these needs to be looked at as well?

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

Re: [PATCH] libcsupport: Have greedy allocations use consume extended memory

[Chris Johns]

On 9/2/21 12:37 am, Joel Sherrill wrote:
> On Mon, Feb 8, 2021 at 12:44 AM Chris Johns  > wrote:
> 
> On 8/2/21 5:38 pm, Sebastian Huber wrote:
> >
> > On 08/02/2021 07:30, chr...@rtems.org  wrote:
> >> diff --git a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> index 4dda39873f..2361f17d2e 100644
> >> --- a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> +++ b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> @@ -30,8 +30,20 @@ void *rtems_heap_greedy_allocate(
> >>     size_t block_count
> >>   )
> >>   {
> >> +  Heap_Control *heap = RTEMS_Malloc_Heap;
> >> +  size_t size = 128 * 1024 * 1024;
> >>     void *opaque;
> >>   +  while (size > 0) {
> >> +    opaque = (*rtems_malloc_extend_handler)( heap, size );
> >> +    if (opaque == NULL) {
> >> +  size >>= 1;
> >> +    } else {
> >> +  if ( rtems_malloc_dirty_helper != NULL )
> >> +    (*rtems_malloc_dirty_helper)( opaque, size );
> >> +    }
> >> +  }
> > You need a couple of more ' ' after and before the braces. Each if 
> should
> have a
> > { }. Apart from the formatting it looks good.
> 
> Thanks, I will fix the formatting and push.
> 
> And there is no performance issue on hardware so that must be a psim 
> thing.
> 
> 
> What performance issue do you think there could have been?

I do not know. I have never looked at how psim is implemented. I believe the
slow down inside the simulator.

> This must just be a side-effect of the PowerPC BSPs which have more than 32MB 
> RAM and want to support dynamically loading code. They must ensure that no
> branches or calls exceed 32MB from the current location. Thus it has to be 
> loaded 
> early in program life before the heap is extended.

This is inside the simulator?

> Are there other supported architectures where code must fit into a subset of 
> the
> address space where it could negatively impact dynamic loading?

ARM.

> How does the DL code deal with PPC code that is built without the -mlongcall 
> option?

libdl adds a trampoline ...

https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-mdreloc-powerpc.c#n184

Chris

> EPICS discusses this here:
> 
> https://epics.anl.gov/base/ppc.php 
> 
> --joel
> 
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Hello World Program proof

[Prateek Pardeshi]

Hello everyone, I was busy with exams lately, and now I've resolved the errors 
which I faced during the RTEMS setup on my machine.
I've attached the program of "Hello World" with this email.

If anyone needs help regarding RTEMS setup can reach out to me, I would be 
happy to help! :) 


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

Re: Coverity Unchecked Return Value Issues

[Joel Sherrill]

On Mon, Feb 8, 2021 at 2:18 PM Joel Sherrill  wrote:

>
>
> On Mon, Feb 8, 2021 at 1:53 PM Gedare Bloom  wrote:
>
>>
>>
>> On Mon, Feb 8, 2021 at 11:59 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, Feb 8, 2021 at 12:39 PM Gedare Bloom  wrote:
>>>


 On Mon, Feb 8, 2021 at 11:24 AM Joel Sherrill  wrote:

> Hi
>
> There are more than a couple of these. in our set of CIDs. I am
> wondering if these can be addressed with a macro like this:
>
> #define _IGNORED_RETURN_STATUS(_status, _ok) \
>   do { \
> _Assert((_status) == (_ok)); \
>

 Can you also pass the comparison? I guess it would usually be ==, but
 it could be != sometimes? I think that is the main challenge here.

>>>
>>> How about 2 macro names? One for positive and one for negative
>>>
>>> _IGNORE_RETURN_STATUS_EQ
>>> _IGNORE_RETURN_STATUS_NEQ
>>>
>>> Or even _Assert_Return_status_eq and _neq. I'd like these to be
>>> candidates for our internal assert.h
>>>
>>
>> I prefer to use the assert part. The wording is a little awkward. I guess
>> it doesn't hurt to put the (void) (_status); and still use the status
>> later? so we don't have to specifically indicate ignored/unused in the
>> macro name?
>>
>> Then:
>> _Assert_Return_value_equals(_return_value, _expected_value)
>> _Assert_Return_not_equals(_return_value, _not_expected_value)
>>
>> or so would be my preference.
>>
>
> OK.
>
>>
>> We should also have
>> RTEMS_IGNORE_RETURN_VALUE(_return_value)
>> maybe.
>>
>
>
> Is this what you want?
>
>   _Assert_Return_value_equals (x, OK);
>   RTEMS_IGNORE_RETURN_VALUE(x);
>

Hmm... this had degenerated to the same as

_Assert( x == OK );
(void) x;

Unless these are in one macro, there isn't any much point in adding any
more macros.


>
> Add the _Assert_xxx to rtems/score/assert.h and RTEMS_IGNORE_xxx where?
>
> Because the only time x is used is when assert is enabled.
>
> But ignored parameter vs ignored return variable is not worth a macro IMO
>
> --joel
>
>
>>
>>
>>> It will end up being three arguments otherwise. It would be nice to keep
>>> it reliably to one line.
>>>
>> Embedding the condition in the name will be easier to spot check anyway.
>> (Like catch == vs = problem)
>>
>>
>>>
>>>


>(void) (_status);
>   } while (0);
>
> Or _Assert_Ignored_return?
>
> The ones I have looked at, the return value should always be
> successful but there isn't any reason we can't be defensive about them.
>
> Thoughts.
>
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


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

Re: [PATCH v2 0/4] bsps/shared/ofw: Bug and Coverity defect fixes

[Joel Sherrill]

On Mon, Feb 8, 2021, 2:27 PM Christian Mauderer  wrote:

> Hello Gedare and Niteesh,
>
> the patches look fine. I pushed them.
>
> @Niteesh: Thanks for creating them.


Thanks to you both. Coverity runs at 12:05am Central time if anything
changes in the RSB or RTEMS. It could be twice a day but just check after
it runs to see if you resolved the issues you were trying to.

--joel





> Best regards
>
> Christian
>
> On 08/02/2021 19:13, Gedare Bloom wrote:
> > Christian,
> >
> > These look good to me, please push if you are happy with them too.
> Thanks!
> >
> > On Sat, Feb 6, 2021 at 10:41 AM G S Niteesh Babu  > > wrote:
> >
> > Update since v1: Using strlcpy instead of memcpy
> >
> > The following series of patches fix bugs and coverity reported
> > defect in bsps/shared/ofw.c.
> >
> > G S Niteesh Babu (4):
> >bsps/shared/ofw: Fix coverity reported defects
> >bsps/shared/ofw: Use strlcpy instead of strncpy
> >bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative
> >bsps/shared/ofw: Bug fixes
> >
> >   bsps/shared/ofw/ofw.c | 35 ++-
> >   1 file changed, 22 insertions(+), 13 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/4] bsps/shared/ofw: Bug and Coverity defect fixes

[Christian Mauderer]

Hello Gedare and Niteesh,

the patches look fine. I pushed them.

@Niteesh: Thanks for creating them.

Best regards

Christian

On 08/02/2021 19:13, Gedare Bloom wrote:

Christian,

These look good to me, please push if you are happy with them too. Thanks!

On Sat, Feb 6, 2021 at 10:41 AM G S Niteesh Babu > wrote:


Update since v1: Using strlcpy instead of memcpy

The following series of patches fix bugs and coverity reported
defect in bsps/shared/ofw.c.

G S Niteesh Babu (4):
   bsps/shared/ofw: Fix coverity reported defects
   bsps/shared/ofw: Use strlcpy instead of strncpy
   bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative
   bsps/shared/ofw: Bug fixes

  bsps/shared/ofw/ofw.c | 35 ++-
  1 file changed, 22 insertions(+), 13 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: Coverity Unchecked Return Value Issues

[Joel Sherrill]

On Mon, Feb 8, 2021 at 1:53 PM Gedare Bloom  wrote:

>
>
> On Mon, Feb 8, 2021 at 11:59 AM Joel Sherrill  wrote:
>
>>
>>
>> On Mon, Feb 8, 2021 at 12:39 PM Gedare Bloom  wrote:
>>
>>>
>>>
>>> On Mon, Feb 8, 2021 at 11:24 AM Joel Sherrill  wrote:
>>>
 Hi

 There are more than a couple of these. in our set of CIDs. I am
 wondering if these can be addressed with a macro like this:

 #define _IGNORED_RETURN_STATUS(_status, _ok) \
   do { \
 _Assert((_status) == (_ok)); \

>>>
>>> Can you also pass the comparison? I guess it would usually be ==, but it
>>> could be != sometimes? I think that is the main challenge here.
>>>
>>
>> How about 2 macro names? One for positive and one for negative
>>
>> _IGNORE_RETURN_STATUS_EQ
>> _IGNORE_RETURN_STATUS_NEQ
>>
>> Or even _Assert_Return_status_eq and _neq. I'd like these to be
>> candidates for our internal assert.h
>>
>
> I prefer to use the assert part. The wording is a little awkward. I guess
> it doesn't hurt to put the (void) (_status); and still use the status
> later? so we don't have to specifically indicate ignored/unused in the
> macro name?
>
> Then:
> _Assert_Return_value_equals(_return_value, _expected_value)
> _Assert_Return_not_equals(_return_value, _not_expected_value)
>
> or so would be my preference.
>

OK.

>
> We should also have
> RTEMS_IGNORE_RETURN_VALUE(_return_value)
> maybe.
>


Is this what you want?

  _Assert_Return_value_equals (x, OK);
  RTEMS_IGNORE_RETURN_VALUE(x);

Add the _Assert_xxx to rtems/score/assert.h and RTEMS_IGNORE_xxx where?

Because the only time x is used is when assert is enabled.

But ignored parameter vs ignored return variable is not worth a macro IMO

--joel


>
>
>> It will end up being three arguments otherwise. It would be nice to keep
>> it reliably to one line.
>>
> Embedding the condition in the name will be easier to spot check anyway.
> (Like catch == vs = problem)
>
>
>>
>>
>>>
>>>
(void) (_status);
   } while (0);

 Or _Assert_Ignored_return?

 The ones I have looked at, the return value should always be successful
 but there isn't any reason we can't be defensive about them.

 Thoughts.

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

Re: Coverity Unchecked Return Value Issues

[Gedare Bloom]

On Mon, Feb 8, 2021 at 11:59 AM Joel Sherrill  wrote:

>
>
> On Mon, Feb 8, 2021 at 12:39 PM Gedare Bloom  wrote:
>
>>
>>
>> On Mon, Feb 8, 2021 at 11:24 AM Joel Sherrill  wrote:
>>
>>> Hi
>>>
>>> There are more than a couple of these. in our set of CIDs. I am
>>> wondering if these can be addressed with a macro like this:
>>>
>>> #define _IGNORED_RETURN_STATUS(_status, _ok) \
>>>   do { \
>>> _Assert((_status) == (_ok)); \
>>>
>>
>> Can you also pass the comparison? I guess it would usually be ==, but it
>> could be != sometimes? I think that is the main challenge here.
>>
>
> How about 2 macro names? One for positive and one for negative
>
> _IGNORE_RETURN_STATUS_EQ
> _IGNORE_RETURN_STATUS_NEQ
>
> Or even _Assert_Return_status_eq and _neq. I'd like these to be candidates
> for our internal assert.h
>

I prefer to use the assert part. The wording is a little awkward. I guess
it doesn't hurt to put the (void) (_status); and still use the status
later? so we don't have to specifically indicate ignored/unused in the
macro name?

Then:
_Assert_Return_value_equals(_return_value, _expected_value)
_Assert_Return_not_equals(_return_value, _not_expected_value)

or so would be my preference.

We should also have
RTEMS_IGNORE_RETURN_VALUE(_return_value)
maybe.


> It will end up being three arguments otherwise. It would be nice to keep
> it reliably to one line.
>
Embedding the condition in the name will be easier to spot check anyway.
(Like catch == vs = problem)


>
>
>>
>>
>>>(void) (_status);
>>>   } while (0);
>>>
>>> Or _Assert_Ignored_return?
>>>
>>> The ones I have looked at, the return value should always be successful
>>> but there isn't any reason we can't be defensive about them.
>>>
>>> Thoughts.
>>>
>>> --joel
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 4/4] bsp/riscv: Add NOEL-V BSP build specification

[Daniel Hellstrom]

From: Martin Aberg 

---
 spec/build/bsps/riscv/noel/abi.yml | 48 ++
 spec/build/bsps/riscv/noel/bspnoel32im.yml | 19 +
 spec/build/bsps/riscv/noel/bspnoel32imafd.yml  | 19 +
 spec/build/bsps/riscv/noel/bspnoel64imac.yml   | 19 +
 spec/build/bsps/riscv/noel/bspnoel64imafd.yml  | 19 +
 spec/build/bsps/riscv/noel/bspnoel64imafdc.yml | 19 +
 spec/build/bsps/riscv/noel/grp.yml | 56 ++
 spec/build/bsps/riscv/noel/obj.yml | 37 +
 spec/build/bsps/riscv/noel/objsmp.yml  | 15 +++
 spec/build/bsps/riscv/noel/optconirq.yml   | 16 
 spec/build/bsps/riscv/noel/optextirqmax.yml| 16 
 spec/build/bsps/riscv/noel/optfdtcpyro.yml | 15 +++
 spec/build/bsps/riscv/noel/optfdtmxsz.yml  | 16 
 spec/build/bsps/riscv/noel/optfdtro.yml| 15 +++
 spec/build/bsps/riscv/noel/optfdtuboot.yml | 15 +++
 spec/build/bsps/riscv/noel/opthtif.yml | 15 +++
 spec/build/bsps/riscv/optrambegin.yml  |  3 ++
 spec/build/cpukit/optarchbits.yml  |  2 +
 spec/build/cpukit/optnet.yml   |  1 +
 spec/build/cpukit/optsmp.yml   |  4 ++
 20 files changed, 369 insertions(+)
 create mode 100644 spec/build/bsps/riscv/noel/abi.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel32im.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel32imafd.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imac.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafd.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafdc.yml
 create mode 100644 spec/build/bsps/riscv/noel/grp.yml
 create mode 100644 spec/build/bsps/riscv/noel/obj.yml
 create mode 100644 spec/build/bsps/riscv/noel/objsmp.yml
 create mode 100644 spec/build/bsps/riscv/noel/optconirq.yml
 create mode 100644 spec/build/bsps/riscv/noel/optextirqmax.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtcpyro.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtmxsz.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtro.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtuboot.yml
 create mode 100644 spec/build/bsps/riscv/noel/opthtif.yml

diff --git a/spec/build/bsps/riscv/noel/abi.yml 
b/spec/build/bsps/riscv/noel/abi.yml
new file mode 100644
index 000..f81e0c1
--- /dev/null
+++ b/spec/build/bsps/riscv/noel/abi.yml
@@ -0,0 +1,48 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- split: null
+- env-append: null
+build-type: option
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+default:
+- -march=rv32ima
+- -mabi=ilp32
+default-by-variant:
+- value:
+  - -march=rv64imafdc
+  - -mabi=lp64d
+  variants:
+  - riscv/noel64imafdc
+- value:
+  - -march=rv64imafd
+  - -mabi=lp64d
+  variants:
+  - riscv/noel64imafd
+- value:
+  - -march=rv64imac
+  - -mabi=lp64
+  variants:
+  - riscv/noel64imac
+- value:
+  - -march=rv64im
+  - -mabi=lp64
+  variants:
+  - riscv/noel64im
+- value:
+  - -march=rv32imafd
+  - -mabi=ilp32d
+  variants:
+  - riscv/noel32imafd
+- value:
+  - -march=rv32im
+  - -mabi=ilp32
+  variants:
+  - riscv/noel32im
+description: |
+  ABI flags
+enabled-by: true
+links: []
+name: ABI_FLAGS
+type: build
diff --git a/spec/build/bsps/riscv/noel/bspnoel32im.yml 
b/spec/build/bsps/riscv/noel/bspnoel32im.yml
new file mode 100644
index 000..bcb27a5
--- /dev/null
+++ b/spec/build/bsps/riscv/noel/bspnoel32im.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: riscv
+bsp: noel32im
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+enabled-by: true
+family: riscv
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: ../../opto2
+- role: build-dependency
+  uid: grp
+source: []
+type: build
diff --git a/spec/build/bsps/riscv/noel/bspnoel32imafd.yml 
b/spec/build/bsps/riscv/noel/bspnoel32imafd.yml
new file mode 100644
index 000..e105620
--- /dev/null
+++ b/spec/build/bsps/riscv/noel/bspnoel32imafd.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: riscv
+bsp: noel32imafd
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+enabled-by: true
+family: riscv
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: ../../opto2
+- role: build-dependency
+  uid: grp
+source: []
+type: build
diff --git a/spec/build/bsps/riscv/noel/bspnoel64imac.yml 
b/spec/build/bsps/riscv/noel/bspnoel64imac.yml
new file mode 100644
index 000..e32bdb3
--- /dev/null
+++ b/spec/build/bsps/riscv/noel/bspnoel64imac.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: riscv
+bsp: noel64imac
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright 

[PATCH 3/4] bsp/riscv: work area size based on stack pointer

[Daniel Hellstrom]

From: Martin Aberg 

Remember the initial stack pointer in start.S. It can later be used to
determine top of RAM.
---
 bsps/riscv/shared/start/bspgetworkarea-fromstack.c | 55 ++
 bsps/riscv/shared/start/start.S| 15 ++
 2 files changed, 70 insertions(+)
 create mode 100644 bsps/riscv/shared/start/bspgetworkarea-fromstack.c

diff --git a/bsps/riscv/shared/start/bspgetworkarea-fromstack.c 
b/bsps/riscv/shared/start/bspgetworkarea-fromstack.c
new file mode 100644
index 000..b8a915e
--- /dev/null
+++ b/bsps/riscv/shared/start/bspgetworkarea-fromstack.c
@@ -0,0 +1,55 @@
+/*
+ *  This set of routines are the BSP specific initialization
+ *  support routines.
+ *
+ *  COPYRIGHT (c) 1989-2020.
+ *  On-Line Applications Research Corporation (OAR),
+ *  Cobham Gaisler AB.
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+#include 
+
+#include 
+
+/*
+ *  These are provided by the linkcmds for ALL of the BSPs which use this file.
+ */
+extern char WorkAreaBase[];
+extern char RamEnd[];
+
+/* Set by BSP early start code. */
+extern uintptr_t bsp_sp_at_entry;
+
+static Memory_Area _Memory_Areas[ 1 ];
+
+static void bsp_memory_initialize( void )
+{
+  char *end;
+
+  /* top of RAM inidicated by initial stack pointer */
+  end = (char *) bsp_sp_at_entry;
+  if (end == 0) {
+/* fall back to linker symbol if not set */
+end = RamEnd;
+  }
+  _Memory_Initialize( &_Memory_Areas[ 0 ], WorkAreaBase, end );
+}
+
+RTEMS_SYSINIT_ITEM(
+  bsp_memory_initialize,
+  RTEMS_SYSINIT_MEMORY,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
+
+static const Memory_Information _Memory_Information =
+  MEMORY_INFORMATION_INITIALIZER( _Memory_Areas );
+
+const Memory_Information *_Memory_Get( void )
+{
+  return &_Memory_Information;
+}
diff --git a/bsps/riscv/shared/start/start.S b/bsps/riscv/shared/start/start.S
index 04a62a2..0bb5ddb 100644
--- a/bsps/riscv/shared/start/start.S
+++ b/bsps/riscv/shared/start/start.S
@@ -59,6 +59,9 @@ SYM(_start):
LADDR   t0, _RISCV_Exception_handler
csrwmtvec, t0
 
+   /* Save stack pointer so it can mark end of work area later on */
+   mv  t3, sp
+
/* Load stack pointer and branch to secondary processor start if 
necessary */
 #ifdef RTEMS_SMP
LADDR   sp, _ISR_Stack_area_begin
@@ -74,6 +77,9 @@ SYM(_start):
LADDR   sp, _ISR_Stack_area_end
 #endif
 
+   LADDR   t0, bsp_sp_at_entry
+   SREGt3, 0(t0)
+
 #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
mv  a0, a1
callbsp_fdt_copy
@@ -145,3 +151,12 @@ SYM(_start):
 #endif
 
 #endif /* RTEMS_SMP */
+
+   .section.data, "aw"
+   .align  3
+
+   .globl  bsp_sp_at_entry
+   .type   bsp_sp_at_entry, @object
+   .size   bsp_sp_at_entry, 8
+bsp_sp_at_entry:
+   .dword  0
-- 
2.7.4

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

[PATCH 2/4] bsp/riscv: Add NOEL-V BSP

[Daniel Hellstrom]

From: Martin Aberg 

Added support for Cobham Gaisler NOEL-V systems. The NOEL-V support
is implemented as a riscv BSP. Both 32-bit and 64-bit processor
systems are supported. Cobham Gaisler's NOEL-V RISC-V processor IP
is described here:
  https://www.gaisler.com/NOELV

Compatible with the following NOEL-V FPGA example design ranges
available from Cobham Gaisler. Follow the links for free
bit-streams, DTS/DTB, user'manuals and quick-start guides:
- NOEL-ARTYA7-EX(https://www.gaisler.com/NOEL-ARTYA7)
- NOEL-PF-EX(https://www.gaisler.com/NOEL-PF)
- NOEL-XCKU-EX  (https://www.gaisler.com/NOEL-XCKU)

Uses the shared GRLIB APBUART console driver "apbuart_termios.c".
APBUART devices are probed using device tree.

Update #4225.
---
 bsps/riscv/noel/console/console-config.c | 182 +++
 bsps/riscv/noel/include/bsp.h|  76 +
 bsps/riscv/noel/include/bsp/irq.h|  75 +
 bsps/riscv/noel/include/tm27.h   |   1 +
 bsps/riscv/noel/start/bsp_fatal_halt.c   |  36 ++
 5 files changed, 370 insertions(+)
 create mode 100644 bsps/riscv/noel/console/console-config.c
 create mode 100644 bsps/riscv/noel/include/bsp.h
 create mode 100644 bsps/riscv/noel/include/bsp/irq.h
 create mode 100644 bsps/riscv/noel/include/tm27.h
 create mode 100644 bsps/riscv/noel/start/bsp_fatal_halt.c

diff --git a/bsps/riscv/noel/console/console-config.c 
b/bsps/riscv/noel/console/console-config.c
new file mode 100644
index 000..11ee6d6
--- /dev/null
+++ b/bsps/riscv/noel/console/console-config.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (c) 2021 Cobham Gaisler AB.
+ *
+ * Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define RISCV_CONSOLE_MAX_APBUART_DEVICES 4
+
+#include 
+#include 
+static struct apbuart_context apbuarts[RISCV_CONSOLE_MAX_APBUART_DEVICES];
+static size_t apbuart_devices = 0;
+
+static struct {
+  rtems_termios_device_context *context;
+  void (*putchar)(rtems_termios_device_context *base, char c);
+  int (*getchar)(rtems_termios_device_context *base);
+} riscv_console;
+
+static void riscv_output_char(char c)
+{
+  (*riscv_console.putchar)(riscv_console.context, c);
+}
+
+static void apbuart_putchar(rtems_termios_device_context *base, char c)
+{
+  struct apbuart_context *ctx = (struct apbuart_context *) base;
+  apbuart_outbyte_polled(ctx->regs, c, 0, 1);
+}
+
+static int apbuart_getchar(rtems_termios_device_context *base)
+{
+  struct apbuart_context *ctx = (struct apbuart_context *) base;
+  return apbuart_inbyte_nonblocking(ctx->regs);
+}
+
+#define RISCV_CONSOLE_IS_COMPATIBLE(actual, actual_len, desired) \
+  (actual_len == sizeof(desired) \
+ && memcmp(actual, desired, sizeof(desired) - 1) == 0)
+
+static uint32_t get_core_frequency(void)
+{
+  uint32_t node;
+  const char *fdt;
+  int len;
+  const fdt32_t *val;
+
+  fdt = bsp_fdt_get();
+  node = fdt_node_offset_by_compatible(fdt, -1, "fixed-clock");
+
+  val = fdt_getprop(fdt, node, "clock-frequency", );
+  if (val != NULL && len == 4) {
+return fdt32_to_cpu(*val);
+  }
+  return 0;
+}
+
+static void riscv_console_probe(void)
+{
+  const void *fdt;
+  int node;
+
+  fdt = bsp_fdt_get();
+
+  node = fdt_next_node(fdt, -1, NULL);
+
+  while (node >= 0) {
+const char *compat;
+int compat_len;
+
+compat = fdt_getprop(fdt, node, "compatible", _len);
+if (compat == NULL) {
+  compat_len = 0;
+}
+
+if (
+  RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "gaisler,apbuart")
+&& (apbuart_devices < RISCV_CONSOLE_MAX_APBUART_DEVICES)
+) {
+  struct apbuart_context *ctx;
+  fdt32_t *val;
+  int len;
+
+  ctx = [apbuart_devices];
+
+  ctx->regs = riscv_fdt_get_address(fdt, node);
+  if (ctx->regs == NULL) {
+bsp_fatal(RISCV_FATAL_NO_NS16550_REG_IN_DEVICE_TREE);
+  }
+
+  ctx->freq_hz = get_core_frequency();
+
+  val = (fdt32_t *) fdt_getprop(fdt, node, "interrupts", );
+  if (val == NULL || len != 4) {
+bsp_fatal(RISCV_FATAL_NO_NS16550_INTERRUPTS_IN_DEVICE_TREE);
+  }
+  ctx->irq = RISCV_INTERRUPT_VECTOR_EXTERNAL(fdt32_to_cpu(val[0]));
+
+  if (apbuart_devices == 0) {
+riscv_console.context = >base;
+riscv_console.putchar = apbuart_putchar;
+riscv_console.getchar = apbuart_getchar;
+  }
+
+  rtems_termios_device_context_initialize(>base, "APBUART");
+
+  apbuart_devices++;
+};
+
+node = fdt_next_node(fdt, node, NULL);
+  }
+
+  BSP_output_char = riscv_output_char;
+}
+
+static void riscv_output_char_init(char c)
+{
+  riscv_console_probe();
+  

[PATCH 1/4] apbuart_termios: use bsp/irq.h

[Daniel Hellstrom]

From: Martin Aberg 

The real dependency in this case is on rtems/irq-extension.h. The theme in
other other console drivers is to get it via bsp/irq.h, so that pattern is
followed.
---
 bsps/shared/grlib/uart/apbuart_termios.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/shared/grlib/uart/apbuart_termios.c 
b/bsps/shared/grlib/uart/apbuart_termios.c
index 81df89c..997b14c 100644
--- a/bsps/shared/grlib/uart/apbuart_termios.c
+++ b/bsps/shared/grlib/uart/apbuart_termios.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void apbuart_isr(void *arg)
 {
-- 
2.7.4

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

[PATCH 0/4] RISC-V: NOEL-V BSP

[Daniel Hellstrom]

This set of patches adds a BSP for the NOEL-V RISC-V processor
IP from Cobham Gaisler:
https://www.gaisler.com/noelv

The patches are for the RTEMS master branch with the autoconf and
new WAF build system. If accepted another patch set for the
RTEMS-5 branch will follow. Patches for the document repository
will be sent separately.

There is a ticket for more details:
https://devel.rtems.org/ticket/4225

The patches has been tested on different NOEL-V designs on
FPGA boards. The below test result is collected from the
single-core design of Arty A7: Artix-7 FPGA Development Board
(https://www.gaisler.com/NOEL-ARTYA7) built with waf:

  # Result Test ExecRes ConsoleRes ExitCode1 ExitCode2
  # FAIL: ttest01 OK FAIL 0x0005 0x
  # FAIL: ttest02 OK FAIL 0x0005 0x
  # FAIL: psxkey07 OK FAIL 0x0005 0x
  # FAIL: minimum OK N/A 0x 0x0005
  # FAIL: spfatal26 FAIL OK N/A N/A
  #
  # SUMMARY
  #  Tests failing:5
  #  Tests successful: 552

We believe the failures are not dependent on the BSP itself.

The BSP does not integrate GRLIB device drivers at this point,
however it is reusing the  APBUART device driver as it is used
by NOEL-V designs. There is a patch that allows auto-detection
of End-of-Memory similar to the LEON BSPs using the same GRLIB
SW ecosystem.

Thanks,
Martin & Daniel


---

 bsps/riscv/noel/console/console-config.c   | 182 +
 bsps/riscv/noel/include/bsp.h  |  76 +
 bsps/riscv/noel/include/bsp/irq.h  |  75 +
 bsps/riscv/noel/include/tm27.h |   1 +
 bsps/riscv/noel/start/bsp_fatal_halt.c |  36 
 bsps/riscv/shared/start/bspgetworkarea-fromstack.c |  55 +++
 bsps/riscv/shared/start/start.S|  16 ++
 bsps/shared/grlib/uart/apbuart_termios.c   |   1 +
 spec/build/bsps/riscv/noel/abi.yml |  48 ++
 spec/build/bsps/riscv/noel/bspnoel32im.yml |  19 +++
 spec/build/bsps/riscv/noel/bspnoel32imafd.yml  |  19 +++
 spec/build/bsps/riscv/noel/bspnoel64imac.yml   |  19 +++
 spec/build/bsps/riscv/noel/bspnoel64imafd.yml  |  19 +++
 spec/build/bsps/riscv/noel/bspnoel64imafdc.yml |  19 +++
 spec/build/bsps/riscv/noel/grp.yml |  56 +++
 spec/build/bsps/riscv/noel/obj.yml |  37 +
 spec/build/bsps/riscv/noel/objsmp.yml  |  15 ++
 spec/build/bsps/riscv/noel/optconirq.yml   |  16 ++
 spec/build/bsps/riscv/noel/optextirqmax.yml|  16 ++
 spec/build/bsps/riscv/noel/optfdtcpyro.yml |  15 ++
 spec/build/bsps/riscv/noel/optfdtmxsz.yml  |  16 ++
 spec/build/bsps/riscv/noel/optfdtro.yml|  15 ++
 spec/build/bsps/riscv/noel/optfdtuboot.yml |  15 ++
 spec/build/bsps/riscv/noel/opthtif.yml |  15 ++
 spec/build/bsps/riscv/optrambegin.yml  |   3 +
 spec/build/cpukit/optarchbits.yml  |   2 +
 spec/build/cpukit/optnet.yml   |   1 +
 spec/build/cpukit/optsmp.yml   |   4 +
 28 files changed, 811 insertions(+)

 create mode 100644 bsps/riscv/noel/console/console-config.c
 create mode 100644 bsps/riscv/noel/include/bsp.h
 create mode 100644 bsps/riscv/noel/include/bsp/irq.h
 create mode 100644 bsps/riscv/noel/include/tm27.h
 create mode 100644 bsps/riscv/noel/start/bsp_fatal_halt.c
 create mode 100644 bsps/riscv/shared/start/bspgetworkarea-fromstack.c
 create mode 100644 spec/build/bsps/riscv/noel/abi.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel32im.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel32imafd.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imac.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafd.yml
 create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafdc.yml
 create mode 100644 spec/build/bsps/riscv/noel/grp.yml
 create mode 100644 spec/build/bsps/riscv/noel/obj.yml
 create mode 100644 spec/build/bsps/riscv/noel/objsmp.yml
 create mode 100644 spec/build/bsps/riscv/noel/optconirq.yml
 create mode 100644 spec/build/bsps/riscv/noel/optextirqmax.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtcpyro.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtmxsz.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtro.yml
 create mode 100644 spec/build/bsps/riscv/noel/optfdtuboot.yml
 create mode 100644 spec/build/bsps/riscv/noel/opthtif.yml
 28 files changed, 811 insertions(+)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity Unchecked Return Value Issues

[Joel Sherrill]

On Mon, Feb 8, 2021 at 12:39 PM Gedare Bloom  wrote:

>
>
> On Mon, Feb 8, 2021 at 11:24 AM Joel Sherrill  wrote:
>
>> Hi
>>
>> There are more than a couple of these. in our set of CIDs. I am wondering
>> if these can be addressed with a macro like this:
>>
>> #define _IGNORED_RETURN_STATUS(_status, _ok) \
>>   do { \
>> _Assert((_status) == (_ok)); \
>>
>
> Can you also pass the comparison? I guess it would usually be ==, but it
> could be != sometimes? I think that is the main challenge here.
>

How about 2 macro names? One for positive and one for negative

_IGNORE_RETURN_STATUS_EQ
_IGNORE_RETURN_STATUS_NEQ

Or even _Assert_Return_status_eq and _neq. I'd like these to be candidates
for our internal assert.h

It will end up being three arguments otherwise. It would be nice to keep it
reliably to one line.


>
>
>>(void) (_status);
>>   } while (0);
>>
>> Or _Assert_Ignored_return?
>>
>> The ones I have looked at, the return value should always be successful
>> but there isn't any reason we can't be defensive about them.
>>
>> Thoughts.
>>
>> --joel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity Unchecked Return Value Issues

[Gedare Bloom]

On Mon, Feb 8, 2021 at 11:24 AM Joel Sherrill  wrote:

> Hi
>
> There are more than a couple of these. in our set of CIDs. I am wondering
> if these can be addressed with a macro like this:
>
> #define _IGNORED_RETURN_STATUS(_status, _ok) \
>   do { \
> _Assert((_status) == (_ok)); \
>

Can you also pass the comparison? I guess it would usually be ==, but it
could be != sometimes? I think that is the main challenge here.


>(void) (_status);
>   } while (0);
>
> Or _Assert_Ignored_return?
>
> The ones I have looked at, the return value should always be successful
> but there isn't any reason we can't be defensive about them.
>
> Thoughts.
>
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Completed Hello World task

[Gedare Bloom]

On Mon, Feb 8, 2021 at 10:37 AM Sanskar Khandelwal 
wrote:

> Hello gedare,
>
> As you asked, I have sent you Hello world Patch with the subject name
> "Sanskar's Modified Hello World" please check it and let me know.
>
> I went through the project list and selected a few projects which I found
> interesting.
> 1. #4162 : SiFive RISC-V HiFive Unleashed BSP (Qemu)
> 2. #3028 :  Run-Time Tracing
> 3. #3302 : Build System conversion of BSP Config (.cfg) files to
> pkg-config (.pc) files
> 4. #3326 : Eclipse Target Communication Framework Support
>
> Also I particularly find tracing as a very interesting topic to work on,
> so I will also like to know what projects I can do in this direction.
>
> You may get more attention by sending a separate email specifically
related to the tracing topics. A lot of work has been done (Sebastian Huber
has done much of this work.) on that in the past 1-2 years, and I'm not
sure what is remaining to complete. This is related to both #2 and #4 on
your list.

Joel and Hesham might be able to advise more about #1.

I believe that #3 may be still of interest, although now it should focus
instead on how to integrate application builds with the newly created
waf-based build for RTEMS. This is also a separate topic for discussion,
that may need discussion with Chris and Sebastian.

If they don't respond here, you may like to create separate emails for each
topic so that you can get a chance to scope them out some more.

What's your view on these projects, I want to know what's the current scope
> is for these projects, if someone can show me a direction like what further
> enhancement you guys are looking for or anything, I will surely present a
> promising project for one of them.
>
> Thanks
> Sanskar
>
> On Sat, Feb 6, 2021 at 7:35 PM Gedare Bloom  wrote:
>
>> Hi Sanskar,
>>
>> Welcome! Please send me a git-patch of your change to RTEMS.
>>
>> We generally underspecify our project descriptions on purpose. The scope
>> that can be accomplished in the timeframe varies depending on individual
>> student experience and skills. So, we like to let the students explore the
>> projects and discuss with potential mentors in order to shape the proposal
>> in a way that suits the student's and mentors' interests with a scope that
>> is appropriate.
>>
>> You should look through the projects and see if any look promising to
>> you, and then ask questions preferably on devel@rtems.org about the ones
>> that interest you. The current open projects list may still need to update
>> slightly for work that has been done, or that is not desired any more. If
>> you're interested in a category of projects but no specific ones, you may
>> also inquire about other ideas from the community within that category.
>>
>> Gedare
>>
>> On Sat, Feb 6, 2021 at 6:21 AM Sanskar Khandelwal 
>> wrote:
>>
>>>
>>> Hello everyone,
>>> My name is Sanskar Khandelwal. I want to contribute on rtems projects.
>>> I have completed the Hello world task. You guys can check the screenshot
>>> below.
>>> But I am a little confused about projects, I went through the project
>>> list and at least read descriptions of each one but could not figure out
>>> which projects I should work on.
>>> Please guide me in selecting a project.
>>>
>>> Thank you
>>> Sanskar
>>> ___
>>> 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: Hello World Program proof

[Gedare Bloom]

Hi Prateek,

Welcome. Please send me the git-patch of your change. You can start
browsing the open projects and asking questions, and also look for Joel's
recent request for students, Subject: Remaining Waf Conversion Tickets for
Community and GSoC Students

-Gedare

On Mon, Feb 8, 2021 at 9:58 AM Prateek Pardeshi  wrote:

> Hello everyone, I was busy with exams lately, and now I've resolved the
> errors which I faced during the RTEMS setup on my machine.
> I've attached the program of "Hello World" with this email.
>
> If anyone needs help regarding RTEMS setup can reach out to me, I would be
> happy to help! :)
>
>
> Thanks & Regards,
> Prateek
>
> ___
> 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] basedefs: Add stringification of argument lists

[Gedare Bloom]

sorry, I saw it before and it looked reasonable/harmless to me.

On Sun, Feb 7, 2021 at 11:55 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/12/2020 09:44, Sebastian Huber wrote:
>
> > Change RTEMS_STRING() and RTEMS_XSTRING() to accept a variable number of
> > arguments which is stringified.  This can be used for example to create
> > register lists for inline assembler statements.
> > ---
> >   cpukit/include/rtems/score/basedefs.h | 16 
> >   1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/cpukit/include/rtems/score/basedefs.h
> b/cpukit/include/rtems/score/basedefs.h
> > index 0081dbfbe4..87a693e180 100644
> > --- a/cpukit/include/rtems/score/basedefs.h
> > +++ b/cpukit/include/rtems/score/basedefs.h
> > @@ -335,13 +335,13 @@ extern "C" {
> >   /**
> >* @ingroup RTEMSAPIBaseDefs
> >*
> > - * @brief Stringifies _x without expanding.
> > + * @brief Stringifies the arguments without expanding them.
> >*
> > - * @param _x is the token to stringify.
> > + * @param ... are the arguments to stringify.
> >*
> > - * @return Returns the stringification of the token _x.
> > + * @return Returns the stringification of the arguments.
> >*/
> > -#define RTEMS_STRING( _x ) #_x
> > +#define RTEMS_STRING( ... ) #__VA_ARGS__
> >
> >   /* Generated from spec:/rtems/basedefs/if/typeof-refx */
> >
> > @@ -898,13 +898,13 @@ extern "C" {
> >   /**
> >* @ingroup RTEMSAPIBaseDefs
> >*
> > - * @brief Stringifies the expansion of _x.
> > + * @brief Stringifies the expansion of the arguments.
> >*
> > - * @param _x is the token expand and stringify.
> > + * @param ... are the arguments to expand and stringify.
> >*
> > - * @return Returns the stringification of the expansion of token _x.
> > + * @return Returns the stringification of the expansion of the
> arguments.
> >*/
> > -#define RTEMS_XSTRING( _x ) RTEMS_STRING( _x )
> > +#define RTEMS_XSTRING( ... ) RTEMS_STRING( __VA_ARGS__ )
> >
> >   /* Generated from spec:/rtems/basedefs/if/define-global-symbol */
> Any objections to push this? It makes the macro a bit more flexible.
> Linux uses the same approach.
>
> --
> 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

Coverity Unchecked Return Value Issues

[Joel Sherrill]

Hi

There are more than a couple of these. in our set of CIDs. I am wondering
if these can be addressed with a macro like this:

#define _IGNORED_RETURN_STATUS(_status, _ok) \
  do { \
_Assert((_status) == (_ok)); \
   (void) (_status);
  } while (0);

Or _Assert_Ignored_return?

The ones I have looked at, the return value should always be successful but
there isn't any reason we can't be defensive about them.

Thoughts.

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

Re: [RTEMS 5 PATCH] bsp/motorola_powerp: Print RTEMS_VERSION from the bootloader

[Joel Sherrill]

On Mon, Feb 8, 2021 at 12:19 PM Gedare Bloom  wrote:

> If you put this on master/6, you can switch that align to use
> RTEMS_ALIGN_UP(addr, PAGE_SIZE) -- not PAGE_MASK
>

Good catch.

And seeing this again, I notice it is powerp not powerpc in the commit
message.

--joel

>
> On Sun, Feb 7, 2021 at 4:29 PM Chris Johns  wrote:
>
>> On 8/2/21 9:48 am, Joel Sherrill wrote:
>> > Do you want another ticket to apply this to 5 as well?
>>
>> This is for 5 and the ticket is ...
>>
>> >
>> > On Sun, Feb 7, 2021, 4:38 PM mailto:chr...@rtems.org>>
>> wrote:
>> >
>> > From: Chris Johns mailto:chr...@rtems.org>>
>> >
>> > Close #4234
>> ..  ^^^
>>
>> I did not raise a ticket for master for this change, just 5.
>>
>> :)
>>
>> Chris
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RTEMS 5 PATCH] bsp/motorola_powerp: Print RTEMS_VERSION from the bootloader

[Gedare Bloom]

If you put this on master/6, you can switch that align to use
RTEMS_ALIGN_UP(addr, PAGE_SIZE) -- not PAGE_MASK

On Sun, Feb 7, 2021 at 4:29 PM Chris Johns  wrote:

> On 8/2/21 9:48 am, Joel Sherrill wrote:
> > Do you want another ticket to apply this to 5 as well?
>
> This is for 5 and the ticket is ...
>
> >
> > On Sun, Feb 7, 2021, 4:38 PM mailto:chr...@rtems.org>>
> wrote:
> >
> > From: Chris Johns mailto:chr...@rtems.org>>
> >
> > Close #4234
> ..  ^^^
>
> I did not raise a ticket for master for this change, just 5.
>
> :)
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/4] bsps/shared/ofw: Bug and Coverity defect fixes

[Gedare Bloom]

Christian,

These look good to me, please push if you are happy with them too. Thanks!

On Sat, Feb 6, 2021 at 10:41 AM G S Niteesh Babu 
wrote:

> Update since v1: Using strlcpy instead of memcpy
>
> The following series of patches fix bugs and coverity reported
> defect in bsps/shared/ofw.c.
>
> G S Niteesh Babu (4):
>   bsps/shared/ofw: Fix coverity reported defects
>   bsps/shared/ofw: Use strlcpy instead of strncpy
>   bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative
>   bsps/shared/ofw: Bug fixes
>
>  bsps/shared/ofw/ofw.c | 35 ++-
>  1 file changed, 22 insertions(+), 13 deletions(-)
>
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Completed Hello World task

[Sanskar Khandelwal]

Hello gedare,

As you asked, I have sent you Hello world Patch with the subject name
"Sanskar's Modified Hello World" please check it and let me know.

I went through the project list and selected a few projects which I found
interesting.
1. #4162 : SiFive RISC-V HiFive Unleashed BSP (Qemu)
2. #3028 :  Run-Time Tracing
3. #3302 : Build System conversion of BSP Config (.cfg) files to pkg-config
(.pc) files
4. #3326 : Eclipse Target Communication Framework Support

Also I particularly find tracing as a very interesting topic to work on, so
I will also like to know what projects I can do in this direction.

What's your view on these projects, I want to know what's the current scope
is for these projects, if someone can show me a direction like what further
enhancement you guys are looking for or anything, I will surely present a
promising project for one of them.

Thanks
Sanskar

On Sat, Feb 6, 2021 at 7:35 PM Gedare Bloom  wrote:

> Hi Sanskar,
>
> Welcome! Please send me a git-patch of your change to RTEMS.
>
> We generally underspecify our project descriptions on purpose. The scope
> that can be accomplished in the timeframe varies depending on individual
> student experience and skills. So, we like to let the students explore the
> projects and discuss with potential mentors in order to shape the proposal
> in a way that suits the student's and mentors' interests with a scope that
> is appropriate.
>
> You should look through the projects and see if any look promising to you,
> and then ask questions preferably on devel@rtems.org about the ones that
> interest you. The current open projects list may still need to update
> slightly for work that has been done, or that is not desired any more. If
> you're interested in a category of projects but no specific ones, you may
> also inquire about other ideas from the community within that category.
>
> Gedare
>
> On Sat, Feb 6, 2021 at 6:21 AM Sanskar Khandelwal 
> wrote:
>
>>
>> Hello everyone,
>> My name is Sanskar Khandelwal. I want to contribute on rtems projects.
>> I have completed the Hello world task. You guys can check the screenshot
>> below.
>> But I am a little confused about projects, I went through the project
>> list and at least read descriptions of each one but could not figure out
>> which projects I should work on.
>> Please guide me in selecting a project.
>>
>> Thank you
>> Sanskar
>> ___
>> 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] Sanskar's Modified Hello World

[kdsanskar07]

From: Sanskar Khandelwal 

Hello everyone,

My name is sanskar khandelwal, I have completed the hello world task, please 
let me know if there is anything to change in this task.

---
 testsuites/samples/hello/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 34ded37c55..8336e2af71 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -22,7 +22,8 @@ static rtems_task Init(
 {
   rtems_print_printer_fprintf_putc(_test_printer);
   TEST_BEGIN();
-  printf( "Hello World\n" );
+  printf( "Modified Hello world from Sanskar Khandelwal.\n" );
+  printf( "I am looking very much forward to work on rtems.\n" );
   TEST_END();
   rtems_test_exit( 0 );
 }
-- 
2.25.1


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

[PATCH v8] Confstr support for RTEMS

[Eshan Dhawan]

From: Eshan dhawan 

Closes #3373

Signed-off-by: Eshan Dhawan 
---
 cpukit/Makefile.am|   1 +
 cpukit/posix/src/confstr.c| 151 ++
 spec/build/cpukit/librtemscpu.yml |   1 +
 spec/build/testsuites/psxtests/grp.yml|   2 +
 spec/build/testsuites/psxtests/psxconfstr.yml |  20 +++
 testsuites/psxtests/Makefile.am   |   9 ++
 testsuites/psxtests/configure.ac  |   1 +
 testsuites/psxtests/psxconfstr/init.c |  97 +++
 testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 ++
 testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
 10 files changed, 303 insertions(+)
 create mode 100644 cpukit/posix/src/confstr.c
 create mode 100644 spec/build/testsuites/psxtests/psxconfstr.yml
 create mode 100644 testsuites/psxtests/psxconfstr/init.c
 create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
 create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 565aa66ce1..469754ab84 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -511,6 +511,7 @@ librtemscpu_a_SOURCES += posix/src/condsignalsupp.c
 librtemscpu_a_SOURCES += posix/src/condtimedwait.c
 librtemscpu_a_SOURCES += posix/src/condwait.c
 librtemscpu_a_SOURCES += posix/src/condwaitsupp.c
+librtemscpu_a_SOURCES += posix/src/confstr.c
 librtemscpu_a_SOURCES += posix/src/_execve.c
 librtemscpu_a_SOURCES += posix/src/fork.c
 librtemscpu_a_SOURCES += posix/src/key.c
diff --git a/cpukit/posix/src/confstr.c b/cpukit/posix/src/confstr.c
new file mode 100644
index 00..5f18f78096
--- /dev/null
+++ b/cpukit/posix/src/confstr.c
@@ -0,0 +1,151 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+/* Reduced to make sense in RTEMS */ 
+__SCCSID("@(#)confstr.c8.1 (Berkeley) 6/4/93");
+__FBSDID("$FreeBSD$");
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Many programming environment flags have same values 
+* this block is added to raise error if the flags value change
+*/
+
+#if (_CS_POSIX_V6_ILP32_OFF32_CFLAGS != _CS_POSIX_V7_ILP32_OFF32_CFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFF32_CFLAGS and _CS_POSIX_V7_ILP32_OFF32_CFLAGS 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFF32_LDFLAGS != _CS_POSIX_V7_ILP32_OFF32_LDFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFF32_LDFLAGS and _CS_POSIX_V7_ILP32_OFF32_LDFLAGS 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFF32_LIBS!= _CS_POSIX_V7_ILP32_OFF32_LIBS)
+#error "_CS_POSIX_V6_ILP32_OFF32_LIBS and _CS_POSIX_V7_ILP32_OFF32_LIBS flag 
values not equal"
+#endif
+
+#if (_CS_POSIX_V6_LPBIG_OFFBIG_CFLAGS != _CS_POSIX_V7_LPBIG_OFFBIG_CFLAGS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_CFLAG and _CS_POSIX_V7_LPBIG_OFFBIG_CFLAG 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS != _CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS and 
_CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS flag values not equal"
+#endif
+
+#if (_CS_POSIX_V7_LPBIG_OFFBIG_LIBS != _CS_POSIX_V7_LPBIG_OFFBIG_LIBS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_LIBS and _CS_POSIX_V7_LPBIG_OFFBIG_LIBS flag 
values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFFBIG_CFLAGS != _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFFBIG_CFLAGS and _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS 
flag values not equal"
+#endif

Re: [PATCH] libcsupport: Have greedy allocations use consume extended memory

[Joel Sherrill]

On Mon, Feb 8, 2021 at 12:44 AM Chris Johns  wrote:

> On 8/2/21 5:38 pm, Sebastian Huber wrote:
> >
> > On 08/02/2021 07:30, chr...@rtems.org wrote:
> >> diff --git a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> index 4dda39873f..2361f17d2e 100644
> >> --- a/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> +++ b/cpukit/libcsupport/src/rtems_heap_greedy.c
> >> @@ -30,8 +30,20 @@ void *rtems_heap_greedy_allocate(
> >> size_t block_count
> >>   )
> >>   {
> >> +  Heap_Control *heap = RTEMS_Malloc_Heap;
> >> +  size_t size = 128 * 1024 * 1024;
> >> void *opaque;
> >>   +  while (size > 0) {
> >> +opaque = (*rtems_malloc_extend_handler)( heap, size );
> >> +if (opaque == NULL) {
> >> +  size >>= 1;
> >> +} else {
> >> +  if ( rtems_malloc_dirty_helper != NULL )
> >> +(*rtems_malloc_dirty_helper)( opaque, size );
> >> +}
> >> +  }
> > You need a couple of more ' ' after and before the braces. Each if
> should have a
> > { }. Apart from the formatting it looks good.
>
> Thanks, I will fix the formatting and push.
>
> And there is no performance issue on hardware so that must be a psim thing.
>

What performance issue do you think there could have been?

This must just be a side-effect of the PowerPC BSPs which have more than
32MB
RAM and want to support dynamically loading code. They must ensure that no
branches or calls exceed 32MB from the current location. Thus it has to be
loaded
early in program life before the heap is extended.

Are there other supported architectures where code must fit into a subset
of the
address space where it could negatively impact dynamic loading?

How does the DL code deal with PPC code that is built without the
-mlongcall
option?

EPICS discusses this here:

https://epics.anl.gov/base/ppc.php

--joel


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

Re: [PATCH v7] Confstr support for RTEMS

[Sebastian Huber]

On 08/02/2021 14:27, Joel Sherrill wrote:



On Mon, Feb 8, 2021 at 4:06 AM Sebastian Huber 
> wrote:


On 08/02/2021 10:22, Eshan Dhawan wrote:

> +static rtems_task Init(rtems_task_argument ignored)
> +{
> +  rtems_test_run(ignored, TEST_STATE);
> +}
Please check the other tests which already use this function and
optimize your test accordingly.


This seems to be a comment on other tests and not the code in this patch.

Are there issues with this patch?

Yes, it contains a bunch of superfluous stuff.

--
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 v7] Confstr support for RTEMS

[Joel Sherrill]

On Mon, Feb 8, 2021 at 4:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/02/2021 10:22, Eshan Dhawan wrote:
>
> > +static rtems_task Init(rtems_task_argument ignored)
> > +{
> > +  rtems_test_run(ignored, TEST_STATE);
> > +}
> Please check the other tests which already use this function and
> optimize your test accordingly.
>

This seems to be a comment on other tests and not the code in this patch.

Are there issues with this patch?

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v7] Confstr support for RTEMS

[Sebastian Huber]

On 08/02/2021 10:22, Eshan Dhawan wrote:


+static rtems_task Init(rtems_task_argument ignored)
+{
+  rtems_test_run(ignored, TEST_STATE);
+}
Please check the other tests which already use this function and 
optimize your test accordingly.


--
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: Remaining Waf Conversion Tickets for Community and GSoC Students

[Chris Johns]

On 8/2/21 5:49 pm, Sebastian Huber wrote:
> On 08/02/2021 06:04, Chris Johns wrote:
> 
>> On 7/2/21 4:15 am, Joel Sherrill wrote:
>>> Hi
>>>
>>> While potential GSoC students are becoming more familiar with RTEMS and the
>>> community,, I wanted to pass along a few tickets that we would appreciate 
>>> having
>>> resolved.
>>>
>>> https://devel.rtems.org/ticket/4124    
>>> -
>>> bsp
>>> tester needs to be switched to waf
>> The tester should not be effected. Do you mean bsp builder? If you do there 
>> is
>> an important architecture question we need to resolve.
>>
>> The bsp builder configuration data in ...
>>
>> https://git.rtems.org/rtems-tools/tree/config
>>
>> We how have a better configuration data set in ...
>>
>> https://git.rtems.org/rtems/tree/spec/build
>>
>> The code to parse the build spec files into some internal Python data used by
>> the waf build is in this waf script ..
>>
>> https://git.rtems.org/rtems/tree/wscript
>>
>> It is not available as module that can be reused. There is also code in the
>> rtems-central.git repo but that is out of reach for this purpose.
>>
>> I do not know how to resolve this.
> 
> All you need is this file to load the specification into a Python data 
> structure:
> 
> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
> 

Thanks.

> It is written in Python 3.6.

We still need to support python 2. Maybe having this file support both could be
part of the project.

Access to all the configure data makes a new problem for the BSP builder, being
able to vary all options a BSP has? We would not want to do this so what would
we want?

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

[PATCH v7] Confstr support for RTEMS

[Eshan Dhawan]

From: Eshan dhawan 

Closes #3373

Signed-off-by: Eshan Dhawan 
---
 cpukit/Makefile.am|   1 +
 cpukit/posix/src/confstr.c| 151 ++
 spec/build/cpukit/librtemscpu.yml |   1 +
 spec/build/testsuites/psxtests/grp.yml|   2 +
 spec/build/testsuites/psxtests/psxconfstr.yml |  20 +++
 testsuites/psxtests/Makefile.am   |   9 ++
 testsuites/psxtests/configure.ac  |   1 +
 testsuites/psxtests/psxconfstr/init.c | 129 +++
 testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 ++
 testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
 10 files changed, 335 insertions(+)
 create mode 100644 cpukit/posix/src/confstr.c
 create mode 100644 spec/build/testsuites/psxtests/psxconfstr.yml
 create mode 100644 testsuites/psxtests/psxconfstr/init.c
 create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
 create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 565aa66ce1..469754ab84 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -511,6 +511,7 @@ librtemscpu_a_SOURCES += posix/src/condsignalsupp.c
 librtemscpu_a_SOURCES += posix/src/condtimedwait.c
 librtemscpu_a_SOURCES += posix/src/condwait.c
 librtemscpu_a_SOURCES += posix/src/condwaitsupp.c
+librtemscpu_a_SOURCES += posix/src/confstr.c
 librtemscpu_a_SOURCES += posix/src/_execve.c
 librtemscpu_a_SOURCES += posix/src/fork.c
 librtemscpu_a_SOURCES += posix/src/key.c
diff --git a/cpukit/posix/src/confstr.c b/cpukit/posix/src/confstr.c
new file mode 100644
index 00..5f18f78096
--- /dev/null
+++ b/cpukit/posix/src/confstr.c
@@ -0,0 +1,151 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+/* Reduced to make sense in RTEMS */ 
+__SCCSID("@(#)confstr.c8.1 (Berkeley) 6/4/93");
+__FBSDID("$FreeBSD$");
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Many programming environment flags have same values 
+* this block is added to raise error if the flags value change
+*/
+
+#if (_CS_POSIX_V6_ILP32_OFF32_CFLAGS != _CS_POSIX_V7_ILP32_OFF32_CFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFF32_CFLAGS and _CS_POSIX_V7_ILP32_OFF32_CFLAGS 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFF32_LDFLAGS != _CS_POSIX_V7_ILP32_OFF32_LDFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFF32_LDFLAGS and _CS_POSIX_V7_ILP32_OFF32_LDFLAGS 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFF32_LIBS!= _CS_POSIX_V7_ILP32_OFF32_LIBS)
+#error "_CS_POSIX_V6_ILP32_OFF32_LIBS and _CS_POSIX_V7_ILP32_OFF32_LIBS flag 
values not equal"
+#endif
+
+#if (_CS_POSIX_V6_LPBIG_OFFBIG_CFLAGS != _CS_POSIX_V7_LPBIG_OFFBIG_CFLAGS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_CFLAG and _CS_POSIX_V7_LPBIG_OFFBIG_CFLAG 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS != _CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS and 
_CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS flag values not equal"
+#endif
+
+#if (_CS_POSIX_V7_LPBIG_OFFBIG_LIBS != _CS_POSIX_V7_LPBIG_OFFBIG_LIBS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_LIBS and _CS_POSIX_V7_LPBIG_OFFBIG_LIBS flag 
values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFFBIG_CFLAGS != _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFFBIG_CFLAGS and _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS 
flag values not equal"

Re: [PATCH v6] Confstr support for RTEMS

[Sebastian Huber]

On 08/02/2021 09:42, Eshan Dhawan wrote:


+  T_register();
+  exit_code = T_main();
+  if (exit_code == 0) {
+TEST_END();
+  }


Please use rtems_test_run().

Check the file templates and fix the Doxygen markup.

--
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 v6] Confstr support for RTEMS

[Eshan Dhawan]

From: Eshan dhawan 

Signed-off-by: Eshan Dhawan 
---
 cpukit/Makefile.am|   1 +
 cpukit/posix/src/confstr.c| 151 ++
 spec/build/cpukit/librtemscpu.yml |   1 +
 spec/build/testsuites/psxtests/grp.yml|   2 +
 spec/build/testsuites/psxtests/psxconfstr.yml |  20 +++
 testsuites/psxtests/Makefile.am   |   9 ++
 testsuites/psxtests/configure.ac  |   1 +
 testsuites/psxtests/psxconfstr/init.c | 143 +
 testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 ++
 testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
 10 files changed, 349 insertions(+)
 create mode 100644 cpukit/posix/src/confstr.c
 create mode 100644 spec/build/testsuites/psxtests/psxconfstr.yml
 create mode 100644 testsuites/psxtests/psxconfstr/init.c
 create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
 create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 565aa66ce1..469754ab84 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -511,6 +511,7 @@ librtemscpu_a_SOURCES += posix/src/condsignalsupp.c
 librtemscpu_a_SOURCES += posix/src/condtimedwait.c
 librtemscpu_a_SOURCES += posix/src/condwait.c
 librtemscpu_a_SOURCES += posix/src/condwaitsupp.c
+librtemscpu_a_SOURCES += posix/src/confstr.c
 librtemscpu_a_SOURCES += posix/src/_execve.c
 librtemscpu_a_SOURCES += posix/src/fork.c
 librtemscpu_a_SOURCES += posix/src/key.c
diff --git a/cpukit/posix/src/confstr.c b/cpukit/posix/src/confstr.c
new file mode 100644
index 00..5f18f78096
--- /dev/null
+++ b/cpukit/posix/src/confstr.c
@@ -0,0 +1,151 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+/* Reduced to make sense in RTEMS */ 
+__SCCSID("@(#)confstr.c8.1 (Berkeley) 6/4/93");
+__FBSDID("$FreeBSD$");
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Many programming environment flags have same values 
+* this block is added to raise error if the flags value change
+*/
+
+#if (_CS_POSIX_V6_ILP32_OFF32_CFLAGS != _CS_POSIX_V7_ILP32_OFF32_CFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFF32_CFLAGS and _CS_POSIX_V7_ILP32_OFF32_CFLAGS 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFF32_LDFLAGS != _CS_POSIX_V7_ILP32_OFF32_LDFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFF32_LDFLAGS and _CS_POSIX_V7_ILP32_OFF32_LDFLAGS 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFF32_LIBS!= _CS_POSIX_V7_ILP32_OFF32_LIBS)
+#error "_CS_POSIX_V6_ILP32_OFF32_LIBS and _CS_POSIX_V7_ILP32_OFF32_LIBS flag 
values not equal"
+#endif
+
+#if (_CS_POSIX_V6_LPBIG_OFFBIG_CFLAGS != _CS_POSIX_V7_LPBIG_OFFBIG_CFLAGS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_CFLAG and _CS_POSIX_V7_LPBIG_OFFBIG_CFLAG 
flag values not equal"
+#endif
+
+#if (_CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS != _CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS and 
_CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS flag values not equal"
+#endif
+
+#if (_CS_POSIX_V7_LPBIG_OFFBIG_LIBS != _CS_POSIX_V7_LPBIG_OFFBIG_LIBS)
+#error "_CS_POSIX_V6_LPBIG_OFFBIG_LIBS and _CS_POSIX_V7_LPBIG_OFFBIG_LIBS flag 
values not equal"
+#endif
+
+#if (_CS_POSIX_V6_ILP32_OFFBIG_CFLAGS != _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS)
+#error "_CS_POSIX_V6_ILP32_OFFBIG_CFLAGS and _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS 
flag values not equal"
+#endif
+
+#if