Re: [rtems-docs commit] Update build system related sections for RTEMS 6

[Sebastian Huber]

On 09/11/2022 01:35, Chris Johns wrote:


Was this posted for review? I do not remember seeing it?


Yes, on September 12.



There are a number of things that could be improved with this change.


I am sure things can be improved, but removing completely out of date 
stuff can't be that bad.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd v2 3/3] freebsd/cgem: Add SGMII support

[Kinsey Moore]

This adds support to the CGEM driver for selection of SGMII PHY
interfaces specified via device tree parameters.
---
 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 047d9104..689c3611 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -134,6 +134,7 @@ struct cgem_softc {
 #ifdef __rtems__
uint32_tnet_cfg_shadow;
int neednullqs;
+   int phy_contype;
 #endif /* __rtems__ */
int ref_clk_num;
 #ifndef __rtems__
@@ -1296,6 +1297,14 @@ cgem_config(struct cgem_softc *sc)
CGEM_NET_CFG_FULL_DUPLEX |
CGEM_NET_CFG_SPEED100;
 
+#ifdef __rtems__
+   /* Check connection type, enable SGMII bits if necessary. */
+   if ( sc->phy_contype == MII_CONTYPE_SGMII ) {
+   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;
@@ -2014,6 +2023,7 @@ cgem_attach(device_t dev)
/* Else for ref-clock-num OF_getprop */
else
sc->ref_clk_num = device_get_unit(dev);
+   sc->phy_contype = mii_fdt_get_contype(node);
} else {
sc->ref_clk_num = device_get_unit(dev);
sc->phy_contype = MII_CONTYPE_RGMII_ID;
-- 
2.30.2

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

[PATCH rtems-libbsd v2 2/3] freebsd/cgem: Add device tree support

[Kinsey Moore]

This reintroduces device tree support to the CGEM driver while
preserving the ability to statically define CGEM interfaces.
---
 freebsd/sys/dev/cadence/if_cgem.c | 42 +--
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
b/freebsd/sys/dev/cadence/if_cgem.c
index 3eaaf6b2..047d9104 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -72,11 +72,9 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
-#ifndef __rtems__
 #include 
 #include 
 #include 
-#endif /* __rtems__ */
 
 #include 
 #include 
@@ -92,6 +90,7 @@ __FBSDID("$FreeBSD$");
 #pragma GCC diagnostic ignored "-Wpointer-sign"
 #pragma GCC diagnostic ignored "-Wincompatible-pointer-types"
 #include 
+#include 
 #endif /* __rtems__ */
 
 #define IF_CGEM_NAME "cgem"
@@ -111,13 +110,14 @@ __FBSDID("$FreeBSD$");
 #define CGEM_CKSUM_ASSIST  (CSUM_IP | CSUM_TCP | CSUM_UDP | \
 CSUM_TCP_IPV6 | CSUM_UDP_IPV6)
 
-#ifndef __rtems__
 static struct ofw_compat_data compat_data[] = {
{ "cadence,gem",1 },
{ "cdns,macb",  1 },
+#ifdef __rtems__
+   { "cdns,gem",   1 },
+#endif
{ NULL, 0 },
 };
-#endif /* __rtems__ */
 
 struct cgem_softc {
if_tifp;
@@ -1947,13 +1947,20 @@ static int
 cgem_probe(device_t dev)
 {
 
-#ifndef __rtems__
+#ifdef __rtems__
+#ifdef FDT
+   if (bsp_fdt_get()) {
+#else
+   if (0) {
+#endif
+#endif /* __rtems__ */
if (!ofw_bus_status_okay(dev))
return (ENXIO);
 
if (ofw_bus_search_compatible(dev, compat_data)->ocd_data == 0)
return (ENXIO);
-#else /* __rtems__ */
+#ifdef __rtems__
+   }
 
struct cgem_softc *sc = device_get_softc(dev);
int val, rid = 0;
@@ -1983,24 +1990,34 @@ cgem_attach(device_t dev)
 {
struct cgem_softc *sc = device_get_softc(dev);
if_t ifp = NULL;
-#ifndef __rtems__
phandle_t node;
pcell_t cell;
-#endif /* __rtems__ */
int rid, err;
u_char eaddr[ETHER_ADDR_LEN];
 
sc->dev = dev;
CGEM_LOCK_INIT(sc);
 
-#ifndef __rtems__
+#ifdef __rtems__
+#ifdef FDT
+   if (bsp_fdt_get()) {
+#else
+   if (0) {
+#endif
+#endif /* __rtems__ */
/* Get reference clock number and base divider from fdt. */
node = ofw_bus_get_node(dev);
sc->ref_clk_num = 0;
if (OF_getprop(node, "ref-clock-num", , sizeof(cell)) > 0)
sc->ref_clk_num = fdt32_to_cpu(cell);
-#else /* __rtems__ */
-   sc->ref_clk_num = device_get_unit(dev);
+#ifdef __rtems__
+   /* Else for ref-clock-num OF_getprop */
+   else
+   sc->ref_clk_num = device_get_unit(dev);
+   } else {
+   sc->ref_clk_num = device_get_unit(dev);
+   sc->phy_contype = MII_CONTYPE_RGMII_ID;
+   }
 #endif /* __rtems__ */
 
/* Get memory resource. */
@@ -2228,9 +2245,8 @@ static driver_t cgem_driver = {
sizeof(struct cgem_softc),
 };
 
-#ifndef __rtems__
 DRIVER_MODULE(cgem, simplebus, cgem_driver, cgem_devclass, NULL, NULL);
-#else /* __rtems__ */
+#ifdef __rtems__
 DRIVER_MODULE(cgem, nexus, cgem_driver, cgem_devclass, NULL, NULL);
 #endif /* __rtems__ */
 DRIVER_MODULE(miibus, cgem, miibus_driver, miibus_devclass, NULL, NULL);
-- 
2.30.2

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

[PATCH rtems-libbsd v2 0/3] CFC400X support

[Kinsey Moore]

In this revised patch set, SGMII support has been reworked to use device
trees while preserving existing static instantiation used by Zynq and
Versal BSPs.

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

[PATCH rtems-libbsd v2 1/3] nexus/zynqmp: Use device trees for CGEM

[Kinsey Moore]

This moves the ZynqMP BSPs over to using device trees for CGEM
instantiation now that all BSP variants provide appropriate device
trees.
---
 rtemsbsd/include/bsp/nexus-devices.h | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 8be29a1c..8f3f437e 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -107,18 +107,14 @@ RTEMS_BSD_DRIVER_MMC;
 
 #include 
 
+RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
+SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR;
 /* Qemu only applies user-mode networking to the first interface by default, so
  * all 4 CGEM instances must be configured in the Qemu arguments using
- * "-nic user,model=cadence_gem" for each nic.
- *
- * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat
- * the highest-mapped CGEM as the primary interface.
+ * "-nic user,model=cadence_gem" for each desired nic.
  */
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
+SYSINIT_DRIVER_REFERENCE(cgem, simplebus);
 RTEMS_BSD_DRIVER_E1000PHY;
 RTEMS_BSD_DRIVER_UKPHY;
 
-- 
2.30.2

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

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

[Chris Johns]

Looks good and thank you for sorting out this approach.

Thanks
Chris

On 9/11/2022 8:56 am, Kinsey Moore wrote:

This adds a BSP variant for the ZynqMP BSP family to support the
Innoflight CFC-400X platform. To properly support the CFC-400X, device
trees were added to the ZynqMP platform due to both the optional
management interface as well as alternate physical configuration of the
ethernet interfaces.
---
  bsps/aarch64/xilinx-zynqmp/console/console.c  | 163 +-
  bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c  |  51 ++
  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts| 110 
  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c  | 124 +
  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts |  94 ++
  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c   |  97 +++
  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  15 ++
  .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |   4 +
  .../aarch64/xilinx-zynqmp/bspcfc400xlp64.yml  |  21 +++
  .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|   2 +
  .../aarch64/xilinx-zynqmp/bspqemulp64.yml |   2 +
  .../aarch64/xilinx-zynqmp/bspzu3egilp32.yml   |   2 +
  .../aarch64/xilinx-zynqmp/bspzu3eglp64.yml|   2 +
  spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |   1 +
  .../aarch64/xilinx-zynqmp/objfdtcfc400x.yml   |  14 ++
  .../aarch64/xilinx-zynqmp/objfdtzynqmp.yml|  14 ++
  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |   1 +
  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |   1 +
  spec/build/cpukit/optsmp.yml  |   1 +
  19 files changed, 718 insertions(+), 1 deletion(-)
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtcfc400x.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtzynqmp.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index d1948f1a0c..d546db8535 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -9,7 +9,7 @@
   */
  
  /*

- * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
   * Written by Kinsey Moore 
   *
   * Redistribution and use in source and binary forms, with or without
@@ -36,13 +36,165 @@
  
  #include 

  #include 
+#include 
+#include 
  #include 
  
+#include 

+#include 
  #include 
+
  #include 
  
  #include 
  
+#include 

+
+uint32_t mgmt_uart_reg_shift = 0;
+static uint8_t get_register(uintptr_t addr, uint8_t i)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  return reg [i];
+}
+
+static void set_register(uintptr_t addr, uint8_t i, uint8_t val)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  reg [i] = val;
+}
+
+static ns16550_context zynqmp_mgmt_uart_context = {
+  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Management UART 0"),
+  .get_reg = get_register,
+  .set_reg = set_register,
+  .port = 0,
+  .irq = 0,
+  .clock = 0,
+  .initial_baud = 0,
+};
+
+__attribute__ ((weak)) void 
zynqmp_configure_management_console(rtems_termios_device_context *base)
+{
+  /* 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(base, mgmt_watchdog_cmd[i]);
+  }
+}
+
+static void zynqmp_management_console_init(void)
+{
+  /* Find the management console in the device tree */
+  rtems_fdt_handle fdt_handle;
+  const uint32_t *prop;
+  uint32_t outprop[4];
+  int proplen;
+  int node;
+
+  rtems_fdt_init_handle(_handle);
+  rtems_fdt_register(bsp_fdt_get(), _handle);
+  const char *alias = rtems_fdt_get_alias(_handle, "mgmtport");
+  if (alias == NULL) {
+rtems_fdt_release_handle(_handle);
+return;
+  }
+  node = rtems_fdt_path_offset(_handle, alias);
+
+  prop = rtems_fdt_getprop(_handle, node, "clock-frequency", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = rtems_uint32_from_big_endian((const uint8_t *) [0]);
+  zynqmp_mgmt_uart_context.clock = outprop[0];
+
+  prop = rtems_fdt_getprop(_handle, node, "current-speed", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = 

Documentation changes required for release

[Chris Johns]

Hello,

The following was add to the documentation build support for the RTEMS 6 
release to avoid the need for us to perform mindless updates of the 
documentation on each release cycle:


https://git.rtems.org/rtems-docs/tree/README.txt#n604

The text is:

10. Use the following to embed the version number in any part of the
documentation source:

 1. @rtems-version@

The complete version string of the documentation.

 2. @rtems-ver-major@

The version major number.

 2. @rtems-ver-minor@

The version minor number.

 2. @rtems-ver-revision@

The version revision number.

The replacement happens during the source read phase of the build
and is not context specific. The substitution will happen in code
blocks and other normally quoted area.

It is a requirement these be used then embedded commands or
related text in the documentation to let the documentation track
the release. For example `microblaze-rtems6-gdb` should be written
as `microblaze-rtems@rtems-ver-major@-gdb`.

Note, the support for these version number may require some adjustments 
of what is provided in the documentation to aid the text being moved 
across releases without change. There is no hard and fast set of rule so 
please use commonsense. Sometimes less is better but is it a piece by 
piece call.


I would appreciate this being followed rather than it being the 
responsibility of the people perform the release to sort out. It only 
delays the releases.


Thanks
Chris

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

Re: [rtems-docs commit] Update build system related sections for RTEMS 6

[Chris Johns]

Hi,

Was this posted for review? I do not remember seeing it?

There are a number of things that could be improved with this change.

Chris

On 8/11/2022 4:47 pm, Sebastian Huber wrote:

Module:rtems-docs
Branch:master
Commit:31199e3a69d2dbd0a8f360e424fd19f3e9ef66ce
Changeset: 
http://git.rtems.org/rtems-docs/commit/?id=31199e3a69d2dbd0a8f360e424fd19f3e9ef66ce

Author:Sebastian Huber 
Date:  Mon Sep 12 09:10:38 2022 +0200

Update build system related sections for RTEMS 6

Update sections which contained the word "bsp_specs".

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

[PATCH v2] 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. To properly support the CFC-400X, device
trees were added to the ZynqMP platform due to both the optional
management interface as well as alternate physical configuration of the
ethernet interfaces.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  | 163 +-
 bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c  |  51 ++
 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts| 110 
 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c  | 124 +
 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts |  94 ++
 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c   |  97 +++
 bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  15 ++
 .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |   4 +
 .../aarch64/xilinx-zynqmp/bspcfc400xlp64.yml  |  21 +++
 .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|   2 +
 .../aarch64/xilinx-zynqmp/bspqemulp64.yml |   2 +
 .../aarch64/xilinx-zynqmp/bspzu3egilp32.yml   |   2 +
 .../aarch64/xilinx-zynqmp/bspzu3eglp64.yml|   2 +
 spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |   1 +
 .../aarch64/xilinx-zynqmp/objfdtcfc400x.yml   |  14 ++
 .../aarch64/xilinx-zynqmp/objfdtzynqmp.yml|  14 ++
 .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |   1 +
 .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |   1 +
 spec/build/cpukit/optsmp.yml  |   1 +
 19 files changed, 718 insertions(+), 1 deletion(-)
 create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c
 create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
 create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
 create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts
 create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtcfc400x.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtzynqmp.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index d1948f1a0c..d546db8535 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -9,7 +9,7 @@
  */
 
 /*
- * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
  * Written by Kinsey Moore 
  *
  * Redistribution and use in source and binary forms, with or without
@@ -36,13 +36,165 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 
+#include 
+#include 
 #include 
+
 #include 
 
 #include 
 
+#include 
+
+uint32_t mgmt_uart_reg_shift = 0;
+static uint8_t get_register(uintptr_t addr, uint8_t i)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  return reg [i];
+}
+
+static void set_register(uintptr_t addr, uint8_t i, uint8_t val)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  reg [i] = val;
+}
+
+static ns16550_context zynqmp_mgmt_uart_context = {
+  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Management UART 0"),
+  .get_reg = get_register,
+  .set_reg = set_register,
+  .port = 0,
+  .irq = 0,
+  .clock = 0,
+  .initial_baud = 0,
+};
+
+__attribute__ ((weak)) void 
zynqmp_configure_management_console(rtems_termios_device_context *base)
+{
+  /* 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(base, mgmt_watchdog_cmd[i]);
+  }
+}
+
+static void zynqmp_management_console_init(void)
+{
+  /* Find the management console in the device tree */
+  rtems_fdt_handle fdt_handle;
+  const uint32_t *prop;
+  uint32_t outprop[4];
+  int proplen;
+  int node;
+
+  rtems_fdt_init_handle(_handle);
+  rtems_fdt_register(bsp_fdt_get(), _handle);
+  const char *alias = rtems_fdt_get_alias(_handle, "mgmtport");
+  if (alias == NULL) {
+rtems_fdt_release_handle(_handle);
+return;
+  }
+  node = rtems_fdt_path_offset(_handle, alias);
+
+  prop = rtems_fdt_getprop(_handle, node, "clock-frequency", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = rtems_uint32_from_big_endian((const uint8_t *) [0]);
+  zynqmp_mgmt_uart_context.clock = outprop[0];
+
+  prop = rtems_fdt_getprop(_handle, node, "current-speed", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = rtems_uint32_from_big_endian((const uint8_t *) [0]);
+  zynqmp_mgmt_uart_context.initial_baud = outprop[0];
+
+  prop = rtems_fdt_getprop(_handle, node, "interrupts", );
+  if ( prop == 

[PATCH v2 0/1] Changes from v1

[Kinsey Moore]

The management interface is now dynamically detected via the device
tree. The device tree also contains information pertinent to LibBSD's
ethernet configuration for all ZynqMP BSPs.

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

[PATCH] riscv: Simplify _CPU_ISR_Set_level()

[Sebastian Huber]

Where CPU_ENABLE_ROBUST_THREAD_DISPATCH == TRUE, the only supported interrupt
level allowed to set is 0 (interrupts enabled).  This constraint is enforced by
the API level functions which return an error status for other interrupt
levels.
---
 .../score/cpu/riscv/include/rtems/score/cpu.h | 28 +--
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/cpukit/score/cpu/riscv/include/rtems/score/cpu.h 
b/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
index 88f7e7960c..f74ce99684 100644
--- a/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
@@ -193,21 +193,19 @@ static inline bool _CPU_ISR_Is_enabled( unsigned long 
level )
 
 static inline void _CPU_ISR_Set_level( uint32_t level )
 {
-  if ( ( level & CPU_MODES_INTERRUPT_MASK) == 0 ) {
-__asm__ volatile (
-  ".option push\n"
-  ".option arch, +zicsr\n"
-  "csrrs zero, mstatus, " RTEMS_XSTRING( RISCV_MSTATUS_MIE ) "\n"
-  ".option pop"
-);
-  } else {
-__asm__ volatile (
-  ".option push\n"
-  ".option arch, +zicsr\n"
-  "csrrc zero, mstatus, " RTEMS_XSTRING( RISCV_MSTATUS_MIE ) "\n"
-  ".option pop"
-);
-  }
+  /*
+   * Where CPU_ENABLE_ROBUST_THREAD_DISPATCH == TRUE, the only supported
+   * interrupt level allowed to set is 0 (interrupts enabled).  This constraint
+   * is enforced by the API level functions which return an error status for
+   * other interrupt levels.
+   */
+  (void) level;
+  __asm__ volatile (
+".option push\n"
+".option arch, +zicsr\n"
+"csrrs zero, mstatus, " RTEMS_XSTRING( RISCV_MSTATUS_MIE ) "\n"
+".option pop"
+  );
 }
 
 uint32_t _CPU_ISR_Get_level( void );
-- 
2.35.3

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

Re: Apple's Ventura OS issue with RSB.

[Karel Gardas]

More info on this issue:

(1) the issue (internal compiler error) does not happen all the time. In 
fact there are builds which even complete. The ratio failure/ok is 10/30 
so far -- building in a loop 6/rtems-sparc.


(2) attempt to bootstrap with GCC failed even more miserably. At least 
with GCC 12.x I installed from homebrew. The symptoms are fork sys call 
failing and a lot of processes created during the configure stage of 
various packages in a manner that it's too much. Basically RSB's 
packages' configure scripts are a fork bomb for whatever reason here on 
Ventura when attempting to use homebrew GCC 12.x. See below.


Due to nature of unpredictability this is not something worth reporting 
to GCC team now IMHO. We need to investigate more.


Ryan, if I'm not mistaken you have M1 mini for RTEMS builds, is that 
right? If so, do you still have Monterey on it? If so, could you be so 
kind and loop building of RSB's 6/rtems-sparc and allow it run for some 
time to see if by any mistake we have not overlooked the same stability 
issues on Monterey too? Let's say 1-2 days run should be enough to tell 
us more or give us some confidence if all builds pass well.


What I did to my clean config in order to compile RSB is:

- install xz (from homebrew is fine), side effect of this is you will 
get Apple's command line developer tools installed too -- which you need.


- compile python3.10 from source -- you need to enable SSL on it 
otherwise RSB would not be able to download from https.


- set paths to those two and run RSB

Nothing more was needed on Monterey in order to RSB compile...

Thanks!
Karel



Fork issues (example):

checking whether strtoull is declared... no
checking whether strverscmp is declared... no
checking whether strnlen is declared... no
checking whether canonicalize_file_name must be declared... yes
checking for stdlib.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable

checking for unistd.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable

checking for sys/param.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable

checking for getpagesize... (cached) yes
checking for working mmap... no
checking for working strncmp... no
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable

configure: updating cache ./config.cache
configure: creating ./config.status
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable

./config.status: fork: Resource temporarily unavailable
./config.status: fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure: 
fork: Resource temporarily unavailable

make[1]: *** [configure-libiberty] Error 1
rm: conftest.dSYM: is a directory
BSD nm
checking whether ln -s works... yes



On 11/6/22 16:09, Joel Sherrill wrote:
Is the cross gcc compiled with the native compiler provided by Apple? 
The alternative would likely be you installing something special.


I wonder if using gcc to compile it would work. But there's not a real 
solution.


Seems like an issue which needs reporting to gcc.

On Sun, Nov 6, 2022, 5:25 AM Karel Gardas  wrote:


   Folks,

upgraded to Ventura from Monterey and this breaks RSB for unknown
reason. The issue looks like segfault/internal compiler error in GCC
while compiling newlib.

6/rtems-sparc:

    CC       libc/stdlib/libc_a-strtoll_r.o
    CC       libm/complex/libm_a-cpowf.o
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c: In
function 'cexpf':
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c:47:9:
internal compiler error: Segmentation fault: 11
     47 |         w = r * cosf(y) + r * sinf(y) * I;
        |         ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See > for
instructions.
make[6]: *** [libm/complex/libm_a-cexpf.o] Error 1
make[6]: *** Waiting for unfinished jobs
    CC