[PATCH libbsd 02/11] imx6_ccm: Port to RTEMS

[Christian Mauderer]

From: Sebastian Huber 

Update #3869.
---
 buildset/default.ini |  1 +
 freebsd/sys/arm/freescale/imx/imx6_ccm.c |  7 +++
 libbsd.py| 21 +
 rtemsbsd/include/bsp/nexus-devices.h |  2 ++
 4 files changed, 31 insertions(+)

diff --git a/buildset/default.ini b/buildset/default.ini
index 43ea82a3..ac8c9c48 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -40,6 +40,7 @@ dhcpcd = on
 dpaa = on
 evdev = on
 fdt = on
+imx = on
 in_cksum = on
 mdnsresponder = on
 mmc = on
diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index 2993f1d6..cef79933 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -92,6 +92,7 @@ WR4(struct ccm_softc *sc, bus_size_t off, uint32_t val)
 static void
 ccm_init_gates(struct ccm_softc *sc)
 {
+#ifndef __rtems__
uint32_t reg;
 
/* ahpbdma, aipstz 1 & 2 buses */
@@ -129,6 +130,7 @@ ccm_init_gates(struct ccm_softc *sc)
reg = CCGR6_USBOH3 | CCGR6_USDHC1 | CCGR6_USDHC2 |
CCGR6_USDHC3 | CCGR6_USDHC4;
WR4(sc, CCM_CCGR6, reg);
+#endif /* __rtems__ */
 }
 
 static int
@@ -204,7 +206,12 @@ ccm_probe(device_t dev)
if (!ofw_bus_status_okay(dev))
return (ENXIO);
 
+#ifndef __rtems__
 if (ofw_bus_is_compatible(dev, "fsl,imx6q-ccm") == 0)
+#else /* __rtems__ */
+if (ofw_bus_is_compatible(dev, "fsl,imx6q-ccm") == 0 &&
+   ofw_bus_is_compatible(dev, "fsl,imx6ul-ccm") == 0)
+#endif /* __rtems__ */
return (ENXIO);
 
device_set_desc(dev, "Freescale i.MX6 Clock Control Module");
diff --git a/libbsd.py b/libbsd.py
index d791efe4..eeb1ec4f 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5010,6 +5010,26 @@ class dpaa(builder.Module):
 mm.generator['source']()
 )
 
+class imx(builder.Module):
+def __init__(self, manager):
+super(imx, self).__init__(manager, type(self).__name__)
+
+def generate(self):
+mm = self.manager
+self.addKernelSpaceHeaderFiles(
+[
+'sys/arm/freescale/imx/imx6_ccmreg.h',
+'sys/arm/freescale/imx/imx6_machdep.h',
+'sys/arm/freescale/imx/imx_machdep.h',
+]
+)
+self.addKernelSpaceSourceFiles(
+[
+'sys/arm/freescale/imx/imx6_ccm.c',
+],
+mm.generator['source']()
+)
+
 #
 # Tests
 #
@@ -5166,6 +5186,7 @@ def load(mm):
 mm.addModule(dev_nic_broadcomm(mm))
 
 mm.addModule(nvme(mm))
+mm.addModule(imx(mm))
 
 # Add in_chksum
 mm.addModule(in_cksum(mm))
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index a916c664..92665409 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -127,6 +127,8 @@ RTEMS_BSD_DRIVER_MMC;
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
 
+SYSINIT_DRIVER_REFERENCE(ccm, simplebus);
+
 SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 
-- 
2.16.4

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

[PATCH libbsd 06/11] Add support for i.mx cache.

[Christian Mauderer]

Update #3869.
---
 rtemsbsd/include/machine/rtems-bsd-cache.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtemsbsd/include/machine/rtems-bsd-cache.h 
b/rtemsbsd/include/machine/rtems-bsd-cache.h
index bd496f9d..73b55e25 100755
--- a/rtemsbsd/include/machine/rtems-bsd-cache.h
+++ b/rtemsbsd/include/machine/rtems-bsd-cache.h
@@ -45,7 +45,7 @@
 #if defined(LIBBSP_ARM_LPC24XX_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) && 
defined(LPC32XX_DISABLE_MMU))
   /* No cache */
 #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H) || \
-  defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) 
&& !defined(LPC32XX_DISABLE_MMU))
+  defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) 
&& !defined(LPC32XX_DISABLE_MMU)) || defined(LIBBSP_ARM_IMX_BSP_H)
   /* With cache, no coherency support in hardware */
   #define CPU_DATA_CACHE_ALIGNMENT 32
 #elif defined(__GEN83xx_BSP_h)
-- 
2.16.4

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

[PATCH libbsd 07/11] bus-dma, imx: Don't sync nocache area.

[Christian Mauderer]

This area doesn't support all cache operations.

Update #3869.
---
 rtemsbsd/rtems/rtems-kernel-bus-dma.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/rtemsbsd/rtems/rtems-kernel-bus-dma.c 
b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
index 8c15e92b..8674bef1 100644
--- a/rtemsbsd/rtems/rtems-kernel-bus-dma.c
+++ b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
@@ -48,6 +48,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -396,6 +398,11 @@ bus_dmamap_sync(bus_dma_tag_t dmat, bus_dmamap_t map, 
bus_dmasync_op_t op)
uintptr_t size = map->buffer_size;
uintptr_t begin = (uintptr_t) map->buffer_begin;
uintptr_t end = begin + size;
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+   if (begin >= bsp_section_nocache_begin && end <= 
bsp_section_nocachenoload_end) {
+   return;
+   }
+#endif
 
if ((op & BUS_DMASYNC_PREWRITE) != 0 && (op & BUS_DMASYNC_PREREAD) == 
0) {
rtems_cache_flush_multiple_data_lines((void *) begin, size);
-- 
2.16.4

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

[PATCH rtems-docs v2] user/imx: Add i.MX6UL/ULL.

[Christian Mauderer]

Update #3869
---
 user/bsps/arm/imx.rst | 47 ---
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index bc93ae3..ee98f0b 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -7,9 +7,10 @@ imx (NXP i.MX)
 ==
 
 This BSP offers only one variant, the `imx7`.  This variant supports the i.MX
-7Dual processor.  The basic hardware initialization is not performed by the
-BSP.  A boot loader with device tree support must be used to start the BSP,
-e.g. U-Boot.
+7Dual processor and the i.MX 6UL/ULL processor family (with slightly different
+clock settings).  The basic hardware initialization is not performed by the 
BSP.
+A boot loader with device tree support must be used to start the BSP, e.g.
+U-Boot or barebox.
 
 Build Configuration Options
 ---
@@ -40,9 +41,30 @@ The following options are available at the configure command 
line.
 ``IMX_CCM_UART_HZ``
The UART clock frequency in Hz (default is 2400).
 
+``IMX_CCM_ECSPI_HZ``
+   The ECSPI clock frequency in Hz (default is 6750).
+
 ``IMX_CCM_AHB_HZ``
The AHB clock frequency in Hz (default is 13500).
 
+``IMX_CCM_SDHCI_HZ``
+   The SDHCI clock frequency in Hz (default is 196363000).
+
+Clock settings for different boards
+---
+
+The default clock settings are targeted for an i.MX 7Dual evaluation board 
using
+U-Boot. Some other boards with different boot loaders need different settings:
+
+ * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
+   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
+
+   * IMX_CCM_IPG_HZ=6600
+   * IMX_CCM_UART_HZ=8000
+   * IMX_CCM_AHB_HZ=6600
+   * IMX_CCM_SDHCI_HZ=19800
+   * IMX_CCM_ECSPI_HZ=6000
+
 Boot via U-Boot
 ---
 
@@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your U-Boot 
environment.  Just
 replace it with the appropriate commands to load the device tree at
 ``${fdt_addr}``.
 
+Boot via barebox
+
+
+The same command like for U-Boot can be used to generate an application image.
+In a default configuration barebox expects an fdt image called `oftree` and a
+kernel image called `zImage` in the root folder of the bootable medium (e.g. an
+SD card).
+
 Clock Driver
 
 
@@ -133,6 +163,17 @@ system controls:
 A value of zero for the time or count disables the interrupt coalescing in the
 corresponding direction.
 
+On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for the
+clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
libbsd
+config like that:
+
+.. code-block:: c
+
+#define RTEMS_BSD_CONFIG_BSP_CONFIG
+#define RTEMS_BSD_CONFIG_INIT
+SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
+#include 
+
 MMC/SDCard Driver
 -
 
-- 
2.16.4

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

Re: [PATCH libbsd 09/11] ehci_imx.c: Port to RTEMS

[Christian Mauderer]

Hello,

just noted: This patch now contains more from my code than from
Sebastian. I'll discuss with him whether we change the author before
commiting it.

Best regards

Christian

On 02/04/2020 16:42, Christian Mauderer wrote:
> From: Sebastian Huber 
> 
> Update #3869.
> ---
>  freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 11 ++
>  freebsd/sys/dev/usb/controller/ehci_imx.c   | 12 +++
>  freebsd/sys/dev/usb/usb_busdma.c| 54 
> +
>  libbsd.py   |  4 +++
>  rtemsbsd/include/bsp/nexus-devices.h|  5 +++
>  5 files changed, 86 insertions(+)
> 
> diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c 
> b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> index 8f47507b..ad545601 100644
> --- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> +++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> @@ -91,6 +91,17 @@ usbphy_detach(device_t dev)
>   return (0);
>  }
>  
> +#ifdef __rtems__
> +#define BUS_SPACE_PHYSADDR(res, offs) \
> + ((u_int)(rman_get_start(res)+(offs)))
> +
> +void
> +imx6_anatop_write_4(bus_size_t offset, uint32_t value)
> +{
> +
> + bus_space_write_4(0, 0x20c8000, offset, value);
> +}
> +#endif /* __rtems__ */
>  static int
>  usbphy_attach(device_t dev)
>  {
> diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
> b/freebsd/sys/dev/usb/controller/ehci_imx.c
> index a872fb62..d158df1d 100644
> --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
> +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
> @@ -303,6 +303,16 @@ imx_ehci_probe(device_t dev)
>   return (ENXIO);
>  
>   if (ofw_bus_search_compatible(dev, compat_data)->ocd_data != 0) {
> +#ifdef __rtems__
> + char dr_mode[24];
> +
> + if (OF_getprop(ofw_bus_get_node(dev), "dr_mode",
> + _mode, sizeof(dr_mode)) > 0 &&
> + strcasecmp(dr_mode, "host") != 0) {
> + return (ENXIO);
> + }
> +#endif /* __rtems__ */
> +
>   device_set_desc(dev, "Freescale i.MX integrated USB 
> controller");
>   return (BUS_PROBE_DEFAULT);
>   }
> @@ -437,8 +447,10 @@ imx_ehci_attach(device_t dev)
>   goto out;
>   }
>  
> +#ifndef __rtems__
>   /* Turn on clocks. */
>   imx_ccm_usb_enable(dev);
> +#endif /* __rtems__ */
>  
>   /* Disable overcurrent detection, if configured to do so. */
>   if (OF_hasprop(ofw_bus_get_node(sc->dev), "disable-over-current"))
> diff --git a/freebsd/sys/dev/usb/usb_busdma.c 
> b/freebsd/sys/dev/usb/usb_busdma.c
> index 9a70c687..c8000170 100644
> --- a/freebsd/sys/dev/usb/usb_busdma.c
> +++ b/freebsd/sys/dev/usb/usb_busdma.c
> @@ -78,6 +78,52 @@ static voidusb_pc_common_mem_cb(void *, 
> bus_dma_segment_t *, int, int,
>   uint8_t);
>  #endif
>  
> +#ifdef __rtems__
> +#include 
> +#if defined(LIBBSP_ARM_IMX_BSP_H)
> +#define NEED_MISSALIGNED_COPY
> +#endif
> +
> +#ifdef NEED_MISSALIGNED_COPY
> +/*
> + * Note: This functions are used instead of memcpy for regions where a
> + * misaligned access is not allowed (e.g. peripheral memory).
> + */
> +static void misaligned_do_copy(
> +  uint8_t *dst,
> +  const uint8_t *src,
> +  size_t n,
> +  bool aligned
> +)
> +{
> +  if (aligned) {
> +while (n > 3) {
> +  *(uint32_t *)dst = *(uint32_t *)src;
> +  dst += 4;
> +  src += 4;
> +  n -= 4;
> +}
> +  }
> +
> +  while (n > 0) {
> +*dst = *src;
> +++dst;
> +++src;
> +--n;
> +  }
> +}
> +
> +void misaligned_copy_to_io(void *dst, const void *src, size_t n)
> +{
> +  misaligned_do_copy(dst, src, n, ((uintptr_t)dst) % 4 == 0);
> +}
> +
> +void misaligned_copy_from_io(void *dst, const void *src, size_t n)
> +{
> +  misaligned_do_copy(dst, src, n, ((uintptr_t)src) % 4 == 0);
> +}
> +#endif
> +#endif /* __rtems__ */
>  /**
>   *  usbd_get_page - lookup DMA-able memory for the given offset
>   *
> @@ -182,7 +228,11 @@ usbd_copy_in(struct usb_page_cache *cache, 
> usb_frlength_t offset,
>   if (buf_res.length > len) {
>   buf_res.length = len;
>   }
> +#if defined(__rtems__) && defined(NEED_MISSALIGNED_COPY)
> + misaligned_copy_to_io(buf_res.buffer, ptr, buf_res.length);
> +#else /* __rtems__ */
>   memcpy(buf_res.buffer, ptr, buf_res.length);
> +#endif /* __rtems__ */
>  
>   offset += buf_res.length

Re: [PATCH libbsd 10/11] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

[Christian Mauderer]

On 02/04/2020 17:13, Gedare Bloom wrote:
> Maybe file a ticket against this for the future.

Problematic point is: I'm not sure when or if FreeBSD ever will have the
necessary functions. So that ticket would be a candidate for being open
forever.

> 
> On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
>  wrote:
>>
>> This is not a nice solution but it should work on all chips. As soon as
>> FreeBSD has a nice solution via the USB PHY driver, this should be
>> replaced.
>>
>> Update #3869.
>> ---
>>  freebsd/sys/dev/usb/controller/ehci_imx.c | 59 
>> +++
>>  1 file changed, 59 insertions(+)
>>
>> diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
>> b/freebsd/sys/dev/usb/controller/ehci_imx.c
>> index d158df1d..544a63b5 100644
>> --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
>> +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
>> @@ -50,6 +50,9 @@ __FBSDID("$FreeBSD$");
>>
>>  #include 
>>  #include 
>> +#ifdef __rtems__
>> +#include 
>> +#endif /* __rtems__ */
>>
>>  #include 
>>  #include 
>> @@ -270,6 +273,9 @@ struct imx_ehci_softc {
>> device_tdev;
>> struct resource *ehci_mem_res;  /* EHCI core regs. */
>> struct resource *ehci_irq_res;  /* EHCI core IRQ. */
>> +#ifdef __rtems__
>> +   void*phy_regs;
>> +#endif /* __rtems__ */
>>  };
>>
>>  static struct ofw_compat_data compat_data[] = {
>> @@ -380,6 +386,32 @@ imx_ehci_disable_oc(struct imx_ehci_softc *sc)
>> index = usbmprops[1];
>> imx_usbmisc_set_ctrl(usbmdev, index, USBNC_OVER_CUR_DIS);
>>  }
>> +#ifdef __rtems__
>> +#define BUS_SPACE_PHYSADDR(res, offs) \
>> +   ((u_int)(rman_get_start(res)+(offs)))
>> +
>> +static uint16_t
>> +imx_ehci_get_port_speed_portsc(struct ehci_softc *sc, uint16_t index)
>> +{
>> +   uint32_t v;
>> +   struct imx_ehci_softc *isc = (struct imx_ehci_softc *)sc;
>> +
>> +   v = ehci_get_port_speed_portsc(sc, index);
>> +
>> +   /* Set/clear ENHOSTDISCONDETECT in USBPHY CTRL register */
>> +   /* FIXME: This is a very hacky method. It should be done by the phy
>> +* driver instead. */
>> +   volatile uint32_t *ctrl_set = isc->phy_regs + 0x34;
>> +   volatile uint32_t *ctrl_clr = isc->phy_regs + 0x38;
>> +   if (v == UPS_HIGH_SPEED) {
>> +   *ctrl_set = 0x2;
>> +   } else {
>> +   *ctrl_clr = 0x2;
>> +   }
>> +
>> +   return (v);
>> +}
>> +#endif /* __rtems__ */
>>
>>  static int
>>  imx_ehci_attach(device_t dev)
>> @@ -474,6 +506,33 @@ imx_ehci_attach(device_t dev)
>> esc->sc_flags |= EHCI_SCFLG_NORESTERM | EHCI_SCFLG_TT;
>> esc->sc_vendor_post_reset = imx_ehci_post_reset;
>> esc->sc_vendor_get_port_speed = ehci_get_port_speed_portsc;
>> +#ifdef __rtems__
>> +   /*
>> +* FIXME: This is a big hack to get the PHY regs and set one bit 
>> during
>> +* changes of the port speed.
>> +*/
>> +   sc->phy_regs = 0;
>> +   if (OF_hasprop(ofw_bus_get_node(sc->dev), "fsl,usbphy")) {
>> +   phandle_t *cells;
>> +   int len;
>> +   phandle_t phynode;
>> +
>> +   cells = NULL;
>> +   len = OF_getencprop_alloc_multi(ofw_bus_get_node(sc->dev),
>> +   "fsl,usbphy", sizeof(*cells), (void **));
>> +   if (len > 0
>> +   && (phynode = OF_node_from_xref(cells[0])) != -1 &&
>> +   ofw_bus_node_is_compatible(phynode, 
>> "fsl,imx6ul-usbphy")) {
>> +   u_long base, size;
>> +   if (fdt_regsize(phynode, , ) == 0) {
>> +   sc->phy_regs = (void*)base;
>> +   esc->sc_vendor_get_port_speed =
>> +   imx_ehci_get_port_speed_portsc;
>> +   }
>> +   }
>> +   OF_prop_free(cells);
>> +   }
>> +#endif /* __rtems__ */
>>
>> err = ehci_init(esc);
>> if (err != 0) {
>> --
>> 2.16.4
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCHES] Add more i.MX6UL/ULL support

[Christian Mauderer]

Hello,

just noted another bug that happened during rebase: Not all steps in
libbsd are compileable. Please see the libbsd stuff as a draft version.
The content won't change but the order of the patches has to.

Best regards

Christian

On 02/04/2020 16:41, Christian Mauderer wrote:
> Hello,
> 
> this set of patches for RTEMS, libbsd and docs extend the i.MX6UL/ULL
> support.
> 
> Best regards
> 
> Christian
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] user/imx: Add i.MX6UL/ULL.

[Christian Mauderer]

On 02/04/2020 16:51, Gedare Bloom wrote:
> On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
>  wrote:
>>
>> Update #3869
>> ---
>>  user/bsps/arm/imx.rst | 49 ++---
>>  1 file changed, 46 insertions(+), 3 deletions(-)
>>
>> diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
>> index bc93ae3..51c3b7e 100644
>> --- a/user/bsps/arm/imx.rst
>> +++ b/user/bsps/arm/imx.rst
>> @@ -7,9 +7,10 @@ imx (NXP i.MX)
>>  ==
>>
>>  This BSP offers only one variant, the `imx7`.  This variant supports the 
>> i.MX
>> -7Dual processor.  The basic hardware initialization is not performed by the
>> -BSP.  A boot loader with device tree support must be used to start the BSP,
>> -e.g. U-Boot.
>> +7Dual processor and the i.MX 6UL/ULL processor family (with slightly 
>> different
>> +clock settings).  The basic hardware initialization is not performed by the 
>> BSP.
>> +A boot loader with device tree support must be used to start the BSP, e.g.
>> +U-Boot or barebox.
>>
>>  Build Configuration Options
>>  ---
>> @@ -40,9 +41,30 @@ The following options are available at the configure 
>> command line.
>>  ``IMX_CCM_UART_HZ``
>> The UART clock frequency in Hz (default is 2400).
>>
>> +``IMX_CCM_ECSPI_HZ``
>> +   The ECSPI clock frequency in Hz (default is 6750).
>> +
>>  ``IMX_CCM_AHB_HZ``
>> The AHB clock frequency in Hz (default is 13500).
>>
>> +``IMX_CCM_SDHCI_HZ``
>> +   The SDHCI clock frequency in Hz (default is 196363000).
>> +
>> +Clock settings for different boards
>> +---
>> +
>> +The default clock settings are targeted for an i.MX 7Dual evaluation board 
>> using
>> +U-Boot. Some other boards with different boot loaders need different 
>> settings:
>> +
>> + * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
>> +   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
>> +
>> +   * IMX_CCM_IPG_HZ=6600
>> +   * IMX_CCM_UART_HZ=8000
>> +   * IMX_CCM_AHB_HZ=6600
>> +   * IMX_CCM_SDHCI_HZ=19800
>> +   * IMX_CCM_ECSPI_HZ=6000
>> +
>>  Boot via U-Boot
>>  ---
>>
>> @@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your U-Boot 
>> environment.  Just
>>  replace it with the appropriate commands to load the device tree at
>>  ``${fdt_addr}``.
>>
>> +Boot via barebox
>> +
>> +
>> +The same command like for U-Boot can be used to generate an application 
>> image.
>> +In a default configuration barebox expects an fdt image called `oftree` and 
>> a
>> +kernel image called `zImage` in the root folder of the bootable medium 
>> (e.g. an
>> +SD card).
>> +
>>  Clock Driver
>>  
>>
>> @@ -133,6 +163,18 @@ system controls:
>>  A value of zero for the time or count disables the interrupt coalescing in 
>> the
>>  corresponding direction.
>>
>> +On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for 
>> the
>> +clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
>> libbsd
>> +config like that:
>> +
>> +.. code-block:: c
>> +
>> +#define RTEMS_BSD_CONFIG_BSP_CONFIG
>> +#define RTEMS_BSD_CONFIG_INIT
>> +SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
>> +#include 
>> +
>> +
> Is the extra space needed here?
> 

No, sorry. That was an accident.

>>  MMC/SDCard Driver
>>  -
>>
>> @@ -147,3 +189,4 @@ Caveats
>>  The clock and pin configuration support is quite rudimentary and mostly 
>> relies
>>  on the boot loader.  For a pin group configuration see
>>  ``imx_iomux_configure_pins()``.  There is no power management support.
>> +
> 
> Many docs end without the blank line. It does cause git to complain.
> I'm not sure if we have any rule about it for writing docs.
> 

Hm. That line shouldn't even be there. I don't wanted to add a blank
line at the end. I'll remove it again.

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

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH libbsd 09/11] ehci_imx.c: Port to RTEMS

[Christian Mauderer]

On 02/04/2020 17:00, Sebastian Huber wrote:
> On 02/04/2020 16:42, Christian Mauderer wrote:
> 
>> diff --git a/freebsd/sys/dev/usb/usb_busdma.c
>> b/freebsd/sys/dev/usb/usb_busdma.c
>> index 9a70c687..c8000170 100644
>> --- a/freebsd/sys/dev/usb/usb_busdma.c
>> +++ b/freebsd/sys/dev/usb/usb_busdma.c
>> @@ -78,6 +78,52 @@ static void    usb_pc_common_mem_cb(void *,
>> bus_dma_segment_t *, int, int,
>>   uint8_t);
>>   #endif
>>   +#ifdef __rtems__
>> +#include 
>> +#if defined(LIBBSP_ARM_IMX_BSP_H)
>> +#define NEED_MISSALIGNED_COPY
>> +#endif
> 
> Could you please move changes in general file imported from FreeBSD to
> separate commits.

OK. I'll split them.

> 
> I don't like this change here at all. I had a similar issue with
> misaligned memcpy() to device memory here on the STM32H7 platform. Could
> you first try this patch here:

Works fine too. The patch seems generic. Do you plan to add it soon as
an extra patch?

> 
> diff --git a/freebsd/sys/dev/usb/usb_busdma.c
> b/freebsd/sys/dev/usb/usb_busdma.c
> index 9a70c687..973a3409 100644
> --- a/freebsd/sys/dev/usb/usb_busdma.c
> +++ b/freebsd/sys/dev/usb/usb_busdma.c
> @@ -584,7 +584,7 @@ usb_pc_alloc_mem(struct usb_page_cache *pc, struct
> usb_page *pg,
>     }
>     /* allocate memory */
>     if (bus_dmamem_alloc(
> -   utag->tag, , (BUS_DMA_WAITOK | BUS_DMA_COHERENT), )) {
> +   utag->tag, , BUS_DMA_WAITOK, )) {
>     goto error;
>     }
>     /* setup page cache */
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5 release status

[Christian Mauderer]

Hello Chris,

I don't think that littlevgl is such an essential or stable package yet.
Currently I know of exactly one project using this repository and that's
only because I added it.

Best regards

Christian

On 02/04/2020 11:00, Chris Johns wrote:
> Hi,
> 
> All OK and thanks for letting us know.
> 
> I am not sure littlevgl is in the release. Maybe it should be?
> 
> I am picking up packages via the RSB.
> 
> Chris
> 
> On 2020-04-02 19:03, Christian Mauderer wrote:
>> Hello Chris,
>>
>> sorry, I missed that mail this morning. I pushed a small patch to
>> rtems-littlevgl that fixes a build problem with python3.
>>
>> I hope I didn't make problems with that.
>>
>> Best regards
>>
>> Christian
>>
>> On 02/04/2020 01:31, Chris Johns wrote:
>>> Hello,
>>>
>>> Please read if you have commit access.
>>>
>>> I am cleaning up a few issues like the release README.txt to match
>>> moving all the released source in to `sources`, then updating the
>>> documentation to reference this and then I will create a 5.0.0-m2004
>>> snapshot.
>>>
>>> After this I will be looking to make a branch so please wait for an ack
>>> from Joel, Gedare or myself for any pushes to any repo. We are in a
>>> slushy state to fix tickets.
>>>
>>> The sooner we clear the tickets from 5.1 the sooner I can create the
>>> branch in the repos and the repos can be open again.
>>>
>>> You help is needed and welcomed.
>>>
>>> Thanks
>>> Chris
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5 release status

[Christian Mauderer]

Hello Chris,

sorry, I missed that mail this morning. I pushed a small patch to
rtems-littlevgl that fixes a build problem with python3.

I hope I didn't make problems with that.

Best regards

Christian

On 02/04/2020 01:31, Chris Johns wrote:
> Hello,
> 
> Please read if you have commit access.
> 
> I am cleaning up a few issues like the release README.txt to match
> moving all the released source in to `sources`, then updating the
> documentation to reference this and then I will create a 5.0.0-m2004
> snapshot.
> 
> After this I will be looking to make a branch so please wait for an ack
> from Joel, Gedare or myself for any pushes to any repo. We are in a
> slushy state to fix tickets.
> 
> The sooner we clear the tickets from 5.1 the sooner I can create the
> branch in the repos and the repos can be open again.
> 
> You help is needed and welcomed.
> 
> Thanks
> Chris
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5 release status

[Christian Mauderer]

On 02/04/2020 11:10, Chris Johns wrote:
> On 2020-04-02 20:02, Christian Mauderer wrote:
>> Hello Chris,
>>
>> I don't think that littlevgl is such an essential or stable package yet.
> 
> Sure.
> 
>> Currently I know of exactly one project using this repository and that's
>> only because I added it.
> 
> I have used it successfully however not on RTEMS. It is great to use.
> 
> Chris

Yes, you pointed me toward it last year. It's a nice library. I meant
that I know exactly one project using the rtems-littlevgl repository. In
this project I'll most likely not use a release version but track the
master instead. So I don't think that it's necessary to put effort into
including rtems-littlevgl into this release.

Best regards

Christian
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Failures on Overnight build sweep

[Christian Mauderer]

On 06/04/2020 13:59, Christian Mauderer wrote:
> On 06/04/2020 01:40, Chris Johns wrote:
>> On 2020-04-06 09:11, Joel Sherrill wrote:
>>> On Sun, Apr 5, 2020, 5:55 PM Chris Johns >> <mailto:chr...@rtems.org>> wrote:
>>>
>>>     On 2020-04-06 05:04, Christian Mauderer wrote:
>>>  > libbsd on raspberry should work again since yesterday (if you
>>>     refer to
>>>  > that ticket: https://devel.rtems.org/ticket/3903).
>>>
>>>     Did the libbsd config in the RSB get updated?
>>>
>>> I have no idea. Someone who is fixing issues in libbsd should check
>>> that and ensure the RSB reflects the best state of the world.
>>> Otherwise, my testing is a huge HUGE waste of time.
>>>
>>> Ditto for rtems-tools fixes and other repos. If you fix something,
>>> bump hashes
>>
>> It might be the rtems-kernel that needs to be update 
>>
>> https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-5.cfg
> 
> Hello Joel and Chris,
> 
> sorry I missed to update that. I'll check it and send a patch for review.
> 
> Best regards
> 
> Christian

I checked it: Chris pulled that one in together with the reverted commit
from Sebastian today at about 7:00 UTC. So both patches are included in
current RSB master.

Sorry for missing that step. It's something normally not really
necessary during normal development (except if we really want to have a
commit for every RTEMS commit) and I'm still not aware of a lot of stuff
that is touched by the release.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd v2 13/14] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

[Christian Mauderer]

This is not a nice solution but it should work on all chips. As soon as
FreeBSD has a nice solution via the USB PHY driver, this should be
replaced.

Update #3869.
---
 freebsd/sys/dev/usb/controller/ehci_imx.c | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
b/freebsd/sys/dev/usb/controller/ehci_imx.c
index d158df1d..544a63b5 100644
--- a/freebsd/sys/dev/usb/controller/ehci_imx.c
+++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
@@ -50,6 +50,9 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
 #include 
 #include 
