[PATCH rtems-libbsd] nexus-devices: Add riscv/MPFS BSP variant

2023-02-28 Thread Padmarao Begari
Add riscv Microchip PolarFire SoC BSP variant and the
CGEM driver support
---
 rtemsbsd/include/bsp/nexus-devices.h | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 43a08207..239cb21e 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -285,6 +285,16 @@ SYSINIT_DRIVER_REFERENCE(xae, simplebus);
 SYSINIT_DRIVER_REFERENCE(axidma, simplebus);
 RTEMS_BSD_DRIVER_E1000PHY;
 
-#endif /* LIBBSP_MICROBLAZE_FPGA_BSP_H */
+#elif defined(LIBBSP_RISCV_GENERIC_H)
+
+#include 
+#if defined(RISCV_ENABLE_MPFS_SUPPORT)
+RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
+SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
+SYSINIT_DRIVER_REFERENCE(cgem, simplebus);
+RTEMS_BSD_DRIVER_UKPHY;
+#endif /* RISCV_ENABLE_MPFS_SUPPORT */
+
+#endif /* LIBBSP_RISCV_GENERIC_H */
 
 #endif
-- 
2.25.1

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


[PATCH rtems-libbsd 3/3] freebsd/cgem: Add weak symbol for riscv

2023-02-28 Thread Padmarao Begari
Add __weak_symbol instead of __weak_reference for the
cgem_set_ref_clk() function for riscv build.
---
 freebsd/sys/dev/cadence/if_cgem.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
b/freebsd/sys/dev/cadence/if_cgem.c
index 363a9717..a12f7b43 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -1764,6 +1764,12 @@ cgem_miibus_linkchg(device_t dev)
  * Overridable weak symbol cgem_set_ref_clk().  This allows platforms to
  * provide a function to set the cgem's reference clock.
  */
+#ifdef __riscv
+__weak_symbol int cgem_set_ref_clk(int unit, int frequency)
+{
+   return 0;
+}
+#else
 static int __used
 cgem_default_set_ref_clk(int unit, int frequency)
 {
@@ -1771,6 +1777,7 @@ cgem_default_set_ref_clk(int unit, int frequency)
return 0;
 }
 __weak_reference(cgem_default_set_ref_clk, cgem_set_ref_clk);
+#endif /* __riscv */
 
 /* Call to set reference clock and network config bits according to media. */
 static void
-- 
2.25.1

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


[PATCH rtems-libbsd 2/3] freebsd/cgem: Read clock frequency from device tree

2023-02-28 Thread Padmarao Begari
Read the clock frequency from the device tree and use it to
calculate the mdc clock divider for the MII bus if not found
then use default clock divider.
---
 freebsd/sys/dev/cadence/if_cgem.c | 39 ---
 1 file changed, 36 insertions(+), 3 deletions(-)

diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
b/freebsd/sys/dev/cadence/if_cgem.c
index 2888a085..363a9717 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -135,6 +135,7 @@ struct cgem_softc {
uint32_tnet_cfg_shadow;
int neednullqs;
int phy_contype;
+   uint32_tpclk_rate;
 #endif /* __rtems__ */
int ref_clk_num;
 #ifndef __rtems__
@@ -1238,6 +1239,27 @@ cgem_get_phyaddr(phandle_t node, int *phy_addr)
return (0);
 }
 
+static uint32_t cgem_mdc_clk_div(struct cgem_softc *sc)
+{
+   uint32_t config;
+   uint32_t pclk_hz = sc->pclk_rate;
+
+   if (pclk_hz <= 2000)
+   config = CGEM_NET_CFG_MDC_CLK_DIV_8;
+   else if (pclk_hz <= 4000)
+   config = CGEM_NET_CFG_MDC_CLK_DIV_16;
+   else if (pclk_hz <= 8000)
+   config = CGEM_NET_CFG_MDC_CLK_DIV_32;
+   else if (pclk_hz <= 12000)
+   config = CGEM_NET_CFG_MDC_CLK_DIV_48;
+   else if (pclk_hz <= 16000)
+   config = CGEM_NET_CFG_MDC_CLK_DIV_64;
+   else
+   config = CGEM_NET_CFG_MDC_CLK_DIV_96;
+
+   return config;
+}
+
 /* Reset hardware. */
 static void
 cgem_reset(struct cgem_softc *sc)
@@ -1279,12 +1301,16 @@ cgem_reset(struct cgem_softc *sc)
sc->net_cfg_shadow = CGEM_NET_CFG_DBUS_WIDTH_32;
}
 
+   if (sc->pclk_rate != 0) {
+   sc->net_cfg_shadow |= cgem_mdc_clk_div(sc);
+   } else {
 #ifdef CGEM64
-   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_48;
+   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_48;
 #else
-   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_64;
+   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_64;
 #endif
-   WR4(sc, CGEM_NET_CFG, sc->net_cfg_shadow);
+   WR4(sc, CGEM_NET_CFG, sc->net_cfg_shadow);
+   }
 #endif /* __rtems__ */
 
