Re: Script to Update Hashes for RTEMS 7 Tools

Hello Joel, I update it through a script, however, after an update usually something is broken and you have to write a bug report or a patch. I was busy with other things recently. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastia

Re: Open Meetup on Discord

Hey everyone, We're doing this again in a few hours at 22:00 UTC for anyone that would like to join in. We made plenty of progress closing out issues and identifying what remains for the 6.1 release last week and we should be there for another hour or so today. Thanks, Kinsey On Thu, Oct 24, 2024

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

Hello Kinsey, thanks for the answer. I am now using the REPHY driver and everything is working fine: diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h index ac4a52a1..6908ca46 100644 --- a/rtemsbsd/include/bsp/nexus-devices.h +++ b/rtemsbsd/include/bsp/nexu

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

Even if that one isn't already used, the generic PHY driver (UKPHY) will work most of the time as long as it's enabled (it isn't by default for the Zynq BSPs). I haven't done much with the Zynq boards, so I won't be of much help. The link you posted mentioned a board frequency change. Have you veri

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

I have a Rev.D board and it has a different Realtek PHY with different connections to MIO Bank. RTL8211F instead of RTL8211E I have to find out where this is defined/used in the rtems-libbsd. Heinz > On 13. Aug 2024, at 17:16, Heinz Junkes wrote: > > This is the output of NFS01 Test: > > *** BE

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

This is the output of NFS01 Test: *** BEGIN OF TEST LIBBSD NFS 1 *** *** TEST VERSION: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e *** TEST STATE: USER_INPUT *** TEST BUILD: RTEMS_POSIX_API *** TEST TOOLS: 13.3.0 20240521 (RTEMS 6, RSB 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)

Re: Updating GitHub Mirrors?

- Am 4. Jul 2024 um 20:18 schrieb o...@c-mauderer.de: > Hello Joel and Sebastian, > > Am 04.07.24 um 19:38 schrieb Sebastian Huber: >> - Am 4. Jul 2024 um 19:30 schrieb Joel Sherrill j...@rtems.org: >> >>> Thanks. What times? >> >> About 7 minutes past 4, 12, and 20 CEST. >> > > I'm

Re: Updating GitHub Mirrors?

Hello Joel and Sebastian, Am 04.07.24 um 19:38 schrieb Sebastian Huber: - Am 4. Jul 2024 um 19:30 schrieb Joel Sherrill j...@rtems.org: Thanks. What times? About 7 minutes past 4, 12, and 20 CEST. I'm not entirely sure how the mirroring is currently set upm, but it sounds like a cron

Re: Updating GitHub Mirrors?

- Am 4. Jul 2024 um 19:30 schrieb Joel Sherrill j...@rtems.org: > Thanks. What times? About 7 minutes past 4, 12, and 20 CEST. -- 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 fa

Re: Updating GitHub Mirrors?

Thanks. What times? On Thu, Jul 4, 2024, 12:12 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > - Am 4. Jul 2024 um 18:12 schrieb Joel Sherrill j...@rtems.org: > > > On Thu, Jul 4, 2024, 1:06 AM Sebastian Huber < > > sebastian.hu...@embedded-brains.de> wrote: > > > >> - A

Re: Updating GitHub Mirrors?

- Am 4. Jul 2024 um 18:12 schrieb Joel Sherrill j...@rtems.org: > On Thu, Jul 4, 2024, 1:06 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> - Am 3. Jul 2024 um 19:29 schrieb Joel Sherrill j...@rtems.org: >> >> > Hi >> > >> > When/how do the mirrors of gcc, binutlls,

Re: Updating GitHub Mirrors?

On Thu, Jul 4, 2024, 1:06 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > - Am 3. Jul 2024 um 19:29 schrieb Joel Sherrill j...@rtems.org: > > > Hi > > > > When/how do the mirrors of gcc, binutlls, newlib, etc get updated? > > They are updated once a day. > At what time? And

Re: Updating GitHub Mirrors?

- Am 3. Jul 2024 um 19:29 schrieb Joel Sherrill j...@rtems.org: > Hi > > When/how do the mirrors of gcc, binutlls, newlib, etc get updated? They are updated once a day. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedde

Re: removing unused third-party headers (objbsd)?

On 29.06.24 02:30, Gedare Bloom wrote: On Fri, Jun 28, 2024 at 10:41 AM Gedare Bloom wrote: On Thu, Jun 27, 2024 at 11:39 PM Sebastian Huber wrote: On 28.06.24 00:42, Gedare Bloom wrote: I've been doing back through my third-party source code attribution. I've found that there is a chunk o

Re: removing unused third-party headers (objbsd)?

On Fri, Jun 28, 2024 at 7:30 PM Gedare Bloom wrote: > On Fri, Jun 28, 2024 at 10:41 AM Gedare Bloom wrote: > > > > On Thu, Jun 27, 2024 at 11:39 PM Sebastian Huber > > wrote: > > > > > > On 28.06.24 00:42, Gedare Bloom wrote: > > > > I've been doing back through my third-party source code attri

Re: removing unused third-party headers (objbsd)?

On Fri, Jun 28, 2024 at 10:41 AM Gedare Bloom wrote: > > On Thu, Jun 27, 2024 at 11:39 PM Sebastian Huber > wrote: > > > > On 28.06.24 00:42, Gedare Bloom wrote: > > > I've been doing back through my third-party source code attribution. > > > I've found that there is a chunk of header files that

Re: removing unused third-party headers (objbsd)?

On Thu, Jun 27, 2024 at 11:39 PM Sebastian Huber wrote: > > On 28.06.24 00:42, Gedare Bloom wrote: > > I've been doing back through my third-party source code attribution. > > I've found that there is a chunk of header files that are apparently > > not included anywhere in rtems, and that are thir

Re: removing unused third-party headers (objbsd)?

On 28.06.24 00:42, Gedare Bloom wrote: I've been doing back through my third-party source code attribution. I've found that there is a chunk of header files that are apparently not included anywhere in rtems, and that are third-party headers. Is there any reason we can't get rid of them? These

Re: Ada

> gcc -v You might try forcing arm mode without supporting thumb modes. If I remember right, official Arm document obsoleted Thumb1, which would explain the “sorry” message. gcc.pdf (.html) helps. Also, there is a separate mailing list for the GCC linker problems. Experts might better assist

Re: Ada

Thanks. I will do that. -- John (Sorry for all my top-posting. I try to use an iPhone. ‘nuff said.) On Jun 23, 2024, at 8:01 PM, Joel Sherrill wrote: > On Sun, Jun 23, 2024, 12:43 PM John Howard wrote: > > Johns recently identified and fixed that problem.) Building gnat is a bit tricky. Yo

