POSIX Issue 8 (2024) Download Available

Hi The PDF and HTML versions of the new POSIX Issue 8 are now available. I have copied the announcement below: Dear all I am pleased to announce that the html version of the 2024 edition is now available to read online, more information and registration at

Fwd: [PATCH] stdatomic: make atomics compatible with GCC-14

This looks like a newlib patch we want to be sure to pick up in the next newlib hash update. -- Forwarded message - From: Alexey Lapshin Date: Mon, Jul 8, 2024 at 2:39 AM Subject: [PATCH] stdatomic: make atomics compatible with GCC-14 To: new...@sourceware.org

Fwd: [ANNOUNCEMENT] GDB 15.1 released!

Thoughts on updating to this for rtems6? -- Forwarded message - From: Joel Brobecker via Gdb-announce via Gdb Date: Sun, Jul 7, 2024 at 1:04 PM Subject: [ANNOUNCEMENT] GDB 15.1 released! To: Cc: Joel Brobecker via Gdb-announce GDB 15.1 released! Release 15.1 of

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

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

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: > > > >> -

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,

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?

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:

Updating GitHub Mirrors?

Hi When/how do the mirrors of gcc, binutlls, newlib, etc get updated? I just patches to newlib this morning and one was to address a small problem blocking part of a GSoC project. Thanks. --joel ___ devel mailing list devel@rtems.org

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

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

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

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

removing unused third-party headers (objbsd)?

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? spec/build/cpukit/objbsd.yml: - destination:

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

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.

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

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

Ada

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 in GNAT 7.5.0 for the aspects.adb file. (That Python UTF-8

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

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

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-drivers-for-rtems The merge request draft

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

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

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

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

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

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

What to do with rtems_cache_disable_data()?

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 at least the L1 data cache is required

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

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

RTEMS Doxygen Broken

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 messages. Can someone please look at this and

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

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

RFC: Deprecate Old/Unused BSPs

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 on tool configurations when building all architectures. +

RFC: Deprecate MIPS port in 6.1

Hi There does not appear to be any recent activity for this port in RTEMS. Thread Local Storage is not supported yet. Dynamic loading has a mips dependent file but it looks like the last work was a patch from 2016 which was committed in 2020. No idea if this works. MIPS Technologies is now a

RFC: Deprecate Moxie port in 6.1

Hi There does not appear to be any activity for this port and the Moxie project does not have any recent activity. Any objections to deprecating this for 6 and removing before 7? Thanks --joel ___ devel mailing list devel@rtems.org

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

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

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

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

Upgrading tools - gcc, binutils, and gdb

Hi 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. Is there any reason we are still on binutils 2.41? binutils 2.42 was release in Jan 2024. I don't mind updating them if no

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

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

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, >

Fwd: GCC 13.3 Release Candidate available from gcc.gnu.org

GCC is getting closer to a real release. When this drops, we need to switch the RSB to it for 6 tools. --joel -- Forwarded message - From: Jakub Jelinek via Gcc Date: Tue, May 14, 2024, 11:33 AM Subject: GCC 13.3 Release Candidate available from gcc.gnu.org To: The first

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

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

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 > -

ZynqMP APU RAM Start

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-assign: null - format-and-define: null build-type: option

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

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

6.1 release on Aug 26, 2024?

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 some planning... Thanks, Cedric

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 ) );

Improvements to SMP under the arch64 architecture

Hi, all The current RTEMS can not run on the multi-core CPUs arranged in clusters, the current code treat mpidr as processor index, but when multi-core arranged in cluster, mpidr is 0,0x100,0x200 ... So a mapping needs to be established between mpidr and processor index. MPIDR_EL1

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

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

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 holds the Set-pending bits for interrupts 0-31." Signed-off-by: Sebastian Huber ---

[PATCH 2/2] hw/intc/arm_gic: Fix writes to GICD_ITARGETSRn

According to the GICv2 specification section 4.3.12, "Interrupt Processor Targets Registers, GICD_ITARGETSRn": "Any change to a CPU targets field value: [...] * Has an effect on any pending interrupts. This means: - adding a CPU interface to the target list of a pending interrupt makes that