sc->net_ctl_shadow = CGEM_NET_CTRL_MGMT_PORT_EN;
@@ -2038,6 +2064,13 @@ cgem_attach(device_t dev)
 #endif /* __rtems__ */
/* Get reference clock number and base divider from fdt. */
node = ofw_bus_get_node(dev);
+#ifdef __rtems__
+   if (OF_getencprop(node, "clock-frequency", , sizeof(cell)) > 0)
+   sc->pclk_rate = cell;
+   else
+   sc->pclk_rate = 0;
+#endif /* __rtems__ */
+
sc->ref_clk_num = 0;
if (OF_getprop(node, "ref-clock-num", , sizeof(cell)) > 0)
sc->ref_clk_num = fdt32_to_cpu(cell);
-- 
2.25.1

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


[PATCH rtems-libbsd 1/3] freebsd/cgem: Add phy address to read it from device tree

2023-02-28 Thread Padmarao Begari
Read the phy address from the device tree and use it to
find the phy device if not found then search in the
range of 0 to 31.
---
 freebsd/sys/dev/cadence/if_cgem.c | 41 ---
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
b/freebsd/sys/dev/cadence/if_cgem.c
index 689c3611..2888a085 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -1217,6 +1217,27 @@ cgem_intr(void *arg)
CGEM_UNLOCK(sc);
 }
 
+static int
+cgem_get_phyaddr(phandle_t node, int *phy_addr)
+{
+   phandle_t phy_node;
+   pcell_t phy_handle, phy_reg;
+
+   if (OF_getencprop(node, "phy-handle", (void *)_handle,
+   sizeof(phy_handle)) <= 0)
+   return (ENXIO);
+
+   phy_node = OF_node_from_xref(phy_handle);
+
+   if (OF_getencprop(phy_node, "reg", (void *)_reg,
+   sizeof(phy_reg)) <= 0)
+   return (ENXIO);
+
+   *phy_addr = phy_reg;
+
+   return (0);
+}
+
 /* Reset hardware. */
 static void
 cgem_reset(struct cgem_softc *sc)
@@ -2003,6 +2024,7 @@ cgem_attach(device_t dev)
pcell_t cell;
int rid, err;
u_char eaddr[ETHER_ADDR_LEN];
+   int phy_addr;
 
sc->dev = dev;
CGEM_LOCK_INIT(sc);
@@ -2091,10 +2113,21 @@ cgem_attach(device_t dev)
cgem_reset(sc);
CGEM_UNLOCK(sc);
 
