Re: Text Formatting Patches coming

[Gedare Bloom]

On Mon, Oct 31, 2022 at 4:07 PM Chris Johns  wrote:
>
> On 1/11/2022 2:59 am, Gedare Bloom wrote:
> > I am planning to roll out several text formatting changes over the
> > next 6 weeks or so, to include:
> > 1. Removal of URLs from Copyright lines as per #4636. Note: Most of
> > the included URLs currently are from EB or Chris Johns (Contemporary
> > Software).
> > 2. Consistent capitalization of Copyright (C) in file header blocks as
> > per #4637.
> > * Style Updates as per #3860.
> >
> > This effort will include documentation, inclusion of automation tools,
> > and 3rd party software management. I will send patches and give notice
> > before any changes hit, but I wanted to give a heads up here that this
> > process will be taking place. If you have any specific requests or
> > patches pending in an area that I should avoid for now, please let me
> > know.
>
> Sounds good and looking forward to seeing this happen.
>
> Where is the clang-format style? I would like to play and have look at the 
> results?
>
See attached, this is the one Sebastian has sent before, and Ida used
also. I have not done any testing with it yet.


clang-format
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Identify 3rd party source in spec?

[Gedare Bloom]

The patches are available at
https://git.rtems.org/gedare/rtems.git/log/?h=test-split-3rd-party

On Mon, Oct 31, 2022 at 1:01 PM Gedare Bloom  wrote:
>
> Resending without the first patch since it may trigger size filters.
>
> -- Forwarded message -
> From: Gedare Bloom 
> Date: Mon, Oct 31, 2022 at 12:55 PM
> Subject: Identify 3rd party source in spec?
> To: devel@rtems.org 
>
>
> Hello all,
>
> I would like to float the idea of managing 3rd party source tracking
> through the build system spec files. I believe this would be the most
> efficient way to maintain this information, and we can leverage the
> existing build system code for tasks such as automatic format checks,
> generating lists of third-party code, etc.
>
> This will require refactoring some spec files to pull 3rd party code
> out to a separate .yml file that gets linked. Once that is done, then
> we could add another attribute for this tracking purpose. I would like
> to keep it simple as a boolean, maybe just "third-party: true/false"
> Attached is an example patch showing how this might work for the
> dtc/libfdt code as a build objects item type 'obj', and for zlib
> library as a build library item type 'lib' with some proof-of-concept
> code for generating a listing of third party source files.
>
> As an initial step before making this refactoring, I have added an
> explicit default "third-party: false" attribute to every yml file
> preceding the enabled-by: attribute, using the following bit of shell:
> rtems.git/spec/build$ find . -name "*.yml" | xargs sed -i -e
> 's/\(enabled-by.*\)/third-party: false\n\1/'
>
> This touches 2333 files adding that one line, which is the contents of
> the first 1 MiB patch attached in the series. The remaining patches
> then layer on the top and are functional, outputting:
>
> rtems.git$ ./waf third_party_list
> cpukit/dtc/libfdt/fdt.c
> cpukit/dtc/libfdt/fdt_addresses.c
> cpukit/dtc/libfdt/fdt_empty_tree.c
> cpukit/dtc/libfdt/fdt_ro.c
> cpukit/dtc/libfdt/fdt_rw.c
> cpukit/dtc/libfdt/fdt_strerror.c
> cpukit/dtc/libfdt/fdt_sw.c
> cpukit/dtc/libfdt/fdt_wip.c
> cpukit/zlib/adler32.c
> cpukit/zlib/compress.c
> cpukit/zlib/crc32.c
> cpukit/zlib/deflate.c
> cpukit/zlib/gzclose.c
> cpukit/zlib/gzlib.c
> cpukit/zlib/gzread.c
> cpukit/zlib/gzwrite.c
> cpukit/zlib/infback.c
> cpukit/zlib/inffast.c
> cpukit/zlib/inflate.c
> cpukit/zlib/inftrees.c
> cpukit/zlib/trees.c
> cpukit/zlib/uncompr.c
> cpukit/zlib/zutil.c
>
> I'll continue to work on this, feedback is requested though if this is
> a good direction or how to improve.
>
> Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Text Formatting Patches coming

[Joel Sherrill]

On Tue, Nov 1, 2022 at 8:55 AM Gedare Bloom  wrote:

> On Mon, Oct 31, 2022 at 4:07 PM Chris Johns  wrote:
> >
> > On 1/11/2022 2:59 am, Gedare Bloom wrote:
> > > I am planning to roll out several text formatting changes over the
> > > next 6 weeks or so, to include:
> > > 1. Removal of URLs from Copyright lines as per #4636. Note: Most of
> > > the included URLs currently are from EB or Chris Johns (Contemporary
> > > Software).
> > > 2. Consistent capitalization of Copyright (C) in file header blocks as
> > > per #4637.
> > > * Style Updates as per #3860.
> > >
> > > This effort will include documentation, inclusion of automation tools,
> > > and 3rd party software management. I will send patches and give notice
> > > before any changes hit, but I wanted to give a heads up here that this
> > > process will be taking place. If you have any specific requests or
> > > patches pending in an area that I should avoid for now, please let me
> > > know.
> >
> > Sounds good and looking forward to seeing this happen.
> >
> > Where is the clang-format style? I would like to play and have look at
> the results?
> >
> See attached, this is the one Sebastian has sent before, and Ida used
> also. I have not done any testing with it yet.
>

Is this still one style point away from the current style? Or was that
setting added?

--joel


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

Re: Fwd: Identify 3rd party source in spec?

[oss]

Hello Gedare,

Am 31.10.22 um 20:01 schrieb Gedare Bloom:

Resending without the first patch since it may trigger size filters.

-- Forwarded message -
From: Gedare Bloom 
Date: Mon, Oct 31, 2022 at 12:55 PM
Subject: Identify 3rd party source in spec?
To: devel@rtems.org 


Hello all,

I would like to float the idea of managing 3rd party source tracking
through the build system spec files. I believe this would be the most
efficient way to maintain this information, and we can leverage the
existing build system code for tasks such as automatic format checks,
generating lists of third-party code, etc.


Sounds like a good idea to have it in the build specification items.



This will require refactoring some spec files to pull 3rd party code
out to a separate .yml file that gets linked. Once that is done, then
we could add another attribute for this tracking purpose. I would like
to keep it simple as a boolean, maybe just "third-party: true/false"
Attached is an example patch showing how this might work for the
dtc/libfdt code as a build objects item type 'obj', and for zlib
library as a build library item type 'lib' with some proof-of-concept
code for generating a listing of third party source files.