@@ -270,6 +273,9 @@ struct imx_ehci_softc {
device_tdev;
struct resource *ehci_mem_res;  /* EHCI core regs. */
struct resource *ehci_irq_res;  /* EHCI core IRQ. */ 
+#ifdef __rtems__
+   void*phy_regs;
+#endif /* __rtems__ */
 };
 
 static struct ofw_compat_data compat_data[] = {
@@ -380,6 +386,32 @@ imx_ehci_disable_oc(struct imx_ehci_softc *sc)
index = usbmprops[1];
imx_usbmisc_set_ctrl(usbmdev, index, USBNC_OVER_CUR_DIS);
 }
+#ifdef __rtems__
+#define BUS_SPACE_PHYSADDR(res, offs) \
+   ((u_int)(rman_get_start(res)+(offs)))
+
+static uint16_t
+imx_ehci_get_port_speed_portsc(struct ehci_softc *sc, uint16_t index)
+{
+   uint32_t v;
+   struct imx_ehci_softc *isc = (struct imx_ehci_softc *)sc;
+
+   v = ehci_get_port_speed_portsc(sc, index);
+
+   /* Set/clear ENHOSTDISCONDETECT in USBPHY CTRL register */
+   /* FIXME: This is a very hacky method. It should be done by the phy
+* driver instead. */
+   volatile uint32_t *ctrl_set = isc->phy_regs + 0x34;
+   volatile uint32_t *ctrl_clr = isc->phy_regs + 0x38;
+   if (v == UPS_HIGH_SPEED) {
+   *ctrl_set = 0x2;
+   } else {
+   *ctrl_clr = 0x2;
+   }
+
+   return (v);
+}
+#endif /* __rtems__ */
 
 static int
 imx_ehci_attach(device_t dev)
@@ -474,6 +506,33 @@ imx_ehci_attach(device_t dev)
esc->sc_flags |= EHCI_SCFLG_NORESTERM | EHCI_SCFLG_TT;
esc->sc_vendor_post_reset = imx_ehci_post_reset;
esc->sc_vendor_get_port_speed = ehci_get_port_speed_portsc;
+#ifdef __rtems__
+   /*
+* FIXME: This is a big hack to get the PHY regs and set one bit during
+* changes of the port speed.
+*/
+   sc->phy_regs = 0;
+   if (OF_hasprop(ofw_bus_get_node(sc->dev), "fsl,usbphy")) {
+   phandle_t *cells;
+   int len;
+   phandle_t phynode;
+
+   cells = NULL;
+   len = OF_getencprop_alloc_multi(ofw_bus_get_node(sc->dev),
+   "fsl,usbphy", sizeof(*cells), (void **));
+   if (len > 0
+   && (phynode = OF_node_from_xref(cells[0])) != -1 &&
+   ofw_bus_node_is_compatible(phynode, "fsl,imx6ul-usbphy")) {
+   u_long base, size;
+   if (fdt_regsize(phynode, , ) == 0) {
+   sc->phy_regs = (void*)base;
+   esc->sc_vendor_get_port_speed =
+   imx_ehci_get_port_speed_portsc;
+   }
+   }
+   OF_prop_free(cells);
+   }
+#endif /* __rtems__ */
 
err = ehci_init(esc);
if (err != 0) {
-- 
2.16.4

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

[PATCH rtems-libbsd v2 10/14] ehci_imx: Import from FreeBSD

[Christian Mauderer]

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 212 
 freebsd/sys/dev/usb/controller/ehci_imx.c   | 516 
 2 files changed, 728 insertions(+)
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_usbphy.c
 create mode 100644 freebsd/sys/dev/usb/controller/ehci_imx.c

diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c 
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
new file mode 100644
index ..8f47507b
--- /dev/null
+++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
@@ -0,0 +1,212 @@
+#include 
+
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2013 Ian Lepore 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+/*
+ * USBPHY driver for Freescale i.MX6 family of SoCs.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * Hardware register defines.
+ */
+#definePWD_REG 0x
+#defineCTRL_STATUS_REG 0x0030
+#defineCTRL_SET_REG0x0034
+#defineCTRL_CLR_REG0x0038
+#defineCTRL_TOGGLE_REG 0x003c
+#define  CTRL_SFTRST (1U << 31)
+#define  CTRL_CLKGATE(1 << 30)
+#define  CTRL_ENUTMILEVEL3   (1 << 15)
+#define  CTRL_ENUTMILEVEL2   (1 << 14)
+
+struct usbphy_softc {
+   device_tdev;
+   struct resource *mem_res;
+   u_int   phy_num;
+};
+
+static struct ofw_compat_data compat_data[] = {
+   {"fsl,imx6q-usbphy",true},
+   {"fsl,imx6ul-usbphy",   true},
+   {NULL,  false}
+};
+
+static int
+usbphy_detach(device_t dev)
+{
+   struct usbphy_softc *sc;
+
+   sc = device_get_softc(dev);
+
+   if (sc->mem_res != NULL)
+   bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);
+
+   return (0);
+}
+
+static int
+usbphy_attach(device_t dev)
+{
+   struct usbphy_softc *sc;
+   int err, regoff, rid;
+
+   sc = device_get_softc(dev);
+   err = 0;
+
+   /* Allocate bus_space resources. */
+   rid = 0;
+   sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, ,
+   RF_ACTIVE);
+   if (sc->mem_res == NULL) {
+   device_printf(dev, "Cannot allocate memory resources\n");
+   err = ENXIO;
+   goto out;
+   }
+
+   /*
+* XXX Totally lame way to get the unit number (but not quite as lame as
+* adding an ad-hoc property to the fdt data).  This works as long as
+* this driver is used for imx6 only.
+*/
+   const uint32_t PWD_PHY1_REG_PHYSADDR = 0x020c9000;
+   if (BUS_SPACE_PHYSADDR(sc->mem_res, 0) == PWD_PHY1_REG_PHYSADDR) {
+   sc->phy_num = 0;
+   regoff = 0;
+   } else {
+   sc->phy_num = 1;
+   regoff = 0x60;
+   }
+
+   /*
+* Based on a note in the u-boot source code, disable charger detection
+* to avoid degrading the differential signaling on the DP line.  Note
+* that this disables (by design) both charger detection and contact
+* detection, because of the screwball mix of active-high and active-low
+* bits in this register.
+*/
+   imx6_anatop_write_4(IMX6_ANALOG_USB1_CHRG_DETECT + regoff, 
+   IMX6_ANALOG_USB_CHRG_DETECT_N_ENABLE | 
+   IMX6_ANALOG_USB_CHRG_DETECT_N_CHK_CHRG);
+
+   

[PATCH rtems-libbsd v2 07/14] regulator: Add to build.

[Christian Mauderer]

Update #3869.
---
 Makefile.todo |  26 ++
 buildset/default.ini  |   1 +
 libbsd.py |  30 +++
 rtemsbsd/include/bsp/nexus-devices.h  |   3 +
 rtemsbsd/include/rtems/bsd/local/regdev_if.h  |  36 
 rtemsbsd/include/rtems/bsd/local/regnode_if.h | 121 ++
 rtemsbsd/local/regdev_if.c|  27 ++
 rtemsbsd/local/regnode_if.c   |  56 
 8 files changed, 300 insertions(+)
 create mode 100644 rtemsbsd/include/rtems/bsd/local/regdev_if.h
 create mode 100644 rtemsbsd/include/rtems/bsd/local/regnode_if.h
 create mode 100644 rtemsbsd/local/regdev_if.c
 create mode 100644 rtemsbsd/local/regnode_if.c

diff --git a/Makefile.todo b/Makefile.todo
index 59e630e1..a05716ef 100644
--- a/Makefile.todo
+++ b/Makefile.todo
@@ -45,6 +45,10 @@ GENERATED += $(LOCAL_INC)/sdhci_if.h
 GENERATED += $(LOCAL_SRC)/sdhci_if.c
 GENERATED += $(LOCAL_INC)/gpiobus_if.h
 GENERATED += $(LOCAL_SRC)/gpiobus_if.c
+GENERATED += $(LOCAL_INC)/regdev_if.h
+GENERATED += $(LOCAL_SRC)/regdev_if.c
+GENERATED += $(LOCAL_INC)/regnode_if.h
+GENERATED += $(LOCAL_SRC)/regnode_if.c
 GENERATED += rtemsbsd/include/machine/rtems-bsd-regdomain.h
 GENERATED += rtemsbsd/rtems/rtems-bsd-regdomain.c
 GENERATED += freebsd/contrib/libpcap/pcap_version.h
@@ -231,6 +235,28 @@ $(LOCAL_SRC)/gpio_if.c: 
$(FREEBSD_SRC)/sys/dev/gpio/gpio_if.m
awk -f $(TOOLS)/makeobjops.awk $< -c
mv gpio_if.c $@
 
+$(LOCAL_INC)/regnode_if.h: $(FREEBSD_SRC)/sys/dev/extres/regulator/regnode_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -h
+   mv regnode_if.h $@
+
+$(LOCAL_SRC)/regnode_if.c: $(FREEBSD_SRC)/sys/dev/extres/regulator/regnode_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -c
+   sed -i regnode_if.c \
+   -e '1 i\#include \n' \
+   -e 's|#include "regnode_if.h"|#include 
|'
+   mv regnode_if.c $@
+
+$(LOCAL_INC)/regdev_if.h: $(FREEBSD_SRC)/sys/dev/extres/regulator/regdev_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -h
+   mv regdev_if.h $@
+
+$(LOCAL_SRC)/regdev_if.c: $(FREEBSD_SRC)/sys/dev/extres/regulator/regdev_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -c
+   sed -i regdev_if.c \
+   -e '1 i\#include \n' \
+   -e 's|#include "regdev_if.h"|#include 
|'
+   mv regdev_if.c $@
+
 $(LOCAL_SRC)/rtwn-rtl8192cfwT.c: 
$(FREEBSD_SRC)/sys/contrib/dev/rtwn/rtwn-rtl8192cfwT.fw.uu
uudecode -o /dev/stdout $< | python firmware-gen.py \
-l "$(FREEBSD_SRC)/sys/contrib/dev/rtwn/LICENSE" \
diff --git a/buildset/default.ini b/buildset/default.ini
index ac8c9c48..b17f2b59 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -54,6 +54,7 @@ nvme = on
 opencrypto = on
 pci = on
 pf = on
+regulator = on
 rtems = on
 tests = on
 tty = on
diff --git a/libbsd.py b/libbsd.py
index e0690601..4f8fb4d2 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5032,6 +5032,35 @@ class imx(builder.Module):
 mm.generator['source']()
 )
 
+class regulator(builder.Module):
+def __init__(self, manager):
+super(regulator, self).__init__(manager, type(self).__name__)
+
+def generate(self):
+mm = self.manager
+self.addRTEMSSourceFiles(
+[
+'local/regdev_if.c',
+'local/regnode_if.c',
+],
+mm.generator['source']()
+)
+self.addKernelSpaceHeaderFiles(
+[
+'sys/dev/extres/regulator/regulator.h',
+'sys/dev/extres/regulator/regulator_fixed.h',
+]
+)
+self.addKernelSpaceSourceFiles(
+[
+'sys/dev/extres/regulator/regulator.c',
+'sys/dev/extres/regulator/regulator_bus.c',
+'sys/dev/extres/regulator/regulator_fixed.c',
+'sys/dev/gpio/gpioregulator.c',
+],
+mm.generator['source']()
+)
+
 #
 # Tests
 #
@@ -5189,6 +5218,7 @@ def load(mm):
 
 mm.addModule(nvme(mm))
 mm.addModule(imx(mm))
+mm.addModule(regulator(mm))
 
 # Add in_chksum
 mm.addModule(in_cksum(mm))
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 92665409..0a210bd9 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -136,6 +136,9 @@ SYSINIT_DRIVER_REFERENCE(imx51_gpio, simplebus);
 SYSINIT_DRIVER_REFERENCE(sdhci_fsl, simplebus);
 RTEMS_BSD_DRIVER_MMC;
 
+SYSINIT_DRIVER_REFERENCE(ofw_regulator_bus, simplebus);
+SYSINIT_DRIVER_REFERENCE(gpioregulator, simplebus);
+
 #elif defined(LIBBSP_ARM_LPC24XX_BSP_H)
 
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(ohci, 0, 0, NULL);
diff --git a/rtemsbsd/include/rtems/bsd/local/regdev_if.h 
b/rtemsbsd/include/rtems/bsd/local/regdev_if.h
new file mode 100644
index ..4a75810f
--- /dev/null
+++ b/rtemsbsd/include/rtems/bsd/local/regdev_if.h
@@ -0,0 +1,36 

[PATCH rtems-libbsd v2 03/14] imx6_ccm: Port to RTEMS

[Christian Mauderer]

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_ccm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index 2993f1d6..cef79933 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -92,6 +92,7 @@ WR4(struct ccm_softc *sc, bus_size_t off, uint32_t val)
 static void
 ccm_init_gates(struct ccm_softc *sc)
 {
+#ifndef __rtems__
uint32_t reg;
 
/* ahpbdma, aipstz 1 & 2 buses */
@@ -129,6 +130,7 @@ ccm_init_gates(struct ccm_softc *sc)
reg = CCGR6_USBOH3 | CCGR6_USDHC1 | CCGR6_USDHC2 |
CCGR6_USDHC3 | CCGR6_USDHC4;
WR4(sc, CCM_CCGR6, reg);
+#endif /* __rtems__ */
 }
 
 static int
@@ -204,7 +206,12 @@ ccm_probe(device_t dev)
if (!ofw_bus_status_okay(dev))
return (ENXIO);
 
+#ifndef __rtems__
 if (ofw_bus_is_compatible(dev, "fsl,imx6q-ccm") == 0)
+#else /* __rtems__ */
+if (ofw_bus_is_compatible(dev, "fsl,imx6q-ccm") == 0 &&
+   ofw_bus_is_compatible(dev, "fsl,imx6ul-ccm") == 0)
+#endif /* __rtems__ */
return (ENXIO);
 
device_set_desc(dev, "Freescale i.MX6 Clock Control Module");
-- 
2.16.4

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

[PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD.

[Christian Mauderer]

Update #3869.
---
 freebsd/sys/dev/extres/regulator/regulator.c   | 1321 
 freebsd/sys/dev/extres/regulator/regulator.h   |  156 +++
 freebsd/sys/dev/extres/regulator/regulator_bus.c   |   89 ++
 freebsd/sys/dev/extres/regulator/regulator_fixed.c |  502 
 freebsd/sys/dev/extres/regulator/regulator_fixed.h |   44 +
 freebsd/sys/dev/gpio/gpioregulator.c   |  350 ++
 6 files changed, 2462 insertions(+)
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator.c
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator.h
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator_bus.c
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.c
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.h
 create mode 100644 freebsd/sys/dev/gpio/gpioregulator.c

diff --git a/freebsd/sys/dev/extres/regulator/regulator.c 
b/freebsd/sys/dev/extres/regulator/regulator.c
new file mode 100644
index ..4ad6e94a
--- /dev/null
+++ b/freebsd/sys/dev/extres/regulator/regulator.c
@@ -0,0 +1,1321 @@
+#include 
+
+/*-
+ * Copyright 2016 Michal Meloun 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef FDT
+#include 
+#include 
+#include 
+#endif
+#include 
+
+#include 
+
+SYSCTL_NODE(_hw, OID_AUTO, regulator, CTLFLAG_RD, NULL, "Regulators");
+
+MALLOC_DEFINE(M_REGULATOR, "regulator", "Regulator framework");
+
+#defineDIV_ROUND_UP(n,d) howmany(n, d)
+
+/* Forward declarations. */
+struct regulator;
+struct regnode;
+
+typedef TAILQ_HEAD(regnode_list, regnode) regnode_list_t;
+typedef TAILQ_HEAD(regulator_list, regulator) regulator_list_t;
+
+/* Default regulator methods. */
+static int regnode_method_init(struct regnode *regnode);
+static int regnode_method_enable(struct regnode *regnode, bool enable,
+int *udelay);
+static int regnode_method_status(struct regnode *regnode, int *status);
+static int regnode_method_set_voltage(struct regnode *regnode, int min_uvolt,
+int max_uvolt, int *udelay);
+static int regnode_method_get_voltage(struct regnode *regnode, int *uvolt);
+static void regulator_constraint(void *dummy);
+static void regulator_shutdown(void *dummy);
+
+/*
+ * Regulator controller methods.
+ */
+static regnode_method_t regnode_methods[] = {
+   REGNODEMETHOD(regnode_init, regnode_method_init),
+   REGNODEMETHOD(regnode_enable,   regnode_method_enable),
+   REGNODEMETHOD(regnode_status,   regnode_method_status),
+   REGNODEMETHOD(regnode_set_voltage,  regnode_method_set_voltage),
+   REGNODEMETHOD(regnode_get_voltage,  regnode_method_get_voltage),
+   REGNODEMETHOD(regnode_check_voltage,regnode_method_check_voltage),
+
+   REGNODEMETHOD_END
+};
+DEFINE_CLASS_0(regnode, regnode_class, regnode_methods, 0);
+
+/*
+ * Regulator node - basic element for modelling SOC and bard power supply
+ * chains. Its contains producer data.
+ */
+struct regnode {
+   KOBJ_FIELDS;
+
+   TAILQ_ENTRY(regnode)reglist_link;   /* Global list entry */
+   regulator_list_tconsumers_list; /* Consumers list */
+
+   /* Cache for already resolved names */
+   struct regnode  *parent;/* Resolved parent */
+
+   /* Details of this device. */
+   const char  *name;  /* Globally unique name */
+   const char  *parent_name;   /* Parent name */
+
+   device_tpdev;   /* Producer device_t */
+  

[PATCH rtems-libbsd v2 02/14] imx6_ccm: Import from FreeBSD

[Christian Mauderer]

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_anatopreg.h | 193 ++
 freebsd/sys/arm/freescale/imx/imx6_anatopvar.h |  49 +++
 freebsd/sys/arm/freescale/imx/imx6_ccm.c   | 468 +
 freebsd/sys/arm/freescale/imx/imx6_ccmreg.h| 149 
 freebsd/sys/arm/freescale/imx/imx6_machdep.h   |  38 ++
 freebsd/sys/arm/freescale/imx/imx_machdep.h|  72 
 6 files changed, 969 insertions(+)
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_anatopreg.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_anatopvar.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_ccm.c
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_ccmreg.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_machdep.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx_machdep.h

diff --git a/freebsd/sys/arm/freescale/imx/imx6_anatopreg.h 
b/freebsd/sys/arm/freescale/imx/imx6_anatopreg.h
new file mode 100644
index ..e8269526
--- /dev/null
+++ b/freebsd/sys/arm/freescale/imx/imx6_anatopreg.h
@@ -0,0 +1,193 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2013 Ian Lepore 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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.
+ *
+ * $FreeBSD$
+ */
+
+#ifndefIMX6_ANATOPREG_H
+#defineIMX6_ANATOPREG_H
+
+#defineIMX6_ANALOG_CCM_PLL_ARM 0x000
+#defineIMX6_ANALOG_CCM_PLL_ARM_SET 0x004
+#defineIMX6_ANALOG_CCM_PLL_ARM_CLR 0x008
+#defineIMX6_ANALOG_CCM_PLL_ARM_TOG 0x00C
+#define  IMX6_ANALOG_CCM_PLL_ARM_DIV_MASK0x7F
+#define  IMX6_ANALOG_CCM_PLL_ARM_LOCK(1U << 31)
+#define  IMX6_ANALOG_CCM_PLL_ARM_BYPASS  (1 << 16)
+#define  IMX6_ANALOG_CCM_PLL_ARM_CLK_SRC_MASK(0x03 << 16)
+#defineIMX6_ANALOG_CCM_PLL_USB10x010
+#defineIMX6_ANALOG_CCM_PLL_USB1_SET0x014
+#defineIMX6_ANALOG_CCM_PLL_USB1_CLR0x018
+#defineIMX6_ANALOG_CCM_PLL_USB1_TOG0x01C
+#define   IMX6_ANALOG_CCM_PLL_USB_LOCK   (1U << 31)
+#define   IMX6_ANALOG_CCM_PLL_USB_BYPASS (1 << 16)
+#define   IMX6_ANALOG_CCM_PLL_USB_ENABLE (1 << 13)
+#define   IMX6_ANALOG_CCM_PLL_USB_POWER  (1 << 12)
+#define   IMX6_ANALOG_CCM_PLL_USB_EN_USB_CLKS(1 <<  6)
+#defineIMX6_ANALOG_CCM_PLL_USB20x020
+#defineIMX6_ANALOG_CCM_PLL_USB2_SET0x024
+#defineIMX6_ANALOG_CCM_PLL_USB2_CLR0x028
+#defineIMX6_ANALOG_CCM_PLL_USB2_TOG0x02C
+#defineIMX6_ANALOG_CCM_PLL_SYS 0x030
+#defineIMX6_ANALOG_CCM_PLL_SYS_SET 0x034
+#defineIMX6_ANALOG_CCM_PLL_SYS_CLR 0x038
+#defineIMX6_ANALOG_CCM_PLL_SYS_TOG 0x03C
+#defineIMX6_ANALOG_CCM_PLL_SYS_SS  0x040
+#defineIMX6_ANALOG_CCM_PLL_SYS_NUM 0x050
+#defineIMX6_ANALOG_CCM_PLL_SYS_DENOM   0x060
+#defineIMX6_ANALOG_CCM_PLL_AUDIO   0x070
+#define   IMX6_ANALOG_CCM_PLL_AUDIO_ENABLE   (1 << 13)
+#define   IMX6_ANALOG_CCM_PLL_AUDIO_DIV_SELECT_SHIFT 0
+#define   IMX6_ANALOG_CCM_PLL_AUDIO_DIV_SELECT_MASK  0x7f
+#defineIMX6_ANALOG_CCM_PLL_AUDIO_SET   0x074
+#define

[PATCH rtems-libbsd v2 12/14] ehci_imx: Add to build.

[Christian Mauderer]

---
 libbsd.py| 2 ++
 rtemsbsd/include/bsp/nexus-devices.h | 5 +
 2 files changed, 7 insertions(+)

diff --git a/libbsd.py b/libbsd.py
index 4f8fb4d2..ed6493b2 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5028,6 +5028,8 @@ class imx(builder.Module):
 self.addKernelSpaceSourceFiles(
 [
 'sys/arm/freescale/imx/imx6_ccm.c',
+'sys/arm/freescale/imx/imx6_usbphy.c',
+'sys/dev/usb/controller/ehci_imx.c',
 ],
 mm.generator['source']()
 )
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 0a210bd9..d2ceab8e 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -128,6 +128,11 @@ RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
 
 SYSINIT_DRIVER_REFERENCE(ccm, simplebus);
+SYSINIT_DRIVER_REFERENCE(ehci, simplebus);
+SYSINIT_DRIVER_REFERENCE(usbphy, simplebus);
+SYSINIT_DRIVER_REFERENCE(usbus, ehci);
+RTEMS_BSD_DRIVER_USB;
+RTEMS_BSD_DRIVER_USB_MASS;
 
 SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
-- 
2.16.4

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

[PATCH rtems-libbsd v2 11/14] ehci_imx: Port to RTEMS

[Christian Mauderer]

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 11 +++
 freebsd/sys/dev/usb/controller/ehci_imx.c   | 12 
 2 files changed, 23 insertions(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c 
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
index 8f47507b..ad545601 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
@@ -91,6 +91,17 @@ usbphy_detach(device_t dev)
return (0);
 }
 
+#ifdef __rtems__
+#define BUS_SPACE_PHYSADDR(res, offs) \
+   ((u_int)(rman_get_start(res)+(offs)))
+
+void
+imx6_anatop_write_4(bus_size_t offset, uint32_t value)
+{
+
+   bus_space_write_4(0, 0x20c8000, offset, value);
+}
+#endif /* __rtems__ */
 static int
 usbphy_attach(device_t dev)
 {
diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
b/freebsd/sys/dev/usb/controller/ehci_imx.c
index a872fb62..d158df1d 100644
--- a/freebsd/sys/dev/usb/controller/ehci_imx.c
+++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
@@ -303,6 +303,16 @@ imx_ehci_probe(device_t dev)
return (ENXIO);
 
if (ofw_bus_search_compatible(dev, compat_data)->ocd_data != 0) {
+#ifdef __rtems__
+   char dr_mode[24];
+
+   if (OF_getprop(ofw_bus_get_node(dev), "dr_mode",
+   _mode, sizeof(dr_mode)) > 0 &&
+   strcasecmp(dr_mode, "host") != 0) {
+   return (ENXIO);
+   }
+#endif /* __rtems__ */
+
device_set_desc(dev, "Freescale i.MX integrated USB 
controller");
return (BUS_PROBE_DEFAULT);
}
@@ -437,8 +447,10 @@ imx_ehci_attach(device_t dev)
goto out;
}
 
+#ifndef __rtems__
/* Turn on clocks. */
imx_ccm_usb_enable(dev);
+#endif /* __rtems__ */
 
/* Disable overcurrent detection, if configured to do so. */
if (OF_hasprop(ofw_bus_get_node(sc->dev), "disable-over-current"))
-- 
2.16.4

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

[PATCH rtems-libbsd v2 01/14] usb_busdma: Add USB_NEED_BUSDMA_COHERENT_ALLOC

[Christian Mauderer]

From: Sebastian Huber 

Some BSPs have a cache-coherent memory area, however, it should not be
used for the USB controller.
---
 freebsd/sys/dev/usb/usb_busdma.c   | 4 
 rtemsbsd/include/rtems/bsd/local/opt_usb.h | 5 +
 2 files changed, 9 insertions(+)

diff --git a/freebsd/sys/dev/usb/usb_busdma.c b/freebsd/sys/dev/usb/usb_busdma.c
index 9a70c687..dc52fe15 100644
--- a/freebsd/sys/dev/usb/usb_busdma.c
+++ b/freebsd/sys/dev/usb/usb_busdma.c
@@ -584,7 +584,11 @@ usb_pc_alloc_mem(struct usb_page_cache *pc, struct 
usb_page *pg,
}
/* allocate memory */
if (bus_dmamem_alloc(
+#if !defined(__rtems__) || USB_NEED_BUSDMA_COHERENT_ALLOC
utag->tag, , (BUS_DMA_WAITOK | BUS_DMA_COHERENT), )) {
+#else /* __rtems__ */
+   utag->tag, , BUS_DMA_WAITOK, )) {
+#endif /* __rtems__ */
goto error;
}
/* setup page cache */
diff --git a/rtemsbsd/include/rtems/bsd/local/opt_usb.h 
b/rtemsbsd/include/rtems/bsd/local/opt_usb.h
index 809a969f..9f654863 100644
--- a/rtemsbsd/include/rtems/bsd/local/opt_usb.h
+++ b/rtemsbsd/include/rtems/bsd/local/opt_usb.h
@@ -1,4 +1,5 @@
 #include 
+#include 
 
 #define USB_HAVE_CONDVAR 1
 
@@ -6,6 +7,10 @@
 
 #define USB_HAVE_BUSDMA 1
 
+#if !defined(LIBBSP_ARM_IMX_BSP_H) && !defined(LIBBSP_ARM_STM32H7_BSP_H)
+#define USB_NEED_BUSDMA_COHERENT_ALLOC 1
+#endif
+
 #define USB_HAVE_COMPAT_LINUX 0
 
 #define USB_HAVE_USER_IO 0
-- 
2.16.4

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

[PATCH rtems-libbsd v2 05/14] imx gpio port

[Christian Mauderer]

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx_gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx_gpio.c 
b/freebsd/sys/arm/freescale/imx/imx_gpio.c
index f5b476d7..7dd49e3f 100644
--- a/freebsd/sys/arm/freescale/imx/imx_gpio.c
+++ b/freebsd/sys/arm/freescale/imx/imx_gpio.c
@@ -125,6 +125,7 @@ struct imx51_gpio_softc {
 
 static struct ofw_compat_data compat_data[] = {
 #ifdef __rtems__
+   {"fsl,imx35-gpio",  1},
{"fsl,imx7d-gpio",  1},
 #endif /* __rtems__ */
{"fsl,imx6q-gpio",  1},
-- 
2.16.4

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

[PATCH rtems-docs v2] user/imx: Add i.MX6UL/ULL.

[Christian Mauderer]

Update #3869
---
 user/bsps/arm/imx.rst | 47 ---
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index bc93ae3..ee98f0b 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -7,9 +7,10 @@ imx (NXP i.MX)
 ==
 
 This BSP offers only one variant, the `imx7`.  This variant supports the i.MX
-7Dual processor.  The basic hardware initialization is not performed by the
-BSP.  A boot loader with device tree support must be used to start the BSP,
-e.g. U-Boot.
+7Dual processor and the i.MX 6UL/ULL processor family (with slightly different
+clock settings).  The basic hardware initialization is not performed by the 
BSP.
+A boot loader with device tree support must be used to start the BSP, e.g.
+U-Boot or barebox.
 
 Build Configuration Options
 ---
@@ -40,9 +41,30 @@ The following options are available at the configure command 
line.
 ``IMX_CCM_UART_HZ``
The UART clock frequency in Hz (default is 2400).
 
+``IMX_CCM_ECSPI_HZ``
+   The ECSPI clock frequency in Hz (default is 6750).
+
 ``IMX_CCM_AHB_HZ``
The AHB clock frequency in Hz (default is 13500).
 
+``IMX_CCM_SDHCI_HZ``
+   The SDHCI clock frequency in Hz (default is 196363000).
+
+Clock settings for different boards
+---
+
+The default clock settings are targeted for an i.MX 7Dual evaluation board 
using
+U-Boot. Some other boards with different boot loaders need different settings:
+
+ * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
+   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
+
+   * IMX_CCM_IPG_HZ=6600
+   * IMX_CCM_UART_HZ=8000
+   * IMX_CCM_AHB_HZ=6600
+   * IMX_CCM_SDHCI_HZ=19800
+   * IMX_CCM_ECSPI_HZ=6000
+
 Boot via U-Boot
 ---
 
@@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your U-Boot 
environment.  Just
 replace it with the appropriate commands to load the device tree at
 ``${fdt_addr}``.
 
+Boot via barebox
+
+
+The same command like for U-Boot can be used to generate an application image.
+In a default configuration barebox expects an fdt image called `oftree` and a
+kernel image called `zImage` in the root folder of the bootable medium (e.g. an
+SD card).
+
 Clock Driver
 
 
@@ -133,6 +163,17 @@ system controls:
 A value of zero for the time or count disables the interrupt coalescing in the
 corresponding direction.
 
+On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for the
+clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
libbsd
+config like that:
+
+.. code-block:: c
+
+#define RTEMS_BSD_CONFIG_BSP_CONFIG
+#define RTEMS_BSD_CONFIG_INIT
+SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
+#include 
+
 MMC/SDCard Driver
 -
 
-- 
2.16.4

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

[PATCH rtems-libbsd v2 04/14] imx6_ccm: Add and build module.

[Christian Mauderer]

Update #3869.
---
 buildset/default.ini |  1 +
 libbsd.py| 23 +++
 rtemsbsd/include/bsp/nexus-devices.h |  2 ++
 3 files changed, 26 insertions(+)

diff --git a/buildset/default.ini b/buildset/default.ini
index 43ea82a3..ac8c9c48 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -40,6 +40,7 @@ dhcpcd = on
 dpaa = on
 evdev = on
 fdt = on
+imx = on
 in_cksum = on
 mdnsresponder = on
 mmc = on
diff --git a/libbsd.py b/libbsd.py
index d791efe4..e0690601 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5010,6 +5010,28 @@ class dpaa(builder.Module):
 mm.generator['source']()
 )
 
+class imx(builder.Module):
+def __init__(self, manager):
+super(imx, self).__init__(manager, type(self).__name__)
+
+def generate(self):
+mm = self.manager
+self.addKernelSpaceHeaderFiles(
+[
+'sys/arm/freescale/imx/imx6_anatopreg.h',
+'sys/arm/freescale/imx/imx6_anatopvar.h',
+'sys/arm/freescale/imx/imx6_ccmreg.h',
+'sys/arm/freescale/imx/imx6_machdep.h',
+'sys/arm/freescale/imx/imx_machdep.h',
+]
+)
+self.addKernelSpaceSourceFiles(
+[
+'sys/arm/freescale/imx/imx6_ccm.c',
+],
+mm.generator['source']()
+)
+
 #
 # Tests
 #
@@ -5166,6 +5188,7 @@ def load(mm):
 mm.addModule(dev_nic_broadcomm(mm))
 
 mm.addModule(nvme(mm))
+mm.addModule(imx(mm))
 
 # Add in_chksum
 mm.addModule(in_cksum(mm))
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index a916c664..92665409 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -127,6 +127,8 @@ RTEMS_BSD_DRIVER_MMC;
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
 
+SYSINIT_DRIVER_REFERENCE(ccm, simplebus);
+
 SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 
-- 
2.16.4

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

[PATCH rtems-libbsd v2 09/14] bus-dma, imx: Don't sync nocache area.

[Christian Mauderer]

This area doesn't support all cache operations.

Update #3869.
---
 rtemsbsd/rtems/rtems-kernel-bus-dma.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/rtemsbsd/rtems/rtems-kernel-bus-dma.c 
b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
index 8c15e92b..8674bef1 100644
--- a/rtemsbsd/rtems/rtems-kernel-bus-dma.c
+++ b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
@@ -48,6 +48,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -396,6 +398,11 @@ bus_dmamap_sync(bus_dma_tag_t dmat, bus_dmamap_t map, 
bus_dmasync_op_t op)
uintptr_t size = map->buffer_size;
uintptr_t begin = (uintptr_t) map->buffer_begin;
uintptr_t end = begin + size;
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+   if (begin >= bsp_section_nocache_begin && end <= 
bsp_section_nocachenoload_end) {
+   return;
+   }
+#endif
 
if ((op & BUS_DMASYNC_PREWRITE) != 0 && (op & BUS_DMASYNC_PREREAD) == 
0) {
rtems_cache_flush_multiple_data_lines((void *) begin, size);
-- 
2.16.4

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

[PATCH rtems-libbsd v2 08/14] Add support for i.mx cache.

[Christian Mauderer]

Update #3869.
---
 rtemsbsd/include/machine/rtems-bsd-cache.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtemsbsd/include/machine/rtems-bsd-cache.h 
b/rtemsbsd/include/machine/rtems-bsd-cache.h
index bd496f9d..73b55e25 100755
--- a/rtemsbsd/include/machine/rtems-bsd-cache.h
+++ b/rtemsbsd/include/machine/rtems-bsd-cache.h
@@ -45,7 +45,7 @@
 #if defined(LIBBSP_ARM_LPC24XX_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) && 
defined(LPC32XX_DISABLE_MMU))
   /* No cache */
 #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H) || \
-  defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) 
&& !defined(LPC32XX_DISABLE_MMU))
+  defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) 
&& !defined(LPC32XX_DISABLE_MMU)) || defined(LIBBSP_ARM_IMX_BSP_H)
   /* With cache, no coherency support in hardware */
   #define CPU_DATA_CACHE_ALIGNMENT 32
 #elif defined(__GEN83xx_BSP_h)
