Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

Ah, that makes sense. If your patch depends on Utkarsh's work, then we'll need to work on getting that into upstream RTEMS as well. If your patch can be rebased on to current RTEMS master, that would be ideal. Regarding Utkarsh's work not being merged into RTEMS, patches sometimes slip through

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

Hi Mr. Kinsey Moore: I am using the RPi4 BSP (project of GSOC2023) written by Utkarsh Verma. For some reason it wasn't merged. https://lists.rtems.org/pipermail/devel/2023-August/076152.html I got the code from his github: https://github.com/UtkarshVerma/rtems Best regards, Ning > 2024年4月11日

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

I couldn't get this patch to apply. Are you sure it came from the right branch and has no merge commits ahead of it? Kinsey On Wed, Apr 10, 2024 at 9:24 AM Ning Yang wrote: > The clock from the ARM timer is derived from the system clock. This clock > can change dynamically e.g. if the system

Re: [PATCH 0/3] Improve Xilinx TTC clock driver

On 11.04.24 16:56, Kinsey Moore wrote: Beyond the rebase issue, this patch set looks good. Thanks for the review, I checked it in. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16

Re: [PATCH 0/3] Improve Xilinx TTC clock driver

Beyond the rebase issue, this patch set looks good. Kinsey On Wed, Apr 10, 2024 at 6:16 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Sebastian Huber (3): > bsps/xil-ttc: Use interrupt entry > bsps/xil-ttc: Add XIL_FATAL_TTC_IRQ_INSTALL > bsps/xil-ttc: Improve clock

Re: [PATCH 1/3] bsps/xil-ttc: Use interrupt entry