Is it a good idea to make it a mandatory attribute? It makes the yaml 
files bigger. It will only mean that we have to look for copy and paste 
bugs instead of missing attributes if someone adds a new third party 
library.


Do we need some additional information / scripts / stuff for third party 
code? Like an upstream source or upstream version? For example the JFFS2 
code has a VERSION file with lots of information:


https://git.rtems.org/rtems/tree/cpukit/libfs/src/jffs2/VERSION

For the imxrt I added something similar in the commit description:

https://git.rtems.org/rtems/commit/bsps/arm/imxrt/nxp?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285

Full text is a bit big for an attribute but maybe the location of a 
VERSION file in the source tree? Or a minimal link to an upstream code 
and a version info?


Best regards

Christian



As an initial step before making this refactoring, I have added an
explicit default "third-party: false" attribute to every yml file
preceding the enabled-by: attribute, using the following bit of shell:
rtems.git/spec/build$ find . -name "*.yml" | xargs sed -i -e
's/\(enabled-by.*\)/third-party: false\n\1/'

This touches 2333 files adding that one line, which is the contents of
the first 1 MiB patch attached in the series. The remaining patches
then layer on the top and are functional, outputting:

rtems.git$ ./waf third_party_list
cpukit/dtc/libfdt/fdt.c
cpukit/dtc/libfdt/fdt_addresses.c
cpukit/dtc/libfdt/fdt_empty_tree.c
cpukit/dtc/libfdt/fdt_ro.c
cpukit/dtc/libfdt/fdt_rw.c
cpukit/dtc/libfdt/fdt_strerror.c
cpukit/dtc/libfdt/fdt_sw.c
cpukit/dtc/libfdt/fdt_wip.c
cpukit/zlib/adler32.c
cpukit/zlib/compress.c
cpukit/zlib/crc32.c
cpukit/zlib/deflate.c
cpukit/zlib/gzclose.c
cpukit/zlib/gzlib.c
cpukit/zlib/gzread.c
cpukit/zlib/gzwrite.c
cpukit/zlib/infback.c
cpukit/zlib/inffast.c
cpukit/zlib/inflate.c
cpukit/zlib/inftrees.c
cpukit/zlib/trees.c
cpukit/zlib/uncompr.c
cpukit/zlib/zutil.c

I'll continue to work on this, feedback is requested though if this is
a good direction or how to improve.

Gedare


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

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

[PATCH] zynqmp: Add support for the CFC-400X

[Kinsey Moore]

This adds a BSP variant for the ZynqMP BSP family to support the
Innoflight CFC-400X platform.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  | 72 +++
 bsps/aarch64/xilinx-zynqmp/include/bsp.h  | 11 +++
 .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |  7 ++
 .../aarch64/xilinx-zynqmp/bspcfc400xlp64.yml  | 21 ++
 .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  1 +
 .../aarch64/xilinx-zynqmp/optmgmtbase.yml | 20 ++
 .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  1 +
 spec/build/cpukit/optsmp.yml  |  1 +
 8 files changed, 134 insertions(+)
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optmgmtbase.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index d1948f1a0c..2fe71787dd 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -43,6 +43,69 @@
 
 #include 
 
+#ifdef BSP_XILINX_ZYNQMP_MGMT_UART_BASE
+#include 
+
+/* These values come from the super_if_axi_uart16550_0 DTS entry */
+/* From the Linux DTS, reg-offset */
+#define MGMT_PORT_OFFSET 0x1000
+/* From the Linux DTS, 89 + 32 (Shared Peripheral Interrupt offset) */
+#define MGMT_PORT_IRQ 121
+/* This provides a clock divider of 14 */
+#define MGMT_PORT_CLK 25804800
+
+static uint8_t get_register(uintptr_t addr, uint8_t i)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= 2;
+  return reg [i];
+}
+
+static void set_register(uintptr_t addr, uint8_t i, uint8_t val)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= 2;
+  reg [i] = val;
+}
+
+static ns16550_context zynqmp_mgmt_uart_context_0 = {
+  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Management UART 0"),
+  .get_reg = get_register,
+  .set_reg = set_register,
+  .port = BSP_XILINX_ZYNQMP_MGMT_UART_BASE + MGMT_PORT_OFFSET,
+  .irq = MGMT_PORT_IRQ,
+  .clock = MGMT_PORT_CLK,
+  .initial_baud = 115200,
+};
+
+__attribute__ ((weak)) void zynqmp_configure_management_console(void)
+{
+  /* This SLIP-encoded watchdog command sets timeouts to 0x seconds. */
+  const char mgmt_watchdog_cmd[] =
+"\xc0\xda\x00\x00\xff\xff\xff\xff\xff\x00\xff\xff\xff\xffM#\xc0";
+
+  /* Send the system watchdog configuration command */
+  for (int i = 0; i < sizeof(mgmt_watchdog_cmd); i++) {
+ns16550_polled_putchar(&zynqmp_mgmt_uart_context_0.base, 
mgmt_watchdog_cmd[i]);
+  }
+}
+
+static void zynqmp_management_console_init(void)
+{
+  ns16550_probe(&zynqmp_mgmt_uart_context_0.base);
+
+  zynqmp_configure_management_console();
+}
+
+RTEMS_SYSINIT_ITEM(
+  zynqmp_management_console_init,
+  RTEMS_SYSINIT_BSP_START,
+  RTEMS_SYSINIT_ORDER_FIRST
+);
+#endif
+
 static zynq_uart_context zynqmp_uart_instances[2] = {
   {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
@@ -81,6 +144,15 @@ rtems_status_code console_initialize(
 }
   }
 
+#ifdef BSP_XILINX_ZYNQMP_MGMT_UART_BASE
+  rtems_termios_device_install(
+"/dev/ttyMGMT0",
+&ns16550_handler_polled,
+NULL,
+&zynqmp_mgmt_uart_context_0.base
+  );
+#endif
+
   return RTEMS_SUCCESSFUL;
 }
 
diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h 
b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
index d937a313f2..c823d963c5 100644
--- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
+++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
@@ -83,6 +83,17 @@ uint32_t zynqmp_clock_i2c0(void);
 
 uint32_t zynqmp_clock_i2c1(void);
 