-- 
2.16.4

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

[PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

Hello,

this patches are an update for

https://lists.rtems.org/pipermail/devel/2020-April/058863.html

The RTEMS and docs patch is rebased to the current master.

The libbsd patches are adapted to have the right order and include the
changes like discussed. This version is for the 5-freebsd-12 branch.
I'll adapt them for libbsd master and push them together as soon as I
have a go.

Best regards

Christian

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

[PATCH rtems v2] bsp/imx: Add an extra ecspi clock.

[Christian Mauderer]

Some imx chips or boards don't use the same frequency for ECSPI and IPG.

Update #3869
---
 bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h | 3 +++
 bsps/arm/imx/spi/imx-ecspi.c| 2 +-
 bsps/arm/imx/start/ccm.c| 5 +
 c/src/lib/libbsp/arm/imx/configure.ac   | 3 +++
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h 
b/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
index 5633de6f50..0f19d80813 100644
--- a/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
+++ b/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
@@ -48,6 +48,9 @@ uint32_t imx_ccm_perclk_hz(void);
 uint32_t imx_ccm_sdhci_hz(void);
 uint32_t imx_ccm_uart_hz(void);
 uint32_t imx_ccm_ahb_hz(void);
+#ifdef __rtems__
+uint32_t imx_ccm_ecspi_hz(void);
+#endif /* __rtems__ */
 
 #ifndef __rtems__
 void imx_ccm_usb_enable(device_t _usbdev);
diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index 4c4978cdac..a18047f2e0 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -435,7 +435,7 @@ int spi_bus_register_imx(const char *bus_path, const char 
*alias_or_path)
 return -1;
   }
 
-  bus->base.max_speed_hz = imx_ccm_ipg_hz();
+  bus->base.max_speed_hz = imx_ccm_ecspi_hz();
   bus->base.delay_usecs = 1;
   bus->regs = imx_get_reg_of_node(fdt, node);
   bus->irq = imx_get_irq_of_node(fdt, node, 0);
diff --git a/bsps/arm/imx/start/ccm.c b/bsps/arm/imx/start/ccm.c
index cc93dcbd5d..3487470357 100644
--- a/bsps/arm/imx/start/ccm.c
+++ b/bsps/arm/imx/start/ccm.c
@@ -27,6 +27,11 @@ uint32_t imx_ccm_uart_hz(void)
   return IMX_CCM_UART_HZ;
 }
 
+uint32_t imx_ccm_ecspi_hz(void)
+{
+  return IMX_CCM_ECSPI_HZ;
+}
+
 uint32_t imx_ccm_ahb_hz(void)
 {
   return IMX_CCM_AHB_HZ;
diff --git a/c/src/lib/libbsp/arm/imx/configure.ac 
b/c/src/lib/libbsp/arm/imx/configure.ac
index aa119b9236..fbb9d9278a 100644
--- a/c/src/lib/libbsp/arm/imx/configure.ac
+++ b/c/src/lib/libbsp/arm/imx/configure.ac
@@ -43,6 +43,9 @@ RTEMS_BSPOPTS_HELP([IMX_CCM_IPG_HZ],[IPG clock frequency in 
Hz])
 RTEMS_BSPOPTS_SET([IMX_CCM_UART_HZ],[*],[2400])
 RTEMS_BSPOPTS_HELP([IMX_CCM_UART_HZ],[UART clock frequency in Hz])
 
+RTEMS_BSPOPTS_SET([IMX_CCM_ECSPI_HZ],[*],[6750])
+RTEMS_BSPOPTS_HELP([IMX_CCM_ECSPI_HZ],[ECSPI clock frequency in Hz])
+
 RTEMS_BSPOPTS_SET([IMX_CCM_AHB_HZ],[*],[13500])
 RTEMS_BSPOPTS_HELP([IMX_CCM_AHB_HZ],[AHB clock frequency in Hz])
 
-- 
2.16.4

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

Re: [PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

On 15/04/2020 15:56, Gedare Bloom wrote:
> Yes, go ahead and push them in.

Thanks. I pushed them. But now I have a small problem: I wanted to
update RSB to use the new versions (Chris said in another mail that it
should be up to date that near to a release). But I noted that I have no
idea what format is used for the hash. Currently
rtems/config/tools/rtems-kernel-5.cfg contains the following:


%define rtems_kernel_version01219541289e8081054d4a57924ee169339f1eaf
%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \

qJIBYkdFGRROoJlkmxRk5Ugr2IcrcWIlXH5FfuE88mecUkDDy4JBtFDXcH0YzjwyrpmlFSaaaK850nb4o89ZCA==


That's definitively not an unprocessed output of sha512sum. Can someone
help me?

Best regards

Christian

> 
> On Wed, Apr 15, 2020 at 12:07 AM Christian Mauderer
>  wrote:
>>
>> On 15/04/2020 07:06, Sebastian Huber wrote:
>>> Hello Christian,
>>>
>>> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
>>> bus-dma, imx: Don't sync nocache area.").
>>>
>>
>> Thanks.
>>
>> Chris, Gedare, Joel: Would it be OK for you if I push the patches before
>> the release?
>>
>> Best regards
>>
>> Christian
>> --
>> 
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.maude...@embedded-brains.de
>> Phone: +49-89-18 94 741 - 18
>> Fax:   +49-89-18 94 741 - 08
>> PGP: Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

Hello Niteesh,

On 05/05/2020 19:10, Niteesh G. S. wrote:
> This is thread is about implementing OFW functions in RTEMS as part
> of my GSoC project. I would like to start off with this part since the
> refactoring
> work will somewhat depend on this.

I'm not sure whether everyone on the list is already fully aware of what
your project is. For some of us the GSoC preparation phase is more of a
background noise. So maybe you want to give a short (only a few
sentences) overview of your target and what is the gain for the RTEMS
project.

> 
> Implementing these functions into RTEMS will make porting drivers from
> FreeBSD to RTEMS easy. Currently, the drivers ported from freebsd implement
> the functions using libfdt variants but this causes a lot of code
> duplication.
> eg: bsps/arm/imx/start/imx_iomux.c
> 
> My initial thoughts were to implement these functions one by one. But then
> Christian and Vijay mentioned about porting them from libbsd.

Yes, there has been an offlist discussion whether the approach of a
reimplementing them is a good idea.

> I went
> through the OFW code in libbsd and have described my porting process below.

If that can be ported, it would be a better approach then reimplementing.

> Please have a look at it and let me know if I have missed something or you
> would like to improve things.
> 
> The following files will be ported from libbsd
> prefix = freebsd/sys/dev/ofw
> /openfirm.c
> /openfirm.h
> /ofw_fdt.c
> /ofwvar.h
> 
> The main idea is to port openfirm.h but the other files are dependencies
> of openfirm.h
> 
> After going through some open firmware documentation. I guess as far as
> RTEMS is 
> concerned we could avoid many functions like OF_init, OF_putchar, OF_test
> and only care about functions defined under openfirm.h:105-142

OK. Note that these functions often have a "node". Think about what that
is and from where you would get it in an RTEMS driver. I think a lot of
FreeBSD drivers get it from their (logical) bus system like ofwbus.

> 
> But these functions have dependency on the automatically generated
> ofw_if.h and KOBJS.
> But after a close inspection, I guess the KOBJSLOOKUP macro in ofw_if.h
> can be
> redefined or replaced for RTEMS. Since all it does is call the
> respective functions defined in ofw_fdt_methods(ofw_fdt.c).

Note that the automatically generated interface is used for the FreeBSD
device driver structure (or rather the bus interface). If you port the
stuff to RTEMS you should think about whether

a) it should replace the libbsd stuff. In that case: What changes would
be necessary to libbsd.

b) or whether it should live side by side.

> 
> I had just spent a few hours going through the code. If I had missed
> something
> please let me know.
> 
> Thanks,
> Niteesh.

Best regards

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

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

Hello Niteesh,

On 07/05/2020 06:58, Niteesh G. S. wrote:
[...]
> Is there any chance that we will be working with the new build system
> for this GSoC project?

I think there is a good chance that the new build system will be added
soon. As far as I know, the current plan is to add it right after the
release. Especially Chris did an awesome work regarding the release and
there are only very few tickets left. Joel is also heavily involved in
testing. So I expect the release any day now.

> 
> I have a few doubts regarding the importing part.
> 
> 1) Say we are importing the openfirm code to RTEMS(rtems.git) then we will
> also have to bring in its dependencies like KOBJS which in turn has some
> other
> dependencies. And I am not really sure about this, but after looking at
> the libbsd
> code. This seems to bring in a huge amount of code into RTEMS. If this
> is what
> is going to happen then we could dump libbsd right?

I don't think that dumping libbsd should be a short term goal and I'm
not sure whether it can be a long term one. There is a lot more in
libbsd than just the bus system.

As a rough direction for now: libbsd was thought as a network and USB
stack. So you could say that simple and low-level peripherals (like GPIO
handling, serial ports, I2C, ...) are better in RTEMS and high-level
stuff and complex peripherals (like a firewall, VPN, TCP/IP, network
drivers, USB and SD drivers, ...) are better in libbsd.

I'm also not sure whether importing KOBJS is the right way. The
alternative would be to do the cut right there: Import the openfirm
parts but replace the parts where KOBJS would be used. Maybe you can
think about importing the ofw_fdt.c stuff too but add shortcuts.

The KOBJS would just look up which ofw_fdt_... functions would be
called. We currently don't have any other sources for this kind of
information then the FDT. So you could just map for example OFW_GETPROP
to the ofw_fdt_getprop function. That would remove the KOBJS dependency
(which pulls in a lot of other stuff) but re-use a lot of the already
well tested FreeBSD code.

> 
> 2) If we didn't dump libbsd, won't this cause double initialization of
> few things.

That's a problem that should be addressed by your GSoC project. One
reason for the suggested FDT based initialization was the situation that
currently is there on the Beagle: Some pin functions are initialized by
the RTEMS drivers with a hard coded value and then they are
re-initialized by the libbsd pinmux driver based on the FDT. I think it
would be optimal if RTEMS would do the initialization based on the FDT
and libbsd would just skip that step.

You maybe noted: Moving the pinmux stuff from libbsd to RTEMS could be
another use case for a FreeBSD code import. Although I don't want to
urge you into that direction if you don't want to do it (there are
always other solutions) it might has some benefits.


> You had already mentioned that libbsd uses some macro magic to avoid name
> collisions that's why I am ignoring that and only worried about double
> initialization.
> 

-- 
--------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 06/05/2020 09:16, Niteesh G. S. wrote:
> On Tue, May 5, 2020 at 11:44 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> On 05/05/2020 19:10, Niteesh G. S. wrote:
> > This is thread is about implementing OFW functions in RTEMS as part
> > of my GSoC project. I would like to start off with this part since the
> > refactoring
> > work will somewhat depend on this.
> 
> I'm not sure whether everyone on the list is already fully aware of what
> your project is. For some of us the GSoC preparation phase is more of a
> background noise. So maybe you want to give a short (only a few
> sentences) overview of your target and what is the gain for the RTEMS
> project.
> 
> 
> I am sorry. I'll make sure that I do that from the next mail onwards.
> 

No reason to be sorry. As soon as you introduced your project once - now
that it officially starts - you can assume that everyone knows about it.
I'm just not sure whether everyone watched the whole GSoC preparation mails.

>  
> 
> >
> > Implementing these functions into RTEMS will make porting drivers from
> > FreeBSD to RTEMS easy. Currently, the drivers ported from freebsd
> implement
> > the functions using libfdt variants but this causes a lot of code
> > duplication.
> > eg: bsps/arm/imx/start/imx_iomux.c
> >
> > My initial thoughts were to implement these functions one by one.
> But then
> > Christian and Vijay mentioned about porting them from libbsd.
> 
> Yes, there has been an offlist discussion whether the approach of a
> reimplementing them is a good idea.
> 
> Can you forward those mails if possible? Maybe I could gather some ideas
> from it.

No, because it hasn't been mails. And it have been only a few comments
about the direction without any relevant content. But you just did
everything necessary: Re-started a discussion whether that direction is OK.

> 
> 
> > I went
> > through the OFW code in libbsd and have described my porting
> process below.
> 
> If that can be ported, it would be a better approach then
> reimplementing.
> 
> > Please have a look at it and let me know if I have missed
> something or you
> > would like to improve things.
> >
> > The following files will be ported from libbsd
> > prefix = freebsd/sys/dev/ofw
> > /openfirm.c
> > /openfirm.h
> > /ofw_fdt.c
> > /ofwvar.h
> >
> > The main idea is to port openfirm.h but the other files
> are dependencies
> > of openfirm.h
> >
> > After going through some open firmware documentation. I guess as
> far as
> > RTEMS is 
> > concerned we could avoid many functions like OF_init, OF_putchar,
> OF_test
> > and only care about functions defined under openfirm.h:105-142
> 
> OK. Note that these functions often have a "node". Think about what that
> is and from where you would get it in an RTEMS driver. I think a lot of
> FreeBSD drivers get it from their (logical) bus system like ofwbus.
> 
> 
> Yes, the FreeBSD drivers do get their node handles from the buses.
> One way(hackish) to accomplish this would be to create a dummy dev
> structure which will be initialized during driver initialization. And
> then the
> drivers could query the node handles from it. But as mentioned this would
> be hackish and I don't think will scale well.
> 
> Another approach will be to import ofwbus itself, but then it would be a
> huge
> diversion from my current project. I don't mind working on this if this
> is the
> cleanest way to do it. But then we should also consider re-working on the
> objectives.

Let's just wait for some further comments on that. From my view
importing ofwbus isn't really the best idea because it most likely has a
lot of dependencies. And I'm really not sure whether we want all these
during system start.

> 
> >
> > But these functions have dependency on the automatically generated
> > ofw_if.h and KOBJS.
> > But after a close inspection, I guess the KOBJSLOOKUP macro in
> ofw_if.h
> > can be
> > redefined or replaced for RTEMS. Since all it does is call the
> > respective functions defined in ofw_fdt_methods(ofw_fdt.c).
> 
> Note that the automatically generated interface is used for the FreeBSD
> device driver structure (or rather the bus interface). If you port the
> stuff to RTEMS you should think about whether
> 
>  
> 
> a) it should replace the libbsd stu

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 06/05/2020 06:58, Sebastian Huber wrote:
> Hello Niteesh,
> 
> On 05/05/2020 19:10, Niteesh G. S. wrote:
>> This is thread is about implementing OFW functions in RTEMS as part
>> of my GSoC project. I would like to start off with this part since the
>> refactoring
>> work will somewhat depend on this.
>>
>> Implementing these functions into RTEMS will make porting drivers from
>> FreeBSD to RTEMS easy. Currently, the drivers ported from freebsd
>> implement
>> the functions using libfdt variants but this causes a lot of code
>> duplication.
>> eg: bsps/arm/imx/start/imx_iomux.c
> yes, what we have currently is a series of hacks and I am glad that we
> have now the opportunity to fix this.
>>
>> My initial thoughts were to implement these functions one by one. But
>> then
>> Christian and Vijay mentioned about porting them from libbsd. I went
>> through the OFW code in libbsd and have described my porting process
>> below.
>> Please have a look at it and let me know if I have missed something or
>> you
>> would like to improve things.
>>
>> The following files will be ported from libbsd
>> prefix = freebsd/sys/dev/ofw
>> /openfirm.c
>> /openfirm.h
>> /ofw_fdt.c
>> /ofwvar.h
>>
>> The main idea is to port openfirm.h but the other files
>> are dependencies of openfirm.h
>>
>> After going through some open firmware documentation. I guess as far
>> as RTEMS is
>> concerned we could avoid many functions like OF_init, OF_putchar, OF_test
>> and only care about functions defined under openfirm.h:105-142
>>
>> But these functions have dependency on the automatically generated
>> ofw_if.h and KOBJS.
>> But after a close inspection, I guess the KOBJSLOOKUP macro in
>> ofw_if.h can be
>> redefined or replaced for RTEMS. Since all it does is call the
>> respective functions defined in ofw_fdt_methods(ofw_fdt.c).
>>
>> I had just spent a few hours going through the code. If I had missed
>> something
>> please let me know.
> 
> This is a good analysis.
> 
> I am not sure if it is a good idea to replace the KOBJS support. This
> mechanism may be used in device drivers. I would try to make it optional.
> 
> I am strongly opposed to reinvent the wheel in this area. If an existing
> library with the right license fits our needs, then we should use and
> improve it. FreeBSD has an active community and from my experience it is
> easy to integrate changes. With the libbsd we have the ability to stay
> in synchronization with the FreeBSD upstream. This is done through the
> import/export script freebsd-to-rtems.py and a Git rebase in the FreeBSD
> Git clone. If you want to include bigger chunks of code from FreeBSD in
> RTEMS, then we should add this ability also to RTEMS. With the new build
> system, this would be easy. We could add an attribute (for example
> "synchronize-with: freebsd") to the objects items, e.g.
> 
> https://git.rtems.org/sebh/rtems.git/tree/spec/build/cpukit/libjffs2.yml?h=build
> 
> 
> A script could load the build items and pick up the ones with
> synchronize-with == freebsd and then perform the import/export job. This
> could be also used for other areas, e.g. JFFS2, the dtc, the libcrypto
> stuff, etc.

That could be a really nice functionality. Especially seeing that we
already have quite some imported files. For example

   https://git.rtems.org/rtems/tree/bsps/arm/imx/start/imx_iomux.c


-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: RTEMS directory for FreeBSD imports

[Christian Mauderer]

On 11/05/2020 09:11, Chris Johns wrote:
> On 11/5/20 4:55 pm, Christian Mauderer wrote:
>> On 11/05/2020 06:57, Chris Johns wrote:
>>>
>>>
>>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:
>>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns >>> <mailto:chr...@rtems.org>> wrote:
>>>>
>>>>  On 10/5/20 6:17 pm, Niteesh G. S. wrote:
>>>>   > This thread is a continuation of "GSoC 2020: Implementation
>>>> of OFW
>>>>   > functions".
>>>>   >
>>>>   > A summary of points discussed in that thread is given below.
>>>>   >
>>>>   > Below is a short description of my GSoC project. For more
>>>>  information please
>>>>   > refer to the wiki.
>>>>   >
>>>> https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization
>>>>   > My GSoC project deals with refactoring the Beagle BSP to add
>>>>  support for FDT
>>>>   > based initialization. As part of this process, I will have to
>>>>  import the
>>>>   > pin mux driver
>>>>   > into RTEMS which currently is present in libBSD.
>>>>   > This would require having support for OFW functions which are
>>>>  currently
>>>>   > not implemented
>>>>   > in RTEMS. Some drivers(eg: imx_iomux.c) which require these
>>>>  functions
>>>>   > provide
>>>>   > a local implementation using libFDT.
>>>>
>>>>  I hope you do not mind if I wind back a couple of steps...
>>>>
>>>>  OFW? Is this http://wiki.laptop.org/go/Open_Firmware?
>>>>  How does OFW related to FDT?
>>>>
>>>>
>>>> We are only interested in the device tree interface provided by the OF.
>>>> Functions like OF_getprop, OF_parent, etc.
>>>>
>>>
>>> Why not call libfdt functions? I am wondering what there is in FreeBSD
>>> that is calling these functions? I am not questioning the need, it is a
>>> case of not understanding the dependency.
>>
>> The use case for the OF_... and ofw_... functions is more or less a
>> simple import from FreeBSD drivers. Beneath that there are some quite
>> nice shortcuts in the OF_... and ofw_... functions that would have to be
>> re-implemented in each driver (like ofw_bus_node_status_okay()).
>>
>> Some drivers already use hacked versions of the functions. For example:
>>
>> bsps/sparc64/shared/clock/ckinit.c
>> bsps/arm/imx/start/imx_iomux.c
>>
>> A use case where the OF_... stuff would have been handy:
>>
>> For the imx pin initialization I would have loved to just use the
>> fdt_pinctrl_configure_tree() from FreeBSD. But that one had a lot of
>> OF_.. stuff. Therefore I had to reimplement that function in a
>> imx_pinctrl_configure_children(). My implementation basically does
>> exactly the same thing but uses fdt_... functions instead of the OF_...
>> functions.
> 
> Thanks. I think I understand. The scope seems to be the low level SoC
> type initialisation. This makes sense.

And maybe some low level drivers like serial or I2C. I don't think that
we should go much further in complexity. Basically everything that is
beyond getting the board up and running is more of a libbsd topic.

> 
>>>>  You discuss importing drivers from FreeBSD? Do you know which core
>>>>  FreeBSD pieces would need to also come over for the drivers listed
>>>>  below?
>>>>
>>>>
>>>> We had discussed this in the previous thread.
>>>> https://lists.rtems.org/pipermail/devel/2020-May/059765.html
>>>> For OF_* functions we will only have to import the following files.
>>>> 1) openfirm.h
>>>> 2) ofw_fdt.c
>>>
>>> You say below some drivers are being imported from FreeBSD, it is these
>>> I am asking about.
>>>
>>>>  Is seamless integration with rtems-libbsd required or does it also
>>>>  include copies of the same code?
>>>>
>>>> I am sorry. I don't really understand what you are asking :(.
>>>
>>> I am asking if the changes effect rtems-libbsd?
>>
>> I think the first step will be copies. It depends a bit on how well the
>> functions can be integrated into RTEMS (the "node" parameter maybe is a
>> bit difficult) but I'm confident that the OF_..

Re: GSoC: RTEMS directory for FreeBSD imports

[Christian Mauderer]

t;>  > directories for eg
>>  > a device driver could be placed in its BSP directories than in a
>>     common
>>  > folder
>>  > along with other imports. But it should also be noted that the
>>     latter
>>  > makes it
>>  > difficult to sync and the former.
>>
>>     Gedare covered these issues in the other thread in an excellent post
>>     [1]
>>     and I would like to reference that as I agree with it.
>>
>>     When importing from such a large and complex code base like
>> FreeBSD we
>>     need to be careful we do not pull on a thread and pull in large
>> pieces
>>     of FreeBSD.
>>
>>     Gedare's point about making sure all imported pieces are from the
>> same
>>     version is important and I think a base requirement.
>>
>>     I am OK with some code being in rtems.git if there is a clear use
>>     outside of rtems-libbsd. FDT support is one use, another is the NFS
>>     client code in FreeBSD being used with the legacy stack (there are
>> BSPs
>>     with only legacy driver support still in use) and the existing
>>     client is
>>     only NFSv2.
>>
>>     We need a place to collect the common base parts of FreeBSD that are
>>     shared by the various imported pieces. Isolated pieces could lead to
>>     repeated imports common pieces if we do not do this.
>>
>>     I believe Sebastian said the new build system should handle the
>>     synchronisation? This is a good idea. Could it manage separated
>> pieces?
>>     Could the build system read in all the sync pieces and logically join
>>     them based on the upstream source and operate on them as a group?
>> This
>>     way we can have drivers in a BSP, NFS in libnfs (or where ever).
>>
>>
>> I am not really familiar with the new build system. So can we please wait
>> until Sebastian answers this.
> 
> Sure.

Although note that I suggested to see the discussion as a _preparation_
for that import. Doing the import right is quite a bit of work. It would
change the target of Niteeshs GSoC project quite a lot. So we should
make sure that a good location is selected and that the same rules like
in libbsd are used. But I don't think that the actual script will be
added in that project.

Best regards

Christian