-   /* Attach phy to mii bus. */
-   err = mii_attach(dev, >miibus, ifp,
-cgem_ifmedia_upd, cgem_ifmedia_sts,
-BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0);
+   err = cgem_get_phyaddr(node, _addr);
+   if (err == 0) {
+   /* Attach phy to mii bus. */
+   err = mii_attach(dev, >miibus, ifp,
+cgem_ifmedia_upd, cgem_ifmedia_sts,
+BMSR_DEFCAPMASK, phy_addr, MII_OFFSET_ANY, 0);
+   }
+
+   if (err) {
+   /* Attach phy to mii bus. */
+   err = mii_attach(dev, >miibus, ifp,
+cgem_ifmedia_upd, cgem_ifmedia_sts,
+BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 
0);
+   }
+
if (err) {
device_printf(dev, "attaching PHYs failed\n");
cgem_detach(dev);
-- 
2.25.1

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


[PATCH rtems-libbsd 0/3] Update the CGEM driver

2023-02-28 Thread Padmarao Begari
Update the CGEM driver with adding the phy address and
the clock to read it from the device tree and use __weak_symbol
for the riscv build.

The patches are based upon latest rtems-libbsd tree at 6-freebsd-12
(https://git.rtems.org/rtems-libbsd.git branch 6-freebsd-12) 
at commit id 1aa4cb8568594aa54238c9fbf2cc0f3ea4edec7f

Padmarao Begari (3):
  freebsd/cgem: Add phy address to read it from device tree
  freebsd/cgem: Read clock frequency from device tree
  freebsd/cgem: Add weak symbol for riscv

 freebsd/sys/dev/cadence/if_cgem.c | 87 ---
 1 file changed, 80 insertions(+), 7 deletions(-)

-- 
2.25.1

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


Re: Interested for GSoC 2023

2023-02-28 Thread Joel Sherrill
On Tue, Feb 28, 2023 at 4:50 PM Vihas Makwana  wrote:

> Hi Joel,
>
> After a careful thought, I have decided to group multiple medium level
> projects for upcoming GSoC.
> That would allow me to contribute substantially, as well as help me to
> learn different parts of the RTEMS.
>

OK. Just work with us to make sure you have done the prep work to reduce
risk on all of them.

In case it isn't clear, we want all projects to succeed and much of the odd
discussion we have is intended to make sure you are prepared and the
project is still viable.

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

Re: Interested for GSoC 2023

2023-02-28 Thread Vihas Makwana
Hi Joel,

After a careful thought, I have decided to group multiple medium level
projects for upcoming GSoC.
That would allow me to contribute substantially, as well as help me to
learn different parts of the RTEMS.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Hello World Test Completed

2023-02-28 Thread Joel Sherrill
Good job! Add yourself to the table here:

https://devel.rtems.org/wiki/GSoC/2023

Do you have any project in mind? The sparc/erc32 may or may not be the best
BSP to do that on.

--joel

On Tue, Feb 28, 2023 at 10:07 AM Siddharth Khattar 
wrote:

> Hello,
> I've successfully completed the GSoC Hello World Test as required, please
> see the screenshots below as confirmation. Please tell me if I have done
> correctly.
>
> Thanking you,
> Siddharth Khattar
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH Resend] bsps/riscv: Clear interrupt complete before disable

2023-02-28 Thread Padmarao Begari
The interrupt complete should clear with the interrupt
number before disabling the interrupt in the PLIC to
get the next interrupt.
---
 bsps/riscv/riscv/irq/irq.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/bsps/riscv/riscv/irq/irq.c b/bsps/riscv/riscv/irq/irq.c
index e8d297052b..8e72bd8da5 100644
--- a/bsps/riscv/riscv/irq/irq.c
+++ b/bsps/riscv/riscv/irq/irq.c
@@ -585,6 +585,8 @@ rtems_status_code 
bsp_interrupt_vector_disable(rtems_vector_number vector)
 
 #ifdef RTEMS_SMP
 if (enable != NULL) {
+  cpu = _Per_CPU_Get_by_index(_CPU_SMP_Get_current_processor());
+  cpu->cpu_per_cpu.plic_hart_regs->claim_complete = interrupt_index;
   enable[group] &= ~bit;
 } else {
   uint32_t cpu_max;
@@ -595,6 +597,7 @@ rtems_status_code 
bsp_interrupt_vector_disable(rtems_vector_number vector)
   for (cpu_index = 0; cpu_index < cpu_max; ++cpu_index) {
 cpu = _Per_CPU_Get_by_index(cpu_index);
 enable = cpu->cpu_per_cpu.plic_m_ie;
+cpu->cpu_per_cpu.plic_hart_regs->claim_complete = interrupt_index;
 
 if (enable != NULL) {
   enable[group] &= ~bit;
@@ -603,6 +606,7 @@ rtems_status_code 
bsp_interrupt_vector_disable(rtems_vector_number vector)
 }
 #else
 cpu = _Per_CPU_Get_by_index(0);
+cpu->cpu_per_cpu.plic_hart_regs->claim_complete = interrupt_index;
 cpu->cpu_per_cpu.plic_m_ie[group] &= ~bit;
 #endif
 
-- 
2.25.1

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


Re: New GPIO-API merged?

2023-02-28 Thread Christian MAUDERER

Hello Jan,

Duc Doan worked on that topic during his GSoC project last year:

  https://github.com/dtbpkmte/GSoC-2022-RTEMS
  https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c
  https://medium.com/@dtbpkmte

The results looked quite interesting (even if some functions were still 
missing like switching GPIO groups). But at the end there was a problem 
with the Apache license of the STM libraries so that the new API would 
have been left without a reference implementation.


The API in the current bsp/gpio.h is designed to match a certain GPIO 
hardware module structure. It is currently implemented only on raspberry 
and beagle. For every GPIO module that doesn't match the structure, it 
adds quite some overhead. For example on the i.MX I tried to use it and 
gave up soon because mapping the structure would have wasted a lot of 
CPU cycles.


Best regards

Christian

On 2023-02-28 10:06, jan.som...@dlr.de wrote:

We now found this general GPIO API here: 
https://github.com/RTEMS/rtems/blob/master/bsps/include/bsp/gpio.h
Is this the current one to use when implementing a new GPIO driver?



-Original Message-
From: devel  On Behalf Of jan.som...@dlr.de
Sent: Mittwoch, 15. Februar 2023 08:40
To: devel@rtems.org
Subject: New GPIO-API merged?

Hello everyone,

Alex' patch reminded me that there was work done related a new general
GPIO-API.
Has that been finished? I tried to find the corresponding header files, but
couldn't.
So, I was wondering what the current status is.

Best regards,

 Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace
Center Institute for Software Technology | Software for Space Systems and
Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

___
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


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.maude...@embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 08

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

RE: New GPIO-API merged?

2023-02-28 Thread Jan.Sommer
We now found this general GPIO API here: 
https://github.com/RTEMS/rtems/blob/master/bsps/include/bsp/gpio.h
Is this the current one to use when implementing a new GPIO driver?


> -Original Message-
> From: devel  On Behalf Of jan.som...@dlr.de
> Sent: Mittwoch, 15. Februar 2023 08:40
> To: devel@rtems.org
> Subject: New GPIO-API merged?
> 
> Hello everyone,
> 
> Alex' patch reminded me that there was work done related a new general
> GPIO-API.
> Has that been finished? I tried to find the corresponding header files, but
> couldn't.
> So, I was wondering what the current status is.
> 
> Best regards,
> 
> Jan
> 
> 
> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace
> Center Institute for Software Technology | Software for Space Systems and
> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
> 
> ___
> 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