+#ifdef BSP_XILINX_ZYNQMP_MGMT_UART_BASE
+/**
+ * @brief Zynq UltraScale+ MPSoC specific set up of a management console.
+ *
+ * The ZynqMP SoC's programmable logic can provide a serial interface for 
system
+ * management which may need special initialization. Provide in the application
+ * to override the defaults in the BSP.
+ */
+__attribute__ ((weak)) void zynqmp_configure_management_console(void);
+#endif
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/bsps/aarch64/xilinx-zynqmp/start/bspstartmmu.c 
b/bsps/aarch64/xilinx-zynqmp/start/bspstartmmu.c
index 33ca1eafab..30b926a7c0 100644
--- a/bsps/aarch64/xilinx-zynqmp/start/bspstartmmu.c
+++ b/bsps/aarch64/xilinx-zynqmp/start/bspstartmmu.c
@@ -50,6 +50,13 @@ zynqmp_mmu_config_table[] = {
 .begin = 0xfd00U,
 .end = 0xffc0U,
 .flags = AARCH64_MMU_DEVICE
+#ifdef BSP_XILINX_ZYNQMP_MGMT_UART_BASE
+/* This covers the range of addresses where the UART could be */
+  }, {
+.begin = 0x8000U,
+.end = 0x9000U,
+.flags = AARCH64_MMU_DEVICE
+#endif
   }
 };
 
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml
new file mode 100644
index 00..05e53c3539
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: aarch64
+bsp: xilinx_zynqmp_lp64_cfc400x
+build-type: bsp
+cflags

[PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Kinsey Moore]

Certain hardware configurations will always use SGMII instead of RGMII.
Apply the appropriate flags for the relevant BSPs.
---
 freebsd/sys/dev/cadence/if_cgem.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
b/freebsd/sys/dev/cadence/if_cgem.c
index 3eaaf6b2..9b4cf693 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
CGEM_NET_CFG_FULL_DUPLEX |
CGEM_NET_CFG_SPEED100;
 
+#ifdef __rtems__
+#define STRINGIFY(to_str) #to_str
+#define BSP_STR(to_str) STRINGIFY(to_str)
+   /* Configure the PHYs to use SGMII for particular BSPs */
+   if ( 0 == strcmp( BSP_STR(RTEMS_BSP), "xilinx_zynqmp_lp64_cfc400x" ) ) {
+   net_cfg |= CGEM_NET_CFG_SGMII_EN;
+   net_cfg |= CGEM_NET_CFG_PCS_SEL;
+   }
+#endif
+
/* Enable receive checksum offloading? */
if ((if_getcapenable(ifp) & IFCAP_RXCSUM) != 0)
net_cfg |=  CGEM_NET_CFG_RX_CHKSUM_OFFLD_EN;
-- 
2.30.2

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

[PATCH rtems-docs] user/zynqmp: Add information about CFC-400X

[Kinsey Moore]

Add a list of known working hardware and commentary about bitstream
loading for specific hardware.
---
 user/bsps/aarch64/xilinx-zynqmp.rst | 48 +++--
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst 
b/user/bsps/aarch64/xilinx-zynqmp.rst
index 2b28132..1fef7a4 100644
--- a/user/bsps/aarch64/xilinx-zynqmp.rst
+++ b/user/bsps/aarch64/xilinx-zynqmp.rst
@@ -6,19 +6,39 @@
 .. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_qemu:
 .. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_zu3eg:
 .. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_zu3eg:
+.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_cfc400x:
 
 Qemu Xilinx ZynqMP
 ==
 
-This BSP supports four variants: `xilinx-zynqmp-ilp32-qemu`,
-`xilinx-zynqmp-lp64-qemu`, `xilinx-zynqmp-ilp32-zu3eg`, and
-`xilinx-zynqmp-lp64-zu3eg`. Platform-specific hardware initialization is
-performed by ARM Trusted Firmware (ATF). Other basic hardware initialization is
-performed by the BSP. These BSPs support the GICv2 interrupt controller present
-in all ZynqMP systems. The zu3eg BSPs have also been tested to be fully
-functional on zu2cg boards and should also work on any other ZynqMP chip 
variant
-since the Processing Subsystem (PS) does not vary among chip variants other 
than
-the number of CPU cores available.
+This BSP family supports the following variants:
+
+* `xilinx-zynqmp-ilp32-qemu`
+
+* `xilinx-zynqmp-lp64-qemu`
+
+* `xilinx-zynqmp-ilp32-zu3eg`
+
+* `xilinx-zynqmp-lp64-zu3eg`
+
+* `xilinx-zynqmp-lp64-cfc400x`
+
+Platform-specific hardware initialization is performed by ARM Trusted Firmware
+(ATF). Other basic hardware initialization is performed by the BSP. These BSPs
+support the GICv2 interrupt controller present in all ZynqMP systems. The zu3eg
+BSPs have also been tested to be fully functional on zu2cg boards and should
+also work on any other ZynqMP chip variant since the Processing Subsystem (PS)
+does not vary among chip variants other than the number of CPU cores available.
+
+This BSP family has been tested on the following hardware:
+
+* `Avnet UltraZed-EG SOM`
+
+* `Innoflight CFC-400X`
+
+* `Trenz TE0802`
+
+* `Xilinx ZCU102`
 
 Boot on QEMU
 
@@ -33,6 +53,14 @@ will drop to EL1 for execution. For quick turnaround during 
testing, it is
 recommended to use the u-boot BOOT.bin that comes with the PetaLinux prebuilts
 for the board in question.
 
+Some systems such as the CFC-400X may require a bitstream to be loaded into the
+FPGA portion of the chip to operate as expected. This bitstream must be loaded
+before RTEMS begins operation since accesses to programmable logic (PL) memory
+space can cause the CPU to hang if the FPGA is not initialized. This can be
+performed as part of BOOT.bin or by a bootloader such as u-boot. Loading
+bitstreams from RTEMS has not been tested on the ZynqMP platform and requires
+additional libraries from Xilinx.
+
 Hardware Boot Image Generation
 --
 
@@ -242,7 +270,7 @@ Network Configuration
 When used with LibBSD, these BSP variants support networking via the four
 Cadence GEM instances present on all ZynqMP hardware variants. All interfaces
 are enabled by default, but only interfaces with operational MII busses will be
-recognized and usable in RTEMS. Most ZynqMP dev boards use CGEM3.
+recognized and usable in RTEMS. Most ZynqMP dev boards use RGMII with CGEM3.
 
 When used with lwIP from the rtems-lwip integration repository, these BSP
 variants support networking via CGEM0 and one of the other CGEM* instances
-- 
2.30.2

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

[PATCH rtems-lwip 2/2] lwip.py: Remove redundant system includes

[Kinsey Moore]

These includes are already provided in the build by the pkgconfig (.pc)
from the installed BSP.
---
 lwip.py | 6 --
 1 file changed, 6 deletions(-)