> 
> Chris
> 
>>
>>
>>
>>     Chris
>>
>>     [1] https://lists.rtems.org/pipermail/devel/2020-May/059807.html
>>

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 07/05/2020 17:19, Niteesh G. S. wrote:
> On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
>  <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> 
> On 07/05/2020 12:28, Niteesh G. S. wrote:
> 
> > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
> >  <mailto:sebastian.hu...@embedded-brains.de>
> > <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
> >
> >     On 07/05/2020 09:35, Niteesh G. S. wrote:
> >
> >     > This is what I was trying to convey in one of the previous
> mails.
> >     > https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> >     > But in that mail, I was planning to replace KOBJLOOKUP.
> >     > Should I start working on it? From the top of my mind, the
> >     following has
> >     > to be done.
> >     > 1) Import openfirm.c openfirm.h, ofw_fdt.c
> >     > 2) Add ofw_fdt.h since all the functions in ofw_fdt are static.
> >     > Should we also import ofw_if.h? Because that is where OFW_*
> >     functions
> >     > are defined or just add a ofw_rtems_map.h which redefines them,
> >     instead
> >     > of importing ofw_if.h?
> >
> >     The KOBJ stuff in the OFW support enables FreeBSD to have three
> >     different implementations of the OFW API which can be selected at
> >     runtime:
> >
> >     sys/powerpc/ofw/ofw_real.c
> >     sys/dev/ofw/ofw_standard.c
> >     sys/dev/ofw/ofw_fdt.c
> >
> >     In libbsd this is already short cut to the FDT implementation:
> >
> >     #ifndef __rtems__
> >     static ofw_def_t    *ofw_def_impl = NULL;
> >     #else /* __rtems__ */
> >     #define    ofw_def_impl (_fdt)
> >     #endif /* __rtems__ */
> >
> >     To me this looks like the KOBJ stuff was just used to enable some
> >     sort
> >     of object oriented programming. Do we need this flexibility at
> >     runtime
> >     in RTEMS? I would say no. I would hard wire this to the FDT
> >     implementation. If someone has a problem with it in the
> future, this
> >     decision can be readdressed.
> >
> >
> > Ok. But what is the neatest way to hardwire this to the FDT
> > implementation?
> > One way as Christian mentioned would be to redefine OFW_* functions to
> > call the functions in ofw_fdt.c directly. Is there any other way?
> 
> I would try to replace the function declarations in openfirm.h with
> inline functions which call the ofw_fdt.c functions.
> 
> 
> Should I proceed with the above method? or should I wait for others
> to comment?
> If I can proceed, the following is what I will be doing.
> 1) import openfirm.h and ofw_fdt.c into RTEMS.
> 2) Add ofw_fdt.h with functions declarations for functions in ofw_fdt.c
> 3) Add necessary compile-time guards. This would include using __rtems__
> preprocessor directive to avoid FreeBSD stuff and change the function
> definitions in ofw_fdt.c from static to non-static.
> Am I missing something? or is there any other way to do this?

Maybe wait one or two more days for others to comment. For me the
direction sounds OK.

You maybe can start thinking about where you want to import the files to.

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: RTEMS directory for FreeBSD imports

[Christian Mauderer]

On 13/05/2020 20:15, Niteesh G. S. wrote:
> Hello,
> 
> This mail is to regain attention for this topic and also to discuss a
> few details
> regarding the porting process.
> 
> In the previous thread, Sebastian mentioned that we will be hard wiring
> the OF
> functions with the FDT implementation. For reasons please have a look at
> previous thread.
> https://lists.rtems.org/pipermail/devel/2020-May/059762.html
> This will be achieved by inlining the functions in openfirm.h with functions
> defined in ofw_fdt.c. This approach is valid for most functions but not all.
> Since not all functions have a one to one mapping.
> 
> For example,
>    The OF_peer can be directly mapped to ofw_fdt_peer.
>    But for OF_getencprop it calls ofw_fdt_getprop after few manipulations.
> Inlining these functions doesn't seem like a good practice for me.
> 
> One way to approach this would be to add the implementation for these
> functions in
> ofw_fdt.c but this would cause code redundancy if we plan to import
> openfirm.c
> in future since these functions are already defined in openfirm.c.

Are the functions exact clones of the the ones in openfirm.c? In that
case I would suggest to import openfirm.c and put #ifndef __rtems__
around everything you don't need. Eveni if it means that you only use
10% of the file.

> 
> Another approach will be to import openfirm.c also and redefine the OFW_*
> macro to directly call the respective functions.

That sounds like a better aproach.

> 
> I don't really know if there is any other better way to approach this.
> Any suggestion on
> how to proceed. 
> 
> Once this is resolved I will proceed with the porting even if we haven't
> finalized the
> directory since it is just a matter of moving files once we are finalized.
> 
> If you think this is too early to start with coding for GSoC please
> understand that my
> university exams haven't been conducted yet. And due to the COVID
> pandemic, the
> dates are quite uncertain. But it is mostly expected to happen during
> the coding period (july/aug)
> and this would eat up quite a lot of time. So just to be one the safe
> side I started
> quite early.
> 
> Thank,
> Niteesh.
> 
> On Mon, May 11, 2020 at 12:48 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> On 11/05/2020 09:11, Chris Johns wrote:
> > On 11/5/20 4:55 pm, Christian Mauderer wrote:
> >> On 11/05/2020 06:57, Chris Johns wrote:
> >>>
> >>>
> >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:
> >>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns  <mailto:chr...@rtems.org>
> >>>> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >>>>
> >>>>  On 10/5/20 6:17 pm, Niteesh G. S. wrote:
> >>>>   > This thread is a continuation of "GSoC 2020: Implementation
> >>>> of OFW
> >>>>   > functions".
> >>>>   >
> >>>>   > A summary of points discussed in that thread is given
> below.
> >>>>   >
> >>>>   > Below is a short description of my GSoC project. For more
> >>>>  information please
> >>>>   > refer to the wiki.
> >>>>   >
> >>>> https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization
> >>>>   > My GSoC project deals with refactoring the Beagle BSP
> to add
> >>>>  support for FDT
> >>>>   > based initialization. As part of this process, I will
> have to
> >>>>  import the
> >>>>   > pin mux driver
> >>>>   > into RTEMS which currently is present in libBSD.
> >>>>   > This would require having support for OFW functions
> which are
> >>>>  currently
> >>>>   > not implemented
> >>>>   > in RTEMS. Some drivers(eg: imx_iomux.c) which require these
> >>>>  functions
> >>>>   > provide
> >>>>   > a local implementation using libFDT.
> >>>>
> >>>>  I hope you do not mind if I wind back a couple of steps...
> >>>>
> >>>>  OFW? Is this http://wiki.laptop.org/go/Open_Firmware?
> >>>>  How does OFW related to FDT?
> >>>>
> >>>>
> &

Re: GSoC: RTEMS directory for FreeBSD imports

[Christian Mauderer]

On 14/05/2020 18:59, Niteesh G. S. wrote:
> On Thu, May 14, 2020 at 4:30 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> On 13/05/2020 20:15, Niteesh G. S. wrote:
> > Hello,
> >
> > This mail is to regain attention for this topic and also to discuss a
> > few details
> > regarding the porting process.
> >
> > In the previous thread, Sebastian mentioned that we will be hard
> wiring
> > the OF
> > functions with the FDT implementation. For reasons please have a
> look at
> > previous thread.
> > https://lists.rtems.org/pipermail/devel/2020-May/059762.html
> > This will be achieved by inlining the functions in openfirm.h with
> functions
> > defined in ofw_fdt.c. This approach is valid for most functions
> but not all.
> > Since not all functions have a one to one mapping.
> >
> > For example,
> >    The OF_peer can be directly mapped to ofw_fdt_peer.
> >    But for OF_getencprop it calls ofw_fdt_getprop after few
> manipulations.
> > Inlining these functions doesn't seem like a good practice for me.
> >
> > One way to approach this would be to add the implementation for these
> > functions in
> > ofw_fdt.c but this would cause code redundancy if we plan to import
> > openfirm.c
> > in future since these functions are already defined in openfirm.c.
> 
> Are the functions exact clones of the the ones in openfirm.c? In that
> case I would suggest to import openfirm.c and put #ifndef __rtems__
> around everything you don't need. Eveni if it means that you only use
> 10% of the file.
> 
> 
> Yes, implementation of the mentioned
> functions(OF_getencprop, OF_getencprop_alloc etc)
> will be a copy of the ones in openfirm.c.
>  
> 
> >
> > Another approach will be to import openfirm.c also and redefine
> the OFW_*
> > macro to directly call the respective functions.
> 
> That sounds like a better aproach.
> 
> 
> We can also call the respective functions directly from the functions in
> openfirm.c
> instead of redefining the OFW_* macro. Which one do you prefer?

I would suggest to use the method that is less invasive. For calling the
functions directly you most likely have to do something like that:

#ifndef __rtems__
OFW_DO_SOMETHING(x, y);
#else /* __rtems__ */
direct_call_to_function(x, y);
#endif

If someone changes the OFW_DO_SOMETHING line and (for example) add
another condition around it that will trigger a conflict on upgrade.

If you add

#ifdef __rtems__
#define OFW_DO_SOMETHING direct_call_to_function
#endif

that will apply fine on an upgrade. So I would use that one.

> 
> I will wait for a couple for everyone to participate in the discussion
> and then start
> implementing it.
> 
> >
> > I don't really know if there is any other better way to approach this.
> > Any suggestion on
> > how to proceed. 
> >
> > Once this is resolved I will proceed with the porting even if we
> haven't
> > finalized the
> > directory since it is just a matter of moving files once we are
> finalized.
> >
> > If you think this is too early to start with coding for GSoC please
> > understand that my
> > university exams haven't been conducted yet. And due to the COVID
> > pandemic, the
> > dates are quite uncertain. But it is mostly expected to happen during
> > the coding period (july/aug)
> > and this would eat up quite a lot of time. So just to be one the safe
> > side I started
> > quite early.
> >
> > Thank,
> > Niteesh.
> >
> > On Mon, May 11, 2020 at 12:48 PM Christian Mauderer
> >  <mailto:christian.maude...@embedded-brains.de>
> > <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >
> >     On 11/05/2020 09:11, Chris Johns wrote:
> >     > On 11/5/20 4:55 pm, Christian Mauderer wrote:
> >     >> On 11/05/2020 06:57, Chris Johns wrote:
> >     >>>
> >     >>>
> >     >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:
> >     >>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns
> mailto:chr...@rtems.org>
> >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     >>>> <mailto:chr...@rtems.org &l

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

. So it could mean that adding stuff to
RTEMS means that it should be removed from libbsd.

>  
> 
> To help you understand the structure of the libbsd:
> * The files in freebsd/ directory are already ported to RTEMS.
> * The freebsd-org/ is the git submodule that has the original source
> of the freebsd.
> * The rtemsbsd/ has the codes that we added to adapt the freebsd codes.
> 
> The *_if.h files are generally automatically generated from the
> *_if.m files.
> The ofw_if.h has already been ported, you can find the generated header
> file in rtemsbsd/include/rtems/bsd/local/ofw_if.h so there's no need
> to do it
> again. If future if there's a need to do it, we generally add a
> recipe to build
> the h files from the .m files in the Makefile.todo . You can have a
> look at it
> if you want, it's simple to follow.
> 
> I had just spent a few hours going through the code. If I had
>     missed something
> please let me know.
> 
> You're in the right direction. We need to wait a bit to get some
> input from
> the community and progress accordingly.
> 
> Best regards,
> Vijay 
> 
> Thanks,
> Niteesh.
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 08/05/2020 17:26, Niteesh G. S. wrote:
> On Fri, May 8, 2020 at 11:43 AM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> 
> On 07/05/2020 17:19, Niteesh G. S. wrote:
> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
> >  <mailto:sebastian.hu...@embedded-brains.de>
> > <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
> >
> >     On 07/05/2020 12:28, Niteesh G. S. wrote:
> >
> >     > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
> >     >  <mailto:sebastian.hu...@embedded-brains.de>
> >     <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>
> >     > <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>
> >     <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>>> wrote:
> >     >
> >     >     On 07/05/2020 09:35, Niteesh G. S. wrote:
> >     >
> >     >     > This is what I was trying to convey in one of the previous
> >     mails.
> >     >     >
> https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> >     >     > But in that mail, I was planning to replace KOBJLOOKUP.
> >     >     > Should I start working on it? From the top of my mind, the
> >     >     following has
> >     >     > to be done.
> >     >     > 1) Import openfirm.c openfirm.h, ofw_fdt.c
> >     >     > 2) Add ofw_fdt.h since all the functions in ofw_fdt
> are static.
> >     >     > Should we also import ofw_if.h? Because that is where
> OFW_*
> >     >     functions
> >     >     > are defined or just add a ofw_rtems_map.h which
> redefines them,
> >     >     instead
> >     >     > of importing ofw_if.h?
> >     >
> >     >     The KOBJ stuff in the OFW support enables FreeBSD to
> have three
> >     >     different implementations of the OFW API which can be
> selected at
> >     >     runtime:
> >     >
> >     >     sys/powerpc/ofw/ofw_real.c
> >     >     sys/dev/ofw/ofw_standard.c
> >     >     sys/dev/ofw/ofw_fdt.c
> >     >
> >     >     In libbsd this is already short cut to the FDT
> implementation:
> >     >
> >     >     #ifndef __rtems__
> >     >     static ofw_def_t    *ofw_def_impl = NULL;
> >     >     #else /* __rtems__ */
> >     >     #define    ofw_def_impl (_fdt)
> >     >     #endif /* __rtems__ */
> >     >
> >     >     To me this looks like the KOBJ stuff was just used to
> enable some
> >     >     sort
> >     >     of object oriented programming. Do we need this
> flexibility at
> >     >     runtime
> >     >     in RTEMS? I would say no. I would hard wire this to the FDT
> >     >     implementation. If someone has a problem with it in the
> >     future, this
> >     >     decision can be readdressed.
> >     >
> >     >
> >     > Ok. But what is the neatest way to hardwire this to the FDT
> >     > implementation?
> >     > One way as Christian mentioned would be to redefine OFW_*
> functions to
> >     > call the functions in ofw_fdt.c directly. Is there any other
> way?
> >
> >     I would try to replace the function declarations in openfirm.h
> with
> >     inline functions which call the ofw_fdt.c functions.
> >
> >
> > Should I proceed with the above method? or should I wait for others
> > to comment?
> > If I can proceed, the following is what I will be doing.
> > 1) import openfirm.h and ofw_fdt.c into RTEMS.
> > 2) Add ofw_fdt.h with functions declarations for functions in
> ofw_fdt.c
> > 3) Add necessary compile-time guards. This would include using
> __rtems__
> > preprocessor directive to avoid FreeBSD stuff and change the function
> > definitions in ofw_fdt.c from static to non-static.
> > Am I missing something? or is there any other way to do this?
> 
> Maybe wait one or two more days for others to comment. For me the
> direction sounds OK.
> 
> You maybe can start thinking about where you want to import the
> files to.
> 
> 
> Since this has scope for future development. I think we should put it in a 
> separate directory under cpukit/include/ofw for header files and cpukit/ofw
> for the source files. What do you think?
> 
> 

If you plan to prepare a FreeBSD sync (regardless whether you implement
it or someone else) another possibility could be to create a similar
directory structure like in libbsd.

Another directory could be ./cpukit/libmisc/rtems-fdt.

But your suggestion is also possible.

Maybe wait for some further input.

Best regards

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

Re: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

[Christian Mauderer]

Hello Amar,

On 18/03/2020 19:24, Amar Takhar wrote:
> The only one I would like to propose is the 80 character limit.  This should 
> be 
> moved to something more reasonable such as 120.
> 
> Code comments should remain below 80 however.
> 

I'm not a big fan of long lines (reason further below) but I won't block
it either. But what I think is really a bad idea is to have different
rules for different parts of the code.

I think we will have a really hard time to set up tools like formatters
or pylint to check and use these rules. I think setting a line length to
120 should be easy to possible for nearly any tool. But I expect that
setting it to 120 for code and 80 for comments can be _very_ difficult
depending on the tool.


PS: Reason for me being not a fan of long lines: While programming I
often use a split window. In that configuration my editor can show 112
columns in each window on my current screen. That fits well for nearly
all code that follows the 80 character convention. But for example your
proposed length of 120 the code will lead to either a smaller font, a
lot of random line breaks done by the editor or to loosing one window.
Again: It's not a strong opinion and I'll accept 120 too. But expect
that some others have stronger opinions about 80 characters. At least it
have been 80 chars since at least punch hole cards:

https://softwareengineering.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width#148678


PPS: Also note one of the first rules in PEP-008: "A Foolish Consistency
is the Hobgoblin of Little Minds":
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

It explicitly tells you to not follow the standard if your code gets
less readable by doing it. So if we only have few cases with long lines,
we can use exceptions and it is conform to PEP-008. Of course it might
could be tricky to tell our tools that this line is an exception.


Best regards

Christian

> Python itself has not followed this rule for a long time you can see many 
> lines 
> over 80 in the Python source itself.
> 
> Also, due to the nature of the language most lines end up below 80 characters 
> anyway.  Python is not an easy language to read when you have to break long 
> lines into 2 especially when you start breaking up strings.
> 
> I'm with most of the developers here -- 80 characters as been the norm for a 
> very long time however this is no longer true for new developers.  There are 
> already examples in our own rtems-tool codebase that make no sense being 
> split:
> 
>   
> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/execute.py?id=274981f77d648ceb87f84cdeaec33a58dfd37385#n579
> 
> I've ran into this more than once where a Python developer ends up in 
> confusion 
> when reading source that has line breaks to keep under line lengths.
> 
> I'd like to go the direction the wind is blowing on this and relax this rule 
> to 
> 120 for source, 80 for documentation where possible.
> 
> This is of course applied to cases where leaving the line long makes sense.  
> A 
> function with 20 parameters shouldn't be in a long line that is a disaster in 
> any language.
> 
> 
> Amar.
> ___
> 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: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

[Christian Mauderer]

Hello Chris and Amar,

On 19/03/2020 04:01, Chris Johns wrote:
> On 19/3/20 7:06 am, Christian Mauderer wrote:
>> Hello Amar,
>>
>> On 18/03/2020 19:24, Amar Takhar wrote:
>>> The only one I would like to propose is the 80 character limit.  This 
>>> should be 
>>> moved to something more reasonable such as 120.
>>>
>>> Code comments should remain below 80 however.
>>>
>>
>> I'm not a big fan of long lines (reason further below) but I won't block
>> it either. But what I think is really a bad idea is to have different
>> rules for different parts of the code.
> 
> And different parts of the project.

Different parts of the project are far less difficult. In that case it's
mostly personal preference / set up of the personal development
environment. Like you noted: Mine isn't 120 characters too. But I could
live with it.

Again: The biggest problem that I see is the tools that will be
difficult to set up if we mix inside of the affected part.

> 
>> I think we will have a really hard time to set up tools like formatters
>> or pylint to check and use these rules. I think setting a line length to
>> 120 should be easy to possible for nearly any tool. But I expect that
>> setting it to 120 for code and 80 for comments can be _very_ difficult
>> depending on the tool.
>>
>>
>> PS: Reason for me being not a fan of long lines: While programming I
>> often use a split window. In that configuration my editor can show 112
>> columns in each window on my current screen. That fits well for nearly
>> all code that follows the 80 character convention. But for example your
>> proposed length of 120 the code will lead to either a smaller font, a
>> lot of random line breaks done by the editor or to loosing one window.
>> Again: It's not a strong opinion and I'll accept 120 too. But expect
>> that some others have stronger opinions about 80 characters.
> 
> I run everything in text mode under tmux and in Emacs I split vertically and
> variable length is painful and prefer we settle on 80.

Maybe let's wait whether there are more opinions. Currently we have

- one clear vote for 120 lines (Amar)
- one clear vote for 80 lines (Chris)
- one a bit undecided with tendency to shorter lines (myself)

Best regards

Christian

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

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Maintainers of rtems-littlevgl package

[Christian Mauderer]

On 18/03/2020 22:17, Gedare Bloom wrote:
> Hi everyone,
> 
> I'm pleased to announce that the rtems-littlevgl package will be
> maintained (officially) by Christian Mauderer and Vijay Kumar
> Bannerjee. Christian/Vijay, please add a README file to the
> rtems-littlevgl package and include some details about the role of
> that repo in RTEMS, and with your information as the package
> maintainers. Eventually there should also be some instructions on how
> to use it in the README :)
> 
> Thanks,
> Gedare

Hello Gedare,

thanks for the trust.

I'll discuss with Vijay whether he will create the patch or whether I
should do that.

Best regards

Christian
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] user/raspberrypi: Fix typo

[Christian Mauderer]

Hello Niteesh,

thanks for finding and fixing that. It's a very small patch and no one
objected in the last days. So I pushed it.

Best regards

Christian

On 16/03/2020 15:42, G S Niteesh Babu wrote:
> enable-uart should be enable_uart in config.txt
> ---
>  user/bsps/arm/raspberrypi.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
> index 72889a5..c26f4b5 100644
> --- a/user/bsps/arm/raspberrypi.rst
> +++ b/user/bsps/arm/raspberrypi.rst
> @@ -46,7 +46,7 @@ Make sure you have these lines below, in your 
> ``config.txt``.
>  
>  .. code-block:: none
>  
> - enable-uart=1
> + enable_uart=1
>   kernel_address=0x20
>   kernel=kernel.img
>  
> 

-- 
--------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 rtems_littlevgl 1/3] waf: Remove unnecessary code.

[Christian Mauderer]

No one objected to these patches so I pushed them.

Best regards

Christian

On 17/03/2020 08:18, Christian Mauderer wrote:
> ---
>  lvgl.py | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/lvgl.py b/lvgl.py
> index 5452ed0..f275287 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -68,26 +68,17 @@ def build(bld):
>  
>  sources, includes = source_list(bld)
>  includes.append('.')
> -objects = []
>  include_paths = []
>  
>  for source in sources:
> -objects.append(source[:-1] + 'o')
>  source_dir = os.path.dirname(source)
>  if source_dir not in include_paths:
>  include_paths.append(source_dir)
>  
> -bld.objects(target = objects,
> -features = 'c',
> -cflags = '-O2',
> -includes = includes,
> -source = source)
> -
>  bld.stlib(target = 'lvgl',
>features = 'c',
>includes = includes,
> -  source = sources,
> -  use = objects)
> +  source = sources)
>  
>  arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>  bld.env.RTEMS_ARCH_BSP)
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-boot-image tool: Raspberry Pi

[Christian Mauderer]

Hello Niteesh,

thanks for the (private) remainder. This thread really stopped quite
some time ago. A lot of us are quite busy right now but that shouldn't
happen. If you don't get a response for some question: Please give it
about a week of time and then just ping the thread.

On 05/03/2020 11:06, G. S. Niteesh wrote:
> On Wed, Feb 26, 2020 at 8:39 AM Chris Johns  > wrote:
> 
> On 22/2/20 1:45 am, G. S. Niteesh wrote:
> > Hi,
> >
> > This is regarding adding RPi support to the boot image generation
> tool.
> >
> > The boot process for Raspberry Pi is very unconventional. The GPU
> starts
> > first, initializes RAM, other hardware, loads the bootloaders and
> then starts
> > the ARM CPU.
> >
> > The minimum files that are required to boot an RPi are
> > bootcode.bin, startx.elf, fixup.dat, kernel.img, config.txt
> > There are also other variants of startx.elf and fixup.dat.
> > Please have a look
> >
> at 
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> > for information on the variants.
> >
> > From what I have tried on my Rpi3 model b v1.2 the minimum files
> that are
> > required are start_x.elf, fixup_x.dat, bootcode.bin, kernel.img,
> config.txt
> > But for this to work, we must add start_x=1 to config.txt because
> by default
> > start.elf is loaded.
> 
> Hello Chris,
>  
> 
> I would have look at how the tool maps to RPi to know if it needs
> more work :)
> 
> 
> Did you take a look at it?

Chris is most likely too busy with the release right now.

> 
> In my opinion, there are two ways to do it.
> The first would be to modify the U-Boot bootloader object to have a
> files field
> to make sure the user provides all the necessary files(fixup.dat,
> startx.elf, config.txt).
> So after this change the rtems-boot.ini for RPI should look something
> like this
> [u-boot-raspberrypi]
> uses = u-boot-arm-raspberrypi
> ..
> ..
> first_stage = %{ubootdir}/bootcode.bin
> boot_device = mmc 0
> second_stage = uboot or startx
> files = [config.txt, fixup.dat etc]
> But also please keep in mind that if we want to support RPi4 then the
> first_stage
> will start4x.elf since bootcode.bin is now replaced by code in the
> EEPROM in RPi4 SOC.

As far as I understand that approach it more or less tells: To start a
raspberry you need U-Boot. U-Boot needs the fixup.dat, startx.elf and
config.txt to boot. But that sounds a bit wrong. On Raspberry U-Boot is
purely optional, isn't it? So from a high-level view it would be more a

- Raspberry needs fixup.dat, startx.elf and config.txt
- That can start either:
  - an application or
  - an U-Boot which can then start an application (or do other things)

> 
> Another approach will be to create the default Raspberry Pi bootloader
> object. But having
> support for U-Boot is important since it will allow for automatic testing.

That approach sounds more correct. But I don't really know the
rtems-boot-image tool. That makes it a lot harder for me to tell whether
that approach works well. From that ignorant position I would say that
it would be nice to have a boot-image command that can be called with or
without a option (like --with-u-boot). Alternatively maybe two targets
would be possible. One raspiboot-u-boot-pi1 and one raspiboot-raw-pi1.

But your best bet might is to wait for Chris to get free again and
answer that question. He knows the boot image tool and can tell you a
lot better which concept works best.

Best regards

Christian

> 
> Which one do you think is a better approach?
> 
> Thank you.
> 
> 
> >
> > So, what should be the values for the first and second stages in
> rtems-boot.ini
> > for Rpi?
> 
> Would this be bootcode.bin?
> 
> > And also wouldn't it be nice if we could add a files field, which
> will copy the
> > specified files to the image? This would save a lot of typing in
> case of RPi
> 
> Do you have an example?
> 
> Chris
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] bsp/beagle: Update console to new Termios device API.

[Christian Mauderer]

Hello Niteesh,


On 15/03/2020 20:44, G S Niteesh Babu wrote:
> This patch updates the console to use new Termios device API.
> Update #3034
> ---
>  bsps/arm/beagle/console/console-config.c | 66 +++-
>  1 file changed, 41 insertions(+), 25 deletions(-)
> 
> diff --git a/bsps/arm/beagle/console/console-config.c 
> b/bsps/arm/beagle/console/console-config.c
> index 78af5f6a93..860a44cb00 100644
> --- a/bsps/arm/beagle/console/console-config.c
> +++ b/bsps/arm/beagle/console/console-config.c
> @@ -41,6 +41,8 @@
>  #define TX_FIFO_E (1<<5)
>  #define RX_FIFO_E (1<<0)
>  
> +#define UART0 "/dev/ttyS0"
> +

I'm not a big fan of such a generic name for a define. It's quite
possible that it conflicts with another define in the future.

I would suggest BEAGLE_UART0 or similar.

>  static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
>  {
>uint8_t v;
> @@ -65,34 +67,27 @@ static void beagle_uart_set_register(uintptr_t addr, 
> uint8_t i, uint8_t val)
>reg [i] = val;
>  }
>  
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_NS16550,
> -#if CONSOLE_POLLED   /* option to facilitate running the tests */
> -  .pDeviceFns = _fns_polled,
> -#else
> -  .pDeviceFns = _fns,
> -#endif
> -  .ulMargin = 16,
> -  .ulHysteresis = 8,
> -  .pDeviceParams = (void *) CONSOLE_BAUD,
> -  .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
> -  .ulDataPort = BSP_CONSOLE_UART_BASE,
> -  .ulIntVector = BSP_CONSOLE_UART_IRQ,
> -  .getRegister = beagle_uart_get_register,
> -  .setRegister = beagle_uart_set_register,
> -  .ulClock = UART_CLOCK,  /* 48MHz base clock */
> -},
> -};
> -
> -unsigned long Console_Configuration_Count = 1;
> +ns16550_context uart_context;
>  
>  static int init_needed = 1; // don't rely on bss being 0
>  
>  static void beagle_console_init(void)
>  {
>if(init_needed) {
> +ns16550_context *ctx;
> +
> +/*
> +   *  Don't rely on BSS being 0
> +*/
> +memset(_context, 0, sizeof(uart_context));
> +ctx = _context;
> +
> +ctx->port = BSP_CONSOLE_UART_BASE;
> +ctx->get_reg = beagle_uart_get_register;
> +ctx->set_reg = beagle_uart_set_register;
> +ctx->clock = UART_CLOCK;
> +ctx->initial_baud = CONSOLE_BAUD;
> +
>  const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
>  CONSOLE_SYSC = 2;
>  while ((CONSOLE_SYSS & 1) == 0)
> @@ -120,6 +115,8 @@ static void beagle_console_init(void)
>  CONSOLE_LCR = 0x03;
>  CONSOLE_ACR = 0x00;
>  init_needed = 0;
> +
> +BSP_output_char = uart_write_polled;
>}
>  }
>  
> @@ -127,15 +124,17 @@ static void beagle_console_init(void)
>  
>  static void uart_write_polled( char c )
>  {
> -  if(init_needed) beagle_console_init();
> -
>while( ( CONSOLE_LSR & TX_FIFO_E ) == 0 )
>  ;
>CONSOLE_THR8 = c;
>  }
>  
>  static void _BSP_put_char( char c ) {
> -   uart_write_polled( c );
> +
> +  if ( init_needed ) {
> +beagle_console_init();
> +  }
> +  uart_write_polled( c );

Why did you have to move the "if (init_needed)" from uart_write_polled
to _BSP_put_char? It seems that it does the same as long as
_BSP_put_char is called first. But if uart_write_polled is called first,
it will lead to an unitialised hardware, wouldn't it?

By the way: Did you have a look whether there are two functions? They
are both static and it seems that only _BSP_put_char is used. So it
seems a bit odd...

>  }
>  
>  static int _BSP_get_char(void)
> @@ -147,6 +146,23 @@ static int _BSP_get_char(void)
>}
>  }
>  
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  rtems_termios_initialize();
> +  rtems_termios_device_install(
> +UART0,
> +_handler_polled,
> +NULL,
> +_context.base
> +  );
> +
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  BSP_output_char_function_type BSP_output_char = _BSP_put_char;
>  
>  BSP_polling_getchar_function_type BSP_poll_char = _BSP_get_char;
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Any short projects available?

[Christian Mauderer]

Hello Niteesh,

currently the release process for 5.1 is very active. Maybe you want to
take a look whether you can support some small tasks there:

https://devel.rtems.org/query?status=assigned=accepted=reopened=status=5.1

https://devel.rtems.org/query?status=new=status=5.1

For example:

Testing the patch I added here: https://devel.rtems.org/ticket/3903

Or adding a test: https://devel.rtems.org/ticket/3889 or
https://devel.rtems.org/ticket/3890

Best regards

Christian

