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

[RSB 1/3] 6/7: Update Newlib

Keep RTEMS up to date with the upstream development. --- rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++-- rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++-- rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++-- rtems/config/tools/rtems-gcc-13-newlib-head.cfg | 4 ++--

[RSB 2/3] 6: Update GCC 12 and 13

Keep RTEMS up to date with the upstream development. For GCC 13, this includes a new set of aarch64 multilibs to address Cortex-A53 workarounds and fixes for powerpc. --- rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++-- rtems/config/tools/rtems-gcc-13-newlib-head.cfg | 4 ++-- 2 files

[RSB 3/3] 7: Update Binutils, GDB, and GCC

Keep RTEMS up to date with the upstream development. This snapshot is close to the GCC 14 release. --- rtems/config/tools/rtems-binutils-head.cfg| 4 ++-- rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++-- rtems/config/tools/rtems-gdb-head.cfg | 4 ++-- 3 files

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

GitLab Launch

Hi RTEMS Community. We will be launching GitLab during the 1st May 2024. You can access RTEMS GitLab (RGL) at: https://gitlab.rtems.org/ Account creation will be enabled on the 1st May 2024. The goal of the move to GitLab is to modernise our workflow reducing the burden of merging patches

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

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

Repo Transition to GitLab

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 branch. We have changes in the repo on

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

Make the kernel I/O output character device processing configurable through an option set parameter. Add RTEMS_IO_NO_OUTPUT and RTEMS_IO_DRAIN options. The goal of this API change is to enable draining the kernel output device in the system termination process before a reset is issued. A use

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

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

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

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

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

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

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

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

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

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

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 fixed in the RTEMS master. Do you have any

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

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

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

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

[PATCH 9/9] bsp/tms570: Use write-back/write-allocate SDRAM

Update #4982. --- bsps/arm/tms570/start/tms570_sys_core.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/arm/tms570/start/tms570_sys_core.S b/bsps/arm/tms570/start/tms570_sys_core.S index 83dee26ec8..ef28d88ede 100644 --- a/bsps/arm/tms570/start/tms570_sys_core.S +++

[PATCH 8/9] bsp/tms570: Use RTI for CPU counter

The performance monitor counter is stopped when the core is waiting for interrupts. Update #4982. --- bsps/arm/tms570/clock/clock.c | 71 -- bsps/arm/tms570/cpucounter/cpucounterread.c | 83 - spec/build/bsps/arm/tms570/obj.yml | 1 - 3

[PATCH 7/9] bsp/tms570: Add TMS570_FATAL_RTI_IRQ_INSTALL

Update #4982. --- bsps/arm/tms570/clock/clock.c | 15 --- bsps/include/bsp/fatal.h | 3 +++ 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c index cf14d5772f..2fb884b3ce 100644 ---

[PATCH 1/9] arm: Add arm_cp15_data_cache_all_invalidate()

Update #4982. --- cpukit/score/cpu/arm/include/libcpu/arm-cp15.h | 17 + 1 file changed, 17 insertions(+) diff --git a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h index c239eaccc8..4a5ddb561e 100644 ---

[PATCH 6/9] bsp/tms570: Fix clock driver

The clock tick rate was off by a factor of two in some configurations. Use the maximum counter frequency to get the best time resolution. Do not use the automatic interrupt clear feature. Update #4982. --- bsps/arm/tms570/clock/clock.c | 99 +++ 1 file changed,

[PATCH 4/9] bsp/tms570: Add TMS570LC4357 PLL support

Update #4982. --- bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h | 27 +++ 1 file changed, 27 insertions(+) diff --git a/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h b/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h index d5583a1cca..1ca2bff685 100644 ---

[PATCH 5/9] bsp/tms570: Add clock BSP options

Update #4982. --- bsps/arm/tms570/clock/clock.c | 4 ++-- bsps/arm/tms570/console/tms570-sci.c| 2 +- bsps/arm/tms570/cpucounter/cpucounterread.c | 2 +- bsps/arm/tms570/include/bsp.h | 6 -- spec/build/bsps/arm/tms570/grp.yml | 12

[PATCH 3/9] bsps/cache: Fix ARM CP-15 get cache size

The rtems_cache_get_data_cache_size() and rtems_cache_get_instruction_cache_size() functions shall return the entire cache size for a level of 0. Levels greater than 0 shall return the size of the associated level. Update #4982. --- bsps/arm/shared/cache/cache-cp15.c | 8 1 file

[PATCH 2/9] bsps/cache: Simplify Cortex-R5 cache support

Update #4982. --- bsps/arm/shared/cache/cache-cp15.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/bsps/arm/shared/cache/cache-cp15.c b/bsps/arm/shared/cache/cache-cp15.c index 88fae2fb1f..92ccfcb276 100644 --- a/bsps/arm/shared/cache/cache-cp15.c +++

[PATCH 0/9] bsp/tms570 Improvements