diff --git a/lwip.py b/lwip.py
index e6580eb..23ffccf 100644
--- a/lwip.py
+++ b/lwip.py
@@ -166,9 +166,6 @@ def build(bld):
 drv_obj_incl = []
 drv_obj_incl.extend(drv_incl)
 drv_obj_incl.extend(common_includes)
-drv_obj_incl.append(os.path.relpath(
-os.path.join(bld.env.PREFIX, arch_lib_path, 'include')
-))
 
 bld(features='c',
 target='driver_obj',
@@ -203,9 +200,6 @@ def build(bld):
 test_app_incl.extend(drv_incl)
 test_app_incl.extend(common_includes)
 test_app_incl.append('rtemslwip/test/')
-test_app_incl.append(
-os.path.relpath(os.path.join(arch_lib_path, 'include'))
-)
 bld.program(features='c',
 target='networking01.exe',
 source='rtemslwip/test/networking01/sample_app.c',
-- 
2.30.2

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

[PATCH rtems-lwip 1/2] lwip.py: Remove redundant assignment

[Kinsey Moore]

---
 lwip.py | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lwip.py b/lwip.py
index c11ed1f..e6580eb 100644
--- a/lwip.py
+++ b/lwip.py
@@ -214,8 +214,6 @@ def build(bld):
 lib=['rtemscpu', 'rtemsbsp', 'rtemstest', 'lwip'],
 includes=' '.join(test_app_incl))
 
-arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
-bld.env.RTEMS_ARCH_BSP)
 lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
 bld.read_stlib('telnetd', paths=[lib_path])
 bld.read_stlib('rtemstest', paths=[lib_path])
-- 
2.30.2

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

Re: Fwd: Identify 3rd party source in spec?

[Kinsey Moore]

On Tue, Nov 1, 2022 at 11:25 AM  wrote:

> Hello Gedare,
>
> Am 31.10.22 um 20:01 schrieb Gedare Bloom:
> > Resending without the first patch since it may trigger size filters.
> >
> > -- Forwarded message -
> > From: Gedare Bloom 
> > Date: Mon, Oct 31, 2022 at 12:55 PM
> > Subject: Identify 3rd party source in spec?
> > To: devel@rtems.org 
> >
> >
> > Hello all,
> >
> > I would like to float the idea of managing 3rd party source tracking
> > through the build system spec files. I believe this would be the most
> > efficient way to maintain this information, and we can leverage the
> > existing build system code for tasks such as automatic format checks,
> > generating lists of third-party code, etc.
>
> Sounds like a good idea to have it in the build specification items.
>
> >
> > This will require refactoring some spec files to pull 3rd party code
> > out to a separate .yml file that gets linked. Once that is done, then
> > we could add another attribute for this tracking purpose. I would like
> > to keep it simple as a boolean, maybe just "third-party: true/false"
> > Attached is an example patch showing how this might work for the
> > dtc/libfdt code as a build objects item type 'obj', and for zlib
> > library as a build library item type 'lib' with some proof-of-concept
> > code for generating a listing of third party source files.
>
> Is it a good idea to make it a mandatory attribute? It makes the yaml
> files bigger. It will only mean that we have to look for copy and paste
> bugs instead of missing attributes if someone adds a new third party
> library.
>

I agree that an implicit "third-party: false" is preferable.

>
> Do we need some additional information / scripts / stuff for third party
> code? Like an upstream source or upstream version? For example the JFFS2
> code has a VERSION file with lots of information:
>
> https://git.rtems.org/rtems/tree/cpukit/libfs/src/jffs2/VERSION


I don't think this should be required for the initial implementation with
existing 3rd party source, but it would be good to define how we do this
for any new 3rd party source that is brought in. Adding this for existing
3rd party inclusions could easily be a janitor task.

For rtems-lwip, I've been enforcing addition of an ORIGIN.* file for new
source imports with an upstream commit hash in the commit message, but that
was added basically from the beginning and almost all directories in the
root of that project are 3rd party source imports that have pretty clear
origin, upstream, and licensing.

>
>
> For the imxrt I added something similar in the commit description:
>
>
> https://git.rtems.org/rtems/commit/bsps/arm/imxrt/nxp?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285
>
> Full text is a bit big for an attribute but maybe the location of a
> VERSION file in the source tree? Or a minimal link to an upstream code
> and a version info?
>
> Best regards
>
> Christian
>
> >
> > As an initial step before making this refactoring, I have added an
> > explicit default "third-party: false" attribute to every yml file
> > preceding the enabled-by: attribute, using the following bit of shell:
> > rtems.git/spec/build$ find . -name "*.yml" | xargs sed -i -e
> > 's/\(enabled-by.*\)/third-party: false\n\1/'
> >
> > This touches 2333 files adding that one line, which is the contents of
> > the first 1 MiB patch attached in the series. The remaining patches
> > then layer on the top and are functional, outputting:
> >
> > rtems.git$ ./waf third_party_list
> > cpukit/dtc/libfdt/fdt.c
> > cpukit/dtc/libfdt/fdt_addresses.c
> > cpukit/dtc/libfdt/fdt_empty_tree.c
> > cpukit/dtc/libfdt/fdt_ro.c
> > cpukit/dtc/libfdt/fdt_rw.c
> > cpukit/dtc/libfdt/fdt_strerror.c
> > cpukit/dtc/libfdt/fdt_sw.c
> > cpukit/dtc/libfdt/fdt_wip.c
> > cpukit/zlib/adler32.c
> > cpukit/zlib/compress.c
> > cpukit/zlib/crc32.c
> > cpukit/zlib/deflate.c
> > cpukit/zlib/gzclose.c
> > cpukit/zlib/gzlib.c
> > cpukit/zlib/gzread.c
> > cpukit/zlib/gzwrite.c
> > cpukit/zlib/infback.c
> > cpukit/zlib/inffast.c
> > cpukit/zlib/inflate.c
> > cpukit/zlib/inftrees.c
> > cpukit/zlib/trees.c
> > cpukit/zlib/uncompr.c
> > cpukit/zlib/zutil.c
> >
> > I'll continue to work on this, feedback is requested though if this is
> > a good direction or how to improve.
> >
> > Gedare
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-lwip 1/2] lwip.py: Remove redundant assignment

[Vijay Kumar Banerjee]

Hi Kinsey,

The patches look great. Thanks for the cleanup.


Best regards,
Vijay