On 10/03/2020 18:32, G. S. Niteesh wrote:
> Hii,
> 
> I interested in taking up small tasks/projects as a primer for GSoC.
> I am mostly interested in drivers, build system, core (Schedulers, MPU, etc)
> part of RTEMS.
> I am also okay with large projects if small ones aren't available. I'll
> start learning
> about them and will start working after GSoC.
> 
> Thank you,
> Niteesh.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 rtems_littlevgl 2/3] waf: Enable optimization and debug symbols.

[Christian Mauderer]

---
 lvgl.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lvgl.py b/lvgl.py
index f275287..b91a265 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -77,6 +77,7 @@ def build(bld):
 
 bld.stlib(target = 'lvgl',
   features = 'c',
+  cflags = ['-O2', '-g'],
   includes = includes,
   source = sources)
 
-- 
2.16.4

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

[PATCH v2 rtems_littlevgl 1/3] waf: Remove unnecessary code.

[Christian Mauderer]

---
 lvgl.py | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/lvgl.py b/lvgl.py
index 5452ed0..f275287 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -68,26 +68,17 @@ def build(bld):
 
 sources, includes = source_list(bld)
 includes.append('.')
-objects = []
 include_paths = []
 
 for source in sources:
-objects.append(source[:-1] + 'o')
 source_dir = os.path.dirname(source)
 if source_dir not in include_paths:
 include_paths.append(source_dir)
 
-bld.objects(target = objects,
-features = 'c',
-cflags = '-O2',
-includes = includes,
-source = source)
-
 bld.stlib(target = 'lvgl',
   features = 'c',
   includes = includes,
-  source = sources,
-  use = objects)
+  source = sources)
 
 arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
 bld.env.RTEMS_ARCH_BSP)
-- 
2.16.4

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

[PATCH v2 rtems_littlevgl 3/3] Update to lvgl v6.1.2

[Christian Mauderer]

---
 lv_drivers | 2 +-
 lvgl   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lv_drivers b/lv_drivers
index 117812e..24cedaa 16
--- a/lv_drivers
+++ b/lv_drivers
@@ -1 +1 @@
-Subproject commit 117812eec9a5b82fe879f53ee0d1bf39cb9027c8
+Subproject commit 24cedaa756b83c50c36f4aa0c625fcdfba89431b
diff --git a/lvgl b/lvgl
index 94c95bc..2ead495 16
--- a/lvgl
+++ b/lvgl
@@ -1 +1 @@
-Subproject commit 94c95bc9e461847a734a5bde9818fa837d343425
+Subproject commit 2ead4959038fcfd01eaee0f124b98a8ae3efec21
-- 
2.16.4

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

Re: [PATCH rtems_littlevgl 1/2] waf: Remove unnecessary code.

[Christian Mauderer]

Hello Vijay,

thanks for the hint and the review. I removed the objects too. Beneath
that I added another patch to use a release version of lvgl.

Best regards

Christian

On 16/03/2020 21:50, Vijay Kumar Banerjee wrote:
> Hi!
> 
> On Wed, Mar 11, 2020 at 7:59 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> ---
>  lvgl.py | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/lvgl.py b/lvgl.py
> index 5452ed0..d6584f7 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -77,12 +77,6 @@ def build(bld):
>          if source_dir not in include_paths:
>              include_paths.append(source_dir)
> 
> -    bld.objects(target = objects,
> -                features = 'c',
> -                cflags = '-O2',
> -                includes = includes,
> -                source = source)
> -
>      bld.stlib(target = 'lvgl',
>                features = 'c',
>                includes = includes,
> 
> 
> I think `use=objects` isn't required either in the next line. This
> builds fine.
> 
> Best regards,
> Vijay
> 
> -- 
> 2.16.4
> 
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 06/05/2020 11:31, Niteesh G. S. wrote:
> On Wed, May 6, 2020 at 2:20 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> Hello Niteesh,
> 
> On 06/05/2020 10:42, Niteesh G. S. wrote:
> > On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee
> mailto:vi...@rtems.org>
> > <mailto:vi...@rtems.org <mailto:vi...@rtems.org>>> wrote:
> >
> >
> >
> >     On Tue, May 5, 2020 at 10:40 PM Niteesh G. S.
> mailto:niteesh...@gmail.com>
> >     <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>>
> wrote:
> >
> >         This is thread is about implementing OFW functions in
> RTEMS as part
> >         of my GSoC project. I would like to start off with this part
> >         since the refactoring
> >         work will somewhat depend on this.
> >
> >         Implementing these functions into RTEMS will make porting
> >         drivers from
> >         FreeBSD to RTEMS easy. Currently, the drivers ported from
> >         freebsd implement
> >         the functions using libfdt variants but this causes a lot of
> >         code duplication.
> >         eg: bsps/arm/imx/start/imx_iomux.c
> >
> >         My initial thoughts were to implement these functions one by
> >         one. But then
> >         Christian and Vijay mentioned about porting them from
> libbsd. I went
> >         through the OFW code in libbsd and have described my porting
> >         process below.
> >         Please have a look at it and let me know if I have missed
> >         something or you
> >         would like to improve things.
> >
> >         The following files will be ported from libbsd
> >         prefix = freebsd/sys/dev/ofw
> >         /openfirm.c
> >         /openfirm.h
> >         /ofw_fdt.c
> >         /ofwvar.h
> >
> >         The main idea is to port openfirm.h but the other files
> >         are dependencies of openfirm.h
> >
> >     Hi Niteesh,
> >
> >     The initial plan of your project was to implement the whole FDT
> >     support on RTEMS,
> >     but there's already support through libbsd, so it might be a
> better
> >     solution to port any
> >     remaining drivers from freebsd through libbsd and adapt the BSP
> >     drivers to use the
> >     freebsd FDT stack. This needs some discussion and input from other
> >     people to form
> >     the right plan and work accordingly.
> >
> >
> > But this would require even the smallest example to link to
> rtems-libbsd.
> > Is it okay for this to happen?
> 
> >From my point of view: No. It would mean that none of the RTEMS tests
> could be build anymore. And I'm not sure whether it would be a good idea
> for applications. There are use cases where you don't need a network
> stack.
> 
> But I'm not the only one with an opinion. So please wait for further
> comments on that.
> 
> > During the proposal period, Hesham also mentioned about this. I
> think the
> > comments are still there in the google docs. And also won't this cause
> > the drivers
> > to initialized only after initialization of libbsd?
> >  
> 
> I think at least some basic drivers have to work before libbsd. For
> example the console.
> 
> Please also take a look at Sebastians suggestion. He mentioned that it
> might could be an idea to import some FreeBSD stuff directly into RTEMS
> with the new build system.
> 
> 
> I am going through the new build system docs and code to understand how
> this importing works.
> https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf
> https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf
> 
> But some more guidance from Sebastian will be really helpful.

Hello Niteesh,

do you have some more specific questions? Do you search for a more
general quick start guide? Or some specific topics?

By the way: I'm new to the new build system too. But I have to learn it
anyway so I'm happy to try to answer questions too.

Best regards

Christian

>  
> 
> >
> >         After going through some open firmware documentation. I
> guess as
> >         far as RTEMS is 
> >         concerned we could avoid many functions like OF_init,
> >         OF_putchar,

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 08/05/2020 23:05, Gedare Bloom wrote:
> On Fri, May 8, 2020 at 9:34 AM Christian Mauderer  wrote:
>>
>>
>> On 08/05/2020 17:26, Niteesh G. S. wrote:
>>> On Fri, May 8, 2020 at 11:43 AM Christian Mauderer
>>> >> <mailto:christian.maude...@embedded-brains.de>> wrote:
>>>
>>>
>>> On 07/05/2020 17:19, Niteesh G. S. wrote:
>>> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
>>> > >> <mailto:sebastian.hu...@embedded-brains.de>
>>> > <mailto:sebastian.hu...@embedded-brains.de
>>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
>>> >
>>> > On 07/05/2020 12:28, Niteesh G. S. wrote:
>>> >
>>> > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
>>> > > >> <mailto:sebastian.hu...@embedded-brains.de>
>>> > <mailto:sebastian.hu...@embedded-brains.de
>>> <mailto:sebastian.hu...@embedded-brains.de>>
>>> > > <mailto:sebastian.hu...@embedded-brains.de
>>> <mailto:sebastian.hu...@embedded-brains.de>
>>> > <mailto:sebastian.hu...@embedded-brains.de
>>> <mailto:sebastian.hu...@embedded-brains.de>>>> wrote:
>>> > >
>>> > > On 07/05/2020 09:35, Niteesh G. S. wrote:
>>> > >
>>> > > > This is what I was trying to convey in one of the previous
>>> > mails.
>>> > > >
>>> https://lists.rtems.org/pipermail/devel/2020-May/059717.html
>>> > > > But in that mail, I was planning to replace KOBJLOOKUP.
>>> > > > Should I start working on it? From the top of my mind, the
>>> > > following has
>>> > > > to be done.
>>> > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c
>>> > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt
>>> are static.
>>> > > > Should we also import ofw_if.h? Because that is where
>>> OFW_*
>>> > > functions
>>> > > > are defined or just add a ofw_rtems_map.h which
>>> redefines them,
>>> > > instead
>>> > > > of importing ofw_if.h?
>>> > >
>>> > > The KOBJ stuff in the OFW support enables FreeBSD to
>>> have three
>>> > > different implementations of the OFW API which can be
>>> selected at
>>> > > runtime:
>>> > >
>>> > > sys/powerpc/ofw/ofw_real.c
>>> > > sys/dev/ofw/ofw_standard.c
>>> > > sys/dev/ofw/ofw_fdt.c
>>> > >
>>> > > In libbsd this is already short cut to the FDT
>>> implementation:
>>> > >
>>> > > #ifndef __rtems__
>>> > > static ofw_def_t*ofw_def_impl = NULL;
>>> > > #else /* __rtems__ */
>>> > > #defineofw_def_impl (_fdt)
>>> > > #endif /* __rtems__ */
>>> > >
>>> > > To me this looks like the KOBJ stuff was just used to
>>> enable some
>>> > > sort
>>> > > of object oriented programming. Do we need this
>>> flexibility at
>>> > > runtime
>>> > > in RTEMS? I would say no. I would hard wire this to the FDT
>>> > > implementation. If someone has a problem with it in the
>>> > future, this
>>> > > decision can be readdressed.
>>> > >
>>> > >
>>> > > Ok. But what is the neatest way to hardwire this to the FDT
>>> > > implementation?
>>> > > One way as Christian mentioned would be to redefine OFW_*
>>> functions to
>>> > > call the functions in ofw_fdt.c directly. Is there any other
>>> way?
>>> >
>>> > I would try to replace the function declarations in openfirm.h
>>> with
>>> > inline functions which call the ofw_fd

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

On 30/08/2020 14:38, Niteesh G. S. wrote:
> Hello,
> 
> On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> On 30/08/2020 08:58, Niteesh G. S. wrote:
> > Hello,
> >
> > I have updated the blog to contain the links to the commits
> > instead of the branches. Please have a look again.
> > https://gs-niteesh.github.io/finalreport/
> 
> >From my point of view, it looks good now. You missed the commit
> with the
> refactored i2c driver:
> 
> Sorry about that. I fixed this. 
> 
> 
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> 
> But if you don't have time left it's not a problem if it isn't there.
> 
> The Submission guidelines tell that "It must be easy to identify the
> work you have done." From my point of view that was already quite clear
> because the commits are all on top of the final branch. But Gedare is of
> course right: Linking every commit is a bit more clear.
> 
> 
> > And sorry to disturb on the weekend,  but we have only about
> > a day left before the submission deadline, so I request
> > everyone to please take a look and let me know if you would
> > like to change anything.
> 
> No problem for disturbing in this case. Don't miss your deadline. It's
> better to submit something that is not perfect than not submitting
> anything. We would have no possibility to fix a missed submission.
> 
> 
> I have to submit it before tomorrow 11:30 PM IST. I'll leave it tonight
> for others to comment and will fill it tomorrow morning.

Be really careful to not miss a deadline. Again: We have no chance of
fixing a missed deadline.

Best regards

Christian

> 
> Thanks,
> Niteesh.
> 
> 
> Best regards
> 
> Christian
> 
> >
> > Thanks,
> > Niteesh.
> >
> > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  <mailto:ged...@rtems.org>
> > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>> wrote:
> >
> >     On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
>     >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> >     >
> >     >
> >     >
> >     > On 29/08/2020 15:04, Niteesh G. S. wrote:
> >     > > Hello,
> >     > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >     > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
> >     > >
> >     > >     Hello Niteesh
> >     > >
> >     > >     On 29/08/2020 11:22, Niteesh G. S. wrote:
> >     > >     > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> >     > >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >     <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>
> >     > >     > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >     <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>>> wrote:
> >     > >     >
> >     > >     >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> >     > >     >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> >     > >     mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>
> >     > >     >     <mailto:ged...@rtems.org
> <mailto:ged...@rtems.org> <mailto:ged...@rtems.org
> <mailto:ged...@rtems.org>>
> >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>>
> >     > >     >     > <mailto:ged...@rtems.org
> <mailto:ged...@rtems.org> <mailto:ged...@rtems.org
&g

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh,

On 30/08/2020 08:58, Niteesh G. S. wrote:
> Hello,
> 
> I have updated the blog to contain the links to the commits
> instead of the branches. Please have a look again.
> https://gs-niteesh.github.io/finalreport/

From my point of view, it looks good now. You missed the commit with the
refactored i2c driver:

https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a

But if you don't have time left it's not a problem if it isn't there.

The Submission guidelines tell that "It must be easy to identify the
work you have done." From my point of view that was already quite clear
because the commits are all on top of the final branch. But Gedare is of
course right: Linking every commit is a bit more clear.

> 
> And sorry to disturb on the weekend,  but we have only about
> a day left before the submission deadline, so I request
> everyone to please take a look and let me know if you would
> like to change anything.

No problem for disturbing in this case. Don't miss your deadline. It's
better to submit something that is not perfect than not submitting
anything. We would have no possibility to fix a missed submission.

Best regards

Christian

> 
> Thanks,
> Niteesh.
> 
> On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> 
> On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> >
> >
> >
> > On 29/08/2020 15:04, Niteesh G. S. wrote:
> > > Hello,
> > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> > >
> > >     Hello Niteesh
> > >
> > >     On 29/08/2020 11:22, Niteesh G. S. wrote:
> > >     > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> > >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> > >     > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
> > >     >
> > >     >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> > >     >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> > >     mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> > >     >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>
> > >     >     > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> > >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>>> wrote:
> > >     >     >
> > >     >     >     Are "Links to commits" 1-4 all the code you (are
> > >     claiming you)
> > >     >     wrote?
> > >     >     >     I just want to make sure. It looks fine to me.
> > >     >     >
> > >     >     > Yes, all the code in the commits is written by me.
> > >     >
> > >     >     I think maybe "Links to branches" would be a better
> title. It
> > >     is not a
> > >     >     single commit each but a few commits. Alternative
> would be to
> > >     add links
> > >     >     to each commit.
> > >     >
> > >     >
> > >     > I have changed the title to "Links to branches". Should I
> also add
> > >     links
> > >     > to the commits that were made in each phase at the end of the
> > >     summary of
> > >     > each phase?
> > >     >
> > >
> > >     If you want, you can do that.
> > >
> > >
> > > I did try that but it didn't work out well, especially with the
> OFW commit.
> > > Since I don't have the old commit I either had to leave that
> commit out
> > > in the first phase or I had to post the newer commit in the
> first phase
> > > itself which actually should in the last phase. So I decided to
> avoid adding
> > > the commits and just leave it out with the branches.
> >
> > That's OK too. Like I said: Mai

Re: AArch64 support and sharing of various drivers

[Christian Mauderer]

Hello Kinsey,

On 01/09/2020 23:56, Kinsey Moore wrote:
> Hi,
> 
> I’ve been working on proper AArch64 support for RTEMS

That's great. It means good raspberry pi 4 support ;-)

> (versus running
> 32-bit ARM RTEMS behind a bootloader or JTAG device that switches the
> CPU to AArch32 mode) and while the vast majority of the architecture
> support code is new, lives in its own aarch64 directories, and is
> unrelated to RTEMS’s ARM support, there are several drivers living in
> the ARM shared directory that are critical to AArch64 support and many
> more that could potentially be shared. Given the limited scope of
> initial bringup on Qemu, that list is currently: GICv3, GPT(timer), and
> PL011(uart). I don’t really see a precedent for this type of sharing
> other than the global bsps/shared and bsps/include directories. The
> global shared directories might make sense for the PL011 since it could
> theoretically be used by anything that supports AXI/AMBA, but the GIC
> and GPT drivers rely on ARM system registers to function with both
> AArch32 and AArch64.
> 
>  
> 
> In short, where should the GICv3 and GPT drivers be relocated along with
> their associated headers, if at all?
> 

I might get a similar problem with some drivers shared between some
PowerPC and ARM too (NXP reuses some of the Freescale PowerPC
peripherals in up to date ARM controllers). I think in theory we already
have such drivers that maybe should be shared but are copied or
re-implemented in multiple BSPs instead.

One possibility might would be to add all arm/shared to the aarch64 too.
But that is a bit unclear.

But as long as the drivers compile for every BSP and are removed at link
time they maybe could just be moved to the general shared directory. We
also have other drivers there that are only used on a few BSPs. For
example the drivers in shared/net/* or shared/dev/ide/*

Best regards

Christian

>  
> 
> Thanks,
> 
> Kinsey Moore
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AArch64 support and sharing of various drivers

[Christian Mauderer]

On 04/09/2020 05:12, Chris Johns wrote:
> On 4/9/20 12:43 pm, Joel Sherrill wrote:
>> On Thu, Sep 3, 2020, 6:58 AM Christian Mauderer
>> > <mailto:christian.maude...@embedded-brains.de>> wrote:
>>
>> Hello Kinsey,
>>
>> On 01/09/2020 23:56, Kinsey Moore wrote:
>> > Hi,
>> >
>> > I’ve been working on proper AArch64 support for RTEMS
>>
>> That's great. It means good raspberry pi 4 support ;-)
>>
>> > (versus running
>> > 32-bit ARM RTEMS behind a bootloader or JTAG device that switches the
>> > CPU to AArch32 mode) and while the vast majority of the architecture
>> > support code is new, lives in its own aarch64 directories, and is
>> > unrelated to RTEMS’s ARM support, there are several drivers living in
>> > the ARM shared directory that are critical to AArch64 support and many
>> > more that could potentially be shared. Given the limited scope of
>> > initial bringup on Qemu, that list is currently: GICv3, GPT(timer), and
>> > PL011(uart). I don’t really see a precedent for this type of sharing
>> > other than the global bsps/shared and bsps/include directories. The
>> > global shared directories might make sense for the PL011 since it could
>> > theoretically be used by anything that supports AXI/AMBA, but the GIC
>> > and GPT drivers rely on ARM system registers to function with both
>> > AArch32 and AArch64.
>> >
>> >  
>> >
>> > In short, where should the GICv3 and GPT drivers be relocated along 
>> with
>> > their associated headers, if at all?
>> >
>>
>> I might get a similar problem with some drivers shared between some
>> PowerPC and ARM too (NXP reuses some of the Freescale PowerPC
>> peripherals in up to date ARM controllers). I think in theory we already
>> have such drivers that maybe should be shared but are copied or
>> re-implemented in multiple BSPs instead.
>>
>> The Gaisler IP drivers were moved up in the tree recently also.
>>
>> One possibility might would be to add all arm/shared to the aarch64 too.
>> But that is a bit unclear
>>
>>
>> shared/arm??
> 
> shared/dev/int
> shared/dev/serial
> 
> ?

shared/dev/ already exist. So maybe wouldn't be a bad choice.

> 
>>
>> shared/nxp
> 
> -1 , companies get taken over and change names.

Agreed. There are still a lot of "freescale/imx" files out there (for
example U-Boot) even if it is NXP since quite some time.

> 
>>
>> Or
>>
>> shared/IP/vendor?

Depends on how you mean that:

Is "vendor" a placeholder so that we for example get a driver

 shared/IP/arm/gicv3.c

In that case: Same problem with company names. Also it's unlikely that
ARM changes the name, it's not impossible. And we will get other vendors
in the same directory.

Or do you mean

shared/IP/vendor/gicv3.c

In that case the directory would be a bit of a big melting pot for all
drivers without any structure.

>>
>> They need to be above a single architecture to be shared across 
>> architectures.
>>
> 
> +1
> 
>> This is just SoC IP modules that are being reused.

Sooner or later we will get more drivers. Like I said: Currently I'm in
the evaluation phase for a project where maybe a DMA is shared between
PowerPC and ARM.

Best regards

Christian

> 
> So should be use the type and then the file names can be the part?
> 
> Chris
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh,

On 31/08/2020 08:23, Niteesh G. S. wrote:
> Hello,
> 
> I have submitted the final eval.
> 
> Thank you, everyone, for all the support throughout the project.

Thank you for your work during GSoC 2020.

> Though I couldn't
> get any of my patches merged.

I'm sure we manage to do that soon (as soon as the new build system is
there).

> I expect to spend a lot of time post-GSoC
> to get
> the work merged and contribute even more :).

That would be great. Feel free to continue asking any questions that you
have.

Best regards

Christian

> 
> Thanks,
> Niteesh. 
> On Sun, Aug 30, 2020 at 8:46 PM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> 
> looks great
> 
> On Sun, Aug 30, 2020 at 6:55 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> >
> > On 30/08/2020 14:38, Niteesh G. S. wrote:
> > > Hello,
> > >
> > > On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> > >
> > >     Hello Niteesh,
> > >
> > >     On 30/08/2020 08:58, Niteesh G. S. wrote:
> > >     > Hello,
> > >     >
> > >     > I have updated the blog to contain the links to the commits
> > >     > instead of the branches. Please have a look again.
> > >     > https://gs-niteesh.github.io/finalreport/
> > >
> > >     >From my point of view, it looks good now. You missed the commit
> > >     with the
> > >     refactored i2c driver:
> > >
> > > Sorry about that. I fixed this.
> > >
> > >   
>  
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> > >
> > >     But if you don't have time left it's not a problem if it
> isn't there.
> > >
> > >     The Submission guidelines tell that "It must be easy to
> identify the
> > >     work you have done." From my point of view that was already
> quite clear
> > >     because the commits are all on top of the final branch. But
> Gedare is of
> > >     course right: Linking every commit is a bit more clear.
> > >
> > >
> > >     > And sorry to disturb on the weekend,  but we have only about
> > >     > a day left before the submission deadline, so I request
> > >     > everyone to please take a look and let me know if you would
> > >     > like to change anything.
> > >
> > >     No problem for disturbing in this case. Don't miss your
> deadline. It's
> > >     better to submit something that is not perfect than not
> submitting
> > >     anything. We would have no possibility to fix a missed
> submission.
> > >
> > >
> > > I have to submit it before tomorrow 11:30 PM IST. I'll leave it
> tonight
> > > for others to comment and will fill it tomorrow morning.
> >
> > Be really careful to not miss a deadline. Again: We have no chance of
> > fixing a missed deadline.
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > Thanks,
> > > Niteesh.
> > >
> > >
> > >     Best regards
> > >
> > >     Christian
> > >
> > >     >
> > >     > Thanks,
> > >     > Niteesh.
> > >     >
> > >     > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom
> mailto:ged...@rtems.org>
> > >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> > >     > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>> wrote:
> > >     >
> > >     >     On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> > >     >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> > >     <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
> > >     >     >
> > >     >     >
> > >     >     >
> > >     >     > On 29/08/2020

Re: Determining Linux Distribution

[Christian Mauderer]

On 10/09/2020 00:25, Chris Johns wrote:
> On 10/9/20 8:15 am, Joel Sherrill wrote:
>> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas > > wrote:
>>
>> On 9/9/20 11:03 PM, Karel Gardas wrote:
>> > so Debian, Kali and OpenSuSE at least are not well handled by this
>> > script and it's quite fun since simple:
>>
>> Can't judge author of the script. The post is from 2008! So I guess
>> /etc/os-release was not so wide spread among the Linuxes at that time...
>>
>> That looks promising and linux.py in rtems-toolkit should be easy to make do 
>> that.
> 
> The code in linux.py that calls platform.dist() should be removed because the
> call has been removed from Python 3 after 3.5.
> 
> Chris

You have seen that there exists a python pip package to find out the
distribution:

https://distro.readthedocs.io/en/latest/

Best regards

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

Re: Determining Linux Distribution

[Christian Mauderer]

On 10/09/2020 18:31, Joel Sherrill wrote:
> 
> 
> On Thu, Sep 10, 2020 at 11:09 AM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> On 10/09/2020 00:25, Chris Johns wrote:
> > On 10/9/20 8:15 am, Joel Sherrill wrote:
> >> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas
> mailto:karel.gar...@centrum.cz>
> >> <mailto:karel.gar...@centrum.cz
> <mailto:karel.gar...@centrum.cz>>> wrote:
> >>
> >>     On 9/9/20 11:03 PM, Karel Gardas wrote:
> >>     > so Debian, Kali and OpenSuSE at least are not well handled
> by this
> >>     > script and it's quite fun since simple:
> >>
> >>     Can't judge author of the script. The post is from 2008! So I
> guess
> >>     /etc/os-release was not so wide spread among the Linuxes at
> that time...
> >>
> >> That looks promising and linux.py in rtems-toolkit should be easy
> to make do that.
> >
> > The code in linux.py that calls platform.dist() should be removed
> because the
> > call has been removed from Python 3 after 3.5.
> >
> > Chris
> 
> You have seen that there exists a python pip package to find out the
> distribution:
> 
> https://distro.readthedocs.io/en/latest/
> 
> 
> I assume we don't want to assume someone will use pip to load a package
> to use the RSB or rtems-tools.  Copying it into our tree gives us a package
> that will periodically need to be updated.
> 
> Chris.. what do you want to do?
> 
> --joel
>  

If it's not a critical information most likely we can also just do a
`uname` and a `cat /etc/os.release` or similar. That will cover _most_
modern distributions.

Best regards

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

[PATCH rtems-libbsd 2/2] imx: Remove ccm functions alredy defined in RTEMS

[Christian Mauderer]

The imx_ccm_*_hz are all defined in RTEMS. So don't duplicate them in
libbsd. Otherwise some applications get linker errors.

Update #3869
---
 freebsd/sys/arm/freescale/imx/imx6_ccm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index 78bbd5c1..7fdb69b8 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -368,6 +368,7 @@ imx6_ccm_sata_enable(void)
return 0;
 }
 
+#ifndef __rtems__
 uint32_t
 imx_ccm_ecspi_hz(void)
 {
@@ -408,6 +409,7 @@ imx_ccm_ahb_hz(void)
 {
return (13200);
 }
+#endif /* __rtems__ */
 
 void
 imx_ccm_ipu_enable(int ipu)
-- 
2.26.2

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

[PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Christian Mauderer]

Some bits are in the wrong order. Beneath that, the interrupts can occur
in an unexpected order. The DATA_AVAIL interrupt can occur at the same
time as the DMA interrupt (or slightly before it). With that, the DMA
and PIO interrupt handling doesn't work well together. Beneath that the
DMA interrupt isn't only executed at block ends but also if all data is
transfered. That can lead to problems with the DATA_END interrupt.
Therefore check whether there is really data left to unload.

Update #3869
---
 freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
 freebsd/sys/dev/sdhci/sdhci.c | 40 ++
 2 files changed, 81 insertions(+)

diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
b/freebsd/sys/dev/sdhci/fsl_sdhci.c
index be3d1de3..acef1c4a 100644
--- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
+++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
@@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
 #endif /* __rtems__ */
 #endif
 
+#ifndef __rtems__
+#include 
+#endif /* __rtems__ */
 #include 
 
 #include 
@@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
 #define SDHC_PROT_CDSS (1 << 7)
 
 #defineSDHC_SYS_CTRL   0x2c
+#ifdef __rtems__
+
+/*
+ * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead of
+ * bit 25 which would be standard.
+ */
+#define SDHC_INT_DMAES (1 << 28)
+
+#define SDHC_CAN_DO_ADMA2  0x0010
+#endif /* __rtems__ */
 
 /*
  * The clock enable bits exist in different registers for ESDHC vs USDHC, but
@@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off)
val32 &= ~SDHCI_CAN_VDD_180;
val32 &= ~SDHCI_CAN_DO_SUSPEND;
val32 |= SDHCI_CAN_DO_8BITBUS;
+#ifdef __rtems__
+   /*
+* Freescale signals ADMA2 capability via bit 20 (which would be
+* ADMA1) instead of 19.
+*/
+   if (val32 & SDHC_CAN_DO_ADMA2) {
+   val32 &= ~SDHC_CAN_DO_ADMA2;
+   val32 |= SDHCI_CAN_DO_ADMA2;
+   }
+#endif /* __rtems__ */
return (val32);
}

@@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off)
 * command with an R1B response, mix it into the hardware status.
 */
if (off == SDHCI_INT_STATUS) {
+#ifdef __rtems__
+   /* Fix messed up DMA error. */
+   if (val32 & SDHC_INT_DMAES) {
+   val32 &= ~SDHC_INT_DMAES;
+   val32 |= SDHCI_INT_ADMAERR;
+   }
+#endif /* __rtems__ */
return (val32 | sc->r1bfix_intmask);
}
 
@@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off, uint32_
if (off == SDHCI_INT_STATUS) {
sc->r1bfix_intmask &= ~val;
}
+#ifdef __rtems__
+   /* Fix messed up DMA error. */
+   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
SDHCI_SIGNAL_ENABLE) {
+   if (val & SDHCI_INT_ADMAERR) {
+   val &= ~SDHCI_INT_ADMAERR;
+   val |= SDHC_INT_DMAES;
+   }
+   }
+#endif /* __rtems__ */
 
WR4(sc, off, val);
 }
@@ -884,10 +923,12 @@ fsl_sdhci_attach(device_t dev)
 
sc->slot.quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
 