On 11.04.24 16:27, Kinsey Moore wrote:  static void zynqmp_ttc_clock_driver_support_install_isr(    rtems_interrupt_handler handler  )  {    rtems_status_code sc; -  sc = rtems_interrupt_handler_install( -    BSP_SELECTED_TTC_IRQ, -    "Clock", -   

Re: [PATCH 1/3] bsps/xil-ttc: Use interrupt entry

On Wed, Apr 10, 2024 at 6:16 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > --- > bsps/shared/dev/clock/xil-ttc.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/bsps/shared/dev/clock/xil-ttc.c > b/bsps/shared/dev/clock/xil-ttc.c >

[PATCH] dev/irq: Improve Doxgyen group assignments

Make the GIC interrupt controller support a subgroup of the generic interrupt controller support. --- bsps/aarch64/include/dev/irq/arm-gic-arch.h| 13 +++-- bsps/arm/include/dev/irq/arm-gic-arch.h| 13 +++-- bsps/include/dev/irq/arm-gic-irq.h | 15

[PATCH] bsps/aarch64/raspberrypi: Add system timer support

The clock from the ARM timer is derived from the system clock. This clock can change dynamically e.g. if the system goes into reduced power or in low power mode. Thus the clock speed adapts to the overall system performance capabilities. For accurate timing it is recommended to use the system

Re: [PATCH 1/2] dev/clock: Move bcm2835-system-timer driver to shared space

Hi Ning, Patch 1 looks good. Instead of renaming it, you can include bcm2711.h in the RPi4's raspberrypi.h or in bsp.h so that the RPi4 BSP remains largely unchanged. Kinsey On Wed, Apr 10, 2024 at 2:14 AM yan...@qq.com wrote: > Hi Mr. Kinsey Moore, > > Thank you very much for your help. > > I

[PATCH 2/3] bsps/xil-ttc: Add XIL_FATAL_TTC_IRQ_INSTALL

--- bsps/include/bsp/fatal.h | 3 + bsps/shared/dev/clock/xil-ttc.c | 6 +- .../bsps/fatal-clock-xil-ttc-irq-install.yml | 21 ++ spec/build/testsuites/validation/grp.yml | 2 + .../bsps/tr-fatal-clock-xil-ttc-irq-install.c | 187 ++

[PATCH 0/3] Improve Xilinx TTC clock driver

Sebastian Huber (3): bsps/xil-ttc: Use interrupt entry bsps/xil-ttc: Add XIL_FATAL_TTC_IRQ_INSTALL bsps/xil-ttc: Improve clock driver bsps/arm/xilinx-zynqmp-rpu/include/bsp.h | 3 - bsps/arm/xilinx-zynqmp-rpu/include/bsp/irq.h | 1 - bsps/include/bsp/fatal.h

[PATCH 1/3] bsps/xil-ttc: Use interrupt entry

--- bsps/shared/dev/clock/xil-ttc.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/bsps/shared/dev/clock/xil-ttc.c b/bsps/shared/dev/clock/xil-ttc.c index 340c428a48..384f23663b 100644 --- a/bsps/shared/dev/clock/xil-ttc.c +++ b/bsps/shared/dev/clock/xil-ttc.c

[PATCH 3/3] bsps/xil-ttc: Improve clock driver

Make the clock driver parameters configurable. Use the maximum counter frequency to get the best time resolution. Decouple the CPU counter from the timecounter. Make the tick catch up handling more robust. Add a validation test for the tick catch up. ---

Re: [PATCH 1/2] dev/clock: Move bcm2835-system-timer driver to shared space

Hi Mr. Kinsey Moore, Thank you very much for your help. I just sent patch 1. And about patch2, I have a question: In shared/dev/clock/bcm2835-system-timer.c: #if RTEMS_BSP == raspberrypi4b #include #else #include #endif /* RTEMS_BSP */ Do I need to rename bcm2711.h in rpi4 BSP to

[PATCH] dev/clock: Move bcm2835-system-timer driver to shared space

This patch moves the bcm2835 system timer driver in the arm/raspberrypi directory to the shared directory and adjusts arm/raspberrypi BSP. --- .../clockdrv.c => shared/dev/clock/bcm2835-system-timer.c} | 0 spec/build/bsps/arm/raspberrypi/obj.yml | 2 +- 2 files

Re: [PATCH 1/2] dev/clock: Move bcm2835-system-timer driver to shared space

One comment inline below. On Tue, Apr 9, 2024 at 10:02 AM Ning Yang wrote: > This patch moves the bcm2835 system timer driver in the arm/raspberrypi > directory to the shared directory. > > Made some changes in the include section to adapt to rpi4 BSP. > --- > .../clockdrv.c =>

[PATCH 2/2] bsps/aarch64/raspberrypi: Add system timer support

The clock from the ARM timer is derived from the system clock. This clock can change dynamically e.g. if the system goes into reduced power or in low power mode. Thus the clock speed adapts to the overall system performance capabilities. For accurate timing it is recommended to use the system

[PATCH 1/2] dev/clock: Move bcm2835-system-timer driver to shared space

This patch moves the bcm2835 system timer driver in the arm/raspberrypi directory to the shared directory. Made some changes in the include section to adapt to rpi4 BSP. --- .../clockdrv.c => shared/dev/clock/bcm2835-system-timer.c} | 7 +++ spec/build/bsps/arm/raspberrypi/obj.yml

[rtems-docs] c-user: Document interrupt get/set priority

Update #5002. --- c-user/interrupt/directives.rst | 185 +- c-user/interrupt/introduction.rst | 10 +- c-user/rtems_data_types.rst | 19 ++- 3 files changed, 211 insertions(+), 3 deletions(-) diff --git a/c-user/interrupt/directives.rst

[PATCH v2] rtems: Add get/set interrupt priorities

Add directives to get and set the priority of an interrupt vector. Implement the directives for the following BSP families: * arm/lpc24xx * arm/lpc32xx * powerpc/mpc55xxevb * powerpc/qoriq Implement the directives for the following interrupt controllers: * GICv2 and GICv3 (arm and aarch64) *

Re: GCC 14: Some warnings are now errors

On 09.04.24 14:41, Joel Sherrill wrote: Is 14 the version for RTEMS 7 tools? If so, that makes it easier to address the issues. I don't have time to update the RTEMS 7 tools currently. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email:

Re: [PATCH 1/2] dev/clock: add bcm2835-system-timer driver

Hi Ning, This patch set creates a duplication of the rpi3 system clock driver. Instead, I'd suggest a different organization of the patch set: Patch 1: Move the existing implementation to shared space and adjust BSPs that use it as necessary. Patch 2: Add support for the now-shared clock driver

Re: [PATCH] score: Improve C/C++ standard compatibility

This looks ok. On Tue, Apr 9, 2024, 7:30 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > The processor mask implementation uses flsl() from which is > only BSD visible. Move the implementation to a separate header file to > hide it from the API level. This fixes build errors