Re: Ada

Hello John, I have some issues on arm and Ada with current versions of GCC, see also: https://gcc.gnu.org/pipermail/gcc/2024-June/244197.html -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94

Re: Ada

On Sun, Jun 23, 2024, 12:43 PM John Howard wrote: > Hello. > > I need Ada for RTEMS on Raspberry Pi. I will settle for whichever versions > work together. > > After moving to gitlab, is Ada continuously built and tested for RTEMS? > > Today, my non-gitlab RSB 5.3 build failed on Debian with error

Re: generic CAN/CAN FD susbsytem for RTEMS - status, review and mainlining

Hello Emanuel, On Sunday 23 of June 2024 17:15:13 emanuel stiebler wrote: > On 2024-06-21 06:27, Pavel Pisa wrote: > > I want to inform you about the progress of the project. > > > > The CTU local project project links can be found in the > > section CAN/CAN FD Subsystem and Drivers for RTEMS on o

Re: generic CAN/CAN FD susbsytem for RTEMS - status, review and mainlining

On 2024-06-21 06:27, Pavel Pisa wrote: Hello everybody, I want to inform you about the progress of the project. The CTU local project project links can be found in the section CAN/CAN FD Subsystem and Drivers for RTEMS on our page https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-dr

Re: What to do with rtems_cache_disable_data()?