+#if !defined(__rtems__) || !defined(LIBBSP_ARM_IMX_BSP_H)
/*
 * DMA is not really broken, I just haven't implemented it yet.
 */
sc->slot.quirks |= SDHCI_QUIRK_BROKEN_DMA;
+#endif /* __rtems__ */
 
/*
 * Set the buffer watermark level to 128 words (512 bytes) for both read
diff --git a/freebsd/sys/dev/sdhci/sdhci.c b/freebsd/sys/dev/sdhci/sdhci.c
index ed6010e8..53d86fe8 100644
--- a/freebsd/sys/dev/sdhci/sdhci.c
+++ b/freebsd/sys/dev/sdhci/sdhci.c
@@ -68,6 +68,9 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
 SYSCTL_NODE(_hw, OID_AUTO, sdhci, CTLFLAG_RD, 0, "sdhci driver");
 
@@ -766,6 +769,17 @@ sdhci_dma_alloc(struct sdhci_slot *slot)
else
slot->sdma_boundary = SDHCI_BLKSZ_SDMA_BNDRY_512K;
}
+#ifdef __rtems__
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+   /*
+* i.MX6ULL doesn't have the SDMA Buffer Boundary bits. Instead the
+* BLKSIZE is one bit larger and would overlap the Buffer Boundary.
+* Setting the Buffer Boundary to 4K makes sure that the highest BLKSIZE
+* bit is always 0.
+*/
+   slot->sdma_boundary = SDHCI_BLKSZ_SDMA_BNDRY_4K;
+#endif
+#endif /* __rtems__ */
slot->sdma_bbufsz = SDHCI_SDMA_BNDRY_TO_BBUFSZ(slot->sdma_boundary);
 
/*
@@ -1896,6 +1910,10 @@ sdhci_start_data(struct sdhci_slot *slot, const struct 
mmc_data *data)
BUS_DMASYNC_PREWRITE);
}

Re: BSP Test Results

[Christian Mauderer]

On 09/09/2020 02:29, Chris Johns wrote:
[...]
> 
>> > Also I am not sure but hopefully the test reports do accurately reflect
>> host OS.
>>
>> There is a "Host" section at the top of the results log? It is just 
>> `uname -a`.
>>
>> I think that's sufficient as long as it can distinguish Linux distributions. 
> 
> Does Linux or Python on Linux provide a common means to find what distribution
> you are on? Do distributions based on another distro make a suitable the
> separation? A Linux distro expert will need to guide this. I have no idea.
> 

In theory there is the platform.linux_distribution() in python:

https://docs.python.org/3.7/library/platform.html#module-platform

But on my OpenSUSE 15.1 that failed to provide anything. Beneath that it
seems to be deprecated since Python 3.5.

A newer package that want to provide this functionality is "distro":

https://distro.readthedocs.io/en/latest/

Beneath that module, there is "/etc/os-release". It's a standard file
for systemd. So most likely most distros have it now:

https://www.freedesktop.org/software/systemd/man/os-release.html

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Virus Warning

[Christian Mauderer]

Hello,

I assume that most of you are careful anyway. But nonetheless a virus
warning: I received a message that pretends to be an answer to a RTEMS
mailing list post. The mail has a .doc file attached that contains a
virus. Text of the mail is:

--
Good afternoon!
It is regarding our recent conversation. Here is edits you have advised
to do:


--

I only received one such message per registered mail account. It
references some random conversations from about April 2020. The fake
mail is addressed directly to me (not to the list).

If you want to know more about the virus, see:

https://www.virustotal.com/gui/file/2e773d1c57ad270fa94ab01d98649f3c12b8d8b6b1cf007fbd7c1c8954a0a5b8/detection

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Build System Status

[Christian Mauderer]

On 11/09/2020 09:19, Chris Johns wrote:
> On 11/9/20 5:14 pm, Sebastian Huber wrote:
>> are there any remaining issues which prevent the new build system from being
>> integrated? At the moment I just sit idle and wait. If there are technical
>> issues, I can fix them only if I know them.
> 
> I have none.

Hello Sebastian,

I think there has been one patch for libbsd that was necessary when
building the BSP with the new build system. You created it somewhen
during summer and I used it in a test build for a GSoC project:

https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7

Beneath that I had no build system related problems for the BBB BSP.

Best regards

Christian

> 
>> I have a BSP using the new build system for the STM32H7 chips with Ethernet 
>> and
>> USB host support waiting for integration since April this year.
> 
> I have the C++ threads with attributes patch I posted last year waiting to be
> merged...
> 
> https://lists.rtems.org/pipermail/devel/2019-December/056436.html
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: We are loosing patches

[Christian Mauderer]

Hello Jan and Joel,

On 09/09/2020 15:19, Joel Sherrill wrote:
> 
> 
> On Wed, Sep 9, 2020 at 3:43 AM  <mailto:jan.som...@dlr.de>> wrote:
> 
> I would like this idea.
> We got Gitlab this year and collaboration with it is pretty convenient.
> They also seem to hand out free licenses for OSS projects.
> I guess installing and maintaining an instance is probably quite
> some work.
> 
> 
> We use Gitlab community edition internally. On a recent non-RTEMS project, 
> we pushed the Continuous Integration and Testing pretty hard. We built, 
> tested, and did coverage for 4 configurations of the software for 3
> different 
> Linux distributions using Docker on every push. We built Doxygen every time
> and ran the FACE Conformance Test Suite on multiple components. Plus 
> had a  commercial tool that did MISRA/CERT compliance checking and MCDC
> coverage analysis. Everything ran well but the commercial tool took a 
> fair amount of babying. 
> 
> We didn't use it for patch management though. We just required issues
> and you had to pass the CIT to merge. We did use milestones for light
> project management but only the basics of the ticketing system.
> 
> One challenge RTEMS has with automated testing is the turnaround time. 
> On the project I mentioned, everything took only a few minutes except the 
> commercial tool which ended up taking 30 minutes. For RTEMS, building 
> and testing everything is quite time consuming. The script I run takes
> about 
> 1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test 
> anything on hardware in that cycle. Because of this, the testing part of CIT
> for RTEMS will likely always only be spot checking. But we could put more 
> emphasis on say Doxygen builds always being warning free and the critical 
> BSPs that are spot checked being warning free.  
> 
> The "critical set of BSPs" to be spot checked is up for discussion but 
> ideally they would run on simulators and represent a realistic but broad 
> subset. That makes the long version of the list something like sparc/leon3, 
> arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904. 
> 
> This was a long reply to just cover what I think we could do for CIT on
> the RTEMS repo. Considering rtems-docs, examples, etc. adds other 
> options.

Also I agree that automated builds or checks could be an extension, that
is not really the core point. Part of these automated builds are already
done by buildbot.rtems.org.

> 
> Back to the patch management system.

That's the part that (at the moment) was the starting point of my mail.

> 
> We have discussed having Patchwork and Phabricator in the past. I don't
> know if there is a true resistance to using such a tool but a lack of time.
> All system administration on rtems.org <http://rtems.org> is volunteer. 
> That by itself is the
> biggest barrier. 

Regarding the administrative effort: I'm well aware that there is a lot
of work. And if my request adds additional workload, we should discuss
who can do that or how it can be funded. But I don't think that it is a
good situation that patches get lost or that _new_ contributors have to
ping a mail because no one has seen it between lot's of other mails.
Patches are valuable and they are the entry point for every new member
of our community.

Beneath that: Our time is valuable too. If systems can collect all
relevant information for one patch set (including earlier versions,
comments, ...): Why do we waste so much time with searching that kind of
stuff on the mailing list. If you just have to use a single command to
apply the latest version of a patch set: Why do we have to find and
download the patches from the mailing list, apply them locally to the
correct repo, make sure that we did the right thing and then push them.

So please let's not jump right into the administrative part of the
system or how many work it maybe would be to implement it. Let's first
find out whether a big part of our community could agree to a more
modern approach of handling patches that can save time for contributors
and maintainers. As soon as we have one: Let's talk about what is
necessary to reach that solution. If it is a step forward, I'm sure we
will find a solution to handle the initial effort.

Best regards

Christian

> 
> --joel
> 
> Ph
> Best regards,
> 
>    Jan
> 
> > -Original Message-
> > From: devel  <mailto:devel-boun...@rtems.org>> On Behalf Of Christian Mauderer
> > Sent: Wednesday, September 9, 2020 10:24 AM
> > To: RTEMS Devel RTEMS mailto:devel@rtems.org>>
> > Subject: We are loosing patches
> >
> > Hello,
> >
> > triggered by a comment from Chris here
> >

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Christian Mauderer]

Hello Gedare,

I'll have to rework some parts (the ones where I checked for the BSP)
but I'll try.

Best regards

Christian

On 09/09/2020 17:58, Gedare Bloom wrote:
> Can this be pushed upstream in a non-RTEMS specific way?
> 
> On Wed, Sep 9, 2020 at 5:16 AM Christian Mauderer
>  wrote:
>>
>> Some bits are in the wrong order. Beneath that, the interrupts can occur
>> in an unexpected order. The DATA_AVAIL interrupt can occur at the same
>> time as the DMA interrupt (or slightly before it). With that, the DMA
>> and PIO interrupt handling doesn't work well together. Beneath that the
>> DMA interrupt isn't only executed at block ends but also if all data is
>> transfered. That can lead to problems with the DATA_END interrupt.
>> Therefore check whether there is really data left to unload.
>>
>> Update #3869
>> ---
>>  freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
>>  freebsd/sys/dev/sdhci/sdhci.c | 40 ++
>>  2 files changed, 81 insertions(+)
>>
>> diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
>> b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>> index be3d1de3..acef1c4a 100644
>> --- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
>> +++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>> @@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
>>  #endif /* __rtems__ */
>>  #endif
>>
>> +#ifndef __rtems__
>> +#include 
>> +#endif /* __rtems__ */
>>  #include 
>>
>>  #include 
>> @@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
>>  #define SDHC_PROT_CDSS (1 << 7)
>>
>>  #defineSDHC_SYS_CTRL   0x2c
>> +#ifdef __rtems__
>> +
>> +/*
>> + * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead 
>> of
>> + * bit 25 which would be standard.
>> + */
>> +#define SDHC_INT_DMAES (1 << 28)
>> +
>> +#define SDHC_CAN_DO_ADMA2  0x0010
>> +#endif /* __rtems__ */
>>
>>  /*
>>   * The clock enable bits exist in different registers for ESDHC vs USDHC, 
>> but
>> @@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
>> bus_size_t off)
>> val32 &= ~SDHCI_CAN_VDD_180;
>> val32 &= ~SDHCI_CAN_DO_SUSPEND;
>> val32 |= SDHCI_CAN_DO_8BITBUS;
>> +#ifdef __rtems__
>> +   /*
>> +* Freescale signals ADMA2 capability via bit 20 (which 
>> would be
>> +* ADMA1) instead of 19.
>> +*/
>> +   if (val32 & SDHC_CAN_DO_ADMA2) {
>> +   val32 &= ~SDHC_CAN_DO_ADMA2;
>> +   val32 |= SDHCI_CAN_DO_ADMA2;
>> +   }
>> +#endif /* __rtems__ */
>> return (val32);
>> }
>>
>> @@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
>> bus_size_t off)
>>  * command with an R1B response, mix it into the hardware status.
>>  */
>> if (off == SDHCI_INT_STATUS) {
>> +#ifdef __rtems__
>> +   /* Fix messed up DMA error. */
>> +   if (val32 & SDHC_INT_DMAES) {
>> +   val32 &= ~SDHC_INT_DMAES;
>> +   val32 |= SDHCI_INT_ADMAERR;
>> +   }
>> +#endif /* __rtems__ */
>> return (val32 | sc->r1bfix_intmask);
>> }
>>
>> @@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot 
>> *slot, bus_size_t off, uint32_
>> if (off == SDHCI_INT_STATUS) {
>> sc->r1bfix_intmask &= ~val;
>> }
>> +#ifdef __rtems__
>> +   /* Fix messed up DMA error. */
>> +   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
>> SDHCI_SIGNAL_ENABLE) {
>> +   if (val & SDHCI_INT_ADMAERR) {
>> +   val &= ~SDHCI_INT_ADMAERR;
>> +   val |= SDHC_INT_DMAES;
>> +   }
>> +   }
>> +#endif /* __rtems__ */
>>
>> WR4(sc, off, val);
>>  }
>> @@ -884,10 +923,12 @@ fsl_sdhci_attach(device_t dev)
>>
>> sc->slot.quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
>>
>> +#if !defined(__rtems__) || !defined(LIBBSP_ARM_IMX_BSP_H)
>> /*
>>  * DMA is not really broken, I just haven't implemented it yet.
>>  */
>> sc->slot.quirks |= SDHCI_QUIRK_BROKEN_DMA;
>> +#endif /* 

Re: We are loosing patches

[Christian Mauderer]

On 09/09/2020 17:52, Gedare Bloom wrote:
> On Wed, Sep 9, 2020 at 8:16 AM Christian Mauderer
>  wrote:
>>
>> Hello Jan and Joel,
>>
>> On 09/09/2020 15:19, Joel Sherrill wrote:
>>>
>>>
>>> On Wed, Sep 9, 2020 at 3:43 AM >> <mailto:jan.som...@dlr.de>> wrote:
>>>
>>> I would like this idea.
>>> We got Gitlab this year and collaboration with it is pretty convenient.
>>> They also seem to hand out free licenses for OSS projects.
>>> I guess installing and maintaining an instance is probably quite
>>> some work.
>>>
>>>
>>> We use Gitlab community edition internally. On a recent non-RTEMS project,
>>> we pushed the Continuous Integration and Testing pretty hard. We built,
>>> tested, and did coverage for 4 configurations of the software for 3
>>> different
>>> Linux distributions using Docker on every push. We built Doxygen every time
>>> and ran the FACE Conformance Test Suite on multiple components. Plus
>>> had a  commercial tool that did MISRA/CERT compliance checking and MCDC
>>> coverage analysis. Everything ran well but the commercial tool took a
>>> fair amount of babying.
>>>
>>> We didn't use it for patch management though. We just required issues
>>> and you had to pass the CIT to merge. We did use milestones for light
>>> project management but only the basics of the ticketing system.
>>>
>>> One challenge RTEMS has with automated testing is the turnaround time.
>>> On the project I mentioned, everything took only a few minutes except the
>>> commercial tool which ended up taking 30 minutes. For RTEMS, building
>>> and testing everything is quite time consuming. The script I run takes
>>> about
>>> 1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test
>>> anything on hardware in that cycle. Because of this, the testing part of CIT
>>> for RTEMS will likely always only be spot checking. But we could put more
>>> emphasis on say Doxygen builds always being warning free and the critical
>>> BSPs that are spot checked being warning free.
>>>
>>> The "critical set of BSPs" to be spot checked is up for discussion but
>>> ideally they would run on simulators and represent a realistic but broad
>>> subset. That makes the long version of the list something like sparc/leon3,
>>> arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904.
>>>
>>> This was a long reply to just cover what I think we could do for CIT on
>>> the RTEMS repo. Considering rtems-docs, examples, etc. adds other
>>> options.
>>
>> Also I agree that automated builds or checks could be an extension, that
>> is not really the core point. Part of these automated builds are already
>> done by buildbot.rtems.org.
>>
>>>
>>> Back to the patch management system.
>>
>> That's the part that (at the moment) was the starting point of my mail.
>>
>>>
>>> We have discussed having Patchwork and Phabricator in the past. I don't
>>> know if there is a true resistance to using such a tool but a lack of time.
>>> All system administration on rtems.org <http://rtems.org> is volunteer.
>>> That by itself is the
>>> biggest barrier.
>>
>> Regarding the administrative effort: I'm well aware that there is a lot
>> of work. And if my request adds additional workload, we should discuss
>> who can do that or how it can be funded. But I don't think that it is a
>> good situation that patches get lost or that _new_ contributors have to
>> ping a mail because no one has seen it between lot's of other mails.
>> Patches are valuable and they are the entry point for every new member
>> of our community.
>>
>> Beneath that: Our time is valuable too. If systems can collect all
>> relevant information for one patch set (including earlier versions,
>> comments, ...): Why do we waste so much time with searching that kind of
>> stuff on the mailing list. If you just have to use a single command to
>> apply the latest version of a patch set: Why do we have to find and
>> download the patches from the mailing list, apply them locally to the
>> correct repo, make sure that we did the right thing and then push them.
>>
>> So please let's not jump right into the administrative part of the
>> system or how many work it maybe would be to implement it. Let's first
>> find out whether a big part of our community could agree to a more
>> modern 

Re: New build system ready for testing

[Christian Mauderer]

Hello Sebastian,

I get a linker error when I try to build libbsd for BBB (with a buildset that 
builds everything but netipsec):

-
/home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld:
 ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio':
/home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1813:
 undefined reference to `PHYS_TO_VM_PAGE'
/home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld:
 
/home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1814:
 undefined reference to `uiomove_fromphys'
collect2: error: ld returned 1 exit status
-

Configure line for libbsd is:

./waf configure \
--prefix=/home/EB/christian_m/Projekte/rtems-bbb//install/rtems/6 \
--rtems-bsps=arm/beagleboneblack \

--buildset=/home/EB/christian_m/Projekte/rtems-bbb//build/src/noipsec.ini \
--enable-warnings \
--optimization=2 \
--rtems-version=6

Adding your patch from ages ago to libbsd works to solve that:


https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7.patch

But you haven't applied it to the libbsd master. So I assume that there is a 
better workaround for that problem? What's the correct solution?

Best regards

Christian

On 14/09/2020 09:07, Sebastian Huber wrote:
> Hello,
> 
> I checked in the new build system today. Now is a good time to test your
> favourite BSP if it still works. You find the user oriented
> documentation of build system here:
> 
> https://docs.rtems.org/branches/master/user/bld/index.html
> 
> The documentation for RTEMS maintainers is here:
> 
> https://docs.rtems.org/branches/master/eng/build-system.html
> 
> How to check the new build system for a particular BSP?
> 
> 1. Build the BSP with all tests enabled.
> 
> 2. Run the tests and compare the results with the old build system.
> Ideally use the RTEMS Tester to run the tests and report them to the
> RTEMS Project.
> 
> 3. Check if all BSP options are available (./waf bsp_defaults). Check
> the type and values of the BSP options.
> 
> 4. Check the linker command file.
> 
> 5. Check the compiler machine flags.
> 
> 6. Install the BSP and build your third-party libraries and applications
> with it.
> 

-- 
 
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim   
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

We are loosing patches

[Christian Mauderer]

Hello,

triggered by a comment from Chris here

https://lists.rtems.org/pipermail/users/2020-September/067873.html

I started to take a look at patches from non maintainers and write after
approval maintainers for some months: I think in May and June we lost at
least one or two of the following ones:

https://lists.rtems.org/pipermail/devel/2020-May/059751.html
https://lists.rtems.org/pipermail/devel/2020-May/059771.html
https://lists.rtems.org/pipermail/devel/2020-May/059772.html
https://lists.rtems.org/pipermail/devel/2020-May/059773.html
https://lists.rtems.org/pipermail/devel/2020-June/060125.html
https://lists.rtems.org/pipermail/devel/2020-June/060231.html
https://lists.rtems.org/pipermail/devel/2020-June/060235.html

It's a bit hard to see exactly whether a later version has been added
with a different subject, merged with another patch or just has been
rejected for some reason. That's another problem with our current system.

I think we start to loose valuable contributions due to that. I also
found some patches where just no one responded because no one noted it
and the person sending the patch had to ping it some time later. That's
not really encouraging to continue participating for new contributors.

I even lost track of some of my own patches in the past and found out
about a month later that I should have pushed them long ago.

Maybe it would be a good idea to start at least discussing whether we
should change something to avoid these problems. I think our current
system has two main problems:

1. All patches go to one single devel mailing list. It's sometimes hard
to see which patches are for what repository. And small patches tend to
just vanish between lot of other mails.

2. We have a big problem seeing which patch sets are done, which are in
the middle of a discussion and which are rejected.

A lot of other projects use software to solve these problems. Linux uses
"patchwork" for it since a long time (which needs one mailing list per
project). Most other projects use systems with pull requests like github
or a self hosted gitlab for that kind of stuff.

Maybe we should think about following these examples and go one step to
more modern software development too? What do you think?

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Christian Mauderer]

Hello Gedare,

I created a ticket for this in FreeBSD (I really hope I picked the right
way for this). I'll wait whether it needs some adaption and then re-send
an adapted patch for libbsd as soon as I have a version that is accepted
in FreeBSD.

Best regards

Christian

On 10/09/2020 09:05, Christian Mauderer wrote:
> Hello Gedare,
> 
> I'll have to rework some parts (the ones where I checked for the BSP)
> but I'll try.
> 
> Best regards
> 
> Christian>
> On 09/09/2020 17:58, Gedare Bloom wrote:
>> Can this be pushed upstream in a non-RTEMS specific way?
>>
>> On Wed, Sep 9, 2020 at 5:16 AM Christian Mauderer
>>  wrote:
>>>
>>> Some bits are in the wrong order. Beneath that, the interrupts can occur
>>> in an unexpected order. The DATA_AVAIL interrupt can occur at the same
>>> time as the DMA interrupt (or slightly before it). With that, the DMA
>>> and PIO interrupt handling doesn't work well together. Beneath that the
>>> DMA interrupt isn't only executed at block ends but also if all data is
>>> transfered. That can lead to problems with the DATA_END interrupt.
>>> Therefore check whether there is really data left to unload.
>>>
>>> Update #3869
>>> ---
>>>  freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
>>>  freebsd/sys/dev/sdhci/sdhci.c | 40 ++
>>>  2 files changed, 81 insertions(+)
>>>
>>> diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
>>> b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>>> index be3d1de3..acef1c4a 100644
>>> --- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
>>> +++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>>> @@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
>>>  #endif /* __rtems__ */
>>>  #endif
>>>
>>> +#ifndef __rtems__
>>> +#include 
>>> +#endif /* __rtems__ */
>>>  #include 
>>>
>>>  #include 
>>> @@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
>>>  #define SDHC_PROT_CDSS (1 << 7)
>>>
>>>  #defineSDHC_SYS_CTRL   0x2c
>>> +#ifdef __rtems__
>>> +
>>> +/*
>>> + * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead 
>>> of
>>> + * bit 25 which would be standard.
>>> + */
>>> +#define SDHC_INT_DMAES (1 << 28)
>>> +
>>> +#define SDHC_CAN_DO_ADMA2  0x0010
>>> +#endif /* __rtems__ */
>>>
>>>  /*
>>>   * The clock enable bits exist in different registers for ESDHC vs USDHC, 
>>> but
>>> @@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot 
>>> *slot, bus_size_t off)
>>> val32 &= ~SDHCI_CAN_VDD_180;
>>> val32 &= ~SDHCI_CAN_DO_SUSPEND;
>>> val32 |= SDHCI_CAN_DO_8BITBUS;
>>> +#ifdef __rtems__
>>> +   /*
>>> +* Freescale signals ADMA2 capability via bit 20 (which 
>>> would be
>>> +* ADMA1) instead of 19.
>>> +*/
>>> +   if (val32 & SDHC_CAN_DO_ADMA2) {
>>> +   val32 &= ~SDHC_CAN_DO_ADMA2;
>>> +   val32 |= SDHCI_CAN_DO_ADMA2;
>>> +   }
>>> +#endif /* __rtems__ */
>>> return (val32);
>>> }
>>>
>>> @@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot 
>>> *slot, bus_size_t off)
>>>  * command with an R1B response, mix it into the hardware status.
>>>  */
>>> if (off == SDHCI_INT_STATUS) {
>>> +#ifdef __rtems__
>>> +   /* Fix messed up DMA error. */
>>> +   if (val32 & SDHC_INT_DMAES) {
>>> +   val32 &= ~SDHC_INT_DMAES;
>>> +   val32 |= SDHCI_INT_ADMAERR;
>>> +   }
>>> +#endif /* __rtems__ */
>>> return (val32 | sc->r1bfix_intmask);
>>> }
>>>
>>> @@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot 
>>> *slot, bus_size_t off, uint32_
>>> if (off == SDHCI_INT_STATUS) {
>>> sc->r1bfix_intmask &= ~val;
>>> }
>>> +#ifdef __rtems__
>>> +   /* Fix messed up DMA error. */
>>> +   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
>>> SDHCI_SIGNAL_ENAB

Re: Legacy networking stack removal

[Christian Mauderer]

oject into the direction of
lwIP we should try to create a package repo so it can be build without a
lot of effort.

> 
> Unfortunately, this is a case where the RTEMS core developers are too
> nice. We don't want to leave users wanting. Many projects would have
> killed the old stack before now.  And I think it is long overdue for us. :)

Do you ask us to be a bit less nice to users? I'll have to create a link
so that I can reference this statement the next time we discuss a change
that could break something for users ;-)

Best regards

Christian

> 
> I am thinking 4-6 weeks after the transition from autoconf to waf, the
> stack should come out. With any luck, this will be in December.  Moving
> to waf is an ideal time to clean cruft and being just after the 5
> release, we left things in for that last release if that's what the
> outcome is.
> 
> --joel
> 
> 
> Peter
> -
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
> 
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd] wpa: Fix multiple definition of `hmac_md5`

[Christian Mauderer]

hmac_md5 is defined in dhcpcd and in wpa supplicant.
---
 freebsd/contrib/wpa/src/crypto/md5.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/freebsd/contrib/wpa/src/crypto/md5.h 
b/freebsd/contrib/wpa/src/crypto/md5.h
index 33f8426c..48afb955 100644
--- a/freebsd/contrib/wpa/src/crypto/md5.h
+++ b/freebsd/contrib/wpa/src/crypto/md5.h
@@ -11,6 +11,10 @@
 
 #define MD5_MAC_LEN 16
 
+#ifdef __rtems__
+#define hmac_md5_vectorwpa_hmac_md5_vector
+#define hmac_md5   wpa_hmac_md5
+#endif /* __rtems__ */
 int hmac_md5_vector(const u8 *key, size_t key_len, size_t num_elem,
const u8 *addr[], const size_t *len, u8 *mac);
 int hmac_md5(const u8 *key, size_t key_len, const u8 *data, size_t data_len,
-- 
2.28.0

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

Re: Announce: RTEMS 5.1 Release

[Christian Mauderer]

On 26/08/2020 07:45, Chris Johns wrote:
> On 26/8/20 3:09 pm, me wrote:
>>> On 26/08/2020, at 1:04 PM, Chris Johns  wrote:
>>> Yes the plan is to have the waf build system in the RTEMS 6 release.
>> Cool, could you point me to a link of the RTEMS 6?
> 
> https://devel.rtems.org/wiki/Release/6
> 
> The waf build system is still under development in Sebastian's personal repo 
> ...
> 
> https://git.rtems.org/sebh/rtems.git/?h=build-2
> 
> It is either the build or build-2 branch. I am sorry I do not know which it 
> is.
> 
> Chris

You might also want to have a look at the new manuals. Sebastian has a
temporary version here:

https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf

https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

On 18/08/2020 11:25, Niteesh G. S. wrote:
> How can we make this API FreeBSD compatible? We have to declare
> defines for the OFW functions
> Eg. #define OF_finddevice rtems_ofw_find_device

I think that was the plan, wasn't it?

> 
> Should I change the openfirm.h in libBSD to this use these defines instead
> of calling the functions in openfirm.c? Though there are some
> functions which
> for which this cannot be done.
> Eg: OF_device_from_xref
> For this, we will have to use the implementation present in openfirm.c

At least as long as no one implements a replacement, yes.

> 
> 
> On Tue, Aug 18, 2020 at 7:57 AM Chris Johns  > wrote:
> 
> On 17/8/20 2:57 pm, Niteesh G. S. wrote:
> > On Mon, Aug 17, 2020 at 3:49 AM Chris Johns  
> > >> wrote:
> >
> >     On 16/8/20 11:19 pm, Niteesh G. S. wrote:
> >     >
> >     > On Sun, Aug 16, 2020 at 2:25 PM Chris Johns
> mailto:chr...@rtems.org>
> >     >
> >     > 
>  >     >
> >     >     On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> >     >     > ---
> >     >
> >     >     > +
> >     >     > +#ifdef HAVE_CONFIG_H
> >     >     > +#include "config.h"
> >     >     > +#endif
> >     >     > +
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +
> >     >     > +const void *fdtp = NULL;
> >     >     > +
> >     >     > +static phandle_t rtems_fdt_offset_to_phandle( int
> offset )
> >     >     > +{
> >     >     > +  if (offset < 0) {
> >     >     > +    return 0;
> >     >     > +  }
> >     >     > +
> >     >     > +  return (phandle_t)offset + fdt_off_dt_struct(fdtp);
> >     >     > +}
> >     >     > +
> >     >     > +static int rtems_fdt_phandle_to_offset( phandle_t
> handle )
> >     >     > +{
> >     >     > +  int off;
> >     >     > +  int fdt_off;
> >     >     > +
> >     >     > +  off = (int) handle;
> >     >     > +  fdt_off = fdt_off_dt_struct(fdtp);
> >     >     > +
> >     >     > +  if (off < fdt_off) {
> >     >     > +    return -1;
> >     >     > +
> >     >     > +  }
> >     >     > +
> >     >     > +  return off - fdt_off;
> >     >     > +}
> >     >     > +
> >     >     > +static void rtems_ofw_init( void ) {
> >     >     > +  int rv;
> >     >     > +  const void *fdt;
> >     >     > + 
> >     >     > +  fdt = bsp_fdt_get();
> >     >     > +
> >     >     > +  rv = fdt_check_header(fdt);
> >     >     > +
> >     >     > +  /*
> >     >     > +   * Is assert a good option to handle error?
> >     >     > +   * AFIAK there is no other way to recover from
> invalid FDT.
> >     >     > +   * On providing an invalid FDT most driver's will
> fail/crash anyway.
> >     >     > +   */
> >     >
> >     >     If you want to fail with an error I suggest a documented
> internal error. I
> >     >     however would prefer we fail in degraded manner but I
> understand this
> >     may not be
> >     >     possible.
> >     >
> >     >
> >     > During the initial discussion, we discussed adding a new
> error code in
> >     case of an
> >     > invalid FDT, something like BSP_INVALID_FDT. I had also sent
> a patch but
> >     then we
> >     > decided not to add one(for some reason that I don't
> remember). Instead, use
> >     > RTEMS_NOT_CONFIGURED. This has also been used in my previous
> OFW patch.
> >
> >     I am sorry I missed the discussion or I would have commented.
> Currently the FDT
> >     support in RTEMS is hostile. If you build a u-boot image and
> forget to add FDT
> >     support added you get a low level crash dump and that is
> unfriendly. I woud like
> >     to this changed.
> >
> > So should we add a proper fatal code in case of invalid FDT or FDT
> is not provided?
> > ARM, POWERPC and RISCV are the only architectures in RTEMS that
> use FDT.
> > Can we add an FDT check inside start.S before bsp_fdt_copy? and
> fail properly in
> > case of an invalid FDT.
> > Or is it a better idea to add the check inside bsp_fdt_copy but
> bsp_fdt_copy is
> > optional
> > in architectures like ARM, RISCV it is compile time guarded with
> > BSP_START_COPY_FDT_FROM_UBOOT
> 
> The crash only happens when you run libbsd so I feel the issue is in
> there. If
> support has been added to libbsd 

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

On 18/08/2020 19:01, Niteesh G. S. wrote:
> 
> 
> On Tue, Aug 18, 2020 at 8:26 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> On 18/08/2020 11:25, Niteesh G. S. wrote:
> > How can we make this API FreeBSD compatible? We have to declare
> > defines for the OFW functions
> > Eg. #define OF_finddevice rtems_ofw_find_device
> 
> I think that was the plan, wasn't it?
> 
>  
> Is everyone OK with this? I am going to start working on it. I would like to
> get at least one of my patches merge readybefore GSoC ends. 

From the current timeframe I'm not sure whether the new build system is
ready till then. So for a merge we will need a backport. Sorry for that.
I expected the new build system to be integrated earlier. On the other
hand it shouldn't be too much work. Basically it means adding the two
sources into a file of the old build system instead of the new one.

> My other patches are somewhat dependent on this patch so I want to get
> this fixed first.
> 
> I also have a few questions now. If we do this change in libBSD and what
> about the imported drivers present in RTEMS? They have to define these
> translations locally in the driver itself. Or we should move openfirm.h into
> RTEMS. Both have their own problems. The first one will create a lot of
> redundant code And the second one has the following problems.
> 
> 1) Where to place openfirm.h in RTEMS?
> 2)  What about functions like OF_device_from_xref etc?
> These functions depend on the libBSD device struct one hack is to forward
> declare these in the openfirm.h implemented in RTEMS. Is everyone OK
> with this or is there any better solution to this?
> 3) We also modify the interface is that fine with BSD-4 license?
> 

