[PATCH] sparc: Prefer RTEMS_FATAL_SOURCE_EXCEPTION

[Sebastian Huber]

Prefer RTEMS_FATAL_SOURCE_EXCEPTION over
INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT since the fatal code
(rtems_exception_frame) provides more context.
---
 cpukit/score/cpu/sparc/sparc-bad-trap.S | 14 --
 testsuites/sptests/spfatal30/init.c | 37 +++--
 testsuites/sptests/spfatal31/init.c | 35 +--
 3 files changed, 55 insertions(+), 31 deletions(-)

diff --git a/cpukit/score/cpu/sparc/sparc-bad-trap.S 
b/cpukit/score/cpu/sparc/sparc-bad-trap.S
index 2e73a4a7da..c20a97889f 100644
--- a/cpukit/score/cpu/sparc/sparc-bad-trap.S
+++ b/cpukit/score/cpu/sparc/sparc-bad-trap.S
@@ -208,20 +208,6 @@ SYM(_SPARC_Bad_trap):
 std %f30, [%l7 + SPARC_EXCEPTION_OFFSET_FP(15)]
 #endif
 
-#if !defined(SPARC_USE_LAZY_FP_SWITCH)
-/*
- * Call
- * _Internal_error( INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT )
- * if necessary.
- */
-cmp %l3, 4
-bne .Lno_fp_disable_trap
- nop
-callSYM(_Internal_error)
- set38, %o0
-.Lno_fp_disable_trap:
-#endif
-
 /*
  * Call _Terminate( RTEMS_FATAL_SOURCE_EXCEPTION, %l0 ).
  */
diff --git a/testsuites/sptests/spfatal30/init.c 
b/testsuites/sptests/spfatal30/init.c
index a02bf062f4..a76fe1f309 100644
--- a/testsuites/sptests/spfatal30/init.c
+++ b/testsuites/sptests/spfatal30/init.c
@@ -22,9 +22,28 @@
 
 const char rtems_test_name[] = "SPFATAL 30";
 
-#if (CPU_HARDWARE_FP == TRUE && CPU_ALL_TASKS_ARE_FP == FALSE) \
-  || SPARC_HAS_FPU == 1
-#define EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT
+#if ( CPU_HARDWARE_FP == TRUE && CPU_ALL_TASKS_ARE_FP == FALSE ) || \
+  defined(SPARC_USE_LAZY_FP_SWITCH)
+
+#define EXPECTED_FATAL_SOURCE INTERNAL_ERROR_CORE
+
+static bool is_expected_fatal_code( rtems_fatal_code code )
+{
+  return code == INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT;
+}
+
+#elif defined(SPARC_USE_SYNCHRONOUS_FP_SWITCH)
+
+#define EXPECTED_FATAL_SOURCE RTEMS_FATAL_SOURCE_EXCEPTION
+
+static bool is_expected_fatal_code( rtems_fatal_code code )
+{
+  const rtems_exception_frame *frame;
+
+  frame = (const rtems_exception_frame *) code;
+  return frame->trap == 4;
+}
+
 #endif
 
 static volatile double f = 1.0;
@@ -35,7 +54,7 @@ static void Init(rtems_task_argument arg)
 
   f *= 123.456;
 
-#ifdef EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT
+#ifdef EXPECTED_FATAL_SOURCE
   rtems_test_assert(0);
 #else
   TEST_END();
@@ -43,7 +62,7 @@ static void Init(rtems_task_argument arg)
 #endif
 }
 