Re: GCC 14: Some warnings are now errors

Is 14 the version for RTEMS 7 tools? If so, that makes it easier to address the issues. And Chris says we need 13 for RTEMS 6 because older doesn't compile on new Mac tools. So that needs action. On Tue, Apr 9, 2024, 8:29 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello,

GCC 14: Some warnings are now errors

Hello, I did some tests with GCC 14 and it turned out that this release turns a couple of warnings into errors: https://gcc.gnu.org/gcc-14/porting_to.html It will be a bit of work to get RTEMS compile clean for GCC 14. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4

[PATCH] validation: Fix powerpc in test case

The powerpc context switch restores the interrupt state. Update #4955. --- testsuites/validation/tc-score-isr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testsuites/validation/tc-score-isr.c b/testsuites/validation/tc-score-isr.c index 9891829a84..b178541e72 100644 ---

[PATCH] score: Improve C/C++ standard compatibility

The processor mask implementation uses flsl() from which is only BSD visible. Move the implementation to a separate header file to hide it from the API level. This fixes build errors with GCC 14. --- cpukit/include/rtems/score/processormask.h| 379 +--

[PATCH] bsps/arm: Improve GICv2 support

In addtion to 1023, the GICC_IAR register may return 1022 as a special value. Simply check for a valid interrupt vector for the dispatching. Check the GICC_IAR again after the dispatch to quickly process a next interrupt without having to go through the interrupt prologue and epiloge. ---

[PATCH] testsuites/unit: Add tests for compiler builtins

On the arm target, __udivmoddi4() cannot be fully tested through normal integer divisions. Update #3716. --- testsuites/unit/tc-compiler-builtins.c | 221 +++-- 1 file changed, 207 insertions(+), 14 deletions(-) diff --git a/testsuites/unit/tc-compiler-builtins.c

[PATCH] smptests/smpipi01: Fix sporadic test failure

Make sure that the last IPI is processed before the next test case is carried out. --- testsuites/smptests/smpipi01/init.c | 48 + 1 file changed, 42 insertions(+), 6 deletions(-) diff --git a/testsuites/smptests/smpipi01/init.c b/testsuites/smptests/smpipi01/init.c

[PATCH 1/2] dev/clock: add bcm2835-system-timer driver

This patch ports the bcm2835 system timer driver in the arm/raspberrypi directory to the shared directory. Made some changes in the include section to adapt to rpi4 BSP. --- bsps/shared/dev/clock/bcm2835-system-timer.c | 114 +++ 1 file changed, 114 insertions(+) create mode

[PATCH 2/2] bsps/aarch64/raspberrypi: Add system timer support

The clock from the ARM timer is derived from the system clock. This clock can change dynamically e.g. if the system goes into reduced power or in low power mode. Thus the clock speed adapts to the overall system performance capabilities. For accurate timing it is recommended to use the system

utf32 test

--- testsuites/samples/utf32/init.c | 43 +- 1 file changed, 43 insertions(+), 0 deletion(-) create mode 100644 testsuites/samples/utf32/init.c diff --git a/testsuites/samples/utf32/init.c b/testsuites/samples/utf32/init.c index 83f6342ab3..5ebcdc9ef2 100644 --- /dev/null +++

utf32 support

--- testsuites/samples/utf32/utf32.h | 45 +- 1 file changed, 45 insertions(+), 0 deletion(-) create mode 100644 testsuites/samples/utf32/utf32.h diff --git a/testsuites/samples/utf32/utf32.h b/testsuites/samples/utf32/utf32.h index 83f6342ab3..5ebcdc9ef2 100644 --- /dev/null +++

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - Embedded World

Hello everybody, Michal Lenc has updated the project to switch from RTEMS semaphores allocated with object ID to self-contained ones according to the previous response that self-contained objects are preferred. Se actual state in the repo https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd

[PATCH] rtems: Add get/set interrupt priorities

Add directives to get and set the priority of an interrupt vector. Update #5002. --- cpukit/include/rtems/rtems/intr.h | 154 +- 1 file changed, 153 insertions(+), 1 deletion(-) diff --git a/cpukit/include/rtems/rtems/intr.h b/cpukit/include/rtems/rtems/intr.h index