There is a third possibility: You can place these defines in a header
(e.g. openfirm_compat.h) and include that in libbsds openfirm.h and in
the ported RTEMS drivers.

> 
> >
> > Should I change the openfirm.h in libBSD to this use these defines
> instead
> > of calling the functions in openfirm.c? Though there are some
> > functions which
> > for which this cannot be done.
> > Eg: OF_device_from_xref
> > For this, we will have to use the implementation present in openfirm.c
> 
> At least as long as no one implements a replacement, yes.
> 
> >
> >
> > On Tue, Aug 18, 2020 at 7:57 AM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 17/8/20 2:57 pm, Niteesh G. S. wrote:
> >     > On Mon, Aug 17, 2020 at 3:49 AM Chris Johns
> mailto:chr...@rtems.org>
> >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>> wrote:
> >     >
> >     >     On 16/8/20 11:19 pm, Niteesh G. S. wrote:
> >     >     >
> >     >     > On Sun, Aug 16, 2020 at 2:25 PM Chris Johns
> >     mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>
> >     >     > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>>> wrote:
> >     >     >
> >     >     >     On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> >     >     >     > ---
> >     >     >
> >     >     >     > +
> >     >     >     > +#ifdef HAVE_CONFIG_H
> >     >     >     > +#include "config.h"
> >     >     >     > +#endif
> >     >     >     > +
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +
> >     >     >     > +const void *fdtp = NULL;
> >     >     >     > +
> >     >     >     > +static phandle_t rtems_fdt_offset_to_phandle( int
>  

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

On 29/08/2020 05:57, Niteesh G. S. wrote:
> On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom  > wrote:
> 
> Are "Links to commits" 1-4 all the code you (are claiming you) wrote?
> I just want to make sure. It looks fine to me.
> 
> Yes, all the code in the commits is written by me.

I think maybe "Links to branches" would be a better title. It is not a
single commit each but a few commits. Alternative would be to add links
to each commit.

It has been quite a bit of back and forth during this GSoC project so I
think the result is quite OK.

Best regards

Christian

> 
> On Fri, Aug 28, 2020 at 12:07 PM Niteesh G. S.  > wrote:
> >
> > Hello,
> >
> > I have prepared my final report for my project. You can have a
> look at it
> > here https://gs-niteesh.github.io/finalreport/. Please kindly
> review the report.
> >
> > Thanks,
> > Niteesh.
> 
> 
> ___
> 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: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

On 29/08/2020 15:04, Niteesh G. S. wrote:
> Hello,
> On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh
> 
> On 29/08/2020 11:22, Niteesh G. S. wrote:
> > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> >
> >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> mailto:ged...@rtems.org>
> >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> >     > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>> wrote:
> >     >
> >     >     Are "Links to commits" 1-4 all the code you (are
> claiming you)
> >     wrote?
> >     >     I just want to make sure. It looks fine to me.
> >     >
> >     > Yes, all the code in the commits is written by me.
> >
> >     I think maybe "Links to branches" would be a better title. It
> is not a
> >     single commit each but a few commits. Alternative would be to
> add links
> >     to each commit.
> >
> >
> > I have changed the title to "Links to branches". Should I also add
> links
> > to the commits that were made in each phase at the end of the
> summary of
> > each phase?
> >  
> 
> If you want, you can do that.
> 
> 
> I did try that but it didn't work out well, especially with the OFW commit.
> Since I don't have the old commit I either had to leave that commit out
> in the first phase or I had to post the newer commit in the first phase
> itself which actually should in the last phase. So I decided to avoid adding
> the commits and just leave it out with the branches.

That's OK too. Like I said: Main target was that it's clear that you
don't have four commits but a bit more.

> 
> 
> The main point of that change was to highlight that it's not 4 commits
> but a bit more.
> 
> >
> >      
> >
> >
> >     It has been quite a bit of back and forth during this GSoC
> project so I
> >     think the result is quite OK.
> >
> >     Best regards
> >
> >     Christian
> >
> >     >
> >     >     On Fri, Aug 28, 2020 at 12:07 PM Niteesh G. S.
> >     mailto:niteesh...@gmail.com>
> <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>
> >     >     <mailto:niteesh...@gmail.com
> <mailto:niteesh...@gmail.com> <mailto:niteesh...@gmail.com
> <mailto:niteesh...@gmail.com>>>>
> >     wrote:
> >     >     >
> >     >     > Hello,
> >     >     >
> >     >     > I have prepared my final report for my project. You
> can have a
> >     >     look at it
> >     >     > here https://gs-niteesh.github.io/finalreport/. Please
> kindly
> >     >     review the report.
> >     >     >
> >     >     > Thanks,
> >     >     > Niteesh.
> >     >
> >     >
> >     > ___
> >     > devel mailing list
> >     > devel@rtems.org <mailto:devel@rtems.org>
> <mailto:devel@rtems.org <mailto:devel@rtems.org>>
> >     > http://lists.rtems.org/mailman/listinfo/devel
> >     >
> >
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh

On 29/08/2020 11:22, Niteesh G. S. wrote:
> On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> On 29/08/2020 05:57, Niteesh G. S. wrote:
> > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom  <mailto:ged...@rtems.org>
> > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>> wrote:
> >
> >     Are "Links to commits" 1-4 all the code you (are claiming you)
> wrote?
> >     I just want to make sure. It looks fine to me.
> >
> > Yes, all the code in the commits is written by me.
> 
> I think maybe "Links to branches" would be a better title. It is not a
> single commit each but a few commits. Alternative would be to add links
> to each commit.
> 
> 
> I have changed the title to "Links to branches". Should I also add links
> to the commits that were made in each phase at the end of the summary of
> each phase?
>  

If you want, you can do that.

The main point of that change was to highlight that it's not 4 commits
but a bit more.

> 
>  
> 
> 
> It has been quite a bit of back and forth during this GSoC project so I
> think the result is quite OK.
> 
> Best regards
> 
> Christian
> 
> >
> >     On Fri, Aug 28, 2020 at 12:07 PM Niteesh G. S.
> mailto:niteesh...@gmail.com>
> >     <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>>
> wrote:
> >     >
> >     > Hello,
> >     >
> >     > I have prepared my final report for my project. You can have a
> >     look at it
> >     > here https://gs-niteesh.github.io/finalreport/. Please kindly
> >     review the report.
> >     >
> >     > Thanks,
> >     > Niteesh.
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org <mailto:devel@rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: License files missing on 5-freebsd-12 branch

[Christian Mauderer]

On 29/09/2020 03:35, Chris Johns wrote:
> On 28/9/20 9:45 pm, Christian Mauderer wrote:
>> Sorry for the delay. I didn't manage to do these before my vacation and
>> then I forgot them during vacation. I just pushed them.
> 
> No problem and thank you. I hope you had a relaxing vacation?
> 
> Chris
> 

Like every vacation, it was too short. Otherwise: Yes, it was relaxing.

Best regards

Christian

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: License files missing on 5-freebsd-12 branch

[Christian Mauderer]

On 17/09/2020 23:37, Chris Johns wrote:
> On 17/9/20 10:57 pm, Joel Sherrill wrote:
>> On Thu, Sep 17, 2020 at 4:33 AM Christian Mauderer
>> > <mailto:christian.maude...@embedded-brains.de>> wrote:
>>
>> Hello,
>>
>> Chris pinged me that I missed to add these patches to the 5-freebsd-12
>> branch. It would be good if we would add the license files to the
>> release branch too. This will allow users to easily find the correct
>> licenses.
>>
>>
>> +1  
> 
> OK to push.
> 
> Thanks
> Chris
> 

Sorry for the delay. I didn't manage to do these before my vacation and
then I forgot them during vacation. I just pushed them.

Best regards

Christian

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

Hello Niteesh,

sorry for adding another delay: I think the new build system needs a bit
of time to settle. As soon as there are some more PASS in the table that
Sebastian created [1] (especially for beagle) we should try to get these
patches merged. Before that I would like to avoid big changes because it
might get hard to distinguish new bugs from build system bugs.

Best regards

Christian

[1] https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist

On 16/09/2020 19:05, Niteesh G. S. wrote:
> Hello,
> 
> Sorry for the delay, I was a bit occupied with my university work.
> Now since the new build system is merged I would like to get my
> GSoC work merged too.
> 
> The goal of this series patches is to implement the OFW API into RTEMS
> and modify libBSD to use this RTEMS API instead of its own.
> 
> Thanks,
> Niteesh.
> 
> On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu  > wrote:
> 
> RTEMS OFW is a FDT only implementation of the OpenFirmWare
> interface. This API is created to be compatible with FreeBSD
> OpenFirmWare interface. The main intention is to make
> porting of FreeBSD drivers to RTEMS easier.
> 
> Most functions implemented have an direct one-one mapping
> with the original OFW API and some extra auxiliary functions
> were implemented to make working with device trees easier in
> RTEMS.
> 
> Update #3784
> ---
>  bsps/include/ofw/ofw.h        | 548 +++
>  bsps/include/ofw/ofw_compat.h |  74 
>  bsps/shared/ofw/ofw.c         | 682 ++
>  spec/build/bsps/obj.yml       |   5 +
>  4 files changed, 1309 insertions(+)
>  create mode 100644 bsps/include/ofw/ofw.h
>  create mode 100644 bsps/include/ofw/ofw_compat.h
>  create mode 100644 bsps/shared/ofw/ofw.c
> 
> diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> new file mode 100644
> index 00..411010be89
> --- /dev/null
> +++ b/bsps/include/ofw/ofw.h
> @@ -0,0 +1,548 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup ofw
> + *
> + * RTEMS FDT implementation of OpenFirmWare Interface.
> + *
> + * RTEMS OFW is a FDT only implementation of the OpenFirmWare
> interface.
> + * This API is created to be compatible with FreeBSD OpenFirmWare
> interface.
> + * The main intention is to make porting of FreeBSD drivers to
> RTEMS easier.
> + */
> +
> +/*
> + * Copyright (C) 2020 Niteesh Babu G S  >
> + *
> + * 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.
> + */
> +
> +#ifndef _OFW_H
> +#define _OFW_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * Represents a node in the device tree. The offset from fdtp to
> node is used
> + * instead of fdt offset to make sure this is compatible with OF
> interface in
> + * FreeBSD.
> + */
> +typedef uint32_t  phandle_t;
> +/**
> + * Represents the effective phandle of the node.
> + */
> +typedef uint32_t  ihandle_t;
> +/**
> + * Represents the data type of the buffer.
> + */
> +typedef uint32_t  pcell_t;
> +
> +/**
> + * @struct rtems_ofw_memory_area
> + *
> + * This is used to represent elements(FDT properties) that define
> + * region 

[PATCH rtems-libbsd 2/3] builder.py: Add case for plain text files.

[Christian Mauderer]

Update #4082
---
 builder.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/builder.py b/builder.py
index f5fe2afc..0eda461f 100755
--- a/builder.py
+++ b/builder.py
@@ -202,6 +202,9 @@ def revertFixLocalIncludes(data):
 data = re.sub('#include ]*)>', '#include "\\1"', data)
 return data
 
+def assertNothing(path):
+pass
+
 def assertHeaderFile(path):
 if path[-2] != '.' or path[-1] != 'h':
 print("*** " + path + " does not end in .h")
@@ -690,6 +693,11 @@ class Module(object):
reverseConverter, buildSystemComposer)]
 return files
 
+def addPlainTextFile(self, files):
+self.files += self.addFiles(files,
+FreeBSDPathComposer(), Converter(),
+Converter(), assertNothing)
+
 def addKernelSpaceHeaderFiles(self, files):
 self.files += self.addFiles(files,
 FreeBSDPathComposer(), 
FromFreeBSDToRTEMSHeaderConverter(),
-- 
2.26.2

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

[PATCH rtems-libbsd 3/3] Import FreeBSD license files.

[Christian Mauderer]

Fix #4082
---
 freebsd/COPYRIGHT | 126 ++
 freebsd/contrib/expat/COPYING |  21 +
 freebsd/contrib/libpcap/LICENSE   |  19 
 freebsd/contrib/libxo/LICENSE |  23 +
 freebsd/contrib/tcpdump/LICENSE   |  19 
 freebsd/contrib/wpa/COPYING   |  22 +
 freebsd/crypto/openssl/LICENSE| 125 +
 freebsd/sys/contrib/libsodium/LICENSE |  18 
 freebsd/sys/dev/e1000/LICENSE |  31 +++
 libbsd.py |  45 +
 10 files changed, 449 insertions(+)
 create mode 100644 freebsd/COPYRIGHT
 create mode 100644 freebsd/contrib/expat/COPYING
 create mode 100644 freebsd/contrib/libpcap/LICENSE
 create mode 100644 freebsd/contrib/libxo/LICENSE
 create mode 100644 freebsd/contrib/tcpdump/LICENSE
 create mode 100644 freebsd/contrib/wpa/COPYING
 create mode 100644 freebsd/crypto/openssl/LICENSE
 create mode 100644 freebsd/sys/contrib/libsodium/LICENSE
 create mode 100644 freebsd/sys/dev/e1000/LICENSE

diff --git a/freebsd/COPYRIGHT b/freebsd/COPYRIGHT
new file mode 100644
index ..4a40a9f3
--- /dev/null
+++ b/freebsd/COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#  @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2020 The FreeBSD Project.
+
+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 AUTHOR 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 AUTHOR 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.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+   The Regents of the University of California.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of 

License files missing on 5-freebsd-12 branch

[Christian Mauderer]

Hello,

Chris pinged me that I missed to add these patches to the 5-freebsd-12
branch. It would be good if we would add the license files to the
release branch too. This will allow users to easily find the correct
licenses.

Best regards

Christian


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

Re: How to use lvgl on pc386 BSP.

[Christian Mauderer]

Hello Karel,

I wasn't aware that there is a framebuffer driver in the PC BSP. Maybe
an alternative to using the BSP framebuffer driver could be to just port
the FreeBSD framebuffer driver for PC and use that one? That might could
be less work than fixing the PC BSPs driver.

If you want to continue to use the BSPs driver, I can try to have a more
detailled look at it. But like I said: I would expect that the FreeBSD
driver is simpler to use.

Best regards

Christian

On 19/09/2020 00:30, Karel Gardas wrote:
> On 9/18/20 11:51 PM, Karel Gardas wrote:
>> Whole demo output looks:
>>
>> i386: isr=0 irr=1
>> i386: isr=0 irr=1
>> FB_VESA_RM frame buffer -- driver initializing..
>>
>>
>> RTEMS LVGL HELLO WORLD
>>
>> nexus0: 
>> pcib0 pcibus 0
>> pci0:  on pcib0
>> pci0:  at device 0.0 (no driver attached)
>> pci0:  at device 1.0 (no driver attached)
>> pci0:  at device 1.1 (no driver attached)
>> pci0:  at device 1.3 (no driver attached)
>> pci0:  at device 2.0 (no driver attached)
>> pci0:  at device 3.0 (no driver attached)
>> cpu0
>> FB_VESA_RM open device
>> The framebuffer device was opened successfully.
>> FB_VESA_RM ioctl called, cmd=4602
>> fbxres 1024, fbyres 768
>> fbbpp 32
>> FB_VESA_RM ioctl called, cmd=4600
>> fbxres 1024, fbyres 768
>> fbbpp 32
>> 1024x768, 32bpp
>> 3145728 screen size.
>> Error: failed to map framebuffer device to memory: Not supported
>>
>>
> 
> ^ that was form Qemu, from my testing hw box it looks as follows. Sorry
> for the dead Reaktek. Also it looks like VBE bios is kind of limited
> since EDID recommended resolution is monitors native: 2560x1440, but
> BIOS does not support it hence offers 1920x1440 as most close.
> 
> i386: isr=0 irr=1
> FB_VESA_RM frame buffer -- driver initializing..
> 
> RTEMS LVGL HELLO WORLD
> 
> nexus0: 
> pcib0 pcibus 0
> pci0:  on pcib0
> pci0:  at device 0.0 (no driver attached)
> pcib1:  at device 1.0 on pci0
> pci1:  on pcib1
> pci1:  at device 5.0 (no driver attached)
> pci1:  at device 5.1 (no driver attached)
> pcib2:  irq 10 at device 10.0 on pci0
> pci2:  on pcib2
> re0:  port
> 0xd800-0xd8ff mem 0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 10 at
> device 0.0 on pci2
> re0: Chip rev. 0x2c00
> re0: MAC rev. 0x0020
> re0: PHY write failed
> re0: PHY write failed
> re0: PHY read failed
> re0: attaching PHYs failed
> device_attach: re0 attach returned 6
> pci0:  at device 17.0 (no driver attached)
> pci0:  at device 18.0 (no driver attached)
> pci0:  at device 18.2 (no driver attached)
> pci0:  at device 19.0 (no driver attached)
> pci0:  at device 19.2 (no driver attached)
> pci0:  at device 20.2 (no driver attached)
> pci0:  at device 20.3 (no driver attached)
> pcib3:  at device 20.4 on pci0
> pci3:  on pcib3
> re0: 
> port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff irq 3 at device 5.0 on pci3
> re0: Chip rev. 0x0400
> re0: MAC rev. 0x
> miibus0:  on re0
> rgephy0:  PHY 1 on miibus0
> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,
> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1w
> info: re0: Using defaults for TSO: 65518/35/2048
> info: re0: Ethernet address: 00:0e:2e:7b:da:0b
> pci0:  at device 20.5 (no driver attached)
> pci0:  at device 22.0 (no driver attached)
> pci0:  at device 22.2 (no driver attached)
> pci0:  at device 24.0 (no driver attached)
> pci0:  at device 24.1 (no driver attached)
> pci0:  at device 24.2 (no driver attached)
> pci0:  at device 24.3 (no driver attached)
> pci0: > at device 24.4 (no driver attached)
> cpu0
> TheFB_VESA_RM ioctl called, cmd=4602
> fbxres 1920, fbyres 1440
> fbbpp 32
> FB_VESA_RM ioctl called, cmd=4600
> fbxres 1920, fbyres 1440
> fbbpp 32
>  framebuffer device was opened successfully.
> 1920x1440, 32bpp
> 11059200 screen size.
> Error: failed to map framebuffer device to memory: Not supported
> 
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> --
> Exception 13 caught at PC  by thread 167837697
> --
> Processor execution context at time of the fault was  :
> --
>  EAX = 0EBX = 0 ECX = 3662e4EDX = 0
>  ESI = 0EDI = 3662bcEBP = ffESP = 3af0a8
> --
> Error code pushed by processor itself (if not 0) = 0
> --
> Call Stack Trace of EIP:
> 0xef7eef7e 0x
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> --
> Exception 13 caught at PC 2ae863 by thread 167837697
> --
> Processor execution context at time of the fault was  :
> --
>  EAX = bEBX =   ECX 

Re: [PATCH rtems-libbsd 1/3] Add helper script to find licenses.

[Christian Mauderer]

On 17/09/2020 23:35, Chris Johns wrote:
> On 17/9/20 10:51 pm, Joel Sherrill wrote:
>> I think I'm ok on all three of these patches but some 
>> comments on the shell script. I can see where this is a
>> tedious but important check. And it can be improved easily.
>>
>> Since this smells like something Chris would poke me f
>> or and call a "Joel script" :)
> 
> Haha ...
> 
> This patch is only for the 5-freesd-12 branch and a script is fine. The script
> has made think for the master and 6-freebsd-12 branches libbsd.py should be
> taught to handle licenses so these are copied across as part of the import.
> 
> Chris
> 

Hello Chris and Joel,

I agree that this script is an ugly one. It has been hacked together
when I needed to import the license files and I didn't wanted to throw
it out of the window because I thought it might could be useful to find
some more missing license files in the future.

Please note that this script is already on master since quite a long
time and that I only cherry-picked the commits for the 5-freebsd-12
branch (and adapted the import patch to import the right version). So
thanks for the suggestions Joel but shouldn't these changes then be an
extra patch? Chris: You mentioned that libbsd.py should be taught to
handle licenses. Do you plan anything into that direction? In that case
touching the script wouldn't be really useful.

Best regards

Christian
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: Porting OFW to RTEMS

[Christian Mauderer]

On 27/05/2020 19:32, Niteesh G. S. wrote:
> 
> 
> On Wed, May 27, 2020 at 12:04 AM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> On 26/05/2020 19:56, Christian Mauderer wrote:
> > Hello Niteesh,
> >
> > On 25/05/2020 11:20, Niteesh G. S. wrote:
> >> Hello,
> >>
> >> I have completed the porting of the OFW code from FreeBSD to RTEMS.
> >> I do acknowledge the fact that we haven't decided on the
> directory for files
> >> to be placed in. The previous conversation had stopped quite a
> while ago.
> >> Christian suggested I work on the patch since that would also
> start the
> >> conversation again and also refactoring the patch to the correct
> directory
> >> will not be much of work.
> >>
> >> cpukit/libfreebsd was suggested as one of the directories to
> place the
> >> ported
> >> FreeBSD files. It is suggested to place all the source files
> under this
> >> directory.
> >> Since this will make the sync part easier. But this causes issues
> when
> >> porting
> >> BSP dependent files. Since RTEMS currently doesn't allow files in
> cpukit to
> >> reference bsp headers. I faced a similar issue during my porting
> process
> >> also.
> >> The OFW init function require bsp_fdt_get function to get a
> reference to
> >> the fdt
> >> blob. But I can't include the bsp/fdt.h header file from a source
> file
> >> under cpukit.
> >> We must decide the directory quickly because my project will
> import other
> >> FreeBSD sources like the pinmux driver for beaglebone into RTEMS.
> >
> > Do you have a suggestion for another directory?
> >
> > If cpukit makes problems (which it clearly does due to the BSP
> > dependencies) maybe something in bsps/shared?
> >
> >>
> >> https://github.com/gs-niteesh/rtems/commits/ofw_branch
> >
> > For small patches it would be better to send them to the list
> using "git
> > send-email". That allows to comment directly on the patches. But
> in this
> > case using a repo is OK because especially the import is quite big.
> >
> > I'll add comments for small stuff directly on github. I hope that
> works ;-)
> 
> Finished adding comments for small stuff. Some bigger questions:
> 
> - How do you plan to include ofw_if.h in some driver files? RTEMS
> currently puts every file that can be included with  into a path
> called "include".
> 
> 
> Will ofw_if.h be included in driver files? As far as I have searched in the
> FreeBSD sources, other than the OFW implementation none of the driver
> files include this header. So this could be placed in the same directory as
> the OFW sources and need not be added to the global include path.
> If there is a case where it is included in some driver please let me know. 
> 
> And also all the references to this header in the OFW implementations are
> relative so in future, if we add other implementations, having it in the
> same
> directory would be the right choice.
> 

You are right. I didn't have a detailed enough look. The functions like
OFW_GETPROP (declared in ofw_if.h) are only used in openfirm.c. So that
location is OK.

>  
> 
> - You created quite some commits. I would suggest to merge all porting
> commits so that you have one import commit, one port commit and maybe
> one commit adding RTEMS specific files
> 
> 
> I have squashed them into a single port commit.
>  
> 
>  
> 
> - You have at least one completely hand written file (ofw_if.h). Maybe
> we should think about whether that is located well in the same directory
> as the imported code or whether a similar structure like used in libbsd
> would be better. One tree for imported files and one for RTEMS specific
> hand written ones.
> 
> 
> Do we need a separate directory for RTEMS specific handwritten ones depends
> on what we will be importing in the future? Since we intend only to
> import mostly
> driver related code I don't think there is a need for a separate
> directory. I think
> this way because I assuming we don't need any RTEMS specific file for
> the drivers.
> But if we plan to include some simple subsystem then having a separate
> directory
> will be nice.

Things like that tend to grow. So even if we don't want 

Re: GSoC: Porting OFW to RTEMS

[Christian Mauderer]

Hello Niteesh,

On 28/05/2020 16:34, Niteesh G. S. wrote:
> 
> 
> On Wed, May 27, 2020 at 11:25 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> On 27/05/2020 19:32, Niteesh G. S. wrote:
> >
> >
> > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
>     >
> >     Hello Niteesh,
> >
> >     On 26/05/2020 19:56, Christian Mauderer wrote:
> >     > Hello Niteesh,
> >     >
> >     > On 25/05/2020 11:20, Niteesh G. S. wrote:
> >     >> Hello,
> >     >>
> >     >> I have completed the porting of the OFW code from FreeBSD
> to RTEMS.
> >     >> I do acknowledge the fact that we haven't decided on the
> >     directory for files
> >     >> to be placed in. The previous conversation had stopped quite a
> >     while ago.
> >     >> Christian suggested I work on the patch since that would also
> >     start the
> >     >> conversation again and also refactoring the patch to the
> correct
> >     directory
> >     >> will not be much of work.
> >     >>
> >     >> cpukit/libfreebsd was suggested as one of the directories to
> >     place the
> >     >> ported
> >     >> FreeBSD files. It is suggested to place all the source files
> >     under this
> >     >> directory.
> >     >> Since this will make the sync part easier. But this causes
> issues
> >     when
> >     >> porting
> >     >> BSP dependent files. Since RTEMS currently doesn't allow
> files in
> >     cpukit to
> >     >> reference bsp headers. I faced a similar issue during my
> porting
> >     process
> >     >> also.
> >     >> The OFW init function require bsp_fdt_get function to get a
> >     reference to
> >     >> the fdt
> >     >> blob. But I can't include the bsp/fdt.h header file from a
> source
> >     file
> >     >> under cpukit.
> >     >> We must decide the directory quickly because my project will
> >     import other
> >     >> FreeBSD sources like the pinmux driver for beaglebone into
> RTEMS.
> >     >
> >     > Do you have a suggestion for another directory?
> >     >
> >     > If cpukit makes problems (which it clearly does due to the BSP
> >     > dependencies) maybe something in bsps/shared?
> >     >
> >     >>
> >     >> https://github.com/gs-niteesh/rtems/commits/ofw_branch
> >     >
> >     > For small patches it would be better to send them to the list
> >     using "git
> >     > send-email". That allows to comment directly on the patches. But
> >     in this
> >     > case using a repo is OK because especially the import is
> quite big.
> >     >
> >     > I'll add comments for small stuff directly on github. I hope
> that
> >     works ;-)
> >
> >     Finished adding comments for small stuff. Some bigger questions:
> >
> >     - How do you plan to include ofw_if.h in some driver files? RTEMS
> >     currently puts every file that can be included with 
> into a path
> >     called "include".
> >
> >
> > Will ofw_if.h be included in driver files? As far as I have
> searched in the
> > FreeBSD sources, other than the OFW implementation none of the driver
> > files include this header. So this could be placed in the same
> directory as
> > the OFW sources and need not be added to the global include path.
> > If there is a case where it is included in some driver please let
> me know. 
> >
> > And also all the references to this header in the OFW
> implementations are
> > relative so in future, if we add other implementations, having it
> in the
> > same
> > directory would be the right choice.
> >
> 
> You are right. I didn't have a detailed enough look. The functions like
> OFW_GETPROP (declared in ofw_if.h) are only used in openfirm.c. So that
> location is OK.
> 
> >  
> >

Re: GSoC: Porting OFW to RTEMS

[Christian Mauderer]

Hello Niteesh,

On 28/05/2020 17:08, Niteesh G. S. wrote:
> Hello Christian,
> 
> On Thu, May 28, 2020 at 8:12 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> Hello Niteesh,
> 
> On 28/05/2020 16:34, Niteesh G. S. wrote:
> >
> >
>     > On Wed, May 27, 2020 at 11:25 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> >
> >     On 27/05/2020 19:32, Niteesh G. S. wrote:
> >     >
> >     >
> >     > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer
> >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >     > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
> >     >
> >     >     Hello Niteesh,
> >     >
> >     >     On 26/05/2020 19:56, Christian Mauderer wrote:
> >     >     > Hello Niteesh,
> >     >     >
> >     >     > On 25/05/2020 11:20, Niteesh G. S. wrote:
> >     >     >> Hello,
> >     >     >>
> >     >     >> I have completed the porting of the OFW code from FreeBSD
> >     to RTEMS.
> >     >     >> I do acknowledge the fact that we haven't decided on the
> >     >     directory for files
> >     >     >> to be placed in. The previous conversation had
> stopped quite a
> >     >     while ago.
> >     >     >> Christian suggested I work on the patch since that
> would also
> >     >     start the
> >     >     >> conversation again and also refactoring the patch to the
> >     correct
> >     >     directory
> >     >     >> will not be much of work.
> >     >     >>
> >     >     >> cpukit/libfreebsd was suggested as one of the
> directories to
> >     >     place the
> >     >     >> ported
> >     >     >> FreeBSD files. It is suggested to place all the
> source files
> >     >     under this
> >     >     >> directory.
> >     >     >> Since this will make the sync part easier. But this
> causes
> >     issues
> >     >     when
> >     >     >> porting
> >     >     >> BSP dependent files. Since RTEMS currently doesn't allow
> >     files in
> >     >     cpukit to
> >     >     >> reference bsp headers. I faced a similar issue during my
> >     porting
> >     >     process
> >     >     >> also.
> >     >     >> The OFW init function require bsp_fdt_get function to
> get a
> >     >     reference to
> >     >     >> the fdt
> >     >     >> blob. But I can't include the bsp/fdt.h header file
> from a
> >     source
> >     >     file
> >     >     >> under cpukit.
> >     >     >> We must decide the directory quickly because my
> project will
> >     >     import other
> >     >     >> FreeBSD sources like the pinmux driver for beaglebone
> into
> >     RTEMS.
> >     >     >
> >     >     > Do you have a suggestion for another directory?
> >     >     >
> >     >     > If cpukit makes problems (which it clearly does due to
> the BSP
> >     >     > dependencies) maybe something in bsps/shared?
> >     >     >
> >     >     >>
> >     >     >> https://github.com/gs-niteesh/rtems/commits/ofw_branch
> >     >     >
> >     >     > For small patches it would be better to send them to
> the list
> >     >     using "git
> >     >     > send-email". That allows to comment directly on the
> patches. But
> >     >     in this
> >     >     > case using a repo is OK because especially the import is
> >     quite big.
> >     >     >
> >     >     > I'll add comments for small stuff directly on github.
> I hope
> >     that
> >     >     works ;-)
> >     >
>

Re: GSoC: Porting OFW to RTEMS

[Christian Mauderer]

Hello Niteesh,

On 26/05/2020 19:56, Christian Mauderer wrote:
> Hello Niteesh,
> 
> On 25/05/2020 11:20, Niteesh G. S. wrote:
>> Hello,
>>
>> I have completed the porting of the OFW code from FreeBSD to RTEMS.
>> I do acknowledge the fact that we haven't decided on the directory for files
>> to be placed in. The previous conversation had stopped quite a while ago.
>> Christian suggested I work on the patch since that would also start the
>> conversation again and also refactoring the patch to the correct directory
>> will not be much of work.
>>
>> cpukit/libfreebsd was suggested as one of the directories to place the
>> ported
>> FreeBSD files. It is suggested to place all the source files under this
>> directory.
>> Since this will make the sync part easier. But this causes issues when
>> porting
>> BSP dependent files. Since RTEMS currently doesn't allow files in cpukit to
>> reference bsp headers. I faced a similar issue during my porting process
>> also.
>> The OFW init function require bsp_fdt_get function to get a reference to
>> the fdt
>> blob. But I can't include the bsp/fdt.h header file from a source file
>> under cpukit.
>> We must decide the directory quickly because my project will import other
>> FreeBSD sources like the pinmux driver for beaglebone into RTEMS.
> 
> Do you have a suggestion for another directory?
> 
> If cpukit makes problems (which it clearly does due to the BSP
> dependencies) maybe something in bsps/shared?
> 
>>
>> https://github.com/gs-niteesh/rtems/commits/ofw_branch
> 
> For small patches it would be better to send them to the list using "git
> send-email". That allows to comment directly on the patches. But in this
> case using a repo is OK because especially the import is quite big.
> 
> I'll add comments for small stuff directly on github. I hope that works ;-)

Finished adding comments for small stuff. Some bigger questions:

- How do you plan to include ofw_if.h in some driver files? RTEMS
currently puts every file that can be included with  into a path
called "include".

- You created quite some commits. I would suggest to merge all porting
commits so that you have one import commit, one port commit and maybe
one commit adding RTEMS specific files.

- You have at least one completely hand written file (ofw_if.h). Maybe
we should think about whether that is located well in the same directory
as the imported code or whether a similar structure like used in libbsd
would be better. One tree for imported files and one for RTEMS specific
hand written ones.

Please see all comments as advises. Feel free to argue against any of
them if you think different ;-)

Best regards

Christian

> 
> Best regards
> 
> Christian
> 
>> Please have a look at the last 6 patches for the ported work.
>> Below is a short summary of the patch.
>> * The openfirm.h is the OF interface that will provided to the user.
>> * The openfirm.c contains the function definition for openfirm.h. The
>> functions
>> call the respective OFW_* functions which are responsible for choosing
>> the correct implementation for OF interface.
>> * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto
>> generated
>> header in FreeBSD which choose the correct OF implementation(ofw_fdt,
>> ofw_std,
>> ofw_32bit, ofw_real). In RTEMS we directly map to the FDT implementation as
>> suggested by Sebastian.
>> * ofw_fdt.c contains the fdt implementation of OF interface.
>>
>> Thanks,
>> Niteesh.
>>
> ___
> 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: GSoC: Porting OFW to RTEMS

[Christian Mauderer]

Hello Niteesh,

On 25/05/2020 11:20, Niteesh G. S. wrote:
> Hello,
> 
> I have completed the porting of the OFW code from FreeBSD to RTEMS.
> I do acknowledge the fact that we haven't decided on the directory for files
> to be placed in. The previous conversation had stopped quite a while ago.
> Christian suggested I work on the patch since that would also start the
> conversation again and also refactoring the patch to the correct directory
> will not be much of work.
> 
> cpukit/libfreebsd was suggested as one of the directories to place the
> ported
> FreeBSD files. It is suggested to place all the source files under this
> directory.
> Since this will make the sync part easier. But this causes issues when
> porting
> BSP dependent files. Since RTEMS currently doesn't allow files in cpukit to
> reference bsp headers. I faced a similar issue during my porting process
> also.
> The OFW init function require bsp_fdt_get function to get a reference to
> the fdt
> blob. But I can't include the bsp/fdt.h header file from a source file
> under cpukit.
> We must decide the directory quickly because my project will import other
> FreeBSD sources like the pinmux driver for beaglebone into RTEMS.

Do you have a suggestion for another directory?

If cpukit makes problems (which it clearly does due to the BSP
dependencies) maybe something in bsps/shared?

> 
> https://github.com/gs-niteesh/rtems/commits/ofw_branch

For small patches it would be better to send them to the list using "git
send-email". That allows to comment directly on the patches. But in this
case using a repo is OK because especially the import is quite big.

I'll add comments for small stuff directly on github. I hope that works ;-)

Best regards

Christian

> Please have a look at the last 6 patches for the ported work.
> Below is a short summary of the patch.
> * The openfirm.h is the OF interface that will provided to the user.
> * The openfirm.c contains the function definition for openfirm.h. The
> functions
> call the respective OFW_* functions which are responsible for choosing
> the correct implementation for OF interface.
> * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto
> generated
> header in FreeBSD which choose the correct OF implementation(ofw_fdt,
> ofw_std,
> ofw_32bit, ofw_real). In RTEMS we directly map to the FDT implementation as
> suggested by Sebastian.
> * ofw_fdt.c contains the fdt implementation of OF interface.
> 
> Thanks,
> Niteesh.
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] media-server: Add ability for retry.

[Christian Mauderer]

Hello Gedare,

thanks for the review.

On 17/07/2020 07:43, Gedare Bloom wrote:
> On Thu, Jul 9, 2020 at 2:21 AM Christian Mauderer
>  wrote:
>>
>> This adds the possibility to request a retry in the media-listener if an
>> operation failed. Usefull for example if you want to automatically
>> reformat a disk if it wasn't possible to mount it.
>> ---
>>  cpukit/include/rtems/media.h |  3 +++
>>  cpukit/libblock/src/media.c  | 29 -
>>  2 files changed, 19 insertions(+), 13 deletions(-)
>>
>> diff --git a/cpukit/include/rtems/media.h b/cpukit/include/rtems/media.h
>> index b2a3e2dc91..db13664975 100644
>> --- a/cpukit/include/rtems/media.h
>> +++ b/cpukit/include/rtems/media.h
>> @@ -281,6 +281,9 @@ typedef enum {
>>   *
>>   * @retval RTEMS_SUCCESSFUL Successful operation.
>>   * @retval RTEMS_IO_ERROR In the inquiry state this will abort the action.
>> + * @retval RTEMS_INCORRECT_STATE In the failed state this will cause a 
>> retry.
>> + * Make sure to have a retry counter or similar to avoid endless loops if 
>> you
>> + * use this this value.
> delete one 'this'
> 
> Glad you have this comment, that was my first thought when I read the
> commit msg.
> 
>>   */
>>  typedef rtems_status_code (*rtems_media_listener)(
>>rtems_media_event event,
>> diff --git a/cpukit/libblock/src/media.c b/cpukit/libblock/src/media.c
>> index 5b2b06b5b2..c00825587c 100644
>> --- a/cpukit/libblock/src/media.c
>> +++ b/cpukit/libblock/src/media.c
>> @@ -420,26 +420,29 @@ static rtems_status_code process_event(
>>  )
>>  {
>>rtems_status_code sc = RTEMS_SUCCESSFUL;
>> +  rtems_status_code sc_retry = RTEMS_SUCCESSFUL;
>>rtems_media_state state = RTEMS_MEDIA_STATE_FAILED;
>>char *dest = NULL;
>>
>> -  sc = notify(event, RTEMS_MEDIA_STATE_INQUIRY, src, NULL);
>> -  if (sc == RTEMS_SUCCESSFUL) {
>> -state = RTEMS_MEDIA_STATE_READY;
>> -  } else {
>> -state = RTEMS_MEDIA_STATE_ABORTED;
>> -  }
>> -
>> -  sc = (*worker)(state, src, , worker_arg);
>> -  if (state == RTEMS_MEDIA_STATE_READY) {
>> +  do {
>> +sc = notify(event, RTEMS_MEDIA_STATE_INQUIRY, src, NULL);
>>  if (sc == RTEMS_SUCCESSFUL) {
>> -  state = RTEMS_MEDIA_STATE_SUCCESS;
>> +  state = RTEMS_MEDIA_STATE_READY;
>>  } else {
>> -  state = RTEMS_MEDIA_STATE_FAILED;
>> +  state = RTEMS_MEDIA_STATE_ABORTED;
>> +}
>> +
>> +sc = (*worker)(state, src, , worker_arg);
>> +if (state == RTEMS_MEDIA_STATE_READY) {
>> +  if (sc == RTEMS_SUCCESSFUL) {
>> +state = RTEMS_MEDIA_STATE_SUCCESS;
>> +  } else {
>> +state = RTEMS_MEDIA_STATE_FAILED;
>> +  }
>>  }
>> -  }
>>
>> -  notify(event, state, src, dest);
>> +sc_retry = notify(event, state, src, dest);
>> +  } while (state == RTEMS_MEDIA_STATE_FAILED && sc_retry == 
>> RTEMS_INCORRECT_STATE);
> line length
> 
> How do you use a retry counter? It's not obvious to me, but this is
> not an area I work with much.
> 

The retry is only done if explicitly requested by the media listener.
The media listener is a software provided by the user. If the user
requests a retry he should also decide how often he wants to retry the
operation.

A possibility to add a retry counter is to use the user specifiable
argument of the media listener. The user can provide a pointer to some
own data structure where the retries are counted.

I think the retries in general are a quite exotic feature. Like my
comment suggests I used it to try a mount for an on-board memory, if it
doesn't work I format the disk and retry the mount.

Best regards

Christian

>>remember_event(event, state, src, dest);
>>
>>if (state == RTEMS_MEDIA_STATE_SUCCESS) {
>> --
>> 2.26.2
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/7] gpioregulator: Remove.

[Christian Mauderer]

Sorry: I accidentally set a reply address instead of having the patch
set as a reply to the intro mail for the first patch set. Please don't
use the reply to addres. It won't work.



On 17/07/2020 07:56, Christian Mauderer wrote:
> There is a bug in the #ifdef regarding FDT so this file hasn't been
> compiled. If that bug is solved, the driver doesn't work for some other
> reason.
> 
> With the FDT-bug the driver hasn't been used by anyone. So just remove
> it again.
> ---
>  freebsd/sys/dev/gpio/gpioregulator.c | 352 ---
>  libbsd.py|   1 -
>  rtemsbsd/include/bsp/nexus-devices.h |   1 -
>  3 files changed, 354 deletions(-)
>  delete mode 100644 freebsd/sys/dev/gpio/gpioregulator.c
> 
> diff --git a/freebsd/sys/dev/gpio/gpioregulator.c 
> b/freebsd/sys/dev/gpio/gpioregulator.c
> deleted file mode 100644
> index 8ca35bfe..
> --- a/freebsd/sys/dev/gpio/gpioregulator.c
> +++ /dev/null
> @@ -1,352 +0,0 @@
> -#include 
> -
> -/*-
> - * Copyright (c) 2016 Jared McNeill 
> - * All rights reserved.
> - *
> - * Redistribution and use in source and binary forms, with or without
> - * modification, are permitted provided that the following conditions
> - * are met:
> - * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of conditions and the following disclaimer.
> - * 2. Redistributions in binary form must reproduce the above copyright
> - *notice, this list of conditions and the following disclaimer in the
> - *documentation and/or other materials provided with the distribution.
> - *
> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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.
> - *
> - * $FreeBSD$
> - */
> -
> -/*
> - * GPIO controlled regulators
> - */
> -
> -#include 
> -__FBSDID("$FreeBSD$");
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#if !defined(__rtems__) || defined(FDT)
> -#include 
> -#include 
> -
> -#include 
> -
> -#include 
> -
> -#include 
> -
> -struct gpioregulator_state {
> - int val;
> - uint32_tmask;
> -};
> -
> -struct gpioregulator_init_def {
> - struct regnode_init_def reg_init_def;
> - struct gpiobus_pin  *enable_pin;
> - int enable_pin_valid;
> - int startup_delay_us;
> - int nstates;
> - struct gpioregulator_state  *states;
> - int npins;
> - struct gpiobus_pin  **pins;
> -};
> -
> -struct gpioregulator_reg_sc {
> - struct regnode  *regnode;
> - device_tbase_dev;
> - struct regnode_std_param*param;
> - struct gpioregulator_init_def   *def;
> -};
> -
> -struct gpioregulator_softc {
> - device_tdev;
> - struct gpioregulator_reg_sc *reg_sc;
> - struct gpioregulator_init_def   init_def;
> -};
> -
> -static int
> -gpioregulator_regnode_init(struct regnode *regnode)
> -{
> - struct gpioregulator_reg_sc *sc;
> - int error, n;
> -
> - sc = regnode_get_softc(regnode);
> -
> - if (sc->def->enable_pin_valid == 1) {
> - error = gpio_pin_setflags(sc->def->enable_pin, GPIO_PIN_OUTPUT);
> - if (error != 0)
> - return (error);
> - }
> -
> - for (n = 0; n < sc->def->npins; n++) {
> - error = gpio_pin_setflags(sc->def->pins[n], GPIO_PIN_OUTPUT);
> - if (error != 0)
> - return (error);
> - }
> -
> - return (0);
> -}
> -
> -static int
> -gpioregulator_regnode_enable(struct regnode *regnode, bool enable, int 
> *udelay)
> -{
> - struct gpioregulator_reg_sc *sc;
> - bool active;
> -  

[PATCH rtems-libbsd 5/7] busdma: Don't sync nocache memory on ARM

[Christian Mauderer]

The busdma shouldn't try to flush or invalidate cache in a nocache area.
---
 rtemsbsd/rtems/rtems-kernel-bus-dma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/rtemsbsd/rtems/rtems-kernel-bus-dma.c 
b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
index 4dc634f3..bda4f3d7 100644
--- a/rtemsbsd/rtems/rtems-kernel-bus-dma.c
+++ b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
@@ -48,6 +48,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -400,6 +402,12 @@ bus_dmamap_sync(bus_dma_tag_t dmat, bus_dmamap_t map, 
bus_dmasync_op_t op)
uintptr_t size = map->buffer_size;
uintptr_t begin = (uintptr_t) map->buffer_begin;
uintptr_t end = begin + size;
+#ifdef __arm__
+   if (begin >= (uintptr_t)bsp_section_nocache_begin &&
+   end <= (uintptr_t)bsp_section_nocachenoload_end) {
+   return;
+   }
+#endif
 
if ((map->flags & DMAMAP_CACHE_ALIGNED) != 0) {
begin &= ~CLMASK;
-- 
2.26.2

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

[PATCH rtems 2/3] bsp/imx: Use GPIOs for SPI CS.

[Christian Mauderer]

The chip select lines of the iMX SPI module doesn't work well for a
generic API like the one RTEMS uses. The existing solution only worked
in some special cases and had odd bugs when trying transfers of
different sizes (like deselecting between each byte for lengths that are
not dividable by 4).

With this patch the same approach like on FreeBSD or Linux is used:
Treat the CS lines as GPIOs.
---
 bsps/arm/imx/spi/imx-ecspi.c | 92 +---
 1 file changed, 85 insertions(+), 7 deletions(-)

diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index a18047f2e0..26ba812f62 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,8 @@
 #include 
 
 #define IMX_ECSPI_FIFO_SIZE 64
+#define IMX_ECSPI_MAX_CHIPSELECTS 4
+#define IMX_ECSPI_CS_NONE IMX_ECSPI_MAX_CHIPSELECTS
 
 typedef struct imx_ecspi_bus imx_ecspi_bus;
 
@@ -44,6 +47,10 @@ struct imx_ecspi_bus {
   void (*pop)(imx_ecspi_bus *, volatile imx_ecspi *);
   rtems_id task_id;
   rtems_vector_number irq;
+  struct {
+struct imx_gpio_pin pin;
+bool valid;
+  } cspins[IMX_ECSPI_MAX_CHIPSELECTS];
 };
 
 static bool imx_ecspi_is_rx_fifo_not_empty(volatile imx_ecspi *regs)
@@ -129,6 +136,27 @@ static void imx_ecspi_push(imx_ecspi_bus *bus, volatile 
imx_ecspi *regs)
   }
 }
 
+/* Call with IMX_ECSPI_CS_NONE for @a cs to set all to idle */
+static void
+imx_ecspi_set_chipsel(imx_ecspi_bus *bus, uint32_t cs)
+{
+  size_t i;
+
+  /* Currently this is fixed active low */
+  static const uint32_t idle = 1;
+  static const uint32_t select = 0;
+
+  for (i = 0; i < IMX_ECSPI_MAX_CHIPSELECTS; ++i) {
+if (bus->cspins[i].valid) {
+  if (i != cs) {
+imx_gpio_set_output(>cspins[i].pin, idle);
+  } else {
+imx_gpio_set_output(>cspins[cs].pin, select);
+  }
+}
+  }
+}
+
 static uint32_t imx_ecspi_conreg_divider(imx_ecspi_bus *bus, uint32_t speed_hz)
 {
   uint32_t post;
@@ -286,6 +314,11 @@ static void imx_ecspi_next_msg(imx_ecspi_bus *bus, 
volatile imx_ecspi *regs)
 msg->cs
   );
 }
+if ((msg->mode & SPI_NO_CS) != 0) {
+  imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+} else {
+  imx_ecspi_set_chipsel(bus, msg->cs);
+}
 
 bus->todo = msg->len;
 bus->rx_buf = msg->rx_buf;
@@ -323,6 +356,37 @@ static void imx_ecspi_interrupt(void *arg)
   }
 }
 