On 14.06.24 11:47, Sebastian Huber wrote: Hello, an user noticed that for example on the Xilinx Zynq 7000 BSP, the rtems_cache_disable_data() doesn't work. I had a look at this and managed to disable the L1 and L2 caches, however, afterwards I got not that far. On the Cortex-A cores it seems

Re: RFC: Deprecate Old/Unused BSPs

Hello Joel and others, On Thursday 30 of May 2024 17:04:08 Joel Sherrill wrote: > + ARM candidates include at least csb336, csb337 and variants. gumstix. > edb7312, and smdk2410 I have still some boards usable with csb336 port there from our CPU core development for medical infusion system which

Re: What to do with rtems_cache_disable_data()?

On 18.06.24 17:32, Gedare Bloom wrote: On Mon, Jun 17, 2024 at 11:20 PM Chris Johns wrote: On 18/6/2024 12:02 am, Sebastian Huber wrote: On 17.06.24 03:35, Chris Johns wrote: On 14/6/2024 10:42 pm, Peter Dufault wrote: On Jun 14, 2024, at 5:47 AM, Sebastian Huber wrote: Hello, an user

Re: What to do with rtems_cache_disable_data()?

On Mon, Jun 17, 2024 at 11:20 PM Chris Johns wrote: > > On 18/6/2024 12:02 am, Sebastian Huber wrote: > > On 17.06.24 03:35, Chris Johns wrote: > >> On 14/6/2024 10:42 pm, Peter Dufault wrote: > >>> > >>> > On Jun 14, 2024, at 5:47 AM, Sebastian Huber > wrote: > > Hello, > >>>

Re: What to do with rtems_cache_disable_data()?

On 18/6/2024 12:02 am, Sebastian Huber wrote: > On 17.06.24 03:35, Chris Johns wrote: >> On 14/6/2024 10:42 pm, Peter Dufault wrote: >>> >>> On Jun 14, 2024, at 5:47 AM, Sebastian Huber wrote: Hello, an user noticed that for example on the Xilinx Zynq 7000 BSP, the >>

Re: What to do with rtems_cache_disable_data()?

On 17.06.24 03:35, Chris Johns wrote: On 14/6/2024 10:42 pm, Peter Dufault wrote: On Jun 14, 2024, at 5:47 AM, Sebastian Huber wrote: Hello, an user noticed that for example on the Xilinx Zynq 7000 BSP, the rtems_cache_disable_data() doesn't work. I had a look at this and managed to dis

Re: What to do with rtems_cache_disable_data()?

On 14/6/2024 10:42 pm, Peter Dufault wrote: > > >> On Jun 14, 2024, at 5:47 AM, Sebastian Huber >> wrote: >> >> Hello, >> >> an user noticed that for example on the Xilinx Zynq 7000 BSP, the >> rtems_cache_disable_data() doesn't work. >> >> I had a look at this and managed to disable the L1 an

Re: What to do with rtems_cache_disable_data()?

> On Jun 14, 2024, at 5:47 AM, Sebastian Huber > wrote: > > Hello, > > an user noticed that for example on the Xilinx Zynq 7000 BSP, the > rtems_cache_disable_data() doesn't work. > > I had a look at this and managed to disable the L1 and L2 caches, however, > afterwards I got not that far

Re: GCC 14: m68k, sh, and sparc64

I reported this to newlib@ and someone posted a patch which is now merged and mirrored to the RTEMS github. I am updating the RSB to the new newlib hash and hopefully will push the MR tomorrow for review. --joel On Mon, Apr 29, 2024 at 1:42 PM Joel Sherrill wrote: > > > On Sun, Apr 28, 2024 at

Re: RTEMS Doxygen Broken

On 04.06.24 21:36, Joel Sherrill wrote: Hi The subject says it all. Doesn't look like the POSIX APIs are even included, CMSIS Definitions is listed 27 times with at least some not linking to content, etc. There are other headings which appear repeatedly. I am basically ignoring the warning me

Re: RFC: Deprecate Old/Unused BSPs