RE: [RFC] Adding RISC-V Vector support to RTEMS

Just a late note to say thanks for the direction Sebastien. What you suggest makes sense to me, requiring (and enforcing) that vector registers not be used within _RISCV_Interrupt_dispatch() while preserving the vector state across _Thread_Do_dispatch(). (ref:

Re: [PATCH v2 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

On 4/4/2024 8:19 pm, Sebastian Huber wrote: > On 28.03.24 16:48, Kinsey Moore wrote: >> This patch set looks good to me. I'd suggest a different file for the versal >> unless there's a good name that can easily cover both. > > The versal BSP doesn't use this driver and seems to have a

Re: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

Hi Purva, On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi wrote: > Hello, > > I am Purva Yeshi, I applied for the project "Add BSP for Polarfire based > Beagle" for GSoC 2024. I proposed a project to create a BSP for the > Beagle-V fire board from scratch. The primary objective of the project is >

Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

Hello, I am Purva Yeshi, I applied for the project "Add BSP for Polarfire based Beagle" for GSoC 2024. I proposed a project to create a BSP for the Beagle-V fire board from scratch. The primary objective of the project is to run a "Hello World" code and a ticker on the board. After that, I will

Re: [PATCH v2 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

On 28.03.24 16:48, Kinsey Moore wrote: This patch set looks good to me. I'd suggest a different file for the versal unless there's a good name that can easily cover both. The versal BSP doesn't use this driver and seems to have a different hardware UART interface. It uses a BSP-specific

Re: qemu-linaro and linaro-image-tools is olde

Hello Ashish, On 2024-04-03 05:07, ashish ashish wrote: Hello all, I am trying to emulate beagle black board and support for beagle board on qemu in past can be achieved by qemu-linaro but from last 10 years there is not activity on the community of qemu-linaro and it is use many depreciated

Re: [RSB PATCH v3] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

Looks good to me. Kinsey On Wed, Apr 3, 2024 at 6:28 PM wrote: > From: Chris Johns > > --- > source-builder/sb-rtems-pkg | 29 > source-builder/sb/download.py | 5 +- > source-builder/sb/git.py | 12 ++ > source-builder/sb/rtemspkg.py | 287 ++

[RSB PATCH v3] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

From: Chris Johns --- source-builder/sb-rtems-pkg | 29 source-builder/sb/download.py | 5 +- source-builder/sb/git.py | 12 ++ source-builder/sb/rtemspkg.py | 287 ++ 4 files changed, 332 insertions(+), 1 deletion(-) create mode 100755

v3 sb-rtems-pkg

Hi I notice after sending v2 I had not implemented the options. These are now done in v3. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH v2] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

From: Chris Johns --- source-builder/sb-rtems-pkg | 29 source-builder/sb/download.py | 5 +- source-builder/sb/git.py | 12 ++ source-builder/sb/rtemspkg.py | 290 ++ 4 files changed, 335 insertions(+), 1 deletion(-) create mode 100755

Re: [PATCH rtems-source-builder 1/2] glib: Update to 2.56.4

Looks good Chris On 6/3/2024 9:12 am, Kinsey Moore wrote: > This updates glib to 2.56.4 for AArch64 build support. > --- > bare/config/devel/glib-2.56.4-1.cfg| 30 ++ > bare/config/devel/qemu-couverture.bset | 2 +- > bare/config/devel/qemu-xilinx.bset | 2 +- >

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

On 4/4/2024 6:54 am, Kinsey Moore wrote: > On Wed, Apr 3, 2024 at 2:11 PM Chris Johns > wrote: > >> On 4 Apr 2024, at 3:52 am, Kinsey Moore > > wrote: >> Looks fine overall. Minor nits: >> "host" is set to "freebsd" and is

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

On Wed, Apr 3, 2024 at 2:11 PM Chris Johns wrote: > On 4 Apr 2024, at 3:52 am, Kinsey Moore wrote: > > Looks fine overall. Minor nits: > "host" is set to "freebsd" and is never used. > > > The tool uses simhost so it could be any host listed in that module and it > references that table.

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

> On 4 Apr 2024, at 3:52 am, Kinsey Moore wrote: > > Looks fine overall. Minor nits: > "host" is set to "freebsd" and is never used. The tool uses simhost so it could be any host listed in that module and it references that table. Nothing is built but needed to creat a build object. Simhost

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

Chris.. if you post a V2 addressing those, I will commit it. On Wed, Apr 3, 2024, 11:52 AM Kinsey Moore wrote: > Looks fine overall. Minor nits: > "host" is set to "freebsd" and is never used. > Numeric indexes for repo config details are nice for brevity, but not for > readability. > > Kinsey

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

Looks fine overall. Minor nits: "host" is set to "freebsd" and is never used. Numeric indexes for repo config details are nice for brevity, but not for readability. Kinsey On Wed, Apr 3, 2024 at 11:29 AM Joel Sherrill wrote: > This looks handy. I don't have an issue with it. > > On Tue, Apr 2,

Re: [PATCH rtems-source-builder 2/2] qemu-xilinx: Update to 2023.2

Ping On Tue, Mar 5, 2024 at 4:13 PM Kinsey Moore wrote: > The 2020.2 version of Xilinx's qemu branch does not build on AArch64 due > to a merge conflict that was integrated into the repository and never > corrected. This brings qemu-xilinx up to 2023.2 to resolve that issue > and allow it to

Re: [PATCH rtems-source-builder 1/2] glib: Update to 2.56.4

Ping On Tue, Mar 5, 2024 at 4:13 PM Kinsey Moore wrote: > This updates glib to 2.56.4 for AArch64 build support. > --- > bare/config/devel/glib-2.56.4-1.cfg| 30 ++ > bare/config/devel/qemu-couverture.bset | 2 +- > bare/config/devel/qemu-xilinx.bset | 2 +- >

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

This looks handy. I don't have an issue with it. On Tue, Apr 2, 2024 at 11:25 PM wrote: > From: Chris Johns > > --- > source-builder/sb-rtems-pkg | 29 > source-builder/sb/download.py | 5 +- > source-builder/sb/git.py | 12 ++ > source-builder/sb/rtemspkg.py | 279

Re: [RSB PATCH] rtems: Update RTEMS packages to their HEAD

Looks good. I will push. On Tue, Apr 2, 2024 at 11:23 PM wrote: > From: Chris Johns > > --- > rtems/config/tools/rtems-kernel-6.cfg | 4 ++-- > rtems/config/tools/rtems-libbsd-6.cfg | 4 ++-- > rtems/config/tools/rtems-tools-6.cfg | 6 +++--- > 3 files changed, 7 insertions(+), 7

[RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

From: Chris Johns --- source-builder/sb-rtems-pkg | 29 source-builder/sb/download.py | 5 +- source-builder/sb/git.py | 12 ++ source-builder/sb/rtemspkg.py | 279 ++ 4 files changed, 324 insertions(+), 1 deletion(-) create mode 100755

[RSB PATCH] rtems: Update RTEMS packages to their HEAD

From: Chris Johns --- rtems/config/tools/rtems-kernel-6.cfg | 4 ++-- rtems/config/tools/rtems-libbsd-6.cfg | 4 ++-- rtems/config/tools/rtems-tools-6.cfg | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/rtems/config/tools/rtems-kernel-6.cfg

qemu-linaro and linaro-image-tools is olde

Hello all, I am trying to emulate beagle black board and support for beagle board on qemu in past can be achieved by qemu-linaro but from last 10 years there is not activity on the community of qemu-linaro and it is use many depreciated packages and hard to got it work anyone tried it or using it.

Re: [Bugfix rtems-lwip 1/4] Fix definition of portTICK_RATE_MS

On 1/4/2024 9:49 am, Bernd Moessner wrote: > The FreeRTOS define portTICK_RATE_MS must represent the time in ms > between two system ticks. > --- > rtemslwip/xilinx/xlwipopts.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/rtemslwip/xilinx/xlwipopts.h

Re: Finished Hello World Example

This patch looks ok. We also need a screenshot of it running. I hope you made the deadline of applying via the Google site. We track proposals at https://devel.rtems.org/wiki/GSoC/2024 On Tue, Apr 2, 2024 at 2:47 PM SEAN TANG wrote: > > ___ > devel

Finished Hello World Example

From a580cedc186d11ab6fc8ca4329404bf8e6e64dd3 Mon Sep 17 00:00:00 2001 From: Sean Tang Date: Tue, 2 Apr 2024 02:13:32 -0700 Subject: [PATCH] Finished Hello World Example --- testsuites/samples/hello/init.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

Re: Clarification Regarding Initial Project Scope for "Add BSP for Polarfire based Beagle"

On Tue, Apr 2, 2024, 9:28 AM Purva Yeshi wrote: > Hello, > > I'm reaching out to seek clarification regarding the initial scope of the > "Add BSP for Polarfire based Beagle" project that I've applied for. > > As outlined in the project description, the primary aim is to create a BSP > for the

Clarification Regarding Initial Project Scope for "Add BSP for Polarfire based Beagle"

Hello, I'm reaching out to seek clarification regarding the initial scope of the "Add BSP for Polarfire based Beagle" project that I've applied for. As outlined in the project description, the primary aim is to create a BSP for the Beagle-V Fire board. Therefore, one part of the project involves

Re: [Bugfix rtems-lwip 4/4] Fix crash due to link_detect_thread

I'd have to see what you're describing. If you'd like, I can reformulate the patch as well. Kinsey On Tue, Apr 2, 2024 at 2:51 AM Bernd Moessner wrote: > Is it ok to implement it using a single ifdef __rtems__ else ? The driver > is already a ifdef - hell and it will become even less readable

Please Review GSOC proposal after recommended changes

I have made recommended changes in my proposal proposal ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

revised proposal for posix conformance project, GSoC

Updated my proposal according to comments. Any comments welcome! https://docs.google.com/document/d/1iwgzx72TZ0aokNLww-y-IlyEkaRCovjGUhpdQXdP9mg/edit?pli=1 -- *"Free society* *Has, at its core, privacy* *You must act in trust." - *Salyzyn ___ devel

Request for Review: Updated Proposal of the project "Add BSP for Polarfire based Beagle"

Hello, I am Purva Yeshi, and I am reaching out to follow up on the proposal that I previously shared with you. After receiving valuable suggestions from members of this community, I have made significant changes to the proposal to address the feedback received. I am now reaching out to kindly

Re: [Bugfix rtems-lwip 4/4] Fix crash due to link_detect_thread

Is it ok to implement it using a single ifdef __rtems__ else ? The driver is already a ifdef - hell and it will become even less readable when I add even more of them. Kinsey Moore schrieb am Mo., 1. Apr. 2024, 16:39: > The intent of this patch is fine, but changes should be purely additive >

Re: [Bugfix rtems-lwip 3/4] Correct the task prio of link_detect_thread

Running SMP on zynq7000 - my theory was that u might use QEMU. Kinsey Moore schrieb am Mo., 1. Apr. 2024, 16:35: > You might be seeing different behavior than I have if you're running > single-core. Almost all my lwIP usage has been on 4 cores on the ZynqMP. > > Kinsey > > On Sun, Mar 31, 2024

[PATCH v2 1/1] x86_64: Fix stack aligment for x86-64 SysV ABI

Makes the code in bsp/x86_64/amd64/start/start.S and the stack frame setup by _CPU_Context_Initialize align the stack properly according to what is expected by the x86-64 SysV ABI Updates #2898 Closes #5004 --- bsps/x86_64/amd64/clock/eficlock.c| 28 ++-

Re: [Bugfix rtems-lwip 4/4] Fix crash due to link_detect_thread

The intent of this patch is fine, but changes should be purely additive and properly wrapped in the __rtems__ check. The addition of thread startup at the end should also be wrapped in !NO_SYS. Kinsey On Sun, Mar 31, 2024 at 5:49 PM Bernd Moessner wrote: > Within xemac_add, the

Re: [Bugfix rtems-lwip 3/4] Correct the task prio of link_detect_thread

You might be seeing different behavior than I have if you're running single-core. Almost all my lwIP usage has been on 4 cores on the ZynqMP. Kinsey On Sun, Mar 31, 2024 at 5:49 PM Bernd Moessner wrote: > On my side, the link_detect_thread never gets to running state. > I assume that the

Proposal Review Request for "Add BSP for Polarfire-based Beagle" GSOC 2024 Project

Hello, I am Purva Yeshi, a pre-final year Electronics and Telecommunication undergraduate from VJTI, Mumbai. I am very interested in the project "Add BSP for Polarfire-based Beagle" for GSOC 2024. I have successfully completed the Hello World task and also built the same Hello World code using the

Proposal Review Request for "Add BSP for Polarfire-based Beagle" GSOC 2024 Project

Hello, I am Purva Yeshi, a pre-final year Electronics and Telecommunication undergraduate from VJTI, Mumbai. I am very interested in the project "Add BSP for Polarfire-based Beagle" for GSOC 2024. I have successfully completed the Hello World task and also built the same Hello World code using the

[Bugfix rtems-lwip 4/4] Fix crash due to link_detect_thread

Within xemac_add, the link_detect_thread is set up before the ethernet interface is configured and all data structures have been set up correctly. The steps within xemac_add are basically: 1) Set up link_detect_thread 2) Initialize the interface 3) Set up the link speed / start autonegotiation 4)