+static int imx_ecspi_check_messages(
+  imx_ecspi_bus *bus,
+  const spi_ioc_transfer *msg,
+  uint32_t size)
+{
+  while(size > 0) {
+if (msg->delay_usecs != 0) {
+  return -EINVAL;
+}
+if (msg->bits_per_word > 32) {
+  return -EINVAL;
+}
+if ((msg->mode &
+~(SPI_CPHA | SPI_CPOL | SPI_LOOP | SPI_NO_CS)) != 0) {
+  return -EINVAL;
+}
+if ((msg->mode & SPI_NO_CS) == 0 &&
+(msg->cs > IMX_ECSPI_MAX_CHIPSELECTS || !bus->cspins[msg->cs].valid)) {
+  return -EINVAL;
+}
+if (msg->cs_change != 0) {
+  return -EINVAL;
+}
+
+++msg;
+--size;
+  }
+
+  return 0;
+}
+
 static int imx_ecspi_transfer(
   spi_bus *base,
   const spi_ioc_transfer *msgs,
@@ -330,16 +394,22 @@ static int imx_ecspi_transfer(
 )
 {
   imx_ecspi_bus *bus;
+  int rv;
 
   bus = (imx_ecspi_bus *) base;
 
-  bus->msg_todo = n;
-  bus->msg = [0];
-  bus->task_id = rtems_task_self();
+  rv = imx_ecspi_check_messages(bus, msgs, n);
 
-  imx_ecspi_next_msg(bus, bus->regs);
-  rtems_event_transient_receive(RTEMS_WAIT, RTEMS_NO_TIMEOUT);
-  return 0;
+  if (rv == 0) {
+bus->msg_todo = n;
+bus->msg = [0];
+bus->task_id = rtems_task_self();
+
+imx_ecspi_next_msg(bus, bus->regs);
+rtems_event_transient_receive(RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+  }
+  return rv;
 }
 
 static void imx_ecspi_destroy(spi_bus *base)
@@ -356,6 +426,14 @@ static int imx_ecspi_init(imx_ecspi_bus *bus, const void 
*fdt, int node)
   rtems_status_code sc;
   int len;
   const uint32_t *val;
+  size_t i;
+
+  for (i = 0; i < IMX_ECSPI_MAX_CHIPSELECTS; ++i) {
+rtems_status_code sc_gpio = imx_gpio_init_from_fdt_property(
+>cspins[i].pin, node, "cs-gpios", IMX_GPIO_MODE_OUTPUT, i);
+bus->cspins[i].valid = (sc_gpio == RTEMS_SUCCESSFUL);
+  }
+  imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
 
   imx_ecspi_config(
 bus,
@@ -436,7 +514,7 @@ int spi_bus_register_imx(const char *bus_path, const char 
*alias_or_path)
   }
 
   bus->base.max_speed_hz = imx_ccm_ecspi_hz();
-  bus->base.delay_usecs = 1;
+  bus->base.delay_usecs = 0;
   bus->regs = imx_get_reg_of_node(fdt, node);
   bus->irq = imx_get_irq_of_node(fdt, node, 0);
 
-- 
2.26.2

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

[PATCH rtems / rtems-libbsd] Updates for imx BSP

[Christian Mauderer]

Hello,

this two patch sets add fixes and improvements for the imx BSP:

In RTEMS:
- A small GPIO driver is added. It is used in the SPI driver to
  fix a wrong behaviour of the chip select lines that can't be fixed if
  the chip selects are controlled by the SPI controller instead of
  GPIOs.
- The copy of the FDT is now cache aligned if a cache alignment is given
  for the CPU.

In libbsd:
- Some dead code is eliminated.
- The imx GPIO driver is used instead of the ported FreeBSD one.
  Otherwise the FreeBSD driver will re-initialize the GPIOs.
- Some caching problems are fixed.

Both patch sets are intended for the master branches. In theory we could
think about backporting them to 5 because some bugs are fixed. But I'm
not sure whether the GPIO counts as a new feature or not.

Best regards

Christian


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

[PATCH rtems 1/3] bsp/imx: Add a GPIO driver.

[Christian Mauderer]

---
 bsps/arm/imx/gpio/imx-gpio.c | 359 +++
 bsps/arm/imx/headers.am  |   1 +
 bsps/arm/imx/include/bsp/imx-gpio.h  | 196 +++
 bsps/arm/imx/include/bsp/irq.h   |   1 +
 bsps/arm/imx/start/bspstart.c|   2 +-
 bsps/include/bsp/fatal.h |   1 +
 c/src/lib/libbsp/arm/imx/Makefile.am |   3 +
 7 files changed, 562 insertions(+), 1 deletion(-)
 create mode 100644 bsps/arm/imx/gpio/imx-gpio.c
 create mode 100644 bsps/arm/imx/include/bsp/imx-gpio.h

diff --git a/bsps/arm/imx/gpio/imx-gpio.c b/bsps/arm/imx/gpio/imx-gpio.c
new file mode 100644
index 00..552e1d5cc2
--- /dev/null
+++ b/bsps/arm/imx/gpio/imx-gpio.c
@@ -0,0 +1,359 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019-2020 embedded brains GmbH.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX_GPIO_ALIAS_NAME "gpioX"
+
+/*
+ * i.MX6ULL has 5, i.MX7D has 7
+ *
+ * Be careful when changing this. The attach() does a simple ASCII conversion.
+ */
+#define IMX_MAX_GPIO_MODULES 7
+
+struct imx_gpio_regs {
+  uint32_t dr;
+  uint32_t gdir;
+  uint32_t psr;
+  uint32_t icr1;
+#define IMX_GPIO_ICR_LOW_LEVEL 0
+#define IMX_GPIO_ICR_HIGH_LEVEL 1
+#define IMX_GPIO_ICR_RISING_EDGE 2
+#define IMX_GPIO_ICR_FALLING_EDGE 3
+  uint32_t icr2;
+  uint32_t imr;
+  uint32_t isr;
+  uint32_t edge_sel;
+};
+
+struct imx_gpio {
+  char name[sizeof(IMX_GPIO_ALIAS_NAME)];
+  struct imx_gpio_regs *regs;
+  rtems_interrupt_lock lock;
+};
+
+/* The GPIO modules. These will be initialized based on the FDT alias table. */
+struct imx_gpio imx_gpio[IMX_MAX_GPIO_MODULES];
+
+const char *imx_gpio_get_name(struct imx_gpio *imx_gpio)
+{
+  return imx_gpio->name;
+}
+
+static void imx_gpio_attach(void)
+{
+  size_t i;
+  const void *fdt;
+
+  fdt = bsp_fdt_get();
+
+  memset(imx_gpio, 0, sizeof(imx_gpio));
+
+  for (i = 0; i < IMX_MAX_GPIO_MODULES; ++i) {
+const char *path;
+int node;
+const uint32_t *val;
+uint32_t gpio_regs = 0;
+int len;
+
+memcpy(imx_gpio[i].name, IMX_GPIO_ALIAS_NAME, sizeof(IMX_GPIO_ALIAS_NAME));
+imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-2] = (char)('0' + i);
+
+path = fdt_get_alias(fdt, imx_gpio[i].name);
+if (path == NULL) {
+  continue;
+}
+
+node = fdt_path_offset(fdt, path);
+if (node < 0) {
+  bsp_fatal(IMX_FATAL_GPIO_UNEXPECTED_FDT);
+}
+
+val = fdt_getprop(fdt, node, "reg", );
+if (len > 0) {
+  gpio_regs = fdt32_to_cpu(val[0]);
+} else {
+  bsp_fatal(IMX_FATAL_GPIO_UNEXPECTED_FDT);
+}
+
+imx_gpio[i].regs = (struct imx_gpio_regs *)gpio_regs;
+rtems_interrupt_lock_initialize(_gpio[i].lock, imx_gpio[i].name);
+  }
+}
+
+struct imx_gpio *imx_gpio_get_by_index(unsigned idx)
+{
+  if ((idx < IMX_MAX_GPIO_MODULES) && (imx_gpio[idx].regs != NULL)) {
+return _gpio[idx];
+  }
+  return NULL;
+}
+
+struct imx_gpio *imx_gpio_get_by_register(void *regs)
+{
+  size_t i;
+
+  for (i = 0; i < IMX_MAX_GPIO_MODULES; ++i) {
+if (imx_gpio[i].regs == regs) {
+  return _gpio[i];
+}
+  }
+  return NULL;
+}
+
+static void imx_gpio_direction_input(struct imx_gpio_pin *pin)
+{
+  rtems_interrupt_lock_context lock_context;
+  rtems_interrupt_lock_acquire(>gpio->lock, _context);
+  pin->gpio->regs->gdir &= ~pin->mask;
+  rtems_interrupt_lock_release(>gpio->lock, _context);
+}
+
+static void imx_gpio_direction_output(struct imx_gpio_pin *pin)
+{
+  rtems_interrupt_lock_context lock_context;
+  rtems_interrupt_lock_acquire(>gpio->lock, _context);
+  pin->gpio->regs->gdir |= pin->mask;
+