On Tue, Nov 1, 2022 at 1:51 PM Kinsey Moore  wrote:
>
> ---
>  lwip.py | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/lwip.py b/lwip.py
> index c11ed1f..e6580eb 100644
> --- a/lwip.py
> +++ b/lwip.py
> @@ -214,8 +214,6 @@ def build(bld):
>  lib=['rtemscpu', 'rtemsbsp', 'rtemstest', 'lwip'],
>  includes=' '.join(test_app_incl))
>
> -arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
> -bld.env.RTEMS_ARCH_BSP)
>  lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
>  bld.read_stlib('telnetd', paths=[lib_path])
>  bld.read_stlib('rtemstest', paths=[lib_path])
> --
> 2.30.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] zynqmp: Add support for the CFC-400X

[Chris Johns]

On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef 
BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> +/**
> + * @brief Zynq UltraScale+ MPSoC specific set up of a management console.
> + *
> + * The ZynqMP SoC's programmable logic can provide a serial interface for 
> system
> + * management which may need special initialization. Provide in the 
> application
> + * to override the defaults in the BSP.
> + */

I am not comfortable with PL implementation dependences for specific hardware
being added to the generic BSP code. The Zynq, ZymqMP and Versal have so far
only referenced the hard IP.

Is the PL project and implementation for the PL logic openly available?

The hardware requires I request a data sheet from the manufacturer and that
makes keeping this code in our open repo difficult.

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

Re: Fwd: Identify 3rd party source in spec?

[Chris Johns]

On 2/11/2022 3:25 am, o...@c-mauderer.de wrote:> Is it a good idea to make it a
mandatory attribute? It makes the yaml files
> bigger. It will only mean that we have to look for copy and paste bugs instead
> of missing attributes if someone adds a new third party library.

Can you avoid having to add the item to all? I am no spec build system expert
(having invested time) and seem to remember needing to hit a lot of files when
adding something ...

https://git.rtems.org/rtems/commit/?id=6f2aa8ad36e3aaffc9fa2cb8c744b04da7339ee2

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 5:51 am, Kinsey Moore wrote:
> Certain hardware configurations will always use SGMII instead of RGMII.
> Apply the appropriate flags for the relevant BSPs.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 3eaaf6b2..9b4cf693 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
>   CGEM_NET_CFG_FULL_DUPLEX |
>   CGEM_NET_CFG_SPEED100;
>  
> +#ifdef __rtems__
> +#define STRINGIFY(to_str) #to_str
> +#define BSP_STR(to_str) STRINGIFY(to_str)
> + /* Configure the PHYs to use SGMII for particular BSPs */
> + if ( 0 == strcmp( BSP_STR(RTEMS_BSP), "xilinx_zynqmp_lp64_cfc400x" ) ) {
> + net_cfg |= CGEM_NET_CFG_SGMII_EN;
> + net_cfg |= CGEM_NET_CFG_PCS_SEL;
> + }

This makes it a precedent a cgem device has to be an RTEMS BSP to support SGMII.
I do not think that is a good idea.

Is the simplest solution adding a weak function call asks which mode and the
default call returns RGMII?

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

Re: [PATCH] zynqmp: Add support for the CFC-400X

[Kinsey Moore]

On Tue, Nov 1, 2022 at 3:59 PM Chris Johns  wrote:

> On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef
> BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> > +/**
> > + * @brief Zynq UltraScale+ MPSoC specific set up of a management
> console.
> > + *
> > + * The ZynqMP SoC's programmable logic can provide a serial interface
> for system
> > + * management which may need special initialization. Provide in the
> application
> > + * to override the defaults in the BSP.
> > + */
>
> I am not comfortable with PL implementation dependences for specific
> hardware
> being added to the generic BSP code. The Zynq, ZymqMP and Versal have so
> far
> only referenced the hard IP.
>
> Is the PL project and implementation for the PL logic openly available?
>
> Unfortunately, not as far as I'm aware. The management interface is
guaranteed to exist as a 16550 UART on all variants of the system and, from
the RTEMS perspective, the PL is a locked/hard part of the system.


> The hardware requires I request a data sheet from the manufacturer and that
> makes keeping this code in our open repo difficult.
>

I understand. The unfortunate part of this is that RTEMS isn't usable on
this platform beyond a couple of seconds without pushing off the system
watchdog via the 16550 UART. I have automated the watchdog parameter
manipulation externally for testing purposes, but a system running outside
that harness would encounter problems with many tests in the testsuite.

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

Re: [PATCH] zynqmp: Add support for the CFC-400X

[Chris Johns]

On 2/11/2022 8:15 am, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 3:59 PM Chris Johns  > wrote:
> 
> On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef
> BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> > +/**
> > + * @brief Zynq UltraScale+ MPSoC specific set up of a management 
> console.
> > + *
> > + * The ZynqMP SoC's programmable logic can provide a serial interface 
> for
> system
> > + * management which may need special initialization. Provide in the
> application
> > + * to override the defaults in the BSP.
> > + */
> 
> I am not comfortable with PL implementation dependences for specific 
> hardware
> being added to the generic BSP code. The Zynq, ZymqMP and Versal have so 
> far
> only referenced the hard IP.
> 
> Is the PL project and implementation for the PL logic openly available?
> 
> Unfortunately, not as far as I'm aware. The management interface is guaranteed
> to exist as a 16550 UART on all variants of the system and, from the RTEMS
> perspective, the PL is a locked/hard part of the system.

The PL is anything but hard, it is a feature of the device.

> The hardware requires I request a data sheet from the manufacturer and 
> that
> makes keeping this code in our open repo difficult.
> 
> I understand. The unfortunate part of this is that RTEMS isn't usable on this
> platform beyond a couple of seconds without pushing off the system watchdog 
> via
> the 16550 UART. I have automated the watchdog parameter manipulation 
> externally
> for testing purposes, but a system running outside that harness would 
> encounter
> problems with many tests in the testsuite.

I am not sure I am following. Have they wired a watchdog to accessing the UART?

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

Re: [PATCH rtems-lwip 1/2] lwip.py: Remove redundant assignment

[Chris Johns]

+1

On 2/11/2022 7:28 am, Vijay Kumar Banerjee wrote:
> Hi Kinsey,
> 
> The patches look great. Thanks for the cleanup.
> 
> 
> Best regards,
> Vijay
> 
> On Tue, Nov 1, 2022 at 1:51 PM Kinsey Moore  wrote:
>>
>> ---
>>  lwip.py | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/lwip.py b/lwip.py
>> index c11ed1f..e6580eb 100644
>> --- a/lwip.py
>> +++ b/lwip.py
>> @@ -214,8 +214,6 @@ def build(bld):
>>  lib=['rtemscpu', 'rtemsbsp', 'rtemstest', 'lwip'],
>>  includes=' '.join(test_app_incl))
>>
>> -arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>> -bld.env.RTEMS_ARCH_BSP)
>>  lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
>>  bld.read_stlib('telnetd', paths=[lib_path])
>>  bld.read_stlib('rtemstest', paths=[lib_path])
>> --
>> 2.30.2
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Kinsey Moore]