[Bugfix rtems-lwip 3/4] Correct the task prio of link_detect_thread

On my side, the link_detect_thread never gets to running state. I assume that the issues with the FreeRTOS tick rate and delay definitions have never been observed as the associated thread was never running / no one requied it to run. Previously, the link_detect_thread was set to

[Bugfix rtems-lwip 2/4] Fix definition of vTaskDelay(x)

FreeRTOS's vTaskDelay(x) is the FreeRTOS equivalent to rtems_task_wake_after(x), it suspends a task for x Ticks. The previously used sys_arch_delay(x) would add x/10 before passing it to rtems_task_wake_after. Due to the fact that portTICK_RATE_MS was set to wrong value the previous impl always

[Bugfix rtems-lwip 1/4] Fix definition of portTICK_RATE_MS

The FreeRTOS define portTICK_RATE_MS must represent the time in ms between two system ticks. --- rtemslwip/xilinx/xlwipopts.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtemslwip/xilinx/xlwipopts.h b/rtemslwip/xilinx/xlwipopts.h index d915c3c..23b942f 100644 ---

[Bugfix rtems-lwip 0/4] XILINX Link detect issues

I had to recognize that cable plug / unplug events are not detected. This is due to the fact that the link detect thread is created, but never gets to running state due to a too high priority (255, but it seems it should be 254). In addition to that, there are some FreeRTOS defines that have not