On Fri, May 31, 2024 at 2:57 AM wrote: > Hello Joel, > > Am 30.05.24 um 17:04 schrieb Joel Sherrill: > > Hi > > > > In reviewing ports for deprecation, I noticed that a few architectures > > have some very old BSPs which are unlikely to be used anymore. Dropping > > architectures and BSPs is bene

Re: RFC: Deprecate Old/Unused BSPs

Hello Joel, Am 30.05.24 um 17:04 schrieb Joel Sherrill: Hi In reviewing ports for deprecation, I noticed that a few architectures have some very old BSPs which are unlikely to be used anymore. Dropping architectures and BSPs is beneficial for a few reasons: + Architecture removal cuts down

Re: Upgrading tools - gcc, binutils, and gdb

Thanks. I just started a build updating gcc, binutils, and gdb. On Thu, May 30, 2024 at 1:35 AM Daniel Hellström wrote: > Sounds good. From Gaisler we will have long term support for the > GCC-13/GDB-14 toolchain on SPARC/LEON, and we recently released support for > GDB-14 in GRMON-3.3.11 for t

Re: Upgrading tools - gcc, binutils, and gdb

Sounds good. From Gaisler we will have long term support for the GCC-13/GDB-14 toolchain on SPARC/LEON, and we recently released support for GDB-14 in GRMON-3.3.11 for the same toolchain. It is currently available in Linux and Baremetal toolchains since April/May. From a maintainence perspectiv

Re: Upgrading tools - gcc, binutils, and gdb

Thanks. It may be a couple of days before I have a merge request ready. Thanks. On Wed, May 29, 2024, 6:28 PM Chris Johns wrote: > On 30/5/2024 7:22 am, Joel Sherrill wrote: > > I am in the middle of updating gcc to the recent 13.3 release to move us > off a > > git hash. > > > > Is there any r

Re: Upgrading tools - gcc, binutils, and gdb

On 30/5/2024 7:22 am, Joel Sherrill wrote: > I am in the middle of updating gcc to the recent 13.3 release to move us off a > git hash. > > Is there any reason we are still on gdb 13? gdb 14.1 was released in Dec > 2023.  No reason. The change to 13 required python 3 but that has now been absorb

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello, I have created the draft merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49 so we can move the review process there. Best regards, Michal On 23. 05. 24 7:17, Christian MAUDERER wrote: Hello Michal, On 2024-05-22 19:49, Michal Lenc wrote: Hello, thank you

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello, Code review without patches or a review system is always a bit more effort because there is nothing to add comments directly. It seems that I can't register on the gitlab instance that you provided. So let's try it here. I already have an account on RTEMS gitlab so I can make my RTEMS

Re: [PATCH 0/5] Update GRLIB L2C driver for technical note TN-0021

Hello Martin, I suggest to remove the grlib/l2c cache support and make sure that everything is available through the RTEMS Cache Manager. On 16.01.24 16:48, Sebastian Huber wrote: Hello Martin, we have also the Cache Manager support in bsps/sparc/leon3/start/cache.c. At least the lock shoul

Re: ZynqMP APU RAM Start

On Tue, May 14, 2024 at 10:39 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 14.05.24 17:11, Kinsey Moore wrote: > > On Tue, May 14, 2024 at 1:28 AM Chris Johns > > wrote: > > > > On 14/5/2024 4:04 pm, Sebastian Huber wrote: > > > Hello, > >

Re: ZynqMP APU RAM Start

On 14.05.24 17:11, Kinsey Moore wrote: On Tue, May 14, 2024 at 1:28 AM Chris Johns > wrote: On 14/5/2024 4:04 pm, Sebastian Huber wrote: > Hello, > > the ZynqMP APU RAM start addresses are far away from 0x0: > > cat spec/build/bsps/aarch64/xi

Re: ZynqMP APU RAM Start

On Tue, May 14, 2024 at 1:28 AM Chris Johns wrote: > On 14/5/2024 4:04 pm, Sebastian Huber wrote: > > Hello, > > > > the ZynqMP APU RAM start addresses are far away from 0x0: > > > > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml > > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello Christian, thank you for the thorough review. I am currently at the international CAN Conference at Baden-Baden, so I will address this once I return by the end of the week. Best regards, Michal Lenc On 14. 05. 24 10:10, Christian MAUDERER wrote: > On 2024-05-13 17:40, Christian MAUDERER

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