Sebastian Huber (9): arm: Add arm_cp15_data_cache_all_invalidate() bsps/cache: Simplify Cortex-R5 cache support bsps/cache: Fix ARM CP-15 get cache size bsp/tms570: Add TMS570LC4357 PLL support bsp/tms570: Add clock BSP options bsp/tms570: Fix clock driver bsp/tms570: Add

[PATCH 6/6] bsps/arm: Fix Doxygen group assignment

--- bsps/arm/shared/cache/cache-cp15.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bsps/arm/shared/cache/cache-cp15.c b/bsps/arm/shared/cache/cache-cp15.c index d78ec4feb4..88fae2fb1f 100644 --- a/bsps/arm/shared/cache/cache-cp15.c +++

[PATCH 4/6] bsps/arm: Add Doxygen group for Armv7-M SysTick

Change license to BSD-2-Clause according to file history and contributor agreements. --- bsps/arm/include/bsp/clock-armv7m.h | 49 +-- bsps/arm/shared/clock/clock-armv7m.c | 8 +++ .../arm/shared/cpucounter/cpucounter-armv7m.c | 8 +++ 3 files changed, 61

[PATCH 5/6] bsps/arm: Add CMSIS files to Doxygen group

--- bsps/arm/shared/doxygen.h | 56 +++ 1 file changed, 56 insertions(+) diff --git a/bsps/arm/shared/doxygen.h b/bsps/arm/shared/doxygen.h index 469928d712..8dbf129f07 100644 --- a/bsps/arm/shared/doxygen.h +++ b/bsps/arm/shared/doxygen.h @@ -29,3 +29,59 @@

[PATCH 3/6] bsps/aarch64: Define Doxygen groups

Fix typos. --- bsps/aarch64/include/bsp/linker-symbols.h | 2 +- bsps/aarch64/include/bsp/start.h | 2 +- bsps/aarch64/shared/doxygen.h | 23 +++ 3 files changed, 25 insertions(+), 2 deletions(-) create mode 100644 bsps/aarch64/shared/doxygen.h diff

[PATCH 2/6] aarch64: Add files to Doxygen groups

--- cpukit/score/cpu/aarch64/aarch64-thread-idle.c | 7 +-- cpukit/score/cpu/aarch64/include/rtems/asm.h | 5 - .../include/rtems/score/aarch64-system-registers.h | 2 ++ cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 10 +++--- 4 files changed, 18

[PATCH 0/6] Doxygen improvements

Sebastian Huber (6): bsps: Add Doxygen group for Arm Generic Timer aarch64: Add files to Doxygen groups bsps/aarch64: Define Doxygen groups bsps/arm: Add Doxygen group for Armv7-M SysTick bsps/arm: Add CMSIS files to Doxygen group bsps/arm: Fix Doxygen group assignment

[PATCH 1/6] bsps: Add Doxygen group for Arm Generic Timer

--- bsps/shared/dev/clock/arm-generic-timer.c | 26 --- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/bsps/shared/dev/clock/arm-generic-timer.c b/bsps/shared/dev/clock/arm-generic-timer.c index 44cf1ebe6c..b2842df175 100644 ---

[PATCH 3/3] bsps/arm: Move BSP-specific header file

--- bsps/arm/{ => edb7312}/include/uart.h | 0 spec/build/bsps/arm/edb7312/bspedb7312.yml | 1 + spec/build/bsps/arm/grp.yml| 1 - 3 files changed, 1 insertion(+), 1 deletion(-) rename bsps/arm/{ => edb7312}/include/uart.h (100%) diff --git a/bsps/arm/include/uart.h

[PATCH 2/3] bsps/arm: Use shared object for ARM920 MMU support

--- spec/build/bsps/arm/csb336/bspcsb336.yml | 3 ++- spec/build/bsps/arm/csb337/grp.yml | 2 ++ spec/build/bsps/arm/csb337/obj.yml | 1 - spec/build/bsps/arm/grp.yml | 3 --- spec/build/bsps/arm/gumstix/bspgumstix.yml | 3 ++-

[PATCH 1/3] bsps/arm: Move BSP-specific header file installs

--- spec/build/bsps/arm/beagle/obj.yml | 5 + spec/build/bsps/arm/grp.yml| 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/spec/build/bsps/arm/beagle/obj.yml b/spec/build/bsps/arm/beagle/obj.yml index 0f2f354ab9..eaaf09f6ac 100644 ---

[PATCH 0/3] Build optimizations for arm BSPs

Sebastian Huber (3): bsps/arm: Move BSP-specific header file installs bsps/arm: Use shared object for ARM920 MMU support bsps/arm: Move BSP-specific header file bsps/arm/{ => edb7312}/include/uart.h| 0 spec/build/bsps/arm/beagle/obj.yml | 5 +

[PATCH] bsps: Use interrupt entry in clock driver

This avoids a dependency on memory allocations. --- bsps/shared/dev/clock/arm-generic-timer.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/bsps/shared/dev/clock/arm-generic-timer.c b/bsps/shared/dev/clock/arm-generic-timer.c index ba159f6833..44cf1ebe6c

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

  1   2   3   4   5   6   7   8   9   10   >