-#ifdef EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT
+#ifdef EXPECTED_FATAL_SOURCE
 static void fatal_extension(
   rtems_fatal_source source,
   bool always_set_to_false,
@@ -51,9 +70,9 @@ static void fatal_extension(
 )
 {
   if (
-source == INTERNAL_ERROR_CORE
+source == EXPECTED_FATAL_SOURCE
   && !always_set_to_false
-  && code == INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT
+  && is_expected_fatal_code( code )
   ) {
 TEST_END();
   }
@@ -63,11 +82,11 @@ static void fatal_extension(
   { .fatal = fatal_extension }, \
   RTEMS_TEST_INITIAL_EXTENSION
 
-#else /* EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT */
+#else /* EXPECTED_FATAL_SOURCE */
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
-#endif /* EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT */
+#endif /* EXPECTED_FATAL_SOURCE */
 
 #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
 
diff --git a/testsuites/sptests/spfatal31/init.c 
b/testsuites/sptests/spfatal31/init.c
index 5aab6630dc..782e7632cc 100644
--- a/testsuites/sptests/spfatal31/init.c
+++ b/testsuites/sptests/spfatal31/init.c
@@ -22,8 +22,27 @@
 
 const char rtems_test_name[] = "SPFATAL 31";
 
-#if SPARC_HAS_FPU == 1
-#define EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT
+#if defined(SPARC_USE_LAZY_FP_SWITCH)
+
+#define EXPECTED_FATAL_SOURCE INTERNAL_ERROR_CORE
+
+static bool is_expected_fatal_code( rtems_fatal_code code )
+{
+  return code == INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT;
+}
+
+#elif defined(SPARC_USE_SYNCHRONOUS_FP_SWITCH)
+
+#define EXPECTED_FATAL_SOURCE RTEMS_FATAL_SOURCE_EXCEPTION
+
+static bool is_expected_fatal_code( rtems_fatal_code code )
+{
+  const rtems_exception_frame *frame;
+
+  frame = (const rtems_exception_frame *) code;
+  return frame->trap == 4;
+}
+
 #endif
 
 static volatile double f = 1.0;
@@ -49,7 +68,7 @@ static void Init(rtems_task_argument arg)
   sc = rtems_task_wake_after(2);
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-#ifdef EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT
+#ifdef EXPECTED_FATAL_SOURCE
   rtems_test_assert(0);
 #else
   TEST_END();
@@ -57,7 +76,7 @@ static void Init(rtems_task_argument arg)
 #endif
 }
 
-#ifdef EXPECT_ILLEGAL_USE_OF_FLOATING_POINT_UNIT
+#ifdef EXPECTED_FATAL_SOURCE
 static void fatal_extension(
   rtems_fatal_source source,
   bool always_set_to_false,
@@ -65,9 +84,9 @@ static void fatal_extension(
 )
 {
   if (
-source == INTERNAL_ERROR_CORE
+source ==

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Hello everyone,
>From the discussion on discord it looks like clang-format cannot be
installed on MacOS and FreeBSD. Is there any alternative or way to have it
on these operating systems?

On Wed, 5 May 2021, 10:21 pm Ida Delphine,  wrote:

> Hello everyone,
>
> Regarding this project (https://devel.rtems.org/ticket/3860) I went with
> clang-format as we all agreed. I have tested it on some "score" files and
> it made some changes which I don't think are very much in line with the
> RTEMS coding style. However, it wasn't really clear if we will chage the
> RTEMS coding style or try to make changes to clang-format to fit the style.
> Please will love to know the best option.
>
> Cheers,
> Ida.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] This adds a way to print the host triplet

[Robin Müller]

Hi,

I think this patch was forgotten so I'm just pushing it up again :-)

Kind Regards
Robin

On Thu, 25 Feb 2021 at 10:57, Robin Müller 
wrote:

> I still think it would be nice if very common tool suites like ARM could
> be installed /downloaded in a pre-compiled way at least for Windows because
> the  tool building process is the only thing preventing
> development on Windows some(or most?) times.
> xPacks is doing that (and they use CXC for the Windows toolchain too,
> building it automatically for Windows on a Debian machine, see here
> https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases) and
> Arduino ships pre-compiled  toolchains with their software (but it's
> possible to download separately as well).
>
> Once the tool suite was available, I did not have any OS specific issues
> any more.
>
> Kind Regards
> Robin
>
> On Thu, 25 Feb 2021 at 10:44, Robin Müller 
> wrote:
>
>> I only used it to CXC the ARM toolchain (Linux -> Windows) mainly because
>> I have only needed the ARM tool suite up until now (and there were issues
>> building it  on Windows, but maybe that has been solved since).
>> That was a few weeks ago and I have not rebuilt it since.
>>
>> Kind Regards
>> Robin
>>
>> On Thu, 25 Feb 2021 at 01:30, Chris Johns  wrote:
>>
>>> On 25/2/21 9:21 am, Robin Müller wrote:
>>> > There is no first patch (the first patch file was a SIS update, but
>>> that's
>>> > already inside master I think).
>>> > I think I used this when I canadian cross-compiled the RTEMS ARM
>>> toolchain for
>>> > Windows on Linux and I was not sure what the triplet was.
>>>
>>> Great and thanks. Have you been using the Cxc mode recently? I have
>>> stopped
>>> testing it.
>>>
>>> Chris
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: New Defects reported by Coverity Scan for RTEMS

[Joel Sherrill]

I am not sure why these popped up now but some indicate logic errors
in the code cited.

--joel

-- Forwarded message -
From: 
Date: Thu, Jul 15, 2021 at 12:26 AM
Subject: New Defects reported by Coverity Scan for RTEMS
To: 


Hi,

Please find the latest report on new defect(s) introduced to RTEMS
found with Coverity Scan.

9 new defect(s) introduced to RTEMS found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 9 of 9 defect(s)


** CID 1468693:  Insecure data handling  (TAINTED_SCALAR)



*** CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
/testsuites/samples/fileio/init.c: 992 in fileio_read_file()
986*/
987   if (!failed) {
988 printf("use suffix K for Kbytes, M for Mbytes or no suffix
for bytes:\n"
989"Enter block size to use for read calls ==>");
990 fflush(stdout);
991 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
>>> CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted expression "tmp_str" to "fileio_str2size", which uses 
>>> it as an offset.
992 failed = fileio_str2size(tmp_str,&buf_size);
993 if (failed) {
994   printf("*** illegal block size, aborted\n");
995 }
996   }
997

** CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
/testsuites/samples/fileio/init.c: 401 in create_ramdisk()



*** CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
/testsuites/samples/fileio/init.c: 401 in create_ramdisk()
395   printf ("error: invalid option: %s\n", argv[arg]);
396   return 1;
397   }
398 }
399   }
400
>>> CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
>>> In expression "size / block_size", division by expression "block_size" 
>>> which may be zero has undefined behavior.
401   block_count = size / block_size;
402
403   /*
404* Register the RAM Disk driver.
405*/
406   printf ("Register RAM Disk Driver [blocks=%" PRIu32 \

** CID 1468691:  Resource leaks  (RESOURCE_LEAK)
/testsuites/samples/fileio/init.c: 209 in shell_nvdisk_erase()



*** CID 1468691:  Resource leaks  (RESOURCE_LEAK)
/testsuites/samples/fileio/init.c: 209 in shell_nvdisk_erase()
203 return 1;
204   }
205
206   if (ioctl (fd, RTEMS_NVDISK_IOCTL_ERASE_DISK) < 0)
207   {
208 printf ("error: nvdisk driver erase failed: %s\n",
strerror (errno));
>>> CID 1468691:  Resource leaks  (RESOURCE_LEAK)
>>> Handle variable "fd" going out of scope leaks the handle.
209 return 1;
210   }
211
212   close (fd);
213
214   printf ("nvdisk erased successful\n");

** CID 1468689:(TAINTED_SCALAR)



*** CID 1468689:(TAINTED_SCALAR)
/testsuites/samples/fileio/init.c: 846 in fileio_write_file()
840*/
841   if (!failed) {
842 printf("use suffix K for Kbytes, M for Mbytes or no suffix
for bytes:\n"
843"Enter block size to use for write calls ==>");
844 fflush(stdout);
845 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
>>> CID 1468689:(TAINTED_SCALAR)
>>> Passing tainted expression "tmp_str" to "fileio_str2size", which uses 
>>> it as an offset.
846 failed = fileio_str2size(tmp_str,&buf_size);
847 if (failed) {
848   printf("*** illegal block size, aborted\n");
849 }
850   }
851
/testsuites/samples/fileio/init.c: 833 in fileio_write_file()
827*/
828   if (!failed) {
829 printf("use suffix K for Kbytes, M for Mbytes or no suffix
for bytes:\n"
830"Enter filesize to write ==>");
831 fflush(stdout);
832 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
>>> CID 1468689:(TAINTED_SCALAR)
>>> Passing tainted expression "tmp_str" to "fileio_str2size", which uses 
>>> it as an offset.
833 failed = fileio_str2size(tmp_str,&file_size);
834 if (failed) {
835   printf("*** illegal file size, aborted\n");
836 }
837   }
838   /*

** CID 1468687:  Incorrect expression  (COPY_PASTE_ERROR)
/testsuites/samples/paranoia/paranoia.c: 584 in paranoia()



*** CID 1468687:  Incorrect expression  (COPY_PASTE_ERROR)
/testsuites/samples/paranoia/paranoia.c: 584 in paranoia()
578 Precision = Y;
579 }
580 if ((Precision != FLOOR (Precision)) || (Radix == One)) {
581 printf ("Precision cannot be characterized by an
Integer number\n");
582 

[PATCH rtems-docs] user/imxrt: Add notes about problems with EVB

[Christian Mauderer]

There are some possible problems with the i.MXRT1050 evaluation board.
Make some notes about that in the BSP manual.
---
 user/bsps/arm/imxrt.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
index 3f8b270..f8d9731 100644
--- a/user/bsps/arm/imxrt.rst
+++ b/user/bsps/arm/imxrt.rst
@@ -10,6 +10,10 @@ This BSP offers only one variant, the `imxrt1052`. This 
variant supports the
 i.MXRT 1052 processor on a IMXRT1050-EVKB (tested with rev A1). You can also
 configure it to work with custom boards.
 
+NOTE: The IMXRT1050-EVKB has an backlight controller that must not be enabled
+without load. Make sure to either attach a load, disable it by software or
+disable it by removing the 0-Ohm resistor on it's input.
+
 Build Configuration Options
 ---
 
@@ -41,6 +45,11 @@ Then just copy the generated binary to the mass storage 
provided by the
 debugger. Wait a bit till the mass storage vanishes and re-appears. After that,
 reset the board and the newly programmed application will start.
 
+NOTE: It seems that there is a bug on at least some of the on board debuggers.
+They can't write more than 1MB to the HyperFlash. If your application is bigger
+than that (like quite some of the applications in libbsd), you should use an
+external debugger or find some alternative programming method.
+
 For debugging: Create a special application with a `while(true)` loop at end of
 `bsp_start_hook_1`. Load that application into flash. Then remove the loop
 again, build your BSP for SDRAM and use a debugger to load the application into
-- 
2.26.2

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

Re: New Defects reported by Coverity Scan for RTEMS

[Gedare Bloom]

I think we have been excluding testsuites. The setting appears to
still be there:
Tests */testsuites/* Ignored=Yes

I think maybe the pattern needs to be updated to put a dot before each
asterisk: .*/testsuites/.*

However, these could probably be fixed mostly without trouble.

On Thu, Jul 15, 2021 at 7:24 AM Joel Sherrill  wrote:
>
> I am not sure why these popped up now but some indicate logic errors
> in the code cited.
>
> --joel
>
> -- Forwarded message -
> From: 
> Date: Thu, Jul 15, 2021 at 12:26 AM
> Subject: New Defects reported by Coverity Scan for RTEMS
> To: 
>
>
> Hi,
>
> Please find the latest report on new defect(s) introduced to RTEMS
> found with Coverity Scan.
>
> 9 new defect(s) introduced to RTEMS found with Coverity Scan.
>
>
> New defect(s) Reported-by: Coverity Scan
> Showing 9 of 9 defect(s)
>
>
> ** CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
>
>
> 
> *** CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
> /testsuites/samples/fileio/init.c: 992 in fileio_read_file()
> 986*/
> 987   if (!failed) {
> 988 printf("use suffix K for Kbytes, M for Mbytes or no suffix
> for bytes:\n"
> 989"Enter block size to use for read calls ==>");
> 990 fflush(stdout);
> 991 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
> >>> CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
> >>> Passing tainted expression "tmp_str" to "fileio_str2size", which uses 
> >>> it as an offset.
> 992 failed = fileio_str2size(tmp_str,&buf_size);
> 993 if (failed) {
> 994   printf("*** illegal block size, aborted\n");
> 995 }
> 996   }
> 997
>
> ** CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
> /testsuites/samples/fileio/init.c: 401 in create_ramdisk()
>
>
> 
> *** CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
> /testsuites/samples/fileio/init.c: 401 in create_ramdisk()
> 395   printf ("error: invalid option: %s\n", argv[arg]);
> 396   return 1;
> 397   }
> 398 }
> 399   }
> 400
> >>> CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
> >>> In expression "size / block_size", division by expression 
> >>> "block_size" which may be zero has undefined behavior.
> 401   block_count = size / block_size;
> 402
> 403   /*
> 404* Register the RAM Disk driver.
> 405*/
> 406   printf ("Register RAM Disk Driver [blocks=%" PRIu32 \
>
> ** CID 1468691:  Resource leaks  (RESOURCE_LEAK)
> /testsuites/samples/fileio/init.c: 209 in shell_nvdisk_erase()
>
>
> 
> *** CID 1468691:  Resource leaks  (RESOURCE_LEAK)
> /testsuites/samples/fileio/init.c: 209 in shell_nvdisk_erase()
> 203 return 1;
> 204   }
> 205
> 206   if (ioctl (fd, RTEMS_NVDISK_IOCTL_ERASE_DISK) < 0)
> 207   {
> 208 printf ("error: nvdisk driver erase failed: %s\n",
> strerror (errno));
> >>> CID 1468691:  Resource leaks  (RESOURCE_LEAK)
> >>> Handle variable "fd" going out of scope leaks the handle.
> 209 return 1;
> 210   }
> 211
> 212   close (fd);
> 213
> 214   printf ("nvdisk erased successful\n");
>
> ** CID 1468689:(TAINTED_SCALAR)
>
>
> 
> *** CID 1468689:(TAINTED_SCALAR)
> /testsuites/samples/fileio/init.c: 846 in fileio_write_file()
> 840*/
> 841   if (!failed) {
> 842 printf("use suffix K for Kbytes, M for Mbytes or no suffix
> for bytes:\n"
> 843"Enter block size to use for write calls ==>");
> 844 fflush(stdout);
> 845 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
> >>> CID 1468689:(TAINTED_SCALAR)
> >>> Passing tainted expression "tmp_str" to "fileio_str2size", which uses 
> >>> it as an offset.
> 846 failed = fileio_str2size(tmp_str,&buf_size);
> 847 if (failed) {
> 848   printf("*** illegal block size, aborted\n");
> 849 }
> 850   }
> 851
> /testsuites/samples/fileio/init.c: 833 in fileio_write_file()
> 827*/
> 828   if (!failed) {
> 829 printf("use suffix K for Kbytes, M for Mbytes or no suffix
> for bytes:\n"
> 830"Enter filesize to write ==>");
> 831 fflush(stdout);
> 832 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
> >>> CID 1468689:(TAINTED_SCALAR)
> >>> Passing tainted expression "tmp_str" to "fileio_str2size", which uses 
> >>> it as an offset.
> 833 failed = fileio_str2size(tmp_str,&file_size);
> 834 if (failed) {
> 835   printf("*** illegal file size, aborted\n");
> 836 

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  wrote:
>
> Hello everyone,
> From the discussion on discord it looks like clang-format cannot be installed 
> on MacOS and FreeBSD. Is there any alternative or way to have it on these 
> operating systems?
>
What are the challenges with them? Can clang-format be built from
source on those hosts?

> On Wed, 5 May 2021, 10:21 pm Ida Delphine,  wrote:
>>
>> Hello everyone,
>>
>> Regarding this project (https://devel.rtems.org/ticket/3860) I went with 
>> clang-format as we all agreed. I have tested it on some "score" files and it 
>> made some changes which I don't think are very much in line with the RTEMS 
>> coding style. However, it wasn't really clear if we will chage the RTEMS 
>> coding style or try to make changes to clang-format to fit the style.
>> Please will love to know the best option.
>>
>> Cheers,
>> Ida.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v1 1/2] xilinx-zynqmp.rst: Documented SDIO driver

[Gedare Bloom]

ok

On Wed, Jul 14, 2021 at 9:03 AM Stephen Clark  wrote:
>
> Added documentation for SDIO driver.
> ---
>  user/bsps/aarch64/xilinx-zynqmp.rst | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst 
> b/user/bsps/aarch64/xilinx-zynqmp.rst
> index 71b6842..30ae8a3 100644
> --- a/user/bsps/aarch64/xilinx-zynqmp.rst
> +++ b/user/bsps/aarch64/xilinx-zynqmp.rst
> @@ -55,6 +55,20 @@ Console Driver
>  The console driver supports the default Qemu emulated ARM PL011 PrimeCell 
> UART
>  as well as the physical ARM PL011 PrimeCell UART in the ZynqMP hardware.
>
> +SDHCI Driver
> +
> +
> +The ZynqMP bsp has an SDHCI driver which allows reading to and writing from 
> SD
> +cards. These can be tested in qemu using the "-sd" option. For example:
> +
> +.. code-block:: shell
> +
> +  qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \
> +   -machine xlnx-zcu102 -m 4096 -kernel media01.exe -sd example.img
> +
> +The SD card image should have an MSDOS partition table with a single 
> partition
> +containing a FAT file system.
> +
>  Network Configuration
>  -
>
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v1] readme: Minor clarifications and fixes

[Gedare Bloom]

On Wed, Jul 14, 2021 at 8:44 AM Stephen Clark  wrote:
>
> Added some instructions for setting up CentOS 8.
> Fixed some minor typographical errors.
> Updated a dead link.
> Reworded some sentences for clarity
> ---
>  README.txt | 58 ++
>  1 file changed, 32 insertions(+), 26 deletions(-)
>
> diff --git a/README.txt b/README.txt
> index 03f57ed..53549f2 100644
> --- a/README.txt
> +++ b/README.txt
> @@ -1,16 +1,17 @@
>  RTEMS Project Documentation
>  ===
>
> -The documents are written in ReST and built using Sphinx. The build system 
> will
> -check the version of Sphinx and ensure you have a suitable version
> -available. If your host does not provide a packaged version use PIP to fetch 
> a
> +The documents are written in ReST and built using Sphinx. The waf build 
> system
> +will check the version of Sphinx and ensure you have a suitable version
> +available. If your host does not provide a packaged version, use PIP to 
> fetch a
>  recent version. The Sphinx website provides details on doing this.
>
> -ReST is the Re-Structured-Text format. It is a simple markup language that 
> allows
> -us to create quality documentaion. It is flexible and powerful however does 
> not
> -attempt to train it to create a specific format. You need to test any new way
> -of presenting something on all output formats. What may look great in one
> -format may not translate with the same clarity to another output format.
> +ReST is the Re-Structured-Text format. It is a simple markup language that
> +allows us to create quality documentation which can easily be converted to
> +multiple different formats. This flexibility is convenient, but you still 
> need
> +to test any new way of presenting something on all output formats. What may 
> look
> +great in one format may not translate with the same clarity to another output
> +format.
>
>  The RTEMS Documentation output formats are:
>
> @@ -26,7 +27,7 @@ Images can be created from source using PlantUML and Ditaa.
>
>  A Sphinx checksheet is:
>
> - http://docs.sphinxdocs.com/en/latest/cheatsheet.html#rst-cheat-sheet
> + https://sphinx-tutorial.readthedocs.io/cheatsheet/#rst-cheat-sheet
>
>  Production Quality Hosts
>  
> @@ -45,7 +46,7 @@ NOTE: RedHat Enterprise Linux (RHEL) and Fedora should be 
> the same as CentOS.
>  Images
>  --
>
> -All images should be placed int he 'images' directory and referenced from the
> +All images should be placed in the 'images' directory and referenced from the
>  ReST with a relative path. This lets us shared and control images.
>
>  We prefer being able to build images from source. This is not always possible
> @@ -85,7 +86,7 @@ The home page contain the language options. The PlantUML 
> online demo server
>  supports Ditaa so use that resource as an online tool. The Ditaa image source
>  extension is '.ditaa'.
>
> -You do not need PlantUML or Ditaa install to build our documentation. The
> +You do not need PlantUML or Ditaa installed to build our documentation. The
>  online resources can be used. Save the source and the generated PNG file in 
> the
>  same directory under 'images'.
>
> @@ -94,12 +95,12 @@ Host Setup
>
>  HTML builds directly with Sphinx, PDF requires a full Latex (texlive) 
> install,
>  and building a Single HTML page requires the 'inliner' tool. The
> -sphinxcontrib-bibtex extension is mandatory. PlantUML requres the Node.js
> +sphinxcontrib-bibtex extension is mandatory. PlantUML requires the Node.js
>  package called 'node-plantuml' which installs the 'puml' command and Ditaa 
> needs
>  the 'ditaa' command and package. Ditaa images are built using the 'puml'
>  command.
>
> -Please add your host as you set it up.
> +Please add your host to this section as you set it up.
>
>  The best results are produced with Python3 and a virtual environment`. It can
>  create a specific python environment using `pip`.
> @@ -107,7 +108,7 @@ create a specific python environment using `pip`.
>  Virtual Environment
>  ~~~
>
> -Create a directory to house the virtual environment, create the envrionment
> +Create a directory to house the virtual environment, create the environment
>  and the activate it. This example assumes Python3 and the `venv` module:
>
>$ mkdir sphinx
> @@ -120,7 +121,7 @@ Alternatively you can use the `virtualenv` command:
>$ virtualenv sphinx
>$ . ./sphinx/bin/activate
>
> -The prompt will now change. You can install Sphinx with:
> +Either way, the prompt will now change. You can install Sphinx with:
>
>$ pip install sphinx
>$ pip install sphinxcontrib-bibtex
> @@ -207,8 +208,8 @@ Ditaa:
>
># pkg install ditaa
>
> -CentOS 7
> -
> +CentOS 7 & 8
> +
>

I think add a section below for CentOS 8, and refer the reader back to
CentOS 7 with the differences noted?

Does & typeset properly in the generated documentation? Not that it
matters if you refactor the C

Re: [PATCH rtems-libbsd v1] nexus: Added SDHCI driver to ZynqMP

[Gedare Bloom]

looks fine to me

On Mon, Jul 12, 2021 at 5:14 PM Stephen Clark  wrote:
>
> Made ZynqMP build with the SDHCI driver.
> ---
>  rtemsbsd/include/bsp/nexus-devices.h  |  4 +++
>  .../include/machine/rtems-bsd-nexus-bus.h | 29 +++
>  2 files changed, 33 insertions(+)
>
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
> b/rtemsbsd/include/bsp/nexus-devices.h
> index 5b51de7e..fdc845c1 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -119,6 +119,10 @@ 
> RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
>  RTEMS_BSD_DRIVER_E1000PHY;
>  RTEMS_BSD_DRIVER_UKPHY;
>
> +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI0;
> +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI1;
> +RTEMS_BSD_DRIVER_MMC;
> +
>  #elif defined(LIBBSP_ARM_ATSAM_BSP_H)
>
>  RTEMS_BSD_DRIVER_USB;
> diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h 
> b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> index ccf8efa6..103d5b1d 100644
> --- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> +++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
> @@ -139,6 +139,35 @@ extern "C" {
>&zynqmp_slcr_res[0])
>  #endif /* RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR */
>
> +/*
> + * Xilinx ZynqMP Arasan SDIO Driver.
> + */
> +#if !defined(RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI)
> +  #define RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI(_num, _base, _irq)
>  \
> +static const rtems_bsd_device_resource arasan_sdhci ## _num ## _res[] = 
> {   \
> +  {  
>\
> +.type = RTEMS_BSD_RES_MEMORY,
>\
> +.start_request = 0,  
>\
> +.start_actual = (_base)  
>\
> +  }, {   
>\
> +.type = RTEMS_BSD_RES_IRQ,   
>\
> +.start_request = 0,  
>\
> +.start_actual = (_irq)   
>\
> +  }  
>\
> +};   
>\
> +RTEMS_BSD_DEFINE_NEXUS_DEVICE(arasan_sdhci, _num,
>\
> +  RTEMS_ARRAY_SIZE(arasan_sdhci ## _num ## 
> _res),  \
> +  &arasan_sdhci ## _num ## _res[0])
> +#endif /* RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI */
> +#if !defined(RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI0)
> +  #define RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI0\
> +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI(0, 0xFF16, 80)
> +#endif /* RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI0 */
> +#if !defined(RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI1)
> +  #define RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI1\
> +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI(1, 0xFF17, 81)
> +#endif /* RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SDHCI1 */
> +
>  /*
>   * Xilinx Zynq Arasan SDIO Driver.
>   */
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Defects reported by Coverity Scan for RTEMS

[Joel Sherrill]

On Thu, Jul 15, 2021, 9:09 AM Gedare Bloom  wrote:

> I think we have been excluding testsuites. The setting appears to
> still be there:
> Tests */testsuites/* Ignored=Yes
>
> I think maybe the pattern needs to be updated to put a dot before each
> asterisk: .*/testsuites/.*
>

No idea why this broke after years though.

>
> However, these could probably be fixed mostly without trouble.
>

That's what I thought. At.keast one looked like a real bug.

--joel


> On Thu, Jul 15, 2021 at 7:24 AM Joel Sherrill  wrote:
> >
> > I am not sure why these popped up now but some indicate logic errors
> > in the code cited.
> >
> > --joel
> >
> > -- Forwarded message -
> > From: 
> > Date: Thu, Jul 15, 2021 at 12:26 AM
> > Subject: New Defects reported by Coverity Scan for RTEMS
> > To: 
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to RTEMS
> > found with Coverity Scan.
> >
> > 9 new defect(s) introduced to RTEMS found with Coverity Scan.
> >
> >
> > New defect(s) Reported-by: Coverity Scan
> > Showing 9 of 9 defect(s)
> >
> >
> > ** CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
> >
> >
> >
> 
> > *** CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
> > /testsuites/samples/fileio/init.c: 992 in fileio_read_file()
> > 986*/
> > 987   if (!failed) {
> > 988 printf("use suffix K for Kbytes, M for Mbytes or no suffix
> > for bytes:\n"
> > 989"Enter block size to use for read calls ==>");
> > 990 fflush(stdout);
> > 991 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
> > >>> CID 1468693:  Insecure data handling  (TAINTED_SCALAR)
> > >>> Passing tainted expression "tmp_str" to "fileio_str2size", which
> uses it as an offset.
> > 992 failed = fileio_str2size(tmp_str,&buf_size);
> > 993 if (failed) {
> > 994   printf("*** illegal block size, aborted\n");
> > 995 }
> > 996   }
> > 997
> >
> > ** CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
> > /testsuites/samples/fileio/init.c: 401 in create_ramdisk()
> >
> >
> >
> 
> > *** CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
> > /testsuites/samples/fileio/init.c: 401 in create_ramdisk()
> > 395   printf ("error: invalid option: %s\n", argv[arg]);
> > 396   return 1;
> > 397   }
> > 398 }
> > 399   }
> > 400
> > >>> CID 1468692:  Integer handling issues  (DIVIDE_BY_ZERO)
> > >>> In expression "size / block_size", division by expression
> "block_size" which may be zero has undefined behavior.
> > 401   block_count = size / block_size;
> > 402
> > 403   /*
> > 404* Register the RAM Disk driver.
> > 405*/
> > 406   printf ("Register RAM Disk Driver [blocks=%" PRIu32 \
> >
> > ** CID 1468691:  Resource leaks  (RESOURCE_LEAK)
> > /testsuites/samples/fileio/init.c: 209 in shell_nvdisk_erase()
> >
> >
> >
> 
> > *** CID 1468691:  Resource leaks  (RESOURCE_LEAK)
> > /testsuites/samples/fileio/init.c: 209 in shell_nvdisk_erase()
> > 203 return 1;
> > 204   }
> > 205
> > 206   if (ioctl (fd, RTEMS_NVDISK_IOCTL_ERASE_DISK) < 0)
> > 207   {
> > 208 printf ("error: nvdisk driver erase failed: %s\n",
> > strerror (errno));
> > >>> CID 1468691:  Resource leaks  (RESOURCE_LEAK)
> > >>> Handle variable "fd" going out of scope leaks the handle.
> > 209 return 1;
> > 210   }
> > 211
> > 212   close (fd);
> > 213
> > 214   printf ("nvdisk erased successful\n");
> >
> > ** CID 1468689:(TAINTED_SCALAR)
> >
> >
> >
> 
> > *** CID 1468689:(TAINTED_SCALAR)
> > /testsuites/samples/fileio/init.c: 846 in fileio_write_file()
> > 840*/
> > 841   if (!failed) {
> > 842 printf("use suffix K for Kbytes, M for Mbytes or no suffix
> > for bytes:\n"
> > 843"Enter block size to use for write calls ==>");
> > 844 fflush(stdout);
> > 845 fgets(tmp_str,sizeof(tmp_str)-1,stdin);
> > >>> CID 1468689:(TAINTED_SCALAR)
> > >>> Passing tainted expression "tmp_str" to "fileio_str2size", which
> uses it as an offset.
> > 846 failed = fileio_str2size(tmp_str,&buf_size);
> > 847 if (failed) {
> > 848   printf("*** illegal block size, aborted\n");
> > 849 }
> > 850   }
> > 851
> > /testsuites/samples/fileio/init.c: 833 in fileio_write_file()
> > 827*/
> > 828   if (!failed) {
> > 829 printf("use suffix K for Kbytes, M for Mbytes or no suffix
> > for bytes:\n"
> > 830"En

Re: [PATCH v3] bsps: Move optfdt* files to shared parent directory

[Gedare Bloom]

This patch looks fine to me if someone can pick it up. It does touch a
lot of build BSPs though.

On Fri, Jul 9, 2021 at 12:16 AM Pranav Dangi  wrote:
>
> ping. (Apart from moving the files in a shared directory, a part of this 
> patch also gets the RTEMS master branch to work on all the Pi's except 4.)
>
> On Fri, 2 Jul 2021, 09:35 Pranav Dangi,  wrote:
>>
>> yes, I've built all of them
>>
>> On Thu, Jul 1, 2021 at 10:01 PM Gedare Bloom  wrote:
>>>
>>> Did you build all affected BSPs?
>>>
>>> On Thu, Jul 1, 2021 at 4:05 AM pranav  wrote:
>>> >
>>> > ---
>>> >  .../arm/altera-cyclone-v/bspalteracyclonev.yml   |  8 
>>> >  spec/build/bsps/arm/beagle/grp.yml   |  8 
>>> >  spec/build/bsps/arm/beagle/optfdtcpyro.yml   | 15 ---
>>> >  spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16 
>>> >  spec/build/bsps/arm/beagle/optfdtro.yml  | 15 ---
>>> >  spec/build/bsps/arm/beagle/optfdtuboot.yml   | 15 ---
>>> >  spec/build/bsps/arm/imx/bspimx.yml   |  8 
>>> >  spec/build/bsps/arm/imx/optfdtcpyro.yml  | 15 ---
>>> >  spec/build/bsps/arm/imx/optfdtmxsz.yml   | 16 
>>> >  spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
>>> >  spec/build/bsps/arm/imx/optfdtuboot.yml  | 15 ---
>>> >  spec/build/bsps/arm/raspberrypi/grp.yml  |  8 
>>> >  .../{arm/altera-cyclone-v => }/optfdtcpyro.yml   |  0
>>> >  .../{arm/altera-cyclone-v => }/optfdtmxsz.yml|  0
>>> >  .../bsps/{arm/altera-cyclone-v => }/optfdtro.yml |  0
>>> >  .../{arm/altera-cyclone-v => }/optfdtuboot.yml   |  0
>>> >  spec/build/bsps/powerpc/qoriq/grp.yml|  4 ++--
>>> >  spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml | 16 
>>> >  spec/build/bsps/powerpc/qoriq/optfdtro.yml   | 15 ---
>>> >  spec/build/bsps/riscv/riscv/grp.yml  |  8 
>>> >  spec/build/bsps/riscv/riscv/optfdtcpyro.yml  | 15 ---
>>> >  spec/build/bsps/riscv/riscv/optfdtmxsz.yml   | 16 
>>> >  spec/build/bsps/riscv/riscv/optfdtro.yml | 15 ---
>>> >  spec/build/bsps/riscv/riscv/optfdtuboot.yml  | 15 ---
>>> >  24 files changed, 26 insertions(+), 232 deletions(-)
>>> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
>>> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
>>> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
>>> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
>>> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
>>> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
>>> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
>>> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
>>> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtcpyro.yml (100%)
>>> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtmxsz.yml (100%)
>>> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtro.yml (100%)
>>> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtuboot.yml (100%)
>>> >  delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml
>>> >  delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtro.yml
>>> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtcpyro.yml
>>> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtmxsz.yml
>>> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtro.yml
>>> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtuboot.yml
>>> >
>>> > diff --git a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml 
>>> > b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
>>> > index da567ddd79..a9f3f7dabf 100644
>>> > --- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
>>> > +++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
>>> > @@ -73,15 +73,15 @@ links:
>>> >  - role: build-dependency
>>> >uid: optconuart1
>>> >  - role: build-dependency
>>> > -  uid: optfdtcpyro
>>> > +  uid: ../../optfdtcpyro
>>> >  - role: build-dependency
>>> >uid: optfdten
>>> >  - role: build-dependency
>>> > -  uid: optfdtmxsz
>>> > +  uid: ../../optfdtmxsz
>>> >  - role: build-dependency
>>> > -  uid: optfdtro
>>> > +  uid: ../../optfdtro
>>> >  - role: build-dependency
>>> > -  uid: optfdtuboot
>>> > +  uid: ../../optfdtuboot
>>> >  - role: build-dependency
>>> >uid: opti2cspeed
>>> >  - role: build-dependency
>>> > diff --git a/spec/build/bsps/arm/beagle/grp.yml 
>>> > b/spec/build/bsps/arm/beagle/grp.yml
>>> > index 1375913fd0..3452c3e5c8 100644
>>> > --- a/spec/build/bsps/arm/beagle/grp.yml
>>> > +++ b/spec/build/bsps/arm/beagle/grp.yml
>>> > @@ -22,13 +22,13 @@ links:
>>> >  - role: build-dependency
>>> >uid: optdm3730
>>> >  - role: build-dependency
>>> > -  uid: optfdtcpyro
>>> > +  uid: ../../optfdtcpyro
>>> >  - role: build-dependency
>>

Re: [PATCH V2] closes #3889 new defect Test needed for timer_create with CLOCK_MONOTONIC

[Gedare Bloom]

The first line of the commit should be shorter. Use a blank line, and
then close the ticket with the Closes # command.

https://devel.rtems.org/wiki/Developer/Git#GitCommits

We need to move this information into
https://docs.rtems.org/branches/master/eng/management.html


On Thu, Jul 8, 2021 at 1:50 PM Zacchaeus Leung  wrote:
>
> ---
>  ...or-timer_create-with-clock_monotonic.patch | 234 ++
>  cpukit/include/rtems/posix/timer.h|   2 +-
>  cpukit/posix/src/psxtimercreate.c |  86 +++
>  cpukit/posix/src/timergettime.c   |  76 ++
>  4 files changed, 300 insertions(+), 98 deletions(-)
>  create mode 100644 
> 0001-Addded-test-for-timer_create-with-clock_monotonic.patch
>
> diff --git a/0001-Addded-test-for-timer_create-with-clock_monotonic.patch 
> b/0001-Addded-test-for-timer_create-with-clock_monotonic.patch
> new file mode 100644
> index 00..33be528411
> --- /dev/null
> +++ b/0001-Addded-test-for-timer_create-with-clock_monotonic.patch
> @@ -0,0 +1,234 @@
> +From f1cac2a4b64e5076f0ceff014b78be41e5f00389 Mon Sep 17 00:00:00 2001
> +From: Zack 
> +Date: Mon, 28 Jun 2021 14:23:42 -0400
> +Subject: [PATCH] Addded test for timer_create with clock_monotonic
> +

It seems that you have included a patch within your patch. Please
check your commit before you email it, to make sure only the changes
you want included are there. Since I'm not sure what changes you are
intending to send, I'm going to stop here.

A few general comments:

Avoid reformatting existing code. Keep your changes limited to
functional changes only, and send reformatting/documentation changes
separately. Make sure you write new code consistently to our style
guide. (https://docs.rtems.org/branches/master/eng/coding.html) If in
doubt, write your code consistent with code near it.

Provide all the patches for your commits that go from the current HEAD
(most recent commit on master). We can't review commits that are based
on other commits on your local repo only, unless you include those
commits also for review.

> +---
> + cpukit/include/rtems/posix/timer.h|  1 +
> + cpukit/posix/src/psxtimercreate.c |  5 +-
> + cpukit/posix/src/timergettime.c   | 79 ---
> + testsuites/psxtests/psxtimer02/psxtimer.c | 38 ++-
> + 4 files changed, 98 insertions(+), 25 deletions(-)
> +
> +diff --git a/cpukit/include/rtems/posix/timer.h 
> b/cpukit/include/rtems/posix/timer.h
> +index bcbf07a65a..839fe3293c 100644
> +--- a/cpukit/include/rtems/posix/timer.h
>  b/cpukit/include/rtems/posix/timer.h
> +@@ -48,6 +48,7 @@ typedef struct {
> +   uint32_t  ticks;  /* Number of ticks of the initialization */
> +   uint32_t  overrun;/* Number of expirations of the timer*/
> +   struct timespec   time;   /* Time at which the timer was started   */
> ++clockid_t clock_type;
> + } POSIX_Timer_Control;
> +
> + /**
> +diff --git a/cpukit/posix/src/psxtimercreate.c 
> b/cpukit/posix/src/psxtimercreate.c
> +index a63cf1d100..b60be3f229 100644
> +--- a/cpukit/posix/src/psxtimercreate.c
>  b/cpukit/posix/src/psxtimercreate.c
> +@@ -40,7 +40,7 @@ int timer_create(
> + {
> +   POSIX_Timer_Control *ptimer;
> +
> +-  if ( clock_id != CLOCK_REALTIME )
> ++  if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC  )
> + rtems_set_errno_and_return_minus_one( EINVAL );
> +
> +   if ( !timerid )
> +@@ -91,7 +91,8 @@ int timer_create(
> +   ptimer->timer_data.it_value.tv_nsec= 0;
> +   ptimer->timer_data.it_interval.tv_sec  = 0;
> +   ptimer->timer_data.it_interval.tv_nsec = 0;
> +-
> ++  ptimer->clock_type=clock_id;
> ++
> +   _Watchdog_Preinitialize( &ptimer->Timer, _Per_CPU_Get_snapshot() );
> +   _Watchdog_Initialize( &ptimer->Timer, _POSIX_Timer_TSR );
> +   _Objects_Open_u32(&_POSIX_Timer_Information, &ptimer->Object, 0);
> +diff --git a/cpukit/posix/src/timergettime.c 
> b/cpukit/posix/src/timergettime.c
> +index ee2a566f0e..57b0ab4918 100644
> +--- a/cpukit/posix/src/timergettime.c
>  b/cpukit/posix/src/timergettime.c
> +@@ -6,6 +6,14 @@
> +  * @brief Function Fetches State of POSIX Per-Process Timers
> +  */
> +
> ++/**
> ++ * @file
> ++ *
> ++ * @ingroup POSIXAPI
> ++ *
> ++ * @brief Function Fetches State of POSIX Per-Process Timers
> ++ */
> ++
> + /*
> +  *  14.2.4 Per-Process Timers, P1003.1b-1993, p. 267
> +  *
> +@@ -21,13 +29,13 @@
> + #include "config.h"
> + #endif
> +
> +-#include 
> + #include 
> +-
> + #include 
> + #include 
> + #include 
> + #include 
> ++#include 
> ++#include 
> +
> + /*
> +  *  - When a timer is initialized, the value of the time in
> +@@ -36,38 +44,65 @@
> +  *between the current time and the initialization time.
> +  */
> +
> +-int timer_gettime(
> +-  timer_ttimerid,
> +-  struct itimerspec *value
> +-)
> +-{
> ++int timer_gettime(timer_t timerid, struct itimerspec *value) {
> +   POSIX_Timer_Control *ptimer;
> +-  ISR_lock_Context

Re: [PATCH v2] rtems:modify spthread01 testsuites for cond variable signal and broadcast intf rtems:making rectification according to Sebastian Huber's opinions

[Gedare Bloom]

The commit message should be rewritten. someone can do this on a push,
but if you send a v3 of the patch, please simplify the first line of
the commit message, like

"testsuites/sptests: add cond variable signal and broadcast to spthread01"

That should be an adequate commit message for this change anyway. If
you want to add more details though, you can do it by adding a blank
line after the first commit line, and writing it in a paragraph form
in your commit text editor.

On Wed, Jul 7, 2021 at 11:50 PM  wrote:
>
> From: tianye 
>
If you have a fuller name to provide, we do like to keep the code
author records.

> ---
>  testsuites/sptests/spthread01/init.c | 86 
> +++-
>  1 file changed, 74 insertions(+), 12 deletions(-)
>
> diff --git a/testsuites/sptests/spthread01/init.c 
> b/testsuites/sptests/spthread01/init.c
> index 9044ca2..b64d0a5 100644
> --- a/testsuites/sptests/spthread01/init.c
> +++ b/testsuites/sptests/spthread01/init.c
> @@ -165,6 +165,7 @@ static void test_recursive_mutex(void)
>  typedef struct {
>rtems_mutex mtx;
>rtems_condition_variable cnd;
> +  unsigned int exeting_task_cnt;
typo: exiting

>  } signal_context;
>
>  static void signal_task(rtems_task_argument arg)
> @@ -173,8 +174,10 @@ static void signal_task(rtems_task_argument arg)
>
>s = (signal_context *) arg;
>rtems_mutex_lock(&s->mtx);
> -  rtems_condition_variable_signal(&s->cnd);
> +  rtems_condition_variable_wait(&s->cnd, &s->mtx);
>rtems_mutex_unlock(&s->mtx);
> +  s->exeting_task_cnt++;
> +  rtems_task_exit();
>  }
>
>  static void test_condition_variable(void)
> @@ -183,7 +186,9 @@ static void test_condition_variable(void)
>signal_context s;
>const char *name;
>rtems_status_code sc;
> -  rtems_id id;
> +  rtems_id id1;
> +  rtems_id id2;
> +  rtems_task_priority task_priority;
>
>name = rtems_condition_variable_get_name(&a);
>rtems_test_assert(strcmp(name, "a") == 0);
> @@ -201,34 +206,91 @@ static void test_condition_variable(void)
>name = rtems_condition_variable_get_name(&s.cnd);
>rtems_test_assert(strcmp(name, "c") == 0);
>
> -  rtems_condition_variable_signal(&s.cnd);
> +  s.exeting_task_cnt = 0;
> +  sc = rtems_task_create(
> +rtems_build_name('C', 'O', 'D', '1'),
> +2,
> +RTEMS_MINIMUM_STACK_SIZE,
> +RTEMS_DEFAULT_MODES,
> +RTEMS_DEFAULT_ATTRIBUTES,
> +&id1
> +  );
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +  sc = rtems_task_start(id1, signal_task, (rtems_task_argument) &s);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +  sc = rtems_task_create(
> +rtems_build_name('C', 'O', 'D', '2'),
> +2,
> +RTEMS_MINIMUM_STACK_SIZE,
> +RTEMS_DEFAULT_MODES,
> +RTEMS_DEFAULT_ATTRIBUTES,
> +&id2
> +  );
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +  sc = rtems_task_start(id2, signal_task, (rtems_task_argument) &s);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>
> -  rtems_condition_variable_broadcast(&s.cnd);
> +  sc = rtems_task_set_priority(rtems_task_self(), RTEMS_MAXIMUM_PRIORITY - 
> 1, &task_priority);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +  sc = rtems_task_wake_after(0);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>
>rtems_mutex_lock(&s.mtx);
> +  rtems_condition_variable_signal(&s.cnd);
> +  rtems_mutex_unlock(&s.mtx);
> +  sc = rtems_task_wake_after(0);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +
> +  rtems_test_assert(s.exeting_task_cnt == 1);
> +  sc = rtems_task_delete(id1);
> +  sc = rtems_task_delete(id2);
> +  rtems_condition_variable_destroy(&s.cnd);
> +  rtems_mutex_destroy(&s.mtx);
> +  sc = rtems_task_set_priority(rtems_task_self(), task_priority, 
> &task_priority);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>
> +  s.exeting_task_cnt = 0;
>sc = rtems_task_create(
> -rtems_build_name('C', 'O', 'N', 'D'),
> +rtems_build_name('C', 'O', 'D', '1'),
>  2,
>  RTEMS_MINIMUM_STACK_SIZE,
>  RTEMS_DEFAULT_MODES,
>  RTEMS_DEFAULT_ATTRIBUTES,
> -&id
> +&id1
>);
>rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> -
> -  sc = rtems_task_start(id, signal_task, (rtems_task_argument) &s);
> +  sc = rtems_task_start(id1, signal_task, (rtems_task_argument) &s);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +  sc = rtems_task_create(
> +rtems_build_name('C', 'O', 'D', '2'),
> +2,
> +RTEMS_MINIMUM_STACK_SIZE,
> +RTEMS_DEFAULT_MODES,
> +RTEMS_DEFAULT_ATTRIBUTES,
> +&id2
> +  );
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +  sc = rtems_task_start(id2, signal_task, (rtems_task_argument) &s);
>rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>
> -  rtems_condition_variable_wait(&s.cnd, &s.mtx);
> -
> -  sc = rtems_task_delete(id);
> +  sc = rtems_task_set_priority(rtems_task_self(), RTEMS_MAXIMUM_PRIORITY - 
> 1, &task_priority);
> +  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> +  sc = rtems_task_wake_after(0);
>rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>
> +  rtems_mutex_lock(&s

Typical workflows for RTEMS-based development using Xilinx Zynq 7000

[Stanislav Pankevich]

 Hello everyone,

I am looking for information on how to start the development with RTEMS on
the Arty Z7 development board (Z7-20).

I see that there are at least two existing BSPs that could help me to get
started: xilinx_zynq_zc702 and xilinx_zynq_zedboard. I followed the
instructions for building these BSPs using the RTEMS toolchain and the Waf
build system and now I have the binaries of the RTEMS "hello world" program.

My immediate question: there seems to be two different approaches for
setting up development workflows: one using Xilinx tools (Vitis IDE, Xilinx
Software Command-line Tools and System Debugger XSDB) and a more
traditional one using GDB/OpenOCD. Being more familiar with the GDB/OpenOCD
approach, I was wondering which tools/workflows for working with Xilinx
Zynq are used or considered best practice by the RTEMS community.

Related question: does anyone have experience running RTEMS on the Z7-20
board? Any information that could help in reducing the setup/porting
efforts is appreciated.

Thank you for your attention.

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

[PATCH rtems-docs v2 2/2] README: Added centOS 8 instructions

[Stephen Clark]

Added some instructions for setting up CentOS 8.
---
 README.txt | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/README.txt b/README.txt
index 13bf8e6..828c9e7 100644
--- a/README.txt
+++ b/README.txt
@@ -287,6 +287,17 @@ PATH:
   export PATH=/usr/local/texlive/2016/bin/i386-linux/:${PATH}
   export PATH=${HOME}/.local/bin:${PATH}
 
+CentOS 8
+
+
+The steps for Centos 8 are similar to the steps for CentOS 7.
+There are just a couple differences.
+
+First, CentOS 8 uses Python 3.x as the default, so intalling the
+centos-release-scl and rh-python36 packages is unnecessary.
+Second, Centos 8 uses dnf as its package manager instead of yum, so
+packages such as npm should be installed using dnf instead.
+
 Arch Linux
 ~~
 
-- 
2.27.0

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

[PATCH rtems-docs v2 1/2] README: Minor clarifications and fixes

[Stephen Clark]

Fixed some minor typographical errors.
Updated a dead link.
Reworded some sentences for clarity.
---
 README.txt | 49 +
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/README.txt b/README.txt
index 03f57ed..13bf8e6 100644
--- a/README.txt
+++ b/README.txt
@@ -1,16 +1,17 @@
 RTEMS Project Documentation
 ===
 
-The documents are written in ReST and built using Sphinx. The build system will
-check the version of Sphinx and ensure you have a suitable version
-available. If your host does not provide a packaged version use PIP to fetch a
+The documents are written in ReST and built using Sphinx. The waf build system
+will check the version of Sphinx and ensure you have a suitable version
+available. If your host does not provide a packaged version, use PIP to fetch a
 recent version. The Sphinx website provides details on doing this.
 
-ReST is the Re-Structured-Text format. It is a simple markup language that 
allows
-us to create quality documentaion. It is flexible and powerful however does not
-attempt to train it to create a specific format. You need to test any new way
-of presenting something on all output formats. What may look great in one
-format may not translate with the same clarity to another output format.
+ReST is the Re-Structured-Text format. It is a simple markup language that
+allows us to create quality documentation which can easily be converted to
+multiple different formats. This flexibility is convenient, but you still need
+to test any new way of presenting something on all output formats. What may 
look
+great in one format may not translate with the same clarity to another output
+format.
 
 The RTEMS Documentation output formats are:
 
@@ -26,7 +27,7 @@ Images can be created from source using PlantUML and Ditaa.
 
 A Sphinx checksheet is:
 
- http://docs.sphinxdocs.com/en/latest/cheatsheet.html#rst-cheat-sheet
+ https://sphinx-tutorial.readthedocs.io/cheatsheet/#rst-cheat-sheet
 
 Production Quality Hosts
 
@@ -45,7 +46,7 @@ NOTE: RedHat Enterprise Linux (RHEL) and Fedora should be the 
same as CentOS.
 Images
 --
 
-All images should be placed int he 'images' directory and referenced from the
+All images should be placed in the 'images' directory and referenced from the
 ReST with a relative path. This lets us shared and control images.
 
 We prefer being able to build images from source. This is not always possible
@@ -85,7 +86,7 @@ The home page contain the language options. The PlantUML 
online demo server
 supports Ditaa so use that resource as an online tool. The Ditaa image source
 extension is '.ditaa'.
 
-You do not need PlantUML or Ditaa install to build our documentation. The
+You do not need PlantUML or Ditaa installed to build our documentation. The
 online resources can be used. Save the source and the generated PNG file in the
 same directory under 'images'.
 
@@ -94,12 +95,12 @@ Host Setup
 
 HTML builds directly with Sphinx, PDF requires a full Latex (texlive) install,
 and building a Single HTML page requires the 'inliner' tool. The
-sphinxcontrib-bibtex extension is mandatory. PlantUML requres the Node.js
+sphinxcontrib-bibtex extension is mandatory. PlantUML requires the Node.js
 package called 'node-plantuml' which installs the 'puml' command and Ditaa 
needs
 the 'ditaa' command and package. Ditaa images are built using the 'puml'
 command.
 
-Please add your host as you set it up.
+Please add your host to this section as you set it up.
 
 The best results are produced with Python3 and a virtual environment`. It can
 create a specific python environment using `pip`.
@@ -107,8 +108,8 @@ create a specific python environment using `pip`.
 Virtual Environment
 ~~~
 
-Create a directory to house the virtual environment, create the envrionment
-and the activate it. This example assumes Python3 and the `venv` module:
+Create a directory to house the virtual environment, create the environment,
+and then activate it. This example assumes Python3 and the `venv` module:
 
   $ mkdir sphinx
   $ python3 -m venv sphinx
@@ -120,7 +121,7 @@ Alternatively you can use the `virtualenv` command:
   $ virtualenv sphinx
   $ . ./sphinx/bin/activate
 
-The prompt will now change. You can install Sphinx with:
+Either way, the prompt will now change. You can install Sphinx with:
 
   $ pip install sphinx
   $ pip install sphinxcontrib-bibtex
@@ -321,11 +322,11 @@ packages. There is no common naming and no real way to 
figure what texlive
 package is present in a host's packaging. It seems not all of texlive is
 available.
 
-The RTEMS Documentation waf configure phase check for each texlive package used
+The RTEMS Documentation waf configure phase checks for each texlive package 
used
 in the generated output and the styles. If you complete configure with the
 --pdf option you should be able to build PDF documentation.
 
-The texlive package requirments

Re: [PATCH v3] bsps: Move optfdt* files to shared parent directory

[Joel Sherrill]

I was going to do a sweep of all BSPs and then push but had an issue
with the patch. If something happened with the mail Pranav, please just
compress it and send it to me privately as an attachment. If it needs
rebasing, please take care of that.

[joel@devel rtems]$ git am /tmp/x
Applying: bsps: Move optfdt* files to shared parent directory
error: patch failed: spec/build/bsps/arm/beagle/optfdtcpyro.yml:1
error: spec/build/bsps/arm/beagle/optfdtcpyro.yml: patch does not apply
error: patch failed: spec/build/bsps/arm/beagle/optfdtmxsz.yml:1
error: spec/build/bsps/arm/beagle/optfdtmxsz.yml: patch does not apply
error: patch failed: spec/build/bsps/arm/beagle/optfdtro.yml:1
error: spec/build/bsps/arm/beagle/optfdtro.yml: patch does not apply
error: patch failed: spec/build/bsps/arm/beagle/optfdtuboot.yml:1
error: spec/build/bsps/arm/beagle/optfdtuboot.yml: patch does not apply
error: patch failed: spec/build/bsps/arm/imx/optfdtcpyro.yml:1
error: spec/build/bsps/arm/imx/optfdtcpyro.yml: patch does not apply
error: patch failed: spec/build/bsps/arm/imx/optfdtmxsz.yml:1
error: spec/build/bsps/arm/imx/optfdtmxsz.yml: patch does not apply
error: patch failed: spec/build/bsps/arm/imx/optfdtro.yml:1
error: spec/build/bsps/arm/imx/optfdtro.yml: patch does not apply
error: patch failed: spec/build/bsps/arm/imx/optfdtuboot.yml:1
error: spec/build/bsps/arm/imx/optfdtuboot.yml: patch does not apply
error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml:1
error: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml: patch does not apply
error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtro.yml:1
error: spec/build/bsps/powerpc/qoriq/optfdtro.yml: patch does not apply
error: patch failed: spec/build/bsps/riscv/riscv/optfdtcpyro.yml:1
error: spec/build/bsps/riscv/riscv/optfdtcpyro.yml: patch does not apply
error: patch failed: spec/build/bsps/riscv/riscv/optfdtmxsz.yml:1
error: spec/build/bsps/riscv/riscv/optfdtmxsz.yml: patch does not apply
error: patch failed: spec/build/bsps/riscv/riscv/optfdtro.yml:1
error: spec/build/bsps/riscv/riscv/optfdtro.yml: patch does not apply
error: patch failed: spec/build/bsps/riscv/riscv/optfdtuboot.yml:1
error: spec/build/bsps/riscv/riscv/optfdtuboot.yml: patch does not apply
Patch failed at 0001 bsps: Move optfdt* files to shared parent directory
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

On Thu, Jul 15, 2021 at 10:13 AM Gedare Bloom  wrote:
>
> This patch looks fine to me if someone can pick it up. It does touch a
> lot of build BSPs though.
>
> On Fri, Jul 9, 2021 at 12:16 AM Pranav Dangi  wrote:
> >
> > ping. (Apart from moving the files in a shared directory, a part of this 
> > patch also gets the RTEMS master branch to work on all the Pi's except 4.)
> >
> > On Fri, 2 Jul 2021, 09:35 Pranav Dangi,  wrote:
> >>
> >> yes, I've built all of them
> >>
> >> On Thu, Jul 1, 2021 at 10:01 PM Gedare Bloom  wrote:
> >>>
> >>> Did you build all affected BSPs?
> >>>
> >>> On Thu, Jul 1, 2021 at 4:05 AM pranav  wrote:
> >>> >
> >>> > ---
> >>> >  .../arm/altera-cyclone-v/bspalteracyclonev.yml   |  8 
> >>> >  spec/build/bsps/arm/beagle/grp.yml   |  8 
> >>> >  spec/build/bsps/arm/beagle/optfdtcpyro.yml   | 15 ---
> >>> >  spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16 
> >>> >  spec/build/bsps/arm/beagle/optfdtro.yml  | 15 ---
> >>> >  spec/build/bsps/arm/beagle/optfdtuboot.yml   | 15 ---
> >>> >  spec/build/bsps/arm/imx/bspimx.yml   |  8 
> >>> >  spec/build/bsps/arm/imx/optfdtcpyro.yml  | 15 ---
> >>> >  spec/build/bsps/arm/imx/optfdtmxsz.yml   | 16 
> >>> >  spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
> >>> >  spec/build/bsps/arm/imx/optfdtuboot.yml  | 15 ---
> >>> >  spec/build/bsps/arm/raspberrypi/grp.yml  |  8 
> >>> >  .../{arm/altera-cyclone-v => }/optfdtcpyro.yml   |  0
> >>> >  .../{arm/altera-cyclone-v => }/optfdtmxsz.yml|  0
> >>> >  .../bsps/{arm/altera-cyclone-v => }/optfdtro.yml |  0
> >>> >  .../{arm/altera-cyclone-v => }/optfdtuboot.yml   |  0
> >>> >  spec/build/bsps/powerpc/qoriq/grp.yml|  4 ++--
> >>> >  spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml | 16 
> >>> >  spec/build/bsps/powerpc/qoriq/optfdtro.yml   | 15 ---
> >>> >  spec/build/bsps/riscv/riscv/grp.yml  |  8 
> >>> >  spec/build/bsps/riscv/riscv/optfdtcpyro.yml  | 15 ---
> >>> >  spec/build/bsps/riscv/riscv/optfdtmxsz.yml   | 16 
> >>> >  spec/build/bsps/riscv/riscv/optfdtro.yml | 15 ---
> >>> >  spec/build/bsps/riscv/riscv/optfdtuboot.yml  

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

I will check on this

On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom  wrote:

> On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  wrote:
> >
> > Hello everyone,
> > From the discussion on discord it looks like clang-format cannot be
> installed on MacOS and FreeBSD. Is there any alternative or way to have it
> on these operating systems?
> >
> What are the challenges with them? Can clang-format be built from
> source on those hosts?
>
> > On Wed, 5 May 2021, 10:21 pm Ida Delphine,  wrote:
> >>
> >> Hello everyone,
> >>
> >> Regarding this project (https://devel.rtems.org/ticket/3860) I went
> with clang-format as we all agreed. I have tested it on some "score" files
> and it made some changes which I don't think are very much in line with the
> RTEMS coding style. However, it wasn't really clear if we will chage the
> RTEMS coding style or try to make changes to clang-format to fit the style.
> >> Please will love to know the best option.
> >>
> >> Cheers,
> >> Ida.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 2/4] usb_template: Configure template driver only for CDC Ethernet

[Christian Mauderer]

Hello Husni,

On 06/07/2021 19:00, Husni Faiz wrote:

Add the conditional macro to prevent the driver from referencing
the templates which are not imported yet.

Include functions which adds the hw.usb.template sysctl variable.

Signed-off-by: Husni Faiz 
---
  freebsd/sys/dev/usb/template/usb_template.c | 4 
  freebsd/sys/dev/usb/usb_device.c| 4 ++--
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/freebsd/sys/dev/usb/template/usb_template.c 
b/freebsd/sys/dev/usb/template/usb_template.c
index 0650da15..fe90d5b7 100644
--- a/freebsd/sys/dev/usb/template/usb_template.c
+++ b/freebsd/sys/dev/usb/template/usb_template.c
@@ -1433,12 +1433,15 @@ usb_temp_setup_by_index(struct usb_device *udev, 
uint16_t index)
usb_error_t err;
  
  	switch (index) {

+#ifndef __rtems__
case USB_TEMP_MSC:
err = usb_temp_setup(udev, &usb_template_msc);
break;
+#endif
case USB_TEMP_CDCE:
err = usb_temp_setup(udev, &usb_template_cdce);
break;
+#ifndef __rtems__
case USB_TEMP_MTP:
err = usb_temp_setup(udev, &usb_template_mtp);
break;
@@ -1469,6 +1472,7 @@ usb_temp_setup_by_index(struct usb_device *udev, uint16_t 
index)
case USB_TEMP_CDCEEM:
err = usb_temp_setup(udev, &usb_template_cdceem);
break;
+#endif
default:
return (USB_ERR_INVAL);
}
diff --git a/freebsd/sys/dev/usb/usb_device.c b/freebsd/sys/dev/usb/usb_device.c
index ee240949..28ef1b74 100644
--- a/freebsd/sys/dev/usb/usb_device.c
+++ b/freebsd/sys/dev/usb/usb_device.c
@@ -123,7 +123,7 @@ int usb_template = USB_TEMPLATE;
  int   usb_template = -1;
  #endif
  
-#ifndef __rtems__

+#if !defined(__rtems__) || defined(RTEMS_BSD_MODULE_DEV_USB_TEMPLATE)


Shouldn't there be an include for the rtems/bsd/modules.h somewhere if 
you use the RTEMS_BSD_MODULE_DEV_USB_TEMPLATE define?



  SYSCTL_PROC(_hw_usb, OID_AUTO, template,
  CTLTYPE_INT | CTLFLAG_RWTUN | CTLFLAG_MPSAFE,
  NULL, 0, sysctl_hw_usb_template,
@@ -255,7 +255,7 @@ sysctl_hw_usb_template(SYSCTL_HANDLER_ARGS)
  
  	return (0);

  }
-#endif /* __rtems__ */
+#endif /* !__rtmes__ || RTEMS_BSD_MODULE_DEV_USB_TEMPLATE */
  
  /* English is default language */
  


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

Re: [PATCH rtems-libbsd 0/4] Beagle BSP: USB Template Driver for CDC Ethernet

[Christian Mauderer]

Hello Husni,

On 14/07/2021 20:18, Ahamed Husni wrote:

Hi,

Ping :)


Sorry for the late reply. I hoped that someone else would review the 
patches. I already had a look at them before you sent them.


I only found two small points. Otherwise the patches look fine. Can you 
fix the two points and then send a v2? I think you also mentioned having 
the patches ported to the 6-freebsd-12 branch? If you post v2: Can you 
just add a link to a branch with these in your [Patch 0/x] mail?


Best regards

Christian



On Tue, Jul 6, 2021 at 10:30 PM Husni Faiz > wrote:


This set of patches import the drivers from freebsd and
configures it for the beagle bsp.

Github Branch for the commits
https://github.com/drac98/rtems-libbsd/commits/usb-cdce


Husni Faiz (4):
   usb_template:Import CDC Ethernet
   usb_template: Configure template driver only for CDC Ethernet
   nexus-devices: Include CDC Ethernet for Beagle
   libbsd.py: add usb template files

  buildset/default.ini                          |    1 +
  buildset/minimal.ini                          |    3 +-
  freebsd/sys/dev/usb/template/usb_template.c   | 1493 +
  freebsd/sys/dev/usb/template/usb_template.h   |  130 ++
  .../sys/dev/usb/template/usb_template_cdce.c  |  355 
  freebsd/sys/dev/usb/usb_device.c              |    4 +-
  libbsd.py                                     |   25 +
  rtemsbsd/include/bsp/nexus-devices.h          |    5 +
  .../include/machine/rtems-bsd-nexus-bus.h     |   17 +
  9 files changed, 2030 insertions(+), 3 deletions(-)
  create mode 100644 freebsd/sys/dev/usb/template/usb_template.c
  create mode 100644 freebsd/sys/dev/usb/template/usb_template.h
  create mode 100644 freebsd/sys/dev/usb/template/usb_template_cdce.c

-- 
2.25.1



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


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

Re: [PATCH rtems-libbsd 3/4] nexus-devices: Include CDC Ethernet for Beagle

[Christian Mauderer]

On 06/07/2021 19:00, Husni Faiz wrote:

Configure bus for CDC Ethernet
Include CDC Ethernet in Beagle BSP

Signed-off-by: Husni Faiz 
---
  rtemsbsd/include/bsp/nexus-devices.h   |  5 +
  rtemsbsd/include/machine/rtems-bsd-nexus-bus.h | 17 +
  2 files changed, 22 insertions(+)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index e6487470..6a35632e 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -83,6 +83,11 @@ SYSINIT_REFERENCE(rtwn_rtl8188eufw);
  RTEMS_BSD_DRIVER_USB;
  RTEMS_BSD_DRIVER_USB_MASS;
  
+#ifdef RTEMS_BSD_MODULE_DEV_USB_TEMPLATE

+RTEMS_BSD_DRIVER_USB_TEMPLATE;
+RTEMS_BSD_DRIVER_CDCE;
+#endif
+


Same like in patch 2: Shouldn't there be an include for 
rtems/bsd/modules.h somewhere?



  #elif defined(LIBBSP_ARM_LPC32XX_BSP_H)
  
  #include 

diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h 
b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
index 50a43873..84f561f5 100644
--- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
+++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
@@ -282,6 +282,15 @@ extern "C" {
  SYSINIT_DRIVER_REFERENCE(umass, uhub)
  #endif /* RTEMS_BSD_DRIVER_USB_MASS */
  
+/*

+ * USB Template base driver.
+ */
+#if !defined(RTEMS_BSD_DRIVER_USB_TEMPLATE)
+  #define RTEMS_BSD_DRIVER_USB_TEMPLATE   \
+SYSINIT_REFERENCE(usb_temp_init); \
+SYSINIT_DRIVER_REFERENCE(usb_template, usb)
+#endif /* RTEMS_BSD_DRIVER_USB_TEMPLATE */
+
  /*
   * USB SAF1761 host controller driver.
   */
@@ -490,6 +499,14 @@ extern "C" {
  SYSINIT_DRIVER_REFERENCE(re, pci);
  #endif /* RTEMS_BSD_DRIVER_PCI_RE */
  
+/*

+ * CDC Ethernet Driver.
+ */
+#if !defined(RTEMS_BSD_DRIVER_CDCE)
+  #define RTEMS_BSD_DRIVER_CDCE   \
+SYSINIT_DRIVER_REFERENCE(cdce, uhub);
+#endif /* RTEMS_BSD_DRIVER_FEC */
+
  /**
   ** MMI Physical Layer Support.
   **/


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

[PATCH v3] spthread01:add cond variable signal and broadcast test case

[tianye]

From: Tian Ye 

---
 testsuites/sptests/spthread01/init.c | 86 +++-
 1 file changed, 74 insertions(+), 12 deletions(-)

diff --git a/testsuites/sptests/spthread01/init.c 
b/testsuites/sptests/spthread01/init.c
index 9044ca2..b64d0a5 100644
--- a/testsuites/sptests/spthread01/init.c
+++ b/testsuites/sptests/spthread01/init.c
@@ -165,6 +165,7 @@ static void test_recursive_mutex(void)
 typedef struct {
   rtems_mutex mtx;
   rtems_condition_variable cnd;
+  unsigned int exeting_task_cnt;
 } signal_context;
 
 static void signal_task(rtems_task_argument arg)
@@ -173,8 +174,10 @@ static void signal_task(rtems_task_argument arg)
 
   s = (signal_context *) arg;
   rtems_mutex_lock(&s->mtx);
-  rtems_condition_variable_signal(&s->cnd);
+  rtems_condition_variable_wait(&s->cnd, &s->mtx);
   rtems_mutex_unlock(&s->mtx);
+  s->exeting_task_cnt++;
+  rtems_task_exit();
 }
 
 static void test_condition_variable(void)
@@ -183,7 +186,9 @@ static void test_condition_variable(void)
   signal_context s;
   const char *name;
   rtems_status_code sc;
-  rtems_id id;
+  rtems_id id1;
+  rtems_id id2;
+  rtems_task_priority task_priority;
 
   name = rtems_condition_variable_get_name(&a);
   rtems_test_assert(strcmp(name, "a") == 0);
@@ -201,34 +206,91 @@ static void test_condition_variable(void)
   name = rtems_condition_variable_get_name(&s.cnd);
   rtems_test_assert(strcmp(name, "c") == 0);
 
-  rtems_condition_variable_signal(&s.cnd);
+  s.exeting_task_cnt = 0;
+  sc = rtems_task_create(
+rtems_build_name('C', 'O', 'D', '1'),
+2,
+RTEMS_MINIMUM_STACK_SIZE,
+RTEMS_DEFAULT_MODES,
+RTEMS_DEFAULT_ATTRIBUTES,
+&id1
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  sc = rtems_task_start(id1, signal_task, (rtems_task_argument) &s);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  sc = rtems_task_create(
+rtems_build_name('C', 'O', 'D', '2'),
+2,
+RTEMS_MINIMUM_STACK_SIZE,
+RTEMS_DEFAULT_MODES,
+RTEMS_DEFAULT_ATTRIBUTES,
+&id2
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  sc = rtems_task_start(id2, signal_task, (rtems_task_argument) &s);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  rtems_condition_variable_broadcast(&s.cnd);
+  sc = rtems_task_set_priority(rtems_task_self(), RTEMS_MAXIMUM_PRIORITY - 1, 
&task_priority);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  sc = rtems_task_wake_after(0);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
   rtems_mutex_lock(&s.mtx);
+  rtems_condition_variable_signal(&s.cnd);
+  rtems_mutex_unlock(&s.mtx);
+  sc = rtems_task_wake_after(0);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  rtems_test_assert(s.exeting_task_cnt == 1);
+  sc = rtems_task_delete(id1);
+  sc = rtems_task_delete(id2);
+  rtems_condition_variable_destroy(&s.cnd);
+  rtems_mutex_destroy(&s.mtx);
+  sc = rtems_task_set_priority(rtems_task_self(), task_priority, 
&task_priority);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
+  s.exeting_task_cnt = 0;
   sc = rtems_task_create(
-rtems_build_name('C', 'O', 'N', 'D'),
+rtems_build_name('C', 'O', 'D', '1'),
 2,
 RTEMS_MINIMUM_STACK_SIZE,
 RTEMS_DEFAULT_MODES,
 RTEMS_DEFAULT_ATTRIBUTES,
-&id
+&id1
   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_task_start(id, signal_task, (rtems_task_argument) &s);
+  sc = rtems_task_start(id1, signal_task, (rtems_task_argument) &s);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  sc = rtems_task_create(
+rtems_build_name('C', 'O', 'D', '2'),
+2,
+RTEMS_MINIMUM_STACK_SIZE,
+RTEMS_DEFAULT_MODES,
+RTEMS_DEFAULT_ATTRIBUTES,
+&id2
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  sc = rtems_task_start(id2, signal_task, (rtems_task_argument) &s);
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  rtems_condition_variable_wait(&s.cnd, &s.mtx);
-
-  sc = rtems_task_delete(id);
+  sc = rtems_task_set_priority(rtems_task_self(), RTEMS_MAXIMUM_PRIORITY - 1, 
&task_priority);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  sc = rtems_task_wake_after(0);
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
+  rtems_mutex_lock(&s.mtx);
+  rtems_condition_variable_broadcast(&s.cnd);
   rtems_mutex_unlock(&s.mtx);
+  sc = rtems_task_wake_after(0);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
+  rtems_test_assert(s.exeting_task_cnt == 2);
+  sc = rtems_task_delete(id1);
+  sc = rtems_task_delete(id2);
   rtems_condition_variable_destroy(&s.cnd);
   rtems_mutex_destroy(&s.mtx);
+  sc = rtems_task_set_priority(rtems_task_self(), task_priority, 
&task_priority);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
 static void test_counting_semaphore(void)
@@ -319,7 +381,7 @@ static void Init(rtems_task_argument arg)
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 
-#define CONFIGURE_MAXIMUM_TASKS 2
+#define CONFIGURE_MAXIMUM_TASKS 3
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
-- 
1.8.3.1

_

Re: [PATCH] covoar: Fix errors building on FreeBSD and clang

[Alex White]

On Thu, Jul 15, 2021 at 1:20 AM Chris Johns  wrote:
>
> On 15/7/21 12:45 pm, Alex White wrote:
> > On Tue, Jul 6, 2021 at 7:55 PM Chris Johns  wrote:
> >>
> >> On 3/7/21 5:56 am, Alex White wrote:
> >> > On Wed, Jun 30, 2021 at 11:40 PM  wrote:
> >> >>
> >> >> From: Chris Johns 
> >> >>
> >> >> - The member variable `path_` cannot be a reference and initialised to
> >> >>   a const char* type input. To do so would require there is a temporary 
> >> >> with
> >> >>   an unspecified life time.
> >> >> ---
> >> >>  tester/covoar/AddressToLineMapper.h | 2 +-
> >> >>  tester/covoar/Target_aarch64.h  | 2 +-
> >> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> >> >>
> >> >> diff --git a/tester/covoar/AddressToLineMapper.h
> >> > b/tester/covoar/AddressToLineMapper.h
> >> >> index 88bf475..c78aef7 100644
> >> >> --- a/tester/covoar/AddressToLineMapper.h
> >> >> +++ b/tester/covoar/AddressToLineMapper.h
> >> >> @@ -84,7 +84,7 @@ namespace Coverage {
> >> >>   *  An iterator pointing to the location in the set that contains 
> >> >> the
> >> >>   *  source file path of the address.
> >> >>   */
> >> >> -const std::string& path_;
> >> >> +const std::string path_;
> >> >
> >> > Ryan alerted me about this issue a couple weeks back. This patch would 
> >> > fix the
> >> > problem, but it would lead to a second copy of every file path string 
> >> > being
> >> > stored in memory. This would also take away the usefulness of the set of 
> >> > file
> >> > path strings maintained by the AddressLineRange class.
> >> >
> >> > Instead, I propose we change the empty SourceLine constructor to take a 
> >> > `const
> >> > std::string&`. This would allow the addition of something like this to 
> >> > the top
> >> > of AddressToLineMapper::getSource():
> >> > const std::string unknown = "unknown";
> >> > const SourceLine default_sourceline = SourceLine(unknown);
> >> >
> >> > That should eliminate the issue and preserve the memory conservation 
> >> > efforts of
> >> > the original design.
> >>
> >> Yes it would but for some reason, that I cannot put my finger on, it seems 
> >> like
> >> a breach of boundaries between classes.
> >>
> >> How much data are we talking about? Are you able to see the memory foot 
> >> print
> >> with the strings being contained vs what you have now?
> >
> > Sorry for the late reply.
> >
> > What I have now yields a peak memory usage for covoar when run on all ARM 
> > tests
> > of 219 MB.
> > Changing `SourceLine::path_` to plain `std::string` results in an increase 
> > to
> > 523 MB.
> >
> > So it is a significant increase.
>
> Yes and thank you for the test results. This makes sharing a worth while 
> exercise.
>
> >> If the figures show the strings need to be shared to avoid a memory blow 
> >> out
> >> would a std::shared_ptr be something to look at where all
> >> references are a shared pointer? A shared pointer means any changes do not 
> >> flow
> >> from one class to other.
> >
> > I don't think that `std::shared_ptr` would help here. Wouldn't that handle 
> > the
> > case of an unknown path the same way as a raw pointer solution? Wouldn't we
> > still have to check the return value of `SourceLine::path()` to make sure 
> > that
> > it is not null?
> > The only other way I see to make it work would be to store some "unknown" 
> > string
> > object and hand pointers to it to all `SourceLine` objects with unknown 
> > paths.
> > But that seems mostly equivalent to what I propose in my original reply to 
> > this
> > patch.
>
> I have not checked all the detail but a raw pointer will always be fragile
> compared to a shared_ptr. You may get it working but there is nothing making
> sure any references are still pointing to valid memory. Given the difference 
> in
> sizes you found there is a lot of sharing and so a lot of references.
>
> > Now that I think about it, maybe making `SourceLine::_path` into an
> > `std::string*` and doing a `nullptr` check in the `SourceLine::path()` 
> > would be
> > most elegant?
>
> All I see are potential leaks, maybe not now but may be after the next person
> makes changes.

I don't see how potential leaks could happen with this. The issue of a possible 
dangling pointer, which I can see, is eliminated by design.
`AddressLineRange` owns the `std::string` vector.
`AddressLineRange` also owns the `SourceLine` vector. `SourceLine` owns the 
`path_` that references a string in the above vector.
This means that the strings will only be deleted when `AddressLineRange` is 
deleted. At the same time, all of the `SourceLine` objects will be deleted. So, 
unless I'm missing something (which I could be), the `SourceLine::_path` as an 
`std::string*` should be fine since both the `std::string` it points to and the 
owner of the `std::string*` will be cleaned up as part of the same teardown of 
`AddressLineRange`.

On top of that, the shared_ptr solution looks like it would be much less 
elegant as far as I can tell.
I think the set of strings 

Re: [PATCH] covoar: Fix errors building on FreeBSD and clang

[Chris Johns]

On 16/7/21 12:22 pm, Alex White wrote:
> 
> On Thu, Jul 15, 2021 at 1:20 AM Chris Johns  wrote:
>>
>> On 15/7/21 12:45 pm, Alex White wrote:
>> > On Tue, Jul 6, 2021 at 7:55 PM Chris Johns  wrote:
>> >>
>> >> On 3/7/21 5:56 am, Alex White wrote:
>> >> > On Wed, Jun 30, 2021 at 11:40 PM  wrote:
>> >> >>
>> >> >> From: Chris Johns 
>> >> >>
>> >> >> - The member variable `path_` cannot be a reference and initialised to
>> >> >>   a const char* type input. To do so would require there is a 
>> >> >> temporary with
>> >> >>   an unspecified life time.
>> >> >> ---
>> >> >>  tester/covoar/AddressToLineMapper.h | 2 +-
>> >> >>  tester/covoar/Target_aarch64.h      | 2 +-
>> >> >>  2 files changed, 2 insertions(+), 2 deletions(-)
>> >> >>
>> >> >> diff --git a/tester/covoar/AddressToLineMapper.h
>> >> > b/tester/covoar/AddressToLineMapper.h
>> >> >> index 88bf475..c78aef7 100644
>> >> >> --- a/tester/covoar/AddressToLineMapper.h
>> >> >> +++ b/tester/covoar/AddressToLineMapper.h
>> >> >> @@ -84,7 +84,7 @@ namespace Coverage {
>> >> >>       *  An iterator pointing to the location in the set that contains 
>> >> >> the
>> >> >>       *  source file path of the address.
>> >> >>       */
>> >> >> -    const std::string& path_;
>> >> >> +    const std::string path_;
>> >> >
>> >> > Ryan alerted me about this issue a couple weeks back. This patch would
> fix the
>> >> > problem, but it would lead to a second copy of every file path string 
>> >> > being
>> >> > stored in memory. This would also take away the usefulness of the set 
>> >> > of file
>> >> > path strings maintained by the AddressLineRange class.
>> >> >
>> >> > Instead, I propose we change the empty SourceLine constructor to take a
> `const
>> >> > std::string&`. This would allow the addition of something like this to
> the top
>> >> > of AddressToLineMapper::getSource():
>> >> > const std::string unknown = "unknown";
>> >> > const SourceLine default_sourceline = SourceLine(unknown);
>> >> >
>> >> > That should eliminate the issue and preserve the memory conservation
> efforts of
>> >> > the original design.
>> >>
>> >> Yes it would but for some reason, that I cannot put my finger on, it 
>> >> seems like
>> >> a breach of boundaries between classes.
>> >>
>> >> How much data are we talking about? Are you able to see the memory foot 
>> >> print
>> >> with the strings being contained vs what you have now?
>> >
>> > Sorry for the late reply.
>> >
>> > What I have now yields a peak memory usage for covoar when run on all ARM 
>> > tests
>> > of 219 MB.
>> > Changing `SourceLine::path_` to plain `std::string` results in an increase 
>> > to
>> > 523 MB.
>> >
>> > So it is a significant increase.
>>
>> Yes and thank you for the test results. This makes sharing a worth while 
>> exercise.
>>
>> >> If the figures show the strings need to be shared to avoid a memory blow 
>> >> out
>> >> would a std::shared_ptr be something to look at where all
>> >> references are a shared pointer? A shared pointer means any changes do 
>> >> not flow
>> >> from one class to other.
>> >
>> > I don't think that `std::shared_ptr` would help here. Wouldn't that handle 
>> > the
>> > case of an unknown path the same way as a raw pointer solution? Wouldn't we
>> > still have to check the return value of `SourceLine::path()` to make sure 
>> > that
>> > it is not null?
>> > The only other way I see to make it work would be to store some "unknown" 
>> > string
>> > object and hand pointers to it to all `SourceLine` objects with unknown 
>> > paths.
>> > But that seems mostly equivalent to what I propose in my original reply to 
>> > this
>> > patch.
>>
>> I have not checked all the detail but a raw pointer will always be fragile
>> compared to a shared_ptr. You may get it working but there is nothing making
>> sure any references are still pointing to valid memory. Given the difference 
>> in
>> sizes you found there is a lot of sharing and so a lot of references.
>>
>> > Now that I think about it, maybe making `SourceLine::_path` into an
>> > `std::string*` and doing a `nullptr` check in the `SourceLine::path()` 
>> > would be
>> > most elegant?
>>
>> All I see are potential leaks, maybe not now but may be after the next person
>> makes changes.
> 
> I don't see how potential leaks could happen with this. The issue of a 
> possible
> dangling pointer, which I can see, is eliminated by design.
Any place the string is passed out of the context of the AddressToLineMapper.h
you need to be careful. I insulated the code to some extent when I refactored
part of it here:

https://git.rtems.org/rtems-tools/tree/tester/covoar/ExecutableInfo.cc#n192

However assuming this is always the case for ever makes the code fragile. My
approach is to make sure classes in a specific area of code take care of 
themselves.

There are plenty of cases in this code of sharing being an issue ...

https://git.rtems.org/rtems-tools/tree/tester/covoar/ExecutableInfo.cc#n117

> `AddressLineRange` owns the `std::str

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Chris Johns]

Hi,

I will bring the discussion to the devel list and I hope the comments are in
line with the purpose of the project. Please correct what I say if it is not.

The pre-commit script that is in github review is a good base and I believe it
solves that problem for those on Linux. It is a great start and it is nice to 
see.

The work needs to mature and progress and that means a few things. I was
approached by Joel about where this would live in rtems-tools. As the script
stands it is not suitable for rtems-tool because the format is specific to the
score code in rtems.git.

I think a pre-commit script needs to live in the repo it is for in a spot a user
can copy to the hooks directory of their repo. For example `git-hooks`.

A git hooks script for rtems.git needs to run on all the supported hosts or we
may result in patches being left on the floor. If a contributor's host OS is not
supported and the patch is rejected for formatting reasons picked up by the
check the contributor may just walk away.

The script should use `/usr/bin/env python3` and it needs to check for a range
of `clang-format` instances. FreeBSD has a package that installs the format
command as `clang-format10` for LLVM 10 and `clang-format11` for version 11.

A contributor being able to run the script may depend on the host having a
package or packages installed. Given this is for RTEMS development that is fine.
The script needs to handle any set up errors nicely if something is missing. I
prefer we avoid the "experts" approach to error management.

There is possible future work adding a command to rtems-tools. Ida and I
discussed this on discord and we decided a command called `rtems-style` would be
nice. It would be nice if that command checked, ie `--mode=check`, a style as
well as `--mode=reformat` to automatically reformat a source file.

A command for rtems-tools has to support python2 and python3 and it has to
handle errors in suitable manner. Printing uncaught exception is not OK. It
should also be self contained and not depend on any pip python packages.

If an `rtems-style` command is created and installed when rtems-tool is
installed the pre-commit git script could be made to use it and so the style is
held in a single location.

Finally an rtems-style command could be extended to support python
(--lang=python) or other styles for other code formats. This is inline with our
other eco-system interfaces we provide.

I hope this helps.

Chris

On 16/7/21 5:13 am, Ida Delphine wrote:
> I will check on this
> 
> On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom  > wrote:
> 
> On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  > wrote:
> >
> > Hello everyone,
> > From the discussion on discord it looks like clang-format cannot be
> installed on MacOS and FreeBSD. Is there any alternative or way to have it
> on these operating systems?
> >
> What are the challenges with them? Can clang-format be built from
> source on those hosts?
> 
> > On Wed, 5 May 2021, 10:21 pm Ida Delphine,  > wrote:
> >>
> >> Hello everyone,
> >>
> >> Regarding this project (https://devel.rtems.org/ticket/3860
> ) I went with clang-format as we all
> agreed. I have tested it on some "score" files and it made some changes
> which I don't think are very much in line with the RTEMS coding style.
> However, it wasn't really clear if we will chage the RTEMS coding style or
> try to make changes to clang-format to fit the style.
> >> Please will love to know the best option.
> >>
> >> Cheers,
> >> Ida.
> >
> > ___
> > 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 v3] bsps: Move optfdt* files to shared parent directory

[Chris Johns]

The patch need to add `default-by-family: []` to the places `default-by-variant`
are.

Chris

On 16/7/21 4:00 am, Joel Sherrill wrote:
> I was going to do a sweep of all BSPs and then push but had an issue
> with the patch. If something happened with the mail Pranav, please just
> compress it and send it to me privately as an attachment. If it needs
> rebasing, please take care of that.
> 
> [joel@devel rtems]$ git am /tmp/x
> Applying: bsps: Move optfdt* files to shared parent directory
> error: patch failed: spec/build/bsps/arm/beagle/optfdtcpyro.yml:1
> error: spec/build/bsps/arm/beagle/optfdtcpyro.yml: patch does not apply
> error: patch failed: spec/build/bsps/arm/beagle/optfdtmxsz.yml:1
> error: spec/build/bsps/arm/beagle/optfdtmxsz.yml: patch does not apply
> error: patch failed: spec/build/bsps/arm/beagle/optfdtro.yml:1
> error: spec/build/bsps/arm/beagle/optfdtro.yml: patch does not apply
> error: patch failed: spec/build/bsps/arm/beagle/optfdtuboot.yml:1
> error: spec/build/bsps/arm/beagle/optfdtuboot.yml: patch does not apply
> error: patch failed: spec/build/bsps/arm/imx/optfdtcpyro.yml:1
> error: spec/build/bsps/arm/imx/optfdtcpyro.yml: patch does not apply
> error: patch failed: spec/build/bsps/arm/imx/optfdtmxsz.yml:1
> error: spec/build/bsps/arm/imx/optfdtmxsz.yml: patch does not apply
> error: patch failed: spec/build/bsps/arm/imx/optfdtro.yml:1
> error: spec/build/bsps/arm/imx/optfdtro.yml: patch does not apply
> error: patch failed: spec/build/bsps/arm/imx/optfdtuboot.yml:1
> error: spec/build/bsps/arm/imx/optfdtuboot.yml: patch does not apply
> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml:1
> error: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml: patch does not apply
> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtro.yml:1
> error: spec/build/bsps/powerpc/qoriq/optfdtro.yml: patch does not apply
> error: patch failed: spec/build/bsps/riscv/riscv/optfdtcpyro.yml:1
> error: spec/build/bsps/riscv/riscv/optfdtcpyro.yml: patch does not apply
> error: patch failed: spec/build/bsps/riscv/riscv/optfdtmxsz.yml:1
> error: spec/build/bsps/riscv/riscv/optfdtmxsz.yml: patch does not apply
> error: patch failed: spec/build/bsps/riscv/riscv/optfdtro.yml:1
> error: spec/build/bsps/riscv/riscv/optfdtro.yml: patch does not apply
> error: patch failed: spec/build/bsps/riscv/riscv/optfdtuboot.yml:1
> error: spec/build/bsps/riscv/riscv/optfdtuboot.yml: patch does not apply
> Patch failed at 0001 bsps: Move optfdt* files to shared parent directory
> hint: Use 'git am --show-current-patch' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> 
> On Thu, Jul 15, 2021 at 10:13 AM Gedare Bloom  wrote:
>>
>> This patch looks fine to me if someone can pick it up. It does touch a
>> lot of build BSPs though.
>>
>> On Fri, Jul 9, 2021 at 12:16 AM Pranav Dangi  wrote:
>>>
>>> ping. (Apart from moving the files in a shared directory, a part of this 
>>> patch also gets the RTEMS master branch to work on all the Pi's except 4.)
>>>
>>> On Fri, 2 Jul 2021, 09:35 Pranav Dangi,  wrote:

 yes, I've built all of them

 On Thu, Jul 1, 2021 at 10:01 PM Gedare Bloom  wrote:
>
> Did you build all affected BSPs?
>
> On Thu, Jul 1, 2021 at 4:05 AM pranav  wrote:
>>
>> ---
>>  .../arm/altera-cyclone-v/bspalteracyclonev.yml   |  8 
>>  spec/build/bsps/arm/beagle/grp.yml   |  8 
>>  spec/build/bsps/arm/beagle/optfdtcpyro.yml   | 15 ---
>>  spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16 
>>  spec/build/bsps/arm/beagle/optfdtro.yml  | 15 ---
>>  spec/build/bsps/arm/beagle/optfdtuboot.yml   | 15 ---
>>  spec/build/bsps/arm/imx/bspimx.yml   |  8 
>>  spec/build/bsps/arm/imx/optfdtcpyro.yml  | 15 ---
>>  spec/build/bsps/arm/imx/optfdtmxsz.yml   | 16 
>>  spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
>>  spec/build/bsps/arm/imx/optfdtuboot.yml  | 15 ---
>>  spec/build/bsps/arm/raspberrypi/grp.yml  |  8 
>>  .../{arm/altera-cyclone-v => }/optfdtcpyro.yml   |  0
>>  .../{arm/altera-cyclone-v => }/optfdtmxsz.yml|  0
>>  .../bsps/{arm/altera-cyclone-v => }/optfdtro.yml |  0
>>  .../{arm/altera-cyclone-v => }/optfdtuboot.yml   |  0
>>  spec/build/bsps/powerpc/qoriq/grp.yml|  4 ++--
>>  spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml | 16 
>>  spec/build/bsps/powerpc/qoriq/optfdtro.yml   | 15 ---
>>  spec/build/bsps/riscv/riscv/grp.yml  |  8 
>>  spec/build/bsps/riscv/riscv/optfdtcpyro.yml  | 15 ---
>>  spec/bui

Re: [PATCH 2/2] This adds a way to print the host triplet

[Chris Johns]

On 15/7/21 9:49 pm, Robin Müller wrote:
> I think this patch was forgotten so I'm just pushing it up again :-)

It was and sorry about that.

Minor change below ... no need to say "Displaying" as we know that. :)

if opts.get_arg('--list-host'):
print('Host operating system information: ')
print('Operating system: %s' % macro_expand(opts.defaults, '%{_os}'))
print('Number of processors: %s' % macro_expand(opts.defaults, '%{_ncpus}'))
print('Build architecture: %s' % macro_expand(opts.defaults, 
'%{_host_arch}'))
print('Host triplet: %s' % macro_expand(opts.defaults, '%{_host}'))
return True

A patch with that change is OK to be pushed if I do not get to it.

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