On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  wrote:

> On 2/11/2022 5:51 am, Kinsey Moore wrote:
> > Certain hardware configurations will always use SGMII instead of RGMII.
> > Apply the appropriate flags for the relevant BSPs.
> > ---
> >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> > index 3eaaf6b2..9b4cf693 100644
> > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >   CGEM_NET_CFG_FULL_DUPLEX |
> >   CGEM_NET_CFG_SPEED100;
> >
> > +#ifdef __rtems__
> > +#define STRINGIFY(to_str) #to_str
> > +#define BSP_STR(to_str) STRINGIFY(to_str)
> > + /* Configure the PHYs to use SGMII for particular BSPs */
> > + if ( 0 == strcmp( BSP_STR(RTEMS_BSP), "xilinx_zynqmp_lp64_cfc400x"
> ) ) {
> > + net_cfg |= CGEM_NET_CFG_SGMII_EN;
> > + net_cfg |= CGEM_NET_CFG_PCS_SEL;
> > + }
>
> This makes it a precedent a cgem device has to be an RTEMS BSP to support
> SGMII.
> I do not think that is a good idea.
>

I don't particularly like this solution either, but I evaluated a few other
options (see below).

>
> Is the simplest solution adding a weak function call asks which mode and
> the
> default call returns RGMII?
>

The downside to that is that none of the tests can operate as expected on a
SGMII-attached-PHY system since the application would be overriding the
weak symbol and the tests wouldn't do that. Another option would be to have
a generic option in RTEMS that specifies the PHY attachment and can be set
in config.ini, but that would appear to be dead code since it's not used
within RTEMS.

As far as I'm aware, the closest analog in LibBSD would be the buildset
configuration, but that seems more like a place to define which modules get
built than a location for configuring hardware.

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 8:56 am, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  > wrote:
> On 2/11/2022 5:51 am, Kinsey Moore wrote:
> > Certain hardware configurations will always use SGMII instead of RGMII.
> > Apply the appropriate flags for the relevant BSPs.
> > ---
> >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> > index 3eaaf6b2..9b4cf693 100644
> > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >               CGEM_NET_CFG_FULL_DUPLEX |
> >               CGEM_NET_CFG_SPEED100;
> > 
> > +#ifdef __rtems__
> > +#define STRINGIFY(to_str) #to_str
> > +#define BSP_STR(to_str) STRINGIFY(to_str)
> > +     /* Configure the PHYs to use SGMII for particular BSPs */
> > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP), 
> "xilinx_zynqmp_lp64_cfc400x" ) ) {
> > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> > +     }
> 
> This makes it a precedent a cgem device has to be an RTEMS BSP to support 
> SGMII.
> I do not think that is a good idea.
> 
> I don't particularly like this solution either, but I evaluated a few other
> options (see below).

I also do not like it.

> Is the simplest solution adding a weak function call asks which mode and 
> the
> default call returns RGMII?
> 
> The downside to that is that none of the tests can operate as expected on a
> SGMII-attached-PHY system since the application would be overriding the weak
> symbol and the tests wouldn't do that. Another option would be to have a 
> generic
> option in RTEMS that specifies the PHY attachment and can be set in 
> config.ini,
> but that would appear to be dead code since it's not used within RTEMS.

Would FDT solve this problem? Forcing FDT support onto the cgem driver would
break compatibility so it would have to handle a default state. If FDT probes
were tolerant of calls without a valid FDT being loaded it would be better but
our FDT support seems to have no middle ground from what I can see.

> As far as I'm aware, the closest analog in LibBSD would be the buildset
> configuration, but that seems more like a place to define which modules get
> built than a location for configuring hardware.

I think FDT is handling this stuff for other archs and the MRMAC will also
require FDT support.

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

Re: [PATCH] zynqmp: Add support for the CFC-400X

[Kinsey Moore]

On Tue, Nov 1, 2022 at 4:23 PM Chris Johns  wrote:

> On 2/11/2022 8:15 am, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 3:59 PM Chris Johns  > > wrote:
> >
> > On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef
> > BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> > > +/**
> > > + * @brief Zynq UltraScale+ MPSoC specific set up of a management
> console.
> > > + *
> > > + * The ZynqMP SoC's programmable logic can provide a serial
> interface for
> > system
> > > + * management which may need special initialization. Provide in
> the
> > application
> > > + * to override the defaults in the BSP.
> > > + */
> >
> > I am not comfortable with PL implementation dependences for specific
> hardware
> > being added to the generic BSP code. The Zynq, ZymqMP and Versal
> have so far
> > only referenced the hard IP.
> >
> > Is the PL project and implementation for the PL logic openly
> available?
> >
> > Unfortunately, not as far as I'm aware. The management interface is
> guaranteed
> > to exist as a 16550 UART on all variants of the system and, from the
> RTEMS
> > perspective, the PL is a locked/hard part of the system.
>
> The PL is anything but hard, it is a feature of the device.
>

In a general sense, yes. In this particular implementation it is guaranteed
to be there because it is critical to system functionality.

>
> > The hardware requires I request a data sheet from the manufacturer
> and that
> > makes keeping this code in our open repo difficult.
> >
> > I understand. The unfortunate part of this is that RTEMS isn't usable on
> this
> > platform beyond a couple of seconds without pushing off the system
> watchdog via
> > the 16550 UART. I have automated the watchdog parameter manipulation
> externally
> > for testing purposes, but a system running outside that harness would
> encounter
> > problems with many tests in the testsuite.
>
> I am not sure I am following. Have they wired a watchdog to accessing the
> UART?
>

The management UART talks to a system controller that manages watchdog
functionality among other things. Internal access can configure or pet the
watchdog. The current default code sets the watchdog timers to effectively
infinity so they don't trip while tests are run.

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Kinsey Moore]

On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  wrote:

> On 2/11/2022 8:56 am, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  > > wrote:
> > On 2/11/2022 5:51 am, Kinsey Moore wrote:
> > > Certain hardware configurations will always use SGMII instead of
> RGMII.
> > > Apply the appropriate flags for the relevant BSPs.
> > > ---
> > >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> > b/freebsd/sys/dev/cadence/if_cgem.c
> > > index 3eaaf6b2..9b4cf693 100644
> > > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> > >   CGEM_NET_CFG_FULL_DUPLEX |
> > >   CGEM_NET_CFG_SPEED100;
> > >
> > > +#ifdef __rtems__
> > > +#define STRINGIFY(to_str) #to_str
> > > +#define BSP_STR(to_str) STRINGIFY(to_str)
> > > + /* Configure the PHYs to use SGMII for particular BSPs */
> > > + if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> "xilinx_zynqmp_lp64_cfc400x" ) ) {
> > > + net_cfg |= CGEM_NET_CFG_SGMII_EN;
> > > + net_cfg |= CGEM_NET_CFG_PCS_SEL;
> > > + }
> >
> > This makes it a precedent a cgem device has to be an RTEMS BSP to
> support SGMII.
> > I do not think that is a good idea.
> >
> > I don't particularly like this solution either, but I evaluated a few
> other
> > options (see below).
>
> I also do not like it.
>
> > Is the simplest solution adding a weak function call asks which mode
> and the
> > default call returns RGMII?
> >
> > The downside to that is that none of the tests can operate as expected
> on a
> > SGMII-attached-PHY system since the application would be overriding the
> weak
> > symbol and the tests wouldn't do that. Another option would be to have a
> generic
> > option in RTEMS that specifies the PHY attachment and can be set in
> config.ini,
> > but that would appear to be dead code since it's not used within RTEMS.
>
> Would FDT solve this problem? Forcing FDT support onto the cgem driver
> would
> break compatibility so it would have to handle a default state. If FDT
> probes
> were tolerant of calls without a valid FDT being loaded it would be better
> but
> our FDT support seems to have no middle ground from what I can see.
>

FDT could technically solve the problem, current driver support and PHY
transport option support notwithstanding. As you pointed out, there isn't
currently a way to have both static configuration and FDT support at the
same time and multiple BSPs across multiple architectures use the CGEM
support - at least Zynq, ZynqMP, and Versal - all of which would need the
appropriate support added. I thought we had a RISC-V BSP that used it as
well, but I don't see it at the moment.

>
> > As far as I'm aware, the closest analog in LibBSD would be the buildset
> > configuration, but that seems more like a place to define which modules
> get
> > built than a location for configuring hardware.
>
> I think FDT is handling this stuff for other archs and the MRMAC will also
> require FDT support.
>

It is and the FDT support in this driver in FreeBSD 13 is a bit better.

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 1:18 pm, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  > wrote:
> 
> On 2/11/2022 8:56 am, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  
> > >> wrote:
> >     On 2/11/2022 5:51 am, Kinsey Moore wrote:
> >     > Certain hardware configurations will always use SGMII instead of 
> RGMII.
> >     > Apply the appropriate flags for the relevant BSPs.
> >     > ---
> >     >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >     >  1 file changed, 10 insertions(+)
> >     >
> >     > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> >     b/freebsd/sys/dev/cadence/if_cgem.c
> >     > index 3eaaf6b2..9b4cf693 100644
> >     > --- a/freebsd/sys/dev/cadence/if_cgem.c
> >     > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> >     > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >     >               CGEM_NET_CFG_FULL_DUPLEX |
> >     >               CGEM_NET_CFG_SPEED100;
> >     > 
> >     > +#ifdef __rtems__
> >     > +#define STRINGIFY(to_str) #to_str
> >     > +#define BSP_STR(to_str) STRINGIFY(to_str)
> >     > +     /* Configure the PHYs to use SGMII for particular BSPs */
> >     > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> "xilinx_zynqmp_lp64_cfc400x" ) ) {
> >     > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> >     > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> >     > +     }
> >
> >     This makes it a precedent a cgem device has to be an RTEMS BSP to
> support SGMII.
> >     I do not think that is a good idea.
> >
> > I don't particularly like this solution either, but I evaluated a few 
> other
> > options (see below).
> 
> I also do not like it.
> 
> >     Is the simplest solution adding a weak function call asks which mode
> and the
> >     default call returns RGMII?
> >
> > The downside to that is that none of the tests can operate as expected 
> on a
> > SGMII-attached-PHY system since the application would be overriding the 
> weak
> > symbol and the tests wouldn't do that. Another option would be to have a
> generic
> > option in RTEMS that specifies the PHY attachment and can be set in
> config.ini,
> > but that would appear to be dead code since it's not used within RTEMS.
> 
> Would FDT solve this problem? Forcing FDT support onto the cgem driver 
> would
> break compatibility so it would have to handle a default state. If FDT 
> probes
> were tolerant of calls without a valid FDT being loaded it would be 
> better but
> our FDT support seems to have no middle ground from what I can see.
> 
> 
> FDT could technically solve the problem, current driver support and PHY
> transport option support notwithstanding. As you pointed out, there isn't
> currently a way to have both static configuration and FDT support at the same
> time and multiple BSPs across multiple architectures use the CGEM support - at
> least Zynq, ZynqMP, and Versal - all of which would need the appropriate 
> support
> added. I thought we had a RISC-V BSP that used it as well, but I don't see it 
> at
> the moment.
> 
> 
> > As far as I'm aware, the closest analog in LibBSD would be the buildset
> > configuration, but that seems more like a place to define which modules 
> get
> > built than a location for configuring hardware.
> 
> I think FDT is handling this stuff for other archs and the MRMAC will also
> require FDT support.
> 
> 
> It is and the FDT support in this driver in FreeBSD 13 is a bit better.

Does this mean existing Zynq etc BSPs would need to add FDT support?

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Kinsey Moore]

On Tue, Nov 1, 2022 at 9:22 PM Chris Johns  wrote:

>
>
> On 2/11/2022 1:18 pm, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  > > wrote:
> >
> > On 2/11/2022 8:56 am, Kinsey Moore wrote:
> > > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  > 
> > > >> wrote:
> > > On 2/11/2022 5:51 am, Kinsey Moore wrote:
> > > > Certain hardware configurations will always use SGMII
> instead of RGMII.
> > > > Apply the appropriate flags for the relevant BSPs.
> > > > ---
> > > >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> > > >  1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> > > b/freebsd/sys/dev/cadence/if_cgem.c
> > > > index 3eaaf6b2..9b4cf693 100644
> > > > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > > > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > > > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> > > >   CGEM_NET_CFG_FULL_DUPLEX |
> > > >   CGEM_NET_CFG_SPEED100;
> > > >
> > > > +#ifdef __rtems__
> > > > +#define STRINGIFY(to_str) #to_str
> > > > +#define BSP_STR(to_str) STRINGIFY(to_str)
> > > > + /* Configure the PHYs to use SGMII for particular BSPs
> */
> > > > + if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> > "xilinx_zynqmp_lp64_cfc400x" ) ) {
> > > > + net_cfg |= CGEM_NET_CFG_SGMII_EN;
> > > > + net_cfg |= CGEM_NET_CFG_PCS_SEL;
> > > > + }
> > >
> > > This makes it a precedent a cgem device has to be an RTEMS BSP
> to
> > support SGMII.
> > > I do not think that is a good idea.
> > >
> > > I don't particularly like this solution either, but I evaluated a
> few other
> > > options (see below).
> >
> > I also do not like it.
> >
> > > Is the simplest solution adding a weak function call asks
> which mode
> > and the
> > > default call returns RGMII?
> > >
> > > The downside to that is that none of the tests can operate as
> expected on a
> > > SGMII-attached-PHY system since the application would be
> overriding the weak
> > > symbol and the tests wouldn't do that. Another option would be to
> have a
> > generic
> > > option in RTEMS that specifies the PHY attachment and can be set in
> > config.ini,
> > > but that would appear to be dead code since it's not used within
> RTEMS.
> >
> > Would FDT solve this problem? Forcing FDT support onto the cgem
> driver would
> > break compatibility so it would have to handle a default state. If
> FDT probes
> > were tolerant of calls without a valid FDT being loaded it would be
> better but
> > our FDT support seems to have no middle ground from what I can see.
> >
> >
> > FDT could technically solve the problem, current driver support and PHY
> > transport option support notwithstanding. As you pointed out, there isn't
> > currently a way to have both static configuration and FDT support at the
> same
> > time and multiple BSPs across multiple architectures use the CGEM
> support - at
> > least Zynq, ZynqMP, and Versal - all of which would need the appropriate
> support
> > added. I thought we had a RISC-V BSP that used it as well, but I don't
> see it at
> > the moment.
> >
> >
> > > As far as I'm aware, the closest analog in LibBSD would be the
> buildset
> > > configuration, but that seems more like a place to define which
> modules get
> > > built than a location for configuring hardware.
> >
> > I think FDT is handling this stuff for other archs and the MRMAC
> will also
> > require FDT support.
> >
> >
> > It is and the FDT support in this driver in FreeBSD 13 is a bit better.
>
> Does this mean existing Zynq etc BSPs would need to add FDT support?
>

Yes, unless there's a solution that allows both to exist at the same time.
I haven't investigated that option thoroughly.

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 1:48 pm, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 9:22 PM Chris Johns  > wrote:
> On 2/11/2022 1:18 pm, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  
> > >> wrote:
> >
> >     On 2/11/2022 8:56 am, Kinsey Moore wrote:
> >     > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  
> >     >
> >     > 
>  >     >     On 2/11/2022 5:51 am, Kinsey Moore wrote:
> >     >     > Certain hardware configurations will always use SGMII 
> instead
> of RGMII.
> >     >     > Apply the appropriate flags for the relevant BSPs.
> >     >     > ---
> >     >     >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >     >     >  1 file changed, 10 insertions(+)
> >     >     >
> >     >     > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> >     >     b/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > index 3eaaf6b2..9b4cf693 100644
> >     >     > --- a/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >     >     >               CGEM_NET_CFG_FULL_DUPLEX |
> >     >     >               CGEM_NET_CFG_SPEED100;
> >     >     > 
> >     >     > +#ifdef __rtems__
> >     >     > +#define STRINGIFY(to_str) #to_str
> >     >     > +#define BSP_STR(to_str) STRINGIFY(to_str)
> >     >     > +     /* Configure the PHYs to use SGMII for particular 
> BSPs */
> >     >     > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> >     "xilinx_zynqmp_lp64_cfc400x" ) ) {
> >     >     > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> >     >     > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> >     >     > +     }
> >     >
> >     >     This makes it a precedent a cgem device has to be an RTEMS 
> BSP to
> >     support SGMII.
> >     >     I do not think that is a good idea.
> >     >
> >     > I don't particularly like this solution either, but I evaluated a
> few other
> >     > options (see below).
> >
> >     I also do not like it.
> >
> >     >     Is the simplest solution adding a weak function call asks 
> which mode
> >     and the
> >     >     default call returns RGMII?
> >     >
> >     > The downside to that is that none of the tests can operate as
> expected on a
> >     > SGMII-attached-PHY system since the application would be 
> overriding
> the weak
> >     > symbol and the tests wouldn't do that. Another option would be to 
> have a
> >     generic
> >     > option in RTEMS that specifies the PHY attachment and can be set 
> in
> >     config.ini,
> >     > but that would appear to be dead code since it's not used within 
> RTEMS.
> >
> >     Would FDT solve this problem? Forcing FDT support onto the cgem 
> driver
> would
> >     break compatibility so it would have to handle a default state. If 
> FDT
> probes
> >     were tolerant of calls without a valid FDT being loaded it would be
> better but
> >     our FDT support seems to have no middle ground from what I can see.
> >
> >
> > FDT could technically solve the problem, current driver support and PHY
> > transport option support notwithstanding. As you pointed out, there 
> isn't
> > currently a way to have both static configuration and FDT support at 
> the same
> > time and multiple BSPs across multiple architectures use the CGEM 
> support - at
> > least Zynq, ZynqMP, and Versal - all of which would need the appropriate
> support
> > added. I thought we had a RISC-V BSP that used it as well, but I don't 
> see
> it at
> > the moment.
> >
> >
> >     > As far as I'm aware, the closest analog in LibBSD would be the 
> buildset
> >     > configuration, but that seems more like a place to define which
> modules get
> >     > built than a location for configuring hardware.
> >
> >     I think FDT is handling this stuff for other archs and the MRMAC 
> will also
> >     require FDT support.
> >
> >
> > It is and the FDT support in this driver in FreeBSD 13 is a bit better.
> 
> Does this mean existing Zynq etc BSPs would need to add FDT support?
> 
> 
> Yes, unless there's a solution that allows both to exist at the same time. I
> haven't investigated that option thoroughly.

Maybe we meet up and discuss the options.

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

bsp/riscv: Store/AMO address misaligned trap occured

[Padmarao.Begari]

Hi Sebastian,

The "Store/AMO address misaligned" trap occured in the "start.S"
 at "amoswap.w zero, zero, 0(t0)" while testing the sample
 application with the latest RTEMS master for RISC-V on
the Microchip PolarFire SoC.

The trap occured after this  
89ba2a98/rtems
 latest commit for riscv
(bsps/riscv: Workaround for sporadic linker issues).

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