Re: Project Proposal feedback

I am Suraj Kumar, currently interested in the project "Add Python initializer for gdb RTEMS specific support" Here is my proposal - https://docs.google.com/document/d/1VeS-QCJv5HUE4pUU8jJ-OqpYSvnffpZclXF7KbKGqAw/edit?usp=sharing I would greatly appreciate if you could review it and leave feedback

propsal for gsoc

hello i have written my proposal and needs your valuable suggestion and feedbacks propsal ___ devel mailing list devel@rtems.org

Re: GSOC proposal - new POSIX APIs 2024

Hi! Requesting comments on my proposal for GSOC 2024 - implementing new POSIX APIs: https://docs.google.com/document/d/1iwgzx72TZ0aokNLww-y-IlyEkaRCovjGUhpdQXdP9mg/edit?usp=sharing Abhinav. -- *"Free society* *Has, at its core, privacy* *You must act in trust." - *Salyzyn

Re: PowerPC e7400 executable is type powerpc:e500 making debug difficult

> On Mar 30, 2024, at 2:15 PM, Joel Sherrill wrote: > > It also leads to dead/unused code in any deployment whose BSP uses this file > I don't know the full definition of code coverage. I suppose code that can never be exercised on a given platform is "dead code"? Even if the code as a

Re: PowerPC e7400 executable is type powerpc:e500 making debug difficult