RTOS/RTEMS (rtems.git) history rewrite

Hello, A merge request was applied that contained a merge commit and a decision was taken to correct this in the git repo. This means the history has been rewritten. Please check your forks or clones if you have updated and pulled in the merge commit. We are looking into getting GitLab to flag

RTOS/RTEMS (rtems.git) history write

Hello, A merge request was applied that contained a merge commit and a decision was taken to correct this in the git repo. This means the history has been rewritten. Please check your forks or clones if you have updated and pulled in the merge commit. We are looking into getting GitLab to flag

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 > > > >

Request for feedback on project proposal and documentation approach

Hello Mentors, I have signed up for the RTEMS Gitlab platform. I am proposing to use hackmd.io as a documentation tool to create blog posts that detail my work progress. However, I am open to any other suggestions or preferred platforms you may have in mind. I would appreciate your feedback on my

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 >

RTEMS Deployment

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. Thanks Chris ___ devel mailing list devel@rtems.org

cgit

Hello, We will be shutting down cgit on git.rtems.org in coming days and the URL redirected to GitLab. If you have personal repos with things you would like to keep please make a local clone. Thanks Chris ___ devel mailing list devel@rtems.org

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: > >

Submit Outstanding Patches Via GitLab

Hi If you have any patches that are still pending on the mailing list, please get yourself an account on gitlab.rtems.org and submit them as a merge request. Instructions are linked to in Chris' emails. Help is available on devel@ and Discord. Thanks. --joel

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

GitLab Workflows and Merge Requests

Hi RTEMS Community. This email explains the Workflows and Merge Requests. GitLab is will be open and accounts can be created from 12PM EST / 5PM GM. The workflow is based around issues and merge requests. We use project forks as the base of our workflow and outside of that there is no workflow

Issues in GitLab

Hi RTEMS Community. This email explains RTEMS Issues in GitLab. GitLab is will be open and accounts can be created from 12PM EST / 5PM GM. All valid tickets in Trac have been brought across to GitLab. This is the fourth move of this database and each move adds a layer of complexity as we align

RTEMS Project Repos in GitLab

Hi RTEMS Community. This email explains the RTEMS Project and Repos in GitLab. GitLab is will be open and accounts can be created from 12PM EST / 5PM GM. Note, GitLab failed to automatically identify the RTOS/RTEMS licence and it incorrectly states it is Apache 2.0. It is not and no licences

RTEMS GitLab Sign In

Hi RTEMS Community. GitLab is will be open and accounts can be created from 12PM EST / 5PM GM. This email explains getting an account and signing onto GitLab. We did not bring any of the existing accounts over to GitLab so you can create and set up a new account that suits you. It also means we

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

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.

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

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

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

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

[PATCH rtems-source-builder v3] bare/config: add renode rsb installation config

Bumping last update of last year's renode porting result. Rebased to most recent commit on master. Change file name based on Chris's review here https://lists.rtems.org/pipermail/devel/2023-July/075802.html Plus, fix `cp` so that it also include dotfiles. Because without the the `.renode-root`

[PATCH rtems-docs] add renode docs

Bumping last update of last year's renode porting result. Rebased to most recent commit on master. Testing using renode docs. Consists of how to install it and how to add new configuration to test BSP using renode. --- user/testing/index.rst | 1 + user/testing/renode.rst | 84

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

Bumping last update of last year's renode porting result. Rebased to most recent commit on master. Fixing typo on renode_script/ folder that is changed to be renode/ in v4 --- .../testing/bsps/kendrytek210-renode.ini | 38 tester/rtems/testing/bsps/leon3-renode.ini| 37

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

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

GCC 14: m68k, sh, and sparc64

Hello, the m68k, sh, and sparc64 build fails with GCC 14 due to: make "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2 -m4-single-only" "CCASFLAGS=-g -O2 -m4-single-only" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=" "INSTALL=/usr/bin/install -c" "LDFLAGS=-m4-single-only" "LIBCFLAGS=-m4-single-only"

GCC 14: nios2

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 just for this target. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178

  1   2   3   4   5   6   7   8   9   10   >