Re: [PATCH rtems-libbsd v2 0/2] Update the CGEM driver
These patches look good to me. Thanks for this contribution!
Kinsey
On Fri, Mar 3, 2023 at 9:54 AM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:
> Update the CGEM driver with adding the phy address and
> the clock to read it from the device tree.
>
> 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
>
> v2:
> - Add changes gated behind #ifdef __rtems__
> - Use braces {} with if/else for a single line
> - Drop weak symbol patch
>
> Padmarao Begari (2):
> freebsd/cgem: Add phy address to read it from device tree
> freebsd/cgem: Read clock frequency from device tree
>
> freebsd/sys/dev/cadence/if_cgem.c | 72 +--
> 1 file changed, 69 insertions(+), 3 deletions(-)
>
> --
> 2.25.1
>
> ___
> 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: Rust for RTEMS [was: Re: Interested for GSoC 2023]
On 2/27/23 12:00, Karel Gardas wrote:
On 2/27/23 02:16, Joel Sherrill wrote:
Another GCC related project could be Rust RTEMS Support but I don't
know what that entails beyond turning it on and seeing what goes
wrong. I tried to build it last year and got far enough to decide to
wait before trying again.
Not sure how far you went. The process is generally:
(1) tune Rust compiler to cross-compile correctly for specific
hardware/os
platform. So basically you get no_std capable compiler
(2) review, patch and by using (1) cross-compile libc
(3) using sources from (1) and (2) build full stage (std enabled) rustc.
(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
sharp edges for RTEMS.
Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not
cortex-
mX).
Something is running:
silence:/tmp$ cat hello-rtems.rs
#![no_std]
#![no_main]
use core::panic::PanicInfo;
use core::ffi::c_char;
use core::ffi::c_int;
extern "C" {
fn puts(str: *const c_char) -> c_int;
}
#[no_mangle]
pub fn main() -> ! {
unsafe {
puts(b"Rust says hello to hosting RTEMS\n\0".as_ptr() as *const
i8);
}
loop {}
}
#[panic_handler]
fn panic(_: ) -> ! {
loop {}
}
silence:/tmp$ /tmp/rustc-rtems-arm/bin/rustc -g -Z verbose
--target=arm-rtems hello-rtems.rs -lrtemscpu -lrtemsbsp -lrtemsdefaultconfig
silence:/tmp$ file hello-rtems.exe
hello-rtems.exe: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
statically linked, with debug_info, not stripped
silence:/tmp$ ~rtems/sfw/qemu-7.2.0/bin/qemu-system-arm -serial null
-serial mon:stdio -nographic -M xilinx-zynq-a9 -m 512M -kernel
/tmp/hello-rtems.exe
Rust says hello to hosting RTEMS
QEMU 7.2.0 monitor - type 'help' for more information
(qemu) q
silence:/tmp$
Note: this is hacked rust-lang.org rust compiler, not gccrs project and
soon to be released GCC 13.
The biggest problem and probably soon to be source of headaches is
mixture of LLVM's compiler-rt and GCC's libgcc binaries. This means once
you employ for example arithmetic you need to add
-C link-arg=-Wl,--allow-multiple-definition otherwise you would get
multiple definitions symbols error.
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd v2 2/2] freebsd/cgem: Read clock frequency from device tree
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 | 42 ---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/freebsd/sys/dev/cadence/if_cgem.c
b/freebsd/sys/dev/cadence/if_cgem.c
index 0aab0771..eda0e853 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,30 @@ cgem_get_phyaddr(phandle_t node)
}
#endif /* __rtems__ */
+#ifdef __rtems__
+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;
+}
+#endif /* __rtems__ */
+
/* Reset hardware. */
static void
cgem_reset(struct cgem_softc *sc)
@@ -1279,12 +1304,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;
@@ -2037,6 +2066,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 v2 1/2] freebsd/cgem: Add phy address to read it from device tree
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 | 30 ++
1 file changed, 30 insertions(+)
diff --git a/freebsd/sys/dev/cadence/if_cgem.c
b/freebsd/sys/dev/cadence/if_cgem.c
index 689c3611..0aab0771 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);
}
+#ifdef __rtems__
+static int
+cgem_get_phyaddr(phandle_t node)
+{
+ phandle_t phy_node;
+ pcell_t phy_handle, phy_reg;
+
+ if (OF_getencprop(node, "phy-handle", (void *)_handle,
+ sizeof(phy_handle)) <= 0)
+ return (MII_PHY_ANY);
+
+ phy_node = OF_node_from_xref(phy_handle);
+
+ if (OF_getencprop(phy_node, "reg", (void *)_reg,
+ sizeof(phy_reg)) <= 0)
+ return (MII_PHY_ANY);
+
+ return (phy_reg);
+}
+#endif /* __rtems__ */
+
/* Reset hardware. */
static void
cgem_reset(struct cgem_softc *sc)
@@ -2091,10 +2112,19 @@ cgem_attach(device_t dev)
cgem_reset(sc);
CGEM_UNLOCK(sc);
+#ifdef __rtems__
+ int phy_addr = cgem_get_phyaddr(node);
+#endif /* __rtems__ */
+
/* Attach phy to mii bus. */
err = mii_attach(dev, >miibus, ifp,
cgem_ifmedia_upd, cgem_ifmedia_sts,
+#ifdef __rtems__
+BMSR_DEFCAPMASK, phy_addr, MII_OFFSET_ANY, 0);
+#else /* __rtems__ */
BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0);
+#endif /* __rtems__ */
+
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 v2 0/2] Update the CGEM driver
Update the CGEM driver with adding the phy address and
the clock to read it from the device tree.
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
v2:
- Add changes gated behind #ifdef __rtems__
- Use braces {} with if/else for a single line
- Drop weak symbol patch
Padmarao Begari (2):
freebsd/cgem: Add phy address to read it from device tree
freebsd/cgem: Read clock frequency from device tree
freebsd/sys/dev/cadence/if_cgem.c | 72 +--
1 file changed, 69 insertions(+), 3 deletions(-)
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: CAN driver implementation for Xilinx Zynq
On Wed, Mar 1, 2023 at 3:14 AM wrote: > > Hello, > > As part of an internship at the German Aerospace Center, I am currently > working on the implementation of a CAN driver for a Xilinx Zynq SoC. For this > I used the existing CAN framework /dev/can/can.h. A merge request will follow > soon. > > > Here's what I'd like to add to the framework if it hasn't already been done: > > * RxFIFO. Currently can_bus_read only stores the latest CAN message in > can_bus->can_rx_msg. > There is a FIXME note on this in can.c, line 188, but I couldn't find an > implementation of it. > This will be great. Other issues to address in this code base are the lack of integration with existing RTEMS functionality. Especially helpful would be to add message queue abstraction layer along with making a more proper device driver structure. Message queue has the advantage that it can take care of handling multiple priorities and synchronization, and reduces the code size and maintenance burden. You can see an interface/implementation like this in: https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan > * ioctl functionality. can_bus_ioctl does not forward the commands and > arguments to can_dev_ops->dev_ioctl. > Is there a reason for that? I propose a command enum that would provide > consistency. > > > @Prashanth S (fishesprasha...@gmail.com) have you already worked on these > points? > > Thanks everyone for your feedback! > > Best regards > Carlo Brokering > > > > ___ > 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: RTEMS LwIP licensing and organization cleanup proposal
Hello Pavel, As discussed on discord, I have created a ticket to resolve this issue: https://devel.rtems.org/ticket/4867 Please see the ticket for further details and further constraining the desired solution. Kinsey On Fri, Mar 3, 2023 at 7:32 AM Pavel Pisa wrote: > Dear Premek and other developers, > > I am happy that LwIP is getting into state > of viable alternative of TCP/IP stack for > resource constrained RTEMS targets. > > But as I have already reported before, I would > be happy if the code licenses and locations are cleanup. > > The RTEMS core integration layer is held in uLan/ports/os/rtems > subdirectory > > > https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c > > It should be moved somewhere else, i.e. under > > https://git.rtems.org/rtems-lwip/tree/rtemslwip/common > > but for sure the reference to our uLAN project is nonsense in this > content > > https://ulan.sourceforge.net/ > > even that initial LwIP integration for RTEMS is based on our > previous work in frame of that project for system-less and later > RTEMS use. > > To make integration with RTEMS easier, the source should > be relicensed to some common actual RTEMS license template, > for example > > https://git.rtems.org/rtems/tree/bsps/arm/lpc176x/start/bspstart.c > > We have referenced Swedish Institute of Computer Science license > there to allow integration even to some official LwIP port > but except for function and defines names the code is our own > so RTEMS copyright with reference to implementation inspired by > other LwIP OS integration should be OK. > > I have contacted Premysl Houdek who worked on project during > his RTEMS GSoC and followup diploma thesis > > > https://support.dce.felk.cvut.cz/mediawiki/images/f/f1/Dp_2016_houdek_premysl.pdf > > and he is prepared to confirm relicensing to any RTEMS fitting > open source license. > > For actual RTEMS LwIP users and contributors, please propose license change > or chose some of above offers and then propose new files location including > git patches or I can take that action if > > Best wishes, > > Pavel > -- > Pavel Píša > phone: +420 603531357 > e-mail: p...@cmp.felk.cvut.cz > Department of Control Engineering FEE CVUT > Karlovo namesti 13, 121 35, Prague 2 > university: http://control.fel.cvut.cz/ > company:https://pikron.com/ > personal: http://cmp.felk.cvut.cz/~pisa > projects: https://www.openhub.net/accounts/ppisa > CAN related:http://canbus.pages.fel.cvut.cz/ > RISC-V education: https://comparch.edu.cvut.cz/ > Open Technologies Research Education and Exchange Services > https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home > ___ > 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] bsps/riscv: Clear interrupt complete before disable
Hi Sebastian, > On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote: > > > On 27.02.23 16:51, Padmarao Begari wrote: > > The interrupt complete should clear with the interrupt > > number before disabling the interrupt in the PLIC to > > get the next interrupt. > > Which problem does this patch address? > The problem occurs when the interrupt register(enabled) in the RTEMS- LIBBSD drivers and want to serve the interrupt subroutine in the RTEMS. Example : CGEM driver When the application running to test the CGEM driver with RTEMS + RTEMS-LIBBSD, The interrupt is occurred while transmiting the ethernet pocket, the RTEMS is received the interrupt but not served with the register interrupt subroutine instead it disable the interrupt and set the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is clearing the interrupt complete register but there is no effect and the next transmit pocket intereupt is not occurred because the interrupt is disabled before the interrupt complete clear. RISC-V interrupt stacktrace ** _RISCV_Exception_handler() _RISCV_Interrupt_dispatch() bsp_interrupt_handler_dispatch_unchecked() bsp_interrupt_dispatch_entries() ( *entry->handler )( entry->arg ); -> bsp_interrupt_server_trigger() bsp_interrupt_server_trigger() bsp_interrupt_is_valid_vector() bsp_interrupt_vector_disable() rtems_event_system_send() * Regards Padmarao -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas > Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS LwIP licensing and organization cleanup proposal
Dear Premek and other developers, I am happy that LwIP is getting into state of viable alternative of TCP/IP stack for resource constrained RTEMS targets. But as I have already reported before, I would be happy if the code licenses and locations are cleanup. The RTEMS core integration layer is held in uLan/ports/os/rtems subdirectory https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c It should be moved somewhere else, i.e. under https://git.rtems.org/rtems-lwip/tree/rtemslwip/common but for sure the reference to our uLAN project is nonsense in this content https://ulan.sourceforge.net/ even that initial LwIP integration for RTEMS is based on our previous work in frame of that project for system-less and later RTEMS use. To make integration with RTEMS easier, the source should be relicensed to some common actual RTEMS license template, for example https://git.rtems.org/rtems/tree/bsps/arm/lpc176x/start/bspstart.c We have referenced Swedish Institute of Computer Science license there to allow integration even to some official LwIP port but except for function and defines names the code is our own so RTEMS copyright with reference to implementation inspired by other LwIP OS integration should be OK. I have contacted Premysl Houdek who worked on project during his RTEMS GSoC and followup diploma thesis https://support.dce.felk.cvut.cz/mediawiki/images/f/f1/Dp_2016_houdek_premysl.pdf and he is prepared to confirm relicensing to any RTEMS fitting open source license. For actual RTEMS LwIP users and contributors, please propose license change or chose some of above offers and then propose new files location including git patches or I can take that action if Best wishes, Pavel -- Pavel Píša phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ company:https://pikron.com/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN driver implementation for Xilinx Zynq
Hi @carlo.broker...@dlr.de , Once the commands are defined the corresponding command and buffer should be passed as arguments. As the commands are not defined Null and zero are passed as buffer and command respectively. Regards Prashanth S On Thu, 2 Mar, 2023, 2:22 pm , wrote: > Hello @Prashanth S > > > > > I saw in discord there was a discussion for the rework of CAN framework, > so you could start a discussion in this mailing list or in discord. > > Good to know. I’ll have a look there. > > > > > The ioctl commands are not defined for the CAN framework, so NULL and 0 > are passed to dev_ioctl. > > Ok but i don't quite understand how commands are otherwise sent to the bsp > driver. > > Should that only work once defined commands have been discussed and > implemented? > > > > > > Best regards > > Carlo Brokering > > > > > > *Von:* Prashanth S > *Gesendet:* Donnerstag, 2. März 2023 07:25 > *An:* Brokering, Carlo > *Cc:* devel@rtems.org > *Betreff:* Re: CAN driver implementation for Xilinx Zynq > > > > Hi @carlo.broker...@dlr.de , > > > > > the design for the rx data path including the RxFIFO looks promising. If > nobody is working on it yet, I would try to implement it. You said it still > needs to be approved - > > > who do I have to contact for this? > > I saw in discord there was a discussion for the rework of CAN framework, > so you could start a discussion in this mailing list or in discord. > > > > > > I think you misunderstood me about the ioctl api. My main question was > why command and buffer are not passed to the dev_ioctl here: > > > > > > bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); > > The ioctl commands are not defined for the CAN framework, so NULL and 0 > are passed to dev_ioctl. > > > > Regards > > Prashanth S > > > > On Wed, 1 Mar 2023 at 21:08, wrote: > > Hello Prashanth S, > > > > the design for the rx data path including the RxFIFO looks promising. If > nobody is working on it yet, I would try to implement it. You said it still > needs to be approved - who do I have to contact for this? > > > > I think you misunderstood me about the ioctl api. My main question was why > command and buffer are not passed to the dev_ioctl here: > > > > bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0); > > > > Regards > > Carlo Brokering > > > > *Von:* Prashanth S > *Gesendet:* Mittwoch, 1. März 2023 11:53 > *An:* Brokering, Carlo > *Cc:* devel@rtems.org > *Betreff:* Re: CAN driver implementation for Xilinx Zynq > > > > Hello @Carlo Brokering, > > > > > As part of an internship at the German Aerospace Center, I am currently > working on the implementation of a CAN driver for a Xilinx > > > Zynq SoC. For this I used the existing CAN framework /dev/can/can.h. A > merge request will follow soon. > > All the best for your Internship. > > > > > > > > Here's what I'd like to add to the framework if it hasn't already been > done: > > > > * RxFIFO. Currently can_bus_read only stores the latest CAN message in > can_bus->can_rx_msg. > > > There is a FIXME note on this in can.c, line 188, but I couldn't find an > implementation of it. > > Currently, the CAN framework has minimal rx support. The design of the rx > data path in the CAN Framework is ready (You could use that design if > approved or you can have your own design). > > > > Note: The tx data path has been implemented, it supports multiple open > among different tasks, configurable buffers. > > > > > * ioctl functionality. can_bus_ioctl does not forward the commands and > arguments to can_dev_ops->dev_ioctl. > > > Is there a reason for that? I propose a command enum that would provide > consistency. > > The bsp CAN driver should register the ioctl api with the CAN Framework > for device specific commands (To add commands for hardware independent > functionality the commands can be added before "if (bus == NULL || > bus->can_dev_ops->dev_ioctl == NULL)" statement. > > > > struct can_dev_ops dev_ops (.dev_ioctl member should be registered). > > > > > > > > @Prashanth S (fishesprasha...@gmail.com) have you already worked on > these points? > > > > For the overview of the CAN framework, tx, rx, data paths you can refer > the docs files in the gitlab link (.puml version of the docs are also > available if you needed ( > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f) > ). > > > > You can use the gitlab > https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs > link for the design documents. > > > > Regards > > Prashanth S > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