On Sat, Mar 30, 2024, 12:18 PM Peter Dufault wrote: > It's the source code lines that I quoted that cause the problem. > > To avoid getting the object defined as an e500 then that file needs to be > conditionally compiled (I think that's the way it is, there should be > another way, having a

Re: PowerPC e7400 executable is type powerpc:e500 making debug difficult

It's the source code lines that I quoted that cause the problem. To avoid getting the object defined as an e500 then that file needs to be conditionally compiled (I think that's the way it is, there should be another way, having a binary that adapts to its target isn't *that* evil.). Including

Re: approve google docs editing request

You do not edit the master proposal template. You make a copy of it and turn it into your proposal. --joel On Sat, Mar 30, 2024 at 12:29 AM ashish ashish wrote: > I requested on google docs for editing to write my proposal. and it needs > approval. > please approve it. > request with email:

approve google docs editing request

I requested on google docs for editing to write my proposal. and it needs approval. please approve it. request with email: ashishashish7...@gmail.com thanks. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: PowerPC e7400 executable is type powerpc:e500 making debug difficult

Hi Chris and I discussed this for a few minutes last night and wondered if code like this which includes arbitrary CPU model specific code could be the culprit? https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65 There may be other sections that do this. If

RTEMS Trac Ticket to GitLab import

