[PATCH v2] libc: Added implementations for sig2str/str2sig methods
Added implementations for sig2str() and str2sig() in libc/signal in order
to improve POSIX compliance. Added function prototypes added to
sys/signal.h.
---
newlib/libc/include/sys/signal.h | 12 ++
newlib/libc/signal/sig2str.c | 235 +++
2 files changed, 247 insertions(+)
create mode 100644 newlib/libc/signal/sig2str.c
diff --git a/newlib/libc/include/sys/signal.h b/newlib/libc/include/sys/signal.h
index 45cc0366c..847dc59bd 100644
--- a/newlib/libc/include/sys/signal.h
+++ b/newlib/libc/include/sys/signal.h
@@ -238,6 +238,18 @@ int sigqueue (pid_t, int, const union sigval);
#endif /* __POSIX_VISIBLE >= 199309 */
+#if __GNU_VISIBLE
+
+/* POSIX Issue 8 adds sig2str() and str2sig(). */
+
+/* This allows for the max length of the error message and longest integer. */
+#define SIG2STR_MAX sizeof("Unknown signal 4294967295 ")
+
+int sig2str(int, char *);
+int str2sig(const char *__restrict, int *__restrict);
+
+#endif /* __GNU_VISIBLE */
+
#if defined(___AM29K__)
/* These all need to be defined for ANSI C, but I don't think they are
meaningful. */
diff --git a/newlib/libc/signal/sig2str.c b/newlib/libc/signal/sig2str.c
new file mode 100644
index 0..04b4bb1be
--- /dev/null
+++ b/newlib/libc/signal/sig2str.c
@@ -0,0 +1,235 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+/*
+ * Copyright (C) 2021 Matthew Joyce
+ *
+ * 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 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.
+ */
+
+/* Defining _GNU_SOURCE to have access to SIG2STR_MAX in signal.h. */
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+
+#define SPACES_TO_N 6 /* Allows indexing to RT Signal number in str2sig */
+#define NUM_OF_SIGS (sizeof(sig_array) / sizeof(sig_name_and_num))
+
+typedef struct sig_name_and_num {
+ const char *sig_name;
+ const int sig_num;
+} sig_name_and_num;
+
+static const sig_name_and_num sig_array[] = {
+#ifdef SIGHUP
+ { "HUP", SIGHUP},
+#endif
+#ifdef SIGINT
+ { "INT", SIGINT },
+#endif
+#ifdef SIGQUIT
+ { "QUIT", SIGQUIT },
+#endif
+#ifdef SIGILL
+ { "ILL", SIGILL },
+#endif
+#ifdef SIGTRAP
+ { "TRAP", SIGTRAP },
+#endif
+#ifdef SIGABRT
+ { "ABRT", SIGABRT },
+#endif
+#ifdef SIGIOT
+ { "IOT", SIGIOT},
+#endif
+#ifdef SIGEMT
+ { "EMT", SIGEMT },
+#endif
+#ifdef SIGFPE
+ { "FPE", SIGFPE },
+#endif
+#ifdef SIGKILL
+ { "KILL", SIGKILL },
+#endif
+#ifdef SIGBUS
+ { "BUS", SIGBUS },
+#endif
+#ifdef SIGSEGV
+ { "SEGV", SIGSEGV },
+#endif
+#ifdef SIGSYS
+ { "SYS", SIGSYS },
+#endif
+#ifdef SIGPIPE
+ { "PIPE", SIGPIPE },
+#endif
+#ifdef SIGALRM
+ { "ALRM", SIGALRM },
+#endif
+#ifdef SIGTERM
+ { "TERM", SIGTERM },
+#endif
+#ifdef SIGURG
+ { "URG", SIGURG },
+#endif
+#ifdef SIGSTOP
+ { "STOP", SIGSTOP },
+#endif
+#ifdef SIGTSTP
+ { "TSTP", SIGTSTP },
+#endif
+#ifdef SIGCONT
+ { "CONT", SIGCONT },
+#endif
+#ifdef SIGCHLD
+ { "CHLD", SIGCHLD },
+#endif
+#ifdef SIGCLD
+ { "CLD", SIGCLD },
+#endif
+#ifdef SIGTTIN
+ { "TTIN", SIGTTIN },
+#endif
+#ifdef SIGTTOU
+ { "TTOU", SIGTTOU },
+#endif
+#ifdef SIGIO
+ { "IO", SIGIO },
+#endif
+#ifdef SIGPOLL
+ { "POLL", SIGPOLL },
+#endif
+#ifdef SIGWINCH
+ { "WINCH", SIGWINCH },
+#endif
+#ifdef SIGUSR1
+ { "USR1", SIGUSR1 },
+#endif
+#ifdef SIGUSR2
+ { "USR2", SIGUSR2 },
+#endif
+#ifdef SIGPWR
+ { "PWR", SIGPWR },
+#endif
+#ifdef SIGXCPU
+ { "XCPU", SIGXCPU },
+#endif
+#ifdef SIGXFSZ
+
[PATCH v3] testsuites: Added tests for sig2str/str2sig methods
Fixed newline error at end of psxsignal09.yml. Added psxsignal09 in psxtests and compile only test in psxhdrs in order to evaluate newly added POSIX standard methods in Newlib. --- spec/build/testsuites/psxtests/grp.yml| 2 + spec/build/testsuites/psxtests/libpsxhdrs.yml | 1 + .../build/testsuites/psxtests/psxsignal09.yml | 21 ++ testsuites/psxtests/Makefile.am | 11 + testsuites/psxtests/configure.ac | 1 + testsuites/psxtests/psxhdrs/signal/sig2str.c | 57 testsuites/psxtests/psxsignal09/init.c| 249 ++ .../psxtests/psxsignal09/psxsignal09.doc | 35 +++ .../psxtests/psxsignal09/psxsignal09.scn | 32 +++ 9 files changed, 409 insertions(+) create mode 100644 spec/build/testsuites/psxtests/psxsignal09.yml create mode 100644 testsuites/psxtests/psxhdrs/signal/sig2str.c create mode 100644 testsuites/psxtests/psxsignal09/init.c create mode 100644 testsuites/psxtests/psxsignal09/psxsignal09.doc create mode 100644 testsuites/psxtests/psxsignal09/psxsignal09.scn diff --git a/spec/build/testsuites/psxtests/grp.yml b/spec/build/testsuites/psxtests/grp.yml index fb7ce465ae..f61f45dbe9 100644 --- a/spec/build/testsuites/psxtests/grp.yml +++ b/spec/build/testsuites/psxtests/grp.yml @@ -205,6 +205,8 @@ links: uid: psxsignal07 - role: build-dependency uid: psxsignal08 +- role: build-dependency + uid: psxsignal09 - role: build-dependency uid: psxspin01 - role: build-dependency diff --git a/spec/build/testsuites/psxtests/libpsxhdrs.yml b/spec/build/testsuites/psxtests/libpsxhdrs.yml index 6a0ab6d4f7..5767bcdacd 100644 --- a/spec/build/testsuites/psxtests/libpsxhdrs.yml +++ b/spec/build/testsuites/psxtests/libpsxhdrs.yml @@ -513,6 +513,7 @@ source: - testsuites/psxtests/psxhdrs/signal/sigtimedwait.c - testsuites/psxtests/psxhdrs/signal/sigwait.c - testsuites/psxtests/psxhdrs/signal/sigwaitinfo.c +- testsuites/psxtests/psxhdrs/signal/sig2str.c - testsuites/psxtests/psxhdrs/stddef/offsetof.c - testsuites/psxtests/psxhdrs/stdio/clearerr.c - testsuites/psxtests/psxhdrs/stdio/ctermid.c diff --git a/spec/build/testsuites/psxtests/psxsignal09.yml b/spec/build/testsuites/psxtests/psxsignal09.yml new file mode 100644 index 00..08a29c7c5b --- /dev/null +++ b/spec/build/testsuites/psxtests/psxsignal09.yml @@ -0,0 +1,21 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +build-type: test-program +cflags: [] +copyrights: +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) +cppflags: [] +cxxflags: [] +enabled-by: +- RTEMS_POSIX_API +features: c cprogram +includes: [] +ldflags: [] +links: [] +source: +- testsuites/psxtests/psxsignal09/init.c +stlib: [] +target: testsuites/psxtests/psxsignal09.exe +type: build +use-after: [] +use-before: [] + diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am index a35f00b665..b62d5cab59 100755 --- a/testsuites/psxtests/Makefile.am +++ b/testsuites/psxtests/Makefile.am @@ -924,6 +924,17 @@ psxsignal08_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxsignal08) \ endif endif +if HAS_POSIX +if TEST_psxsignal09 +psx_tests += psxsignal09 +psx_screens += psxsignal09/psxsignal09.scn +psx_docs += psxsignal09/psxsignal09.doc +psxsignal09_SOURCES = psxsignal09/init.c +psxsignal09_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxsignal09) \ + $(support_includes) -I$(top_srcdir)/include +endif +endif + if TEST_psxspin01 psx_tests += psxspin01 psx_screens += psxspin01/psxspin01.scn diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac index 3f95010cd3..7b9a1027ca 100644 --- a/testsuites/psxtests/configure.ac +++ b/testsuites/psxtests/configure.ac @@ -138,6 +138,7 @@ RTEMS_TEST_CHECK([psxsignal05]) RTEMS_TEST_CHECK([psxsignal06]) RTEMS_TEST_CHECK([psxsignal07]) RTEMS_TEST_CHECK([psxsignal08]) +RTEMS_TEST_CHECK([psxsignal09]) RTEMS_TEST_CHECK([psxspin01]) RTEMS_TEST_CHECK([psxstack01]) RTEMS_TEST_CHECK([psxstack02]) diff --git a/testsuites/psxtests/psxhdrs/signal/sig2str.c b/testsuites/psxtests/psxhdrs/signal/sig2str.c new file mode 100644 index 00..520a0db740 --- /dev/null +++ b/testsuites/psxtests/psxhdrs/signal/sig2str.c @@ -0,0 +1,57 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/** + * @file + * @brief Header File Conformance Test + * + * This test file is used to verify that the header files associated with + * invoking this function are correct. + */ + +/* + * Copyright (C) 2021 Matthew Joyce + * + * 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
[PATCH v2] testsuites: Added tests for sig2str/str2sig methods
Added psxsignal09 in psxtests and compile only test in psxhdrs in order to evaluate newly added POSIX standard methods in Newlib. --- spec/build/testsuites/psxtests/grp.yml| 2 + spec/build/testsuites/psxtests/libpsxhdrs.yml | 1 + .../build/testsuites/psxtests/psxsignal09.yml | 20 ++ testsuites/psxtests/Makefile.am | 11 + testsuites/psxtests/configure.ac | 1 + testsuites/psxtests/psxhdrs/signal/sig2str.c | 57 testsuites/psxtests/psxsignal09/init.c| 249 ++ .../psxtests/psxsignal09/psxsignal09.doc | 35 +++ .../psxtests/psxsignal09/psxsignal09.scn | 32 +++ 9 files changed, 408 insertions(+) create mode 100644 spec/build/testsuites/psxtests/psxsignal09.yml create mode 100644 testsuites/psxtests/psxhdrs/signal/sig2str.c create mode 100644 testsuites/psxtests/psxsignal09/init.c create mode 100644 testsuites/psxtests/psxsignal09/psxsignal09.doc create mode 100644 testsuites/psxtests/psxsignal09/psxsignal09.scn diff --git a/spec/build/testsuites/psxtests/grp.yml b/spec/build/testsuites/psxtests/grp.yml index fb7ce465ae..f61f45dbe9 100644 --- a/spec/build/testsuites/psxtests/grp.yml +++ b/spec/build/testsuites/psxtests/grp.yml @@ -205,6 +205,8 @@ links: uid: psxsignal07 - role: build-dependency uid: psxsignal08 +- role: build-dependency + uid: psxsignal09 - role: build-dependency uid: psxspin01 - role: build-dependency diff --git a/spec/build/testsuites/psxtests/libpsxhdrs.yml b/spec/build/testsuites/psxtests/libpsxhdrs.yml index 6a0ab6d4f7..5767bcdacd 100644 --- a/spec/build/testsuites/psxtests/libpsxhdrs.yml +++ b/spec/build/testsuites/psxtests/libpsxhdrs.yml @@ -513,6 +513,7 @@ source: - testsuites/psxtests/psxhdrs/signal/sigtimedwait.c - testsuites/psxtests/psxhdrs/signal/sigwait.c - testsuites/psxtests/psxhdrs/signal/sigwaitinfo.c +- testsuites/psxtests/psxhdrs/signal/sig2str.c - testsuites/psxtests/psxhdrs/stddef/offsetof.c - testsuites/psxtests/psxhdrs/stdio/clearerr.c - testsuites/psxtests/psxhdrs/stdio/ctermid.c diff --git a/spec/build/testsuites/psxtests/psxsignal09.yml b/spec/build/testsuites/psxtests/psxsignal09.yml new file mode 100644 index 00..5c9a16a7fc --- /dev/null +++ b/spec/build/testsuites/psxtests/psxsignal09.yml @@ -0,0 +1,20 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +build-type: test-program +cflags: [] +copyrights: +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) +cppflags: [] +cxxflags: [] +enabled-by: +- RTEMS_POSIX_API +features: c cprogram +includes: [] +ldflags: [] +links: [] +source: +- testsuites/psxtests/psxsignal09/init.c +stlib: [] +target: testsuites/psxtests/psxsignal09.exe +type: build +use-after: [] +use-before: [] \ No newline at end of file diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am index a35f00b665..b62d5cab59 100755 --- a/testsuites/psxtests/Makefile.am +++ b/testsuites/psxtests/Makefile.am @@ -924,6 +924,17 @@ psxsignal08_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxsignal08) \ endif endif +if HAS_POSIX +if TEST_psxsignal09 +psx_tests += psxsignal09 +psx_screens += psxsignal09/psxsignal09.scn +psx_docs += psxsignal09/psxsignal09.doc +psxsignal09_SOURCES = psxsignal09/init.c +psxsignal09_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxsignal09) \ + $(support_includes) -I$(top_srcdir)/include +endif +endif + if TEST_psxspin01 psx_tests += psxspin01 psx_screens += psxspin01/psxspin01.scn diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac index 3f95010cd3..7b9a1027ca 100644 --- a/testsuites/psxtests/configure.ac +++ b/testsuites/psxtests/configure.ac @@ -138,6 +138,7 @@ RTEMS_TEST_CHECK([psxsignal05]) RTEMS_TEST_CHECK([psxsignal06]) RTEMS_TEST_CHECK([psxsignal07]) RTEMS_TEST_CHECK([psxsignal08]) +RTEMS_TEST_CHECK([psxsignal09]) RTEMS_TEST_CHECK([psxspin01]) RTEMS_TEST_CHECK([psxstack01]) RTEMS_TEST_CHECK([psxstack02]) diff --git a/testsuites/psxtests/psxhdrs/signal/sig2str.c b/testsuites/psxtests/psxhdrs/signal/sig2str.c new file mode 100644 index 00..520a0db740 --- /dev/null +++ b/testsuites/psxtests/psxhdrs/signal/sig2str.c @@ -0,0 +1,57 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/** + * @file + * @brief Header File Conformance Test + * + * This test file is used to verify that the header files associated with + * invoking this function are correct. + */ + +/* + * Copyright (C) 2021 Matthew Joyce + * + * 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.
[PATCH rtems-libbsd v2 1/2] freebsd/if_cgem: Fail probe for unterminated MII
When the MII bus is unterminated on unused interfaces, it results in PHY
read timeouts which manifest as spurious PHYs during the attach call.
Detect these timeouts during the probe so the device can be ignored.
---
freebsd/sys/dev/cadence/if_cgem.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/freebsd/sys/dev/cadence/if_cgem.c
b/freebsd/sys/dev/cadence/if_cgem.c
index 34df7ac7..51e0bd6d 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -1955,6 +1955,24 @@ cgem_probe(device_t dev)
return (ENXIO);
#endif /* __rtems__ */
+ struct cgem_softc *sc = device_get_softc(dev);
+ int val, rid = 0;
+
+ /* Check for PHY read timeouts which indicate an unterminated MII bus */
+ sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, ,
+RF_ACTIVE);
+
+ val = cgem_miibus_readreg(dev, 0, MII_BMSR);
+ if (val == -1) {
+ bus_release_resource(dev, SYS_RES_MEMORY, ,
+sc->mem_res);
+ sc->mem_res = NULL;
+ return (ENXIO);
+ }
+ bus_release_resource(dev, SYS_RES_MEMORY, ,
+sc->mem_res);
+ sc->mem_res = NULL;
+
device_set_desc(dev, "Cadence CGEM Gigabit Ethernet Interface");
return (0);
}
--
2.20.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd v2 2/2] rtemsbsd: Present all ZynqMP interfaces by default
Now that the issue with false PHY detection on unterminated MII busses has been resolved, present all hardware interfaces for use on ZynqMP. --- rtemsbsd/include/bsp/nexus-devices.h | 9 - testsuite/include/rtems/bsd/test/network-config.h.in | 8 waf_libbsd.py| 4 +--- 3 files changed, 1 insertion(+), 20 deletions(-) diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h index cbb3f48b..9486083b 100644 --- a/rtemsbsd/include/bsp/nexus-devices.h +++ b/rtemsbsd/include/bsp/nexus-devices.h @@ -38,7 +38,6 @@ #include #include -#include #include @@ -116,18 +115,10 @@ RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR; * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat * the highest-mapped CGEM as the primary interface. */ -#if NET_CFG_ZYNQMP_USE_CGEM0 == '1' RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0); -#endif -#if NET_CFG_ZYNQMP_USE_CGEM1 == '1' RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1); -#endif -#if NET_CFG_ZYNQMP_USE_CGEM2 == '1' RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2); -#endif -#if NET_CFG_ZYNQMP_USE_CGEM3 == '1' RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3); -#endif RTEMS_BSD_DRIVER_E1000PHY; RTEMS_BSD_DRIVER_UKPHY; diff --git a/testsuite/include/rtems/bsd/test/network-config.h.in b/testsuite/include/rtems/bsd/test/network-config.h.in index da316e15..39bb5388 100755 --- a/testsuite/include/rtems/bsd/test/network-config.h.in +++ b/testsuite/include/rtems/bsd/test/network-config.h.in @@ -64,12 +64,4 @@ #define NET_CFG_GATEWAY_IP "@NET_CFG_GATEWAY_IP@" -#define NET_CFG_ZYNQMP_USE_CGEM0 '@NET_CFG_ZYNQMP_USE_CGEM0@' - -#define NET_CFG_ZYNQMP_USE_CGEM1 '@NET_CFG_ZYNQMP_USE_CGEM1@' - -#define NET_CFG_ZYNQMP_USE_CGEM2 '@NET_CFG_ZYNQMP_USE_CGEM2@' - -#define NET_CFG_ZYNQMP_USE_CGEM3 '@NET_CFG_ZYNQMP_USE_CGEM3@' - #endif /* _RTEMS_BSD_TEST_NETWORK_CONFIG_H_ */ diff --git a/waf_libbsd.py b/waf_libbsd.py index bb4182e3..e7222a03 100644 --- a/waf_libbsd.py +++ b/waf_libbsd.py @@ -289,9 +289,7 @@ class Builder(builder.ModuleManager): (bld.env.NET_CONFIG)) tags = [ 'NET_CFG_INTERFACE_0', 'NET_CFG_SELF_IP', 'NET_CFG_NETMASK', -'NET_CFG_PEER_IP', 'NET_CFG_GATEWAY_IP', -'NET_CFG_ZYNQMP_USE_CGEM0', 'NET_CFG_ZYNQMP_USE_CGEM1', -'NET_CFG_ZYNQMP_USE_CGEM2', 'NET_CFG_ZYNQMP_USE_CGEM3' +'NET_CFG_PEER_IP', 'NET_CFG_GATEWAY_IP' ] try: net_cfg_lines = open(bld.env.NET_CONFIG).readlines() -- 2.20.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/3] dev/mii: Handle PHY read timeouts
On 7/9/2021 00:32, Chris Johns wrote: On 9/7/21 3:28 pm, Sebastian Huber wrote: On 09/07/2021 03:14, Kinsey Moore wrote: PHY read timeouts return 0x and bypass the current bad/no PHY checks. This adds a check specifically for that read timeout to avoid probing PHYs that don't exist. --- freebsd/sys/dev/mii/mii.c | 1 + 1 file changed, 1 insertion(+) diff --git a/freebsd/sys/dev/mii/mii.c b/freebsd/sys/dev/mii/mii.c index d0428f24..8f087cab 100644 --- a/freebsd/sys/dev/mii/mii.c +++ b/freebsd/sys/dev/mii/mii.c @@ -474,6 +474,7 @@ mii_attach(device_t dev, device_t *miibus, if_t ifp, */ bmsr = MIIBUS_READREG(dev, ma.mii_phyno, MII_BMSR); if (bmsr == 0 || bmsr == 0x || + bmsr == 0x || Could you please fix the driver so that it returns 0 or 0x in case of timeouts? This is the general MII module of FreeBSD. If you think there is a bug in this code, then please report it to FreeBSD first. We should resolve the issue in the probe and not the attach call. Attach errors are real errors, probe errors or failures are niche to the specifics of the hardware. It looks like other drivers ensure that only the bottom two bytes of the return value are used though I can't seem to find a spec on the interface, so that's a possible bug in the cgem driver whose fix would achieve the same effect as this patch. Unfortunately, nothing is initialized or allocated until just before the PHYs are scanned in cgem_attach and getting something into the probe isn't going to be pretty, though it should at least be possible. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices
On 9/7/21 3:39 pm, Sebastian Huber wrote: > On 08/07/2021 03:11, Kinsey Moore wrote: >> I wonder why this never came up with Zynq or QorIQ. Maybe no one wanted to >> run >> network tests on the alternate interfaces because dev boards with those >> interfaces configured didn't exist? It's possible that the ukphy driver could >> be improved and this entire problem just goes away or we ban that driver from >> the default configuration for multi-interface BSPs and the problem goes away. > > The QorIQ BSP uses a device tree. > > The chips will get more and more complex. Managing this complexity with hand > written C preprocessor defines is a dead end from my point of view. Device > trees > allow you to provide a generic BSP which is initialized for a particular board > using the device tree. Compared to other operating systems, the device tree > support and generic device enumeration in RTEMS is a bit under developed. See > for example: > > https://docs.zephyrproject.org/latest/guides/dts/index.html#dt-guide > I agree and this is well said. I am concerned an ad-hock implementation leaves us with fragmented and hard to maintain support at the BSP level. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3] bsps: Move optfdt* files to shared parent directory
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
>> > - uid: optfdtmxsz
>> > + uid: ../../optfdtmxsz
>> > - role: build-dependency
>> > - uid: optfdtro
>> > + uid: ../../optfdtro
>> > - role: build-dependency
>> > - uid: optfdtuboot
>> > + uid: ../../optfdtuboot
>> > - role: build-dependency
>>
Re: typical RTEMS system HW?
On Thu, Jul 8, 2021 at 3:11 AM Shiro wrote: > > Hello, > > I’m new to RTEMS but very much like its features. I’m wonder what HW > (MCU/MPU and memory size) RTEMS is typical used on. Anyone care to share a > bit of details? > Well I held back hoping more people on the using side would answer. This is my perspective from the long-term developer view. Most users are on 32-bit platforms. There have been 64-bit ports for a long time but most people aren't using them. There are a lot of users from the space community who tend to be on hardened hardware. This SPARC LEON family is probably the most commonly used there. In the early days of the LEON predecessor (ERC32), I would say 1-4 MB was quite common for RAM. Other CPU architectures have been used in RTEMS space-based systems like PowerPC, Coldfire, MIPS, and ARM. There are also a lot of users in the EPICS (Experimental Physics and Industrial Control System) community which is commonly used in high energy physics, astronomy, and other big science equipment. I would tend to put a lot of those users on VME and CompactPCI boards with the PowerPC and x86 being common. They may still use some of their old VME m68040 boards or at least we haven't dropped support for them. These mostly tend to have 4-16 MB RAM. There are also a lot of commercial users and currently I think a lot of those are on ARM platforms (STM, Xilinx, NXP, etc) with RISC-V coming on strong. There are users on other architectures but I think the bulk are there now. PowerPC users seem to be realizing they are on the tail end of the lifecycle and need to look forward to a transition. RTEMS has been ported to 16-bit CPUs but there are none currently in the tree. You can certainly have an RTEMS application which fits into a small amount of Flash but as you add capabilities, you tend to pick up code and data space requirements. The earliest RTEMS systems would be big if they had 1-4 MB total Flash and RAM but that's considered small these days in general. I recall one m68k based system that has 96K total code and data space. The legacy network stack could easily run on 1 MB RAM. Now libbsd generally has more features and takes more memory. It may be able to be trimmed down but no one has invested the time. lwIP would be a better alternative in those cases. If you need a lot of features, the footprint naturally grows. If you are on a small target board, some tests won't fit. For example, some of the file system tests assume a 1MB RAM disk. If you don't have the space, you just don't. I still think that a large RTEMS system is on the smallest end of Linux systems. Not sure this gives specific answers but that's my impression. --joel > Thanks, > Shiro > ___ > 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: Throughput/Goodput analysis on RTEMS
On 2/7/21 4:40 am, Vijay Kumar Banerjee wrote: > I'm planning to do a throughput analysis on the RTEMS network stacks > and I'm looking for some suggestions on the tools/applications for > that if anyone has done something like that before. This is a great project. > If such application has not been used with RTEMS, then I might be > willing to port it to RTEMS or write one from scratch as a net-demo > maybe. Any resource/advice for that is welcome and much appreciated. Throughput is one parameter when dealing with networking and it is important in some applications while latency is another parameter that can be critical. Consider a voice switch with operators using Push To Talk (PTT) buttons to activate a radio's transmitter, an enable packet needs to be delivered within 10msec max in all cases. I would look at removing the networking fabric from the analysis because it is subjective and can be effected by the NIC hardware, PHY configuration plus any externally connected equipment. In terms of network stack performance for RTEMS you need to consider the protocol, buffering used, size of the buffer pool, transmit and receive paths, they will have different characteristics, and target's memory effects such as caches. On top of this is filtering, ie packet filtering, and the types of access. With libbsd there are a number of sysctl settings that effect the performance. How will you manage these? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
On Fri, Jul 9, 2021 at 8:25 PM Chris Johns wrote: > > On 2/7/21 4:40 am, Vijay Kumar Banerjee wrote: > > I'm planning to do a throughput analysis on the RTEMS network stacks > > and I'm looking for some suggestions on the tools/applications for > > that if anyone has done something like that before. > > This is a great project. > > > If such application has not been used with RTEMS, then I might be > > willing to port it to RTEMS or write one from scratch as a net-demo > > maybe. Any resource/advice for that is welcome and much appreciated. > > Throughput is one parameter when dealing with networking and it is important > in > some applications while latency is another parameter that can be critical. > Consider a voice switch with operators using Push To Talk (PTT) buttons to > activate a radio's transmitter, an enable packet needs to be delivered within > 10msec max in all cases. > This is an interesting point. Thanks for mentioning latency. > I would look at removing the networking fabric from the analysis because it is > subjective and can be effected by the NIC hardware, PHY configuration plus any > externally connected equipment. > I'm approaching this by running different network stacks over the same hardware. I have a uC5282 that runs legacy networking and I have ported the driver to libbsd nexus device (dhcp doesn't work yet) and I'm able to see some difference in the round trip time over loopback with different stacks. > In terms of network stack performance for RTEMS you need to consider the > protocol, buffering used, size of the buffer pool, transmit and receive paths, > they will have different characteristics, and target's memory effects such as > caches. On top of this is filtering, ie packet filtering, and the types of > access. > Thanks for these interesting attributes to consider. I have done preliminary analysis over ICMP with packets of same size over different network stacks on the same board. > With libbsd there are a number of sysctl settings that effect the performance. > How will you manage these? > I'm not sure. I didn't know about the possible performance difference based on sysctl settings. This would be relevant for any user and I would like to explore it. Could you please point to some resources or examples? > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC - Code Formatting and Style Checking for RTEMS score
Hello everyone, I added the functionality for my script to ignore certain directories like /bsps/, /testsuites/, '/cpukit/zlib', '/cpukit/mghttpd'. https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit Are there any extra directories I should exclude? Also open to more suggestions and feedback to make my code better :) Cheers, Ida. On Sun, Jul 4, 2021 at 12:40 AM Ida Delphine wrote: > Hello mentors, > > I got some feedback and I have improved my code based on it - > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit > Will love to get some more feedback and ways to make it look better. > And is it okay I start working on its documentation though it hasn't been > approved yet? > > Cheers, > Ida > > On Thu, Jul 1, 2021 at 6:42 PM Ida Delphine wrote: > >> Thank you. I will make changes accordingly. >> >> On Thu, 1 Jul 2021, 5:31 pm Gedare Bloom, wrote: >> >>> Hi Ida, >>> >>> On Tue, Jun 29, 2021 at 1:11 PM Ida Delphine wrote: >>> > >>> > Hello mentors, >>> > >>> > Here is the code for my pre-commit hook script. How it works is by >>> default, upon commiting it outputs a warning stating the number of style >>> issues in case there are mismatches. >>> > The user can trigger the strict mode which gives a more detailed >>> output of the style issues by running adding the mode to the config file ( >>> git config mode "strict") - will document this. >>> > >>> > https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit >>> > >>> I made comments on your commit that added this: >>> >>> https://github.com/Idadelveloper/rtems/commit/6bfc4802d17b3aab260190d53467b750848f0002 >>> >>> > I had already sent some screenshots here on how the outcome looks >>> like. Will love to improve my code based on your feedback and get more >>> suggestions. >>> > >>> > >>> > On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom wrote: >>> >> >>> >> >>> >> >>> >> On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine >>> wrote: >>> >>> >>> >>> Hello everyone, >>> >>> I updated the hooks script. About the modes, we have the default, >>> "strict" and "nonstrict" (couldn't think of better names). With the default >>> mode, it prints a warning specifying the number of style issues if any and >>> aborts the commit. With the strict mode, it goes into more detail showing >>> both the formatted and unformatted patch, the number of style issues, and >>> aborts the commit. In the non-strict mode, it simply displays the warning >>> with the style issues and the commit happens. >>> >>> >>> >>> The default mode basically happens when you run >>> >>> git commit -m "Commit message" >>> >>> >>> >>> The best method I could find to pass arguments to a script was via >>> environment variables. So the nonstrict mode applies when you run >>> >>> STYLEMODE=nonstrict git commit -m "Commit message" >>> >>> >>> >>> The strict mode applies when you run >>> >>> STYLEMODE=strict git commit -m "Commit message" >>> >>> >>> >>> >>> >> What are the possible options to pass arguments? (Maybe, a blog post >>> :)) Reading from a git-config file would be better than environment >>> variables. >>> >> >>> >> It might be better to share screenshots by a link (e.g., a blog post >>> :)) to avoid hitting the mailing list attachment limits. >>> >> >>> >> Gedare >>> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