On 2024-05-13 17:40, Christian MAUDERER wrote: Hello Pavel and Michal, sorry for the late reply. I was on vacation last week. On 2024-05-06 11:27, Pavel Pisa wrote: Dear Christian, On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote: For others, code under review hosted in CTU univ

Re: ZynqMP APU RAM Start

On 14/5/2024 4:04 pm, Sebastian Huber wrote: > Hello, > > the ZynqMP APU RAM start addresses are far away from 0x0: > > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > actions: > - get-integer: null > - assert-uint32: null > - env-

Re: 6.1 release on Aug 26, 2024?

On 11/5/2024 9:40 pm, Cedric Berger wrote: > Hello, > > On gitlab, issues tagged "6.1" show a release date of Aug 26, 2024 for this > milestone, is it the current plan? > > If not, before or after? > > Any plan to merge GCC 13.3 or 14.1 before the release? > > Just curious, and trying to do som

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello Pavel and Michal, sorry for the late reply. I was on vacation last week. On 2024-05-06 11:27, Pavel Pisa wrote: Dear Christian, On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote: For others, code under review hosted in CTU university GitLab server https://gitlab.fel.cvut

Re: Improvements to SMP under the arch64 architecture

在 2024/5/8 22:36, Sebastian Huber 写道: On 08.05.24 08:17, Sebastian Huber wrote: Hello, on the arm target, we use this: static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control( void ) {    struct Per_CPU_Control *cpu_self;    /* Use PL1 only Thread ID Register (TPIDRPRW) */

Re: Improvements to SMP under the arch64 architecture

On Wed, May 8, 2024 at 9:36 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 08.05.24 08:17, Sebastian Huber wrote: > > Hello, > > > > on the arm target, we use this: > > > > static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control( > > void ) > > { > >struct

Re: Improvements to SMP under the arch64 architecture

On 08.05.24 08:17, Sebastian Huber wrote: Hello, on the arm target, we use this: static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control( void ) {   struct Per_CPU_Control *cpu_self;   /* Use PL1 only Thread ID Register (TPIDRPRW) */   __asm__ volatile (     "mrc p15, 0, %

Re: Improvements to SMP under the arch64 architecture

Hello, on the arm target, we use this: static inline struct Per_CPU_Control *_ARM_Get_current_per_CPU_control( void ) { struct Per_CPU_Control *cpu_self; /* Use PL1 only Thread ID Register (TPIDRPRW) */ __asm__ volatile ( "mrc p15, 0, %0, c13, c0, 4" : "=r" ( cpu_self ) );

Re: [PATCH 1/2] hw/intc/arm_gic: Fix set pending of PPIs

Sorry, this did go to the wrong mailing list. On 07.05.24 14:56, Sebastian Huber wrote: According to the GICv2 specification section 4.3.7, "Interrupt Set-Pending Registers, GICD_ISPENDRn": "In a multiprocessor implementation, GICD_ISPENDR0 is banked for each connected processor. This register

Re: [PATCH] Fix the CPU count calculation error.

在 2024/4/19 16:50, Sebastian Huber 写道: On 19.04.24 09:16, zhengxiaojun wrote: I tested on arm64, the cpu_count do not increase when (redist->icrtyper & GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last core. The current code assumes that you have exactly one interrupt export

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Dear Christian, On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote: > > For others, code under review hosted in CTU university GitLab > > server > >https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd > > Documentation > > > > https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/d

Re: RTEMS Deployment

On Fri, May 3, 2024, 7:52 AM Joel Sherrill wrote: > > > On Thu, May 2, 2024 at 11:48 PM Chris Johns wrote: > >> Hi, >> >> This email ask for the rtems-deployment repo to be moved RTEMS/Tools in >> GitLab. >> >> It is a repo of RSB configs to build packages of common or user specific >> vertical

Re: RTEMS Deployment

On Thu, May 2, 2024 at 11:48 PM Chris Johns wrote: > Hi, > > This email ask for the rtems-deployment repo to be moved RTEMS/Tools in > GitLab. > > It is a repo of RSB configs to build packages of common or user specific > vertical stacks. > I am in favor of it moving. --joel > > Thanks > Chris

Re: Cortex-M floating point (Was: RTEMS 6 branching)

On 2/5/2024 7:18 am, Cedric Berger wrote: > Hello, > > On 25.04.2024 02:16, Chris Johns wrote: >> I know I am getting ahead of myself but once we have GiLab running and you >> have >> a patch you would like merged please make a merge request. > > Done: > > https://gitlab.rtems.org/rtems/rtos/rt

Re: [PATCH rtems-tools v5] tester/rtemstoolkit: add renode implementation

gitlab.rtems.org is now alive. Please setup an account and follow the instructions for a merge request. We need to see how well things are working. :) --joel On Sun, Apr 28, 2024 at 11:35 PM Muhammad Sulthan Mazaya < msulthanmaz...@gmail.com> wrote: > Bumping last update of last year's renode

Re: Cortex-M floating point (Was: RTEMS 6 branching)

Hello, On 25.04.2024 02:16, Chris Johns wrote: I know I am getting ahead of myself but once we have GiLab running and you have a patch you would like merged please make a merge request. Done: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/10 It worked really well. Cedric __

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hi, > OK. Maybe then it would be good to make some notes in which cases it's > OK to add another flag to avoid that someone adds a lot of hardware > dependent flags here. Yes, we will add the description. Thanks. > I assume if something is really very special to a specific hardware, > the driver

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello Michal, On 2024-04-29 22:48, Michal Lenc wrote: Hello Christian, thank you a lot for the review. Thank you for your work. In addition to Pavel Píša's reply, I have updated the documentation to provide (hopefully) a better description. https://otrees.pages.fel.cvut.cz/rtems/rtems-can

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello Pavel, thanks for your explanations. On 2024-04-29 21:23, Pavel Pisa wrote: Dear Christian, thanks a lot for finding time to read through documentation. On Monday 29 of April 2024 10:56:29 Christian MAUDERER wrote: it's quite a big work. So I've started to read through the documentatio

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello Christian, thank you a lot for the review. In addition to Pavel Píša's reply, I have updated the documentation to provide (hopefully) a better description. https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html I plan to enhance it further, I write it in parallel w

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Dear Christian, thanks a lot for finding time to read through documentation. On Monday 29 of April 2024 10:56:29 Christian MAUDERER wrote: > it's quite a big work. So I've started to read through the > documentation to get an overview. For others, code under review hosted in CTU university GitLa

Re: GCC 14: m68k, sh, and sparc64

On Sun, Apr 28, 2024 at 3:18 PM Joel Sherrill wrote: > > > On Sun, Apr 28, 2024 at 6:17 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello, >> >> the m68k, sh, and sparc64 build fails with GCC 14 due to: >> > > Two of those are scheduled to be removed after we branch 6.

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Hello Pavel, it's quite a big work. So I've started to read through the documentation to get an overview. Some questions: Do I understand that correctly, that the only user-facing interface is via the "/dev/can*" files. There is no separate interface for special operations, right? That's complet

Re: GCC 14: m68k, sh, and sparc64

On Sun, Apr 28, 2024 at 6:17 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > the m68k, sh, and sparc64 build fails with GCC 14 due to: > Two of those are scheduled to be removed after we branch 6. So only the m68k really matters. More below. > > make "CC_FOR_BUILD=g

Re: GCC 14: nios2

On Sun, Apr 28, 2024 at 6:13 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > in order to build the nios2 GCC 14, you have to add --enable-obsolete to > the configure command line. With this option, it builds fine. I am not > sure how this option can be added to the RSB

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

Dear RTEMS and CAN community, I want to report another update in Michal Lenc work on the generic CAN/CAN FD RTEMS stack. The Sphinx and Doxygen documentation is generated by CI on our faculty GitLab server. Links to RTEMS CAN resources in the section CAN/CAN FD Subsystem and Drivers for RTEMS htt

Re: Repo Transition to GitLab

On Fri, Apr 26, 2024, 12:49 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 26.04.24 00:38, Chris Johns wrote: > > Hi RTEMS Community > > > > The git repos on git.rtems.org are open and accepting patches. The > GitLab repos > > will move us to main, something we have been wait

Re: Repo Transition to GitLab

On 26.04.24 00:38, Chris Johns wrote: Hi RTEMS Community The git repos on git.rtems.org are open and accepting patches. The GitLab repos will move us to main, something we have been waiting to do. Allowing commits into the repos means they will be brought across and played on top of the new main

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

On 16.04.24 07:25, Sebastian Huber wrote: On 09.04.24 16:28, Sebastian Huber wrote: 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 direct

Re: Cortex-M floating point (Was: RTEMS 6 branching)

On 24.04.24 14:37, Cedric Berger wrote: Hello Sebastian, On 23.04.2024 19:56, Sebastian Huber wrote: 1. Are all the things need for the release resolved? Tickets reviewed? It would be nice to have the interrupt get/set priority API in RTEMS 6. The Cortex-M floating point issue is not yet fixe

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

(Adding devel back in the CC) On Wed, Apr 24, 2024 at 1:34 AM Purva Yeshi wrote: > Please feel free to call me Vijay :) > > Sure. > > That's great! You might be able to relate some of the documentation to the >> riscv BSP code in the repository. > > Yes, and I also added examples related to risc

Re: Cortex-M floating point (Was: RTEMS 6 branching)

On 24/4/2024 10:37 pm, Cedric Berger wrote: > Hello Sebastian, > > On 23.04.2024 19:56, Sebastian Huber wrote: >>> 1. Are all the things need for the release resolved? Tickets reviewed? >> It would be nice to have the interrupt get/set priority API in RTEMS 6. The >> Cortex-M floating point issue

Re: Cortex-M floating point (Was: RTEMS 6 branching)

On 24/4/2024 10:37 pm, Cedric Berger wrote: > Hello Sebastian, > > On 23.04.2024 19:56, Sebastian Huber wrote: >>> 1. Are all the things need for the release resolved? Tickets reviewed? >> It would be nice to have the interrupt get/set priority API in RTEMS 6. The >> Cortex-M floating point issue

Re: RTEMS 6 branching

On 25/4/2024 12:06 am, Peter Dufault wrote: >> On Apr 24, 2024, at 9:27 AM, Kinsey Moore wrote: >> >> That use case definitely wasn't considered for rtems-lwip and I don't know >> that it's ever been discussed. If that were intended, I'd expect a "./waf >> uninstall" target to exist that would r

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

Looks good, thanks! Kinsey On Tue, Apr 16, 2024 at 5:20 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 goes into reduced power or in low > power > mode. Thus the clock speed adapts to the overall syst

Re: RTEMS 6 branching

> On Apr 24, 2024, at 9:27 AM, Kinsey Moore wrote: > > That use case definitely wasn't considered for rtems-lwip and I don't know > that it's ever been discussed. If that were intended, I'd expect a "./waf > uninstall" target to exist that would remove the installed network stack so > that y

Re: RTEMS 6 branching

On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault wrote: > > On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee > wrote: > > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > - Am 21.

Re: RTEMS 6 branching

> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee wrote: > > > > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber > wrote: > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > > > Hi, > > > > There has been s

Re: RTEMS 6 branching

On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: >> >> > Hi, >> > >> > There has been some discussion about when we will

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

Hi Purva, On Tue, Apr 23, 2024 at 3:18 PM Purva Yeshi wrote: > Hello Sir, > Please feel free to call me Vijay :) > > Up until now, I have been studying the BSP driver documentation from > https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a good > understanding of why and how t

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

Hello Sir, Up until now, I have been studying the BSP driver documentation from https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a good understanding of why and how target-dependent files are written. Additionally, I am currently working on how the console and clock driver are wri

Re: RTEMS 6 branching

On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > > > Hi, > > > > There has been some discussion about when we will branch and it is > timely we > > discuss this. This is my input. :)

Re: RTEMS 6 branching

- Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > Hi, > > There has been some discussion about when we will branch and it is timely we > discuss this. This is my input. :) > > While I create the releases I am not solely responsible for milestone dates or > thresholds for a re

Re: RSB format changes to meet coding standard

On Sat, Apr 20, 2024, 7:19 PM Chris Johns wrote: > On 19/4/2024 7:15 pm, andrew.butterfi...@scss.tcd.ie wrote: > > Will you also do this with the formal code in rtems-central/formal ? > > Sorry, I do not use it so would prefer not to update it just yet. I think > it > best left to the leaders of

Re: [PATCH] bsps/powerpc: Introduction of interrupt locks

On 19/4/2024 6:12 pm, Christian MAUDERER wrote: > it is tested on an MVME2500 which uses the powerpc/qoriq_e500 in an SMP > configuration. Great and thanks. I should have access next week to MVME2700 hardware and can test it there. I doubt there will be an issue looking at the change but this grou

Re: RSB format changes to meet coding standard

On 19/4/2024 7:15 pm, andrew.butterfi...@scss.tcd.ie wrote: > Will you also do this with the formal code in rtems-central/formal ? Sorry, I do not use it so would prefer not to update it just yet. I think it best left to the leaders of that repo. > I do remember using yapf at some point – I have

Re: [rtems-tools PATCH 1/2] rtemstoolkit: Fix decoding unicode strings in output

stoolkit/execute.py b/rtemstoolkit/execute.py > index 31d3a8a..c7d8134 100755 > --- a/rtemstoolkit/execute.py > +++ b/rtemstoolkit/execute.py > @@ -37,6 +37,7 @@ > from __future__ import print_function > > import functools > +import codecs > import io > import os >

Re: [RFC] rtems: Add options to kernel output char handler

> On Apr 18, 2024, at 6:32 PM, Chris Johns wrote: > > On 18/4/2024 4:16 pm, Sebastian Huber wrote: >> On 18.04.24 04:02, Chris Johns wrote: >>> On 17/4/2024 11:06 pm, Sebastian Huber wrote: Make the kernel I/O output character device processing configurable through an option set param

Re: [PATCH] Fix the CPU count calculation error.

在 2024/4/19 16:50, Sebastian Huber 写道: On 19.04.24 09:16, zhengxiaojun wrote: I tested on arm64, the cpu_count do not increase when (redist->icrtyper & GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last core. The current code assumes that you have exactly one interrupt export port. With whic

Re: RSB format changes to meet coding standard

, Andrew From: devel on behalf of Joel Sherrill Date: Friday, 19 April 2024 at 03:09 To: Chris Johns Cc: Development Subject: Re: RSB format changes to meet coding standard On Thu, Apr 18, 2024, 7:31 PM Chris Johns mailto:chr...@rtems.org>> wrote: Hi, I would like to run the python code

Re: [PATCH] Fix the CPU count calculation error.

On 19.04.24 09:16, zhengxiaojun wrote: I tested on arm64, the cpu_count do not increase when (redist->icrtyper & GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last core. The current code assumes that you have exactly one interrupt export port. With which SoC are you working currently? One optio

Re: [PATCH] bsps/powerpc: Introduction of interrupt locks

Hello Chris, it is tested on an MVME2500 which uses the powerpc/qoriq_e500 in an SMP configuration. Best regards Christian On 2024-04-18 04:04, Chris Johns wrote: Hi Vincenzo, Welcome to RTEMS. What hardware in the shared VME PowerPC family of BSPS has this change been tested on? Thanks

Re: [PATCH] Fix the CPU count calculation error.

I tested on arm64, the cpu_count do not increase when (redist->icrtyper & GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last core. 在 2024/4/19 15:00, Sebastian Huber 写道: Hello, on which platform does this fix a error? ___ devel mailing list devel@r

  1   2   3   4   5   6   7   8   9   10   >