Hi RTEMS Community GitLab transition is progressing better than we expected and we are now at a point where we want to move the tickets in Trac to GitLab. A lot of preparation has been done in planning the move and an outcome we had not planned is the time it will take is much more. The original

Seeking review for GSoC Proposal "Add RTEMS Framework to PlatformIO"

Please have a look at my project proposal for GSoC and suggest changes. Google Docs Link: https://docs.google.com/document/d/1uyC1Eai73RET6lcWMkSe01FvcXWhceSD9_q4v8eYCCI/edit pdf for proposal attached below. GSOC2024_GUPTA_Add RTEMS Framework to PlatformIO (1).pdf Description: Adobe PDF

Re: [PATCH v2 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

This patch set looks good to me. I'd suggest a different file for the versal unless there's a good name that can easily cover both. Kinsey On Wed, Mar 27, 2024 at 9:26 PM Chris Johns wrote: > On 28/3/2024 6:43 am, Sebastian Huber wrote: > > This helps to provide a shared implementation of the

Re: Xilinx header files installed by BSP

On 27/3/2024 7:14 am, Kinsey Moore wrote: > On Mon, Mar 25, 2024 at 3:34 PM Bernd Moessner > wrote: > > > On 25.03.2024 13:26, Sebastian Huber wrote: > > Hello, > > > > the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from > >

Re: [PATCH v2 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

On 28/3/2024 6:43 am, Sebastian Huber wrote: > This helps to provide a shared implementation of the kernel I/O support. > --- > bsps/aarch64/xilinx-zynqmp/console/console.c | 4 +- > bsps/aarch64/xilinx-zynqmp/include/bsp.h | 2 + > bsps/arm/xilinx-zynq/console/console-config.c | 5 +- >

[PATCH] Added screenshot of output

--- hello.c | 2 +- output_screenshot.png | Bin 0 -> 111964 bytes 2 files changed, 1 insertion(+), 1 deletion(-) create mode 100755 output_screenshot.png diff --git a/hello.c b/hello.c index 72d1dd4..1d6fa3e 100644 --- a/hello.c +++ b/hello.c @@ -9,6 +9,6 @@ rtems_task Init(

GSOC x86_64 BSP Proposal

Hey, Here is the first draft of my proposal, I appreciate the feedback. https://docs.google.com/document/d/1Q9F-BwuLKz66-83UBcraiPQzoZ_hEbMoWDNWGvbJM4o/edit?usp=sharing ___ devel mailing list devel@rtems.org

[PATCH v2 3/3] dev/serial: Add Zynq UART kernel I/O support

Replace the BSP_CONSOLE_MINOR BSP option for the Xilinx Zynq BSPs with the new BSP option ZYNQ_UART_KERNEL_IO_BASE_ADDR. Move the kernel I/O support to a shared file. --- bsps/aarch64/xilinx-zynqmp/console/console.c | 41 ++ bsps/arm/xilinx-zynq/console/console-config.c | 50

[PATCH v2 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

This helps to provide a shared implementation of the kernel I/O support. --- bsps/aarch64/xilinx-zynqmp/console/console.c | 4 +- bsps/aarch64/xilinx-zynqmp/include/bsp.h | 2 + bsps/arm/xilinx-zynq/console/console-config.c | 5 +- bsps/arm/xilinx-zynq/include/bsp.h| 1 +

[PATCH v2 1/3] dev/serial: Simplify some Zynq UART functions

Make the initialization and polled functions independent of the Termios context. This helps to implement the kernel I/O support without a dependency on the Termios framework. --- bsps/aarch64/xilinx-zynqmp/console/console.c | 23 --- bsps/arm/xilinx-zynq/console/debug-console.c |

<    1   2   3   4   5   6   7   8   9   10   >