Re: Naming convention for Rust target platforms

On 1/29/24 19:41, jan.som...@dlr.de wrote: Hi everyone, As mentioned in the other Rust thread, I am working on an initial Rust port for RTEMS. The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs. Where I am not completely sure, is how to name the new target for Rust (see her

Re: Naming convention for Rust target platforms

On 1/30/24 18:13, Frank Kühndel wrote: Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the naming convention of the Rust community:     https://docs.rust-embedded.org/embedonomicon/custom-target.html According to this file, the part `eabi` is for bare metal. Would this be

Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13

On 12/18/23 07:05, Chris Johns wrote: Mac with M1/M2/M3 work fine with the latest tooling. I think there is a middle ground here and that means some investigation is needed to determine what works and what is at issue then deciding how much further work is done. I have done some of this. The re

Re: Outdated list of BSPs in rtems-tools/config

Hello Thomas, On 9/14/23 21:35, Thomas DOERFLER wrote: Hello Peter, just my two cents regarding eTPU: NXP has more or less left the PowerPC architecture and favor ARM for automotive applications. But the MPC5xxx controllers were developed in some sort of cooperation with ST microelectro

Re: [PATCH] testproc/gsed: update from 4.8 to 4.9.

This is tested on FBSD 14 and 13.2 and also macOS (latest). Also on Ubuntu 20.04 LTS where it is a no-op due to GNU sed being installed on the system. On 8/5/23 20:27, Karel Gardas wrote: Fixes #4938. --- bare/config/textproc/gsed-4.9.cfg | 12 bare/config/textproc/gsed.cfg

[PATCH] testproc/gsed: update from 4.8 to 4.9.

Fixes #4938. --- bare/config/textproc/gsed-4.9.cfg | 12 bare/config/textproc/gsed.cfg | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 bare/config/textproc/gsed-4.9.cfg diff --git a/bare/config/textproc/gsed-4.9.cfg b/bare/config/textproc/gsed-4.9.c

Re: [PATCH] build: Add PROGRAM_PREFIX option

A bit off-topic. On 8/2/23 10:39, Sebastian Huber wrote: Yes, but this would be another patch and it is a bit more work since you have to test the clang support. Is building with clang already supported? I'm curious since this is something I'd like to test locally too but neither code nor t

Re: Fwd: [rtems-bsp-builder] 2023-07-31 17:37:34: Profile(s): everything

ue, Aug 1, 2023 at 9:00 AM Karel Gardas wrote:    Joel, not sure about what do you mean by "before the fix was pushed", but certainly RTEMS HEAD does not contain the fix for this yet and fix is already awaiting review here: https://lists.rtems.org/piperma

Re: Fwd: [rtems-bsp-builder] 2023-07-31 17:37:34: Profile(s): everything

Joel, not sure about what do you mean by "before the fix was pushed", but certainly RTEMS HEAD does not contain the fix for this yet and fix is already awaiting review here: https://lists.rtems.org/pipermail/devel/2023-July/076043.html If you ok that, I may push... Thanks, Karel On 8/1

Re: [PATCH] Revert "bsps/arm/beagle/dcan: Added DCAN support"

37:10: fatal error: dev/can/can.h: No such file or directory Thanks, Karel On 7/31/23 20:07, Karel Gardas wrote: This reverts commit 26d50bdfb601b9ef71ec2b30d2d9467c2437f443. --- bsps/arm/beagle/dcan/am335x-dcan.c| 104 - bsps/arm/beagle/dcan/d

Re: Pushing to 6.1

Hello, do we have any plan with timeline? I think to see some roadmap would be greatly appreciated on all sides, wouldn't it? Thanks! Karel On 7/27/23 19:56, Joel Sherrill wrote: Hi The number of tickets is unfortunately not declining as I would like. This is in spite of us actually clo

[PATCH] eng: add Apache License 2.0 restriction

--- eng/license-requirements.rst | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst index b2720f2..537b45e 100644 --- a/eng/license-requirements.rst +++ b/eng/license-requirements.rst @@ -98,9 +

[PATCH] eng: add Apache License 2.0 restriction

--- eng/license-requirements.rst | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst index b2720f2..b9eea9a 100644 --- a/eng/license-requirements.rst +++ b/eng/license-requirements.rst @@ -98,9 +98,25 @@

Re: [PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

On 7/25/23 17:23, Sebastian Huber wrote: On 25.07.23 16:20, Karel Gardas wrote: On 7/25/23 15:32, Sebastian Huber wrote: On 21.07.23 17:37, Karel Gardas wrote: ---   bsps/arm/include/cmsis_gcc.h | 4 +++-   1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bsps/arm/include

[PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

--- bsps/arm/include/cmsis_gcc.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h index 4f0762d6dc..f8267ded0d 100644 --- a/bsps/arm/include/cmsis_gcc.h +++ b/bsps/arm/include/cmsis_gcc.h @@ -1,3 +1,6 @@ +/* + * The file w

[PATCH] import Apache License 2.0 text file

--- LICENSE.Apache-2.0 | 202 + 1 file changed, 202 insertions(+) create mode 100644 LICENSE.Apache-2.0 diff --git a/LICENSE.Apache-2.0 b/LICENSE.Apache-2.0 new file mode 100644 index 00..d645695673 --- /dev/null +++ b/LICENSE.Apache-2.0 @@ -0,

Re: [PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

On 7/25/23 15:32, Sebastian Huber wrote: On 21.07.23 17:37, Karel Gardas wrote: ---   bsps/arm/include/cmsis_gcc.h | 4 +++-   1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h index 4f0762d6dc..9e867348d2 100644 --- a/bsps

Re: [PATCH v1 2/2] bsps/stm32h7: Configure UART clocks when enabled

On 7/24/23 23:17, Kinsey Moore wrote: [...] There is no other UART1 connector provided on the board. So I do not see reason why you add all other UARTs into #ifdefs for this particular board/bsp variant? And hence my question about your motivation and where you are headi

Re: [PATCH] bsps/arm: fix installation broken by recent CMSIS files update

: warning: nested extern declaration of '_start' [-Wnested-externs]   139 |   extern void _start(void) __NO_RETURN; Best regards Christian On 2023-07-25 08:55, Karel Gardas wrote: Sure! Not a problem, I was just waiting for Christian to confirm its also working on his side. Thanks, Kare

Re: [PATCH] bsps/arm: fix installation broken by recent CMSIS files update

first pass. Thanks Chris On 25/7/2023 1:53 am, Karel Gardas wrote: --- spec/build/bsps/arm/grp.yml | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml index 1058f58d92..a48cd80d74 100644 --- a/spec/build/bsps/arm

Re: [PATCH v1 2/2] bsps/stm32h7: Configure UART clocks when enabled

Hello Kinsey, honestly I don't know what to do about this patch. Let me explain a bit history behind STM32h7. It was originally submitted by embedded brains guys (Sebastian main, Christian added few things later) supporting the only eval board of that time stm32h743-eval(2). Sebastian also

Re: [PATCH v1 1/2] bsps/stm32h7: Make UART7 pins configurable

Hello Kinsey, I think the patch looks good, although I've not verified precise PIN/REGs assignment value. I trust you test this somehow otherwise you would not submit it. And this steers my curiosity. The only board (from ST Micro) I know which provides connection to UART7 is stm32h735g-dk

[PATCH] bsps/arm: fix installation broken by recent CMSIS files update

--- spec/build/bsps/arm/grp.yml | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml index 1058f58d92..a48cd80d74 100644 --- a/spec/build/bsps/arm/grp.yml +++ b/spec/build/bsps/arm/grp.yml @@ -10,12 +10,13 @@ includes:

Re: [PATCH] 6: Use GDB 13.2

Hello Sebastian, this together with also libexpat patch builds fine on: - macOS 13.4.1 - FreeBSD 13.2 - Ubuntu 20.04 btw, recently Joel remarked that gdb from 7/ makes troubles building on fbsd 12.x. I verified the same on fbsd 13.x and Hesham noted on discord that he has the same issues on

Re: [PATCH] fix type and logic issue when libbsd checking is enforced by the user code

On 7/22/23 17:26, Joel Sherrill wrote: I'm not that familiar with this logic but your change looks right to me. ACK. Please.change the title from type to typo. It looks like a typo in your commitmto fix a typo. Lol No, not at all. As a big fan of statically typed languages I think this is

[PATCH] fix type and logic issue when libbsd checking is enforced by the user code

Fixes #4930. --- rtems_bsd.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rtems_bsd.py b/rtems_bsd.py index 7fbe66f..8faae10 100644 --- a/rtems_bsd.py +++ b/rtems_bsd.py @@ -71,8 +71,8 @@ def bsp_configure(conf, arch_bsp, mandatory=True): 'config

[PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

--- bsps/arm/include/cmsis_gcc.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h index 4f0762d6dc..9e867348d2 100644 --- a/bsps/arm/include/cmsis_gcc.h +++ b/bsps/arm/include/cmsis_gcc.h @@ -30,7 +30,9 @@ #pragma G

[PATCH series for review] STM32 H7 HAL update.

Folks, I'd like to propose and perform STM32 H7 HAL code update. Currently this HAL code is part of RTEMS source tree located inside bsps/arm/stm32h7 subdirectory. As the patches are too big to be sent to the mailing list, I'm providing them here for review: https://github.com/karelfv/

Re: HEADS UP: git repo WRONG push landed.

Follow-up: Amar decided to fix that properly. It'll take some time for which I personally apologize and thank you Amar for dealing with this! Thanks, Karel On 7/18/23 15:40, Karel Gardas wrote:   Folks, I've completely screwed up and pushed wrong repository to the git.rtem

HEADS UP: git repo WRONG push landed.

Folks, I've completely screwed up and pushed wrong repository to the git.rtems.org. I don't know how that happen as this should land on github.com... So please do not commit anything for now, I'll try to lookup help on discord.com and see what can be done to unpush... Thanks and really s

Libbsd situation.

Hello, if I'm right than RTEMS 6 should be accompanied with libbsd from 6-freebsd-12 branch which should be based on freebsd-12 (stable/12 branch). Please correct me if I'm wrong here. If I'm right above, then there are few things which worries me a bit: (1) FreeBSD's 12 branch is going

Re: Discussion: How to handle HALs, SDKs and libraries

On 7/16/23 10:03, o...@c-mauderer.de wrote: Of course the revision from two months back has to be available in the repo. It doesn't really matter whether it's on master because the code just worked or whether it's a RTEMS specific branch because adaptions have been necessary. You "it doesn't

Westernization of RTEMS/stm32H7 [was: Re: Discussion: How to handle HALs, SDKs and libraries]

Hello, Christian mentioned Zephyr west tool as one of good/possible candidates for RTEMS tree modularization especially with regarding to HALs and other 3rd party libraries. For comparison with my previous git submodulization of RTEMS/stm32H7 I've also westernized the same in a similar w

Re: Discussion: How to handle HALs, SDKs and libraries

On 7/15/23 16:00, o...@c-mauderer.de wrote: We should avoid rebasing and overwriting the old branch because we have to preserve a version that can be used with older RTEMS versions. So for rebasing, we would have to use multiple branches. Instead of rtems-6-branch, it could be a rtems- or somet

Re: Discussion: How to handle HALs, SDKs and libraries

On 7/15/23 14:33, o...@c-mauderer.de wrote: I like submodules because they are well-supported by the usual tools. Honestly. I like submodules idea, but hate its implementation. Some reasons: - submodules were added as a light weight feature and during the development of git/submodule featur

Re: Discussion: How to handle HALs, SDKs and libraries

On 7/15/23 09:47, o...@c-mauderer.de wrote: Am 15.07.23 um 01:48 schrieb Karel Gardas:   Hello, I've created setup where I've put updated STM32H7 HAL consisting of two submodules: - stm32h7xx_hal_driver - cmsis_device_h7 and ARM's - CMSIS_5 into hals/arm/stm32h7 to fol

Re: Discussion: How to handle HALs, SDKs and libraries

ygen tag change done by Sebastian. This is to be discussed topic if doxygen changes belongs to submodule or are not needed anymore... hello.exe/ticker.exe/paranoia.exe runs fine. Comments welcome! Karel On 7/14/23 13:53, Karel Gardas wrote: Hello, are we really that close to RTEMS 6 relea

Re: Discussion: How to handle HALs, SDKs and libraries

Hello, are we really that close to RTEMS 6 release that none of this is acceptable to do now? Asking since I'd also like to update stm32h7 HAL. I may do that manually or I may do that submodule way which may perhaps save some of the manual work involved as some of the patches may not be ne

Re: [PATCH] bsps/arm: replace CMSIS v4 with CMSIS v5 files

On 7/14/23 01:24, Joel Sherrill wrote: On Thu, Jul 13, 2023 at 4:11 PM Karel Gardas wrote:   Folks, please take this patch as an attempt to renew old discussion or rather start a new one focused solely on importing new ARM CMSIS code which is (i) under Apache 2 license but

Re: [PATCH] bsps/arm: replace CMSIS v4 with CMSIS v5 files

affected by the change. Thanks for any comments! Karel On 7/13/23 23:05, Karel Gardas wrote: CAVEAT: license change from BSD to Apache2 license! Explanation: The imported files come from CMSIS v5 project available on: https://github.com/ARM-software/CMSIS_5/tree/develop The files imported are

Ping: github.com mirroring of RTEMS repositories not working.

Hello Amar, github.com mirroring of RTEMS repositories is not working since March 23[1] of this year. This was reported several times IIRC on devel@ and discord channels. Since this is already several months of outage, I would like to ask you if you plan to make that working again or shall

Re: [PATCH v2 2/2] bsps/stm32h7: Move SDRAM1 to correct memory range

Hello Kinsley, you are indeed right. I've not fixed this bit since it also requires fixes in linker scripts and additional sdram region for sdram2 remap. E.g. Original Sebastian's code is using SDRAM_1 as a remap of SDRAM_2. Linker script(s) then are using SDRAM_1 as an executable region (r

Re: [PATCH] arm/stm32h7: Add support for STM32H750B-DK

On 7/11/23 15:50, Kinsey Moore wrote: This adds support for the STM32H750B-DK discovery kit. This kit includes a built-in STLINKv3 debugger which provides a USB serial bridge for USART3. USART1 is routed to the Arduino header and USART2 is routed to the STMOD connector. This BSP reuses what would

Re: [PATCH 1/2] score/arm: improve printed exception information for Cortex-Mx CPUs

On 7/7/23 07:00, Sebastian Huber wrote: Hello Karel, both patches are fine in terms of functionality. It would be nice to keep the score coding style in cpukit/score/cpu/arm/arm-exception-frame-print.c. Hello Sebastian, thanks for the review. I've tried my best to fix that and also squash

[PATCH] score/arm: improve printed exception information for Cortex-Mx CPUs

Sponsored-By: Precidata --- .../score/cpu/arm/arm-exception-frame-print.c | 145 +- .../cpu/arm/include/rtems/score/armv7m.h | 11 ++ 2 files changed, 154 insertions(+), 2 deletions(-) diff --git a/cpukit/score/cpu/arm/arm-exception-frame-print.c b/cpukit/score/cpu/arm/ar

[PATCH 1/2] score/arm: improve printed exception information for Cortex-Mx CPUs

Sponsored-By: Precidata --- .../score/cpu/arm/arm-exception-frame-print.c | 101 ++ .../cpu/arm/include/rtems/score/armv7m.h | 11 ++ 2 files changed, 112 insertions(+) diff --git a/cpukit/score/cpu/arm/arm-exception-frame-print.c b/cpukit/score/cpu/arm/arm-exception-fram

[PATCH 2/2] score/arm: print FPU registers also for VFP-D16 equipped CPUs

Sponsored-By: Precidata --- cpukit/score/cpu/arm/arm-exception-frame-print.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/cpukit/score/cpu/arm/arm-exception-frame-print.c b/cpukit/score/cpu/arm/arm-exception-frame-print.c index 32e9c723d9..4bef9a8866 100644 --

RTEMS_SYSINIT_ITEM not working sometimes?

Hello, while working on STM32H7 I've noticed that rng is not working well. Tracked that down to stm32h7_rng_enable function not being properly called as it should be. The function call should be enforced by: RTEMS_SYSINIT_ITEM( stm32h7_rng_enable, RTEMS_SYSINIT_DEVICE_DRIVERS, RTEMS

Re: Tool versions for RTEMS 6.1 release?

Hello Sebastian, so what is the best way to test GCC 13.2 with RTEMS 6? Is ../source-builder/sb-set-builder --prefix= --with-rtems-gcc=tools/rtems-gcc-13-newlib-head 6/rtems-all canonical way how to build those tools for RTEMS 6? Or is there some trickery involved I do not see yet? Thank

[PATCH] bsps/stm32h7: disable MPU alignment for M4-based BSP variants

There is no point in wasting precious memory space on enforced section alignment for the purpose of MPU which is not implemented on M4 core anyway. --- spec/build/bsps/arm/stm32h7/optenmpualign.yml | 4 1 file changed, 4 insertions(+) diff --git a/spec/build/bsps/arm/stm32h7/optenmpualign.ym

Re: RSB repo commits need approval

On 4/27/23 08:13, Sebastian Huber wrote: Why don't we use a Git pull request workflow with CI pipelines in the RTEMS Project? I don't know, but certainly github.com is not available as an open-source solution which may be seen as a major roadblock. Am I right assuming that GitLab Community i

Re: Change build specification files from YAML to JSON?

On 4/25/23 12:32, Sebastian Huber wrote: On 25.04.23 12:10, Karel Gardas wrote: On 4/25/23 11:03, Sebastian Huber wrote: On 25.04.23 11:00, Karel Gardas wrote: On 4/25/23 09:35, Sebastian Huber wrote: The change from YAML to JSON for the build specification files is just an implementation

Re: Change build specification files from YAML to JSON?

On 4/25/23 11:03, Sebastian Huber wrote: On 25.04.23 11:00, Karel Gardas wrote: On 4/25/23 09:35, Sebastian Huber wrote: The change from YAML to JSON for the build specification files is just an implementation detail of the new build system. For the users of the new build system nothing

Re: Change build specification files from YAML to JSON?

On 4/25/23 09:35, Sebastian Huber wrote: The change from YAML to JSON for the build specification files is just an implementation detail of the new build system. For the users of the new build system nothing changes. Let me ask for clarification. Does this yaml -> json transition include (or

Re: Qemu and missing dynamic libraries

On 4/24/23 21:33, Joel Sherrill wrote: On Mon, Apr 24, 2023, 2:11 PM Karel Gardas wrote: What have you done to this poor FBSD? ;-) Anyway, I've just pkg update; pkg upgrade and result is: karel@rtems:/usr/local/lib $ ls -la libglib-2.0.* -rw-r--r--  1 root  wheel  24

Re: Qemu and missing dynamic libraries

What have you done to this poor FBSD? ;-) Anyway, I've just pkg update; pkg upgrade and result is: karel@rtems:/usr/local/lib $ ls -la libglib-2.0.* -rw-r--r-- 1 root wheel 2434866 Apr 2 03:18 libglib-2.0.a lrwxr-xr-x 1 root wheel 16 Apr 2 03:19 libglib-2.0.so -> libglib-2.0.so.0

[PATCH 1/3] bsps/shared: import FreeBSD libefi library

The library is imported in minimalist version just to support future amd64efi BSP. The FreeBSD tree commit id with imported libefi version is: ce7b20e5129cf0f269951b313d336a9c7d54d790 --- bsps/shared/freebsd/stand/efi/include/README | 36 + .../freebsd/stand/efi/include/amd64/efibind.h | 275

[PATCH 2/3] bsps/amd64: increase CPU alignment to 16

AMD64 requires SSE support which operates on 128bit data values. --- cpukit/score/cpu/x86_64/include/rtems/score/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h index 26

How to get amd64efi BSP running.

Folks, I just send my amd64efi BSP results for review. One of the commits (with BSP actually) awaits moderator approval due to size so before it gets in let me add few remarks about how to make that BSP working on either Qemu or real hardware. CAVEAT: We have serious issue somewhere betwee

[PATCH 3/3] bsps/amd64: increase CPU alignment to 16

AMD64 requires SSE support which operates on 128bit data values. --- cpukit/score/cpu/x86_64/include/rtems/score/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h index 26

[PATCH 1/3] bsps/shared: import FreeBSD libefi library

The library is imported in minimalist version just to support future amd64efi BSP. The FreeBSD tree commit id with imported libefi version is: ce7b20e5129cf0f269951b313d336a9c7d54d790 --- bsps/shared/freebsd/stand/efi/include/README | 36 + .../freebsd/stand/efi/include/amd64/efibind.h | 275

Re: [PATCH] gdb-common: Fix the python-config library parsing

Thanks for the quick fix. I tested here and indeed this fixes the reported issue. Karel On 4/11/23 08:03, chr...@rtems.org wrote: From: Chris Johns Closes #4894 --- source-builder/config/gdb-common-1.cfg | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source-b

Re: [PATCH] README for raspberry pi 4 AArch64 BSP

Hi, nice patch. I'm not sure if I'm right here, but I've thought the idea is to get rid of BSPs specific README files and move all the information into the RTEMS user docs. If I'm right, then it would be great if you merge your changes to the doc you already pointed out: https://docs.rtems

FreeBSD libefi import -- how to proceed?

Folks, I'm using FreeBSD's libefi on my hacked multiboot2 based amd64 BSP which I'd like to push for review (at least). Now, I'd like to prepare libefi for import but I'm still in doubts if to do that in: - as intact form as possible, import even files which will not be used in foresee

[PATCH] tester/bsps: change stm32h7-stlink to handle SIGTRAP as a nostop

The ST-Link GDB server throws spurious SIGTRAP into the GDB sometimes. When this happen, the gdb exits immediately as it's run in batch/script manner. Unfortunately this may be while testcase itself is still running and does not have enough time to print all the required output. Such testcase is th

Re: Help regarding Building x86_64 BSP

On 3/8/23 11:08, Frank Kühndel wrote: The build failures all happen when `building: grub2-2.06-x86_64-linux-gnu-1` which is the last build step. There are several similar errors. These are two of them taken from the build log: cc1: all warnings being treated as errors util/mkimage.c: In functi

[PATCH] grub2.cfg: fix GRUB compilation with GCC 12.

--- source-builder/config/grub2.cfg | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source-builder/config/grub2.cfg b/source-builder/config/grub2.cfg index 2333d6a..174b846 100644 --- a/source-builder/config/grub2.cfg +++ b/source-builder/config/grub2.cfg @@ -56,7 +56,8 @@ UR

Re: [PATCH 1/2] spec: add MPU CTRL option to be usable on ARMV7M based BSPs

On 3/16/23 14:34, Sebastian Huber wrote: On 16.03.23 14:28, Karel Gardas wrote: +description: | +  Default value of the ARM MPU CTRL register +default: +- enabled-by: +  - arm/imxrt1052 +  - arm/stm32h7 +  - arm/nucleo-h743zi +  - arm/stm32h7b3i-dk +  - arm/stm32h747i-disco +  - arm/stm32h757i

[PATCH 2/2] score/arm: enhance ARMV7M MPU setup with capability to set control register

Due to API change, the patch also fixes affected BSPs and uses value provided by MPU CTRL spec option there. Sponsored-By: Precidata --- bsps/arm/imxrt/start/bspstarthooks.c | 2 +- .../stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c | 2 +- .../stm32h7/boar

[PATCH 1/2] spec: add MPU CTRL option to be usable on ARMV7M based BSPs

/optmpuctrl.yml new file mode 100644 index 00..96f68968a6 --- /dev/null +++ b/spec/build/bsps/arm/optmpuctrl.yml @@ -0,0 +1,25 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-string: null +- define-unquoted: null +build-type: option +copyrights: +- Copyright (C) 2023 Karel

Re: [PATCH] score/arm: make MPU setup more generic

On 3/16/23 10:19, Sebastian Huber wrote: On 16.03.23 10:14, Karel Gardas wrote: This patch makes MPU setup more generic by adding capability to set also control register. This way BSPs are allowed to enable MPU also for hard faults by simply not setting PRIVDEFENA attribute to control register

[PATCH] score/arm: make MPU setup more generic

This patch makes MPU setup more generic by adding capability to set also control register. This way BSPs are allowed to enable MPU also for hard faults by simply not setting PRIVDEFENA attribute to control register. Compatibility with previous behavior and API is preserved. Sponsored-By: Precida

[PATCH] bsps/stm32h7: add comments explaining MPU setup

--- bsps/arm/stm32h7/start/mpu-config.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/bsps/arm/stm32h7/start/mpu-config.c b/bsps/arm/stm32h7/start/mpu-config.c index ce3c92ccb0..a3ebc065ec 100644 --- a/bsps/arm/stm32h7/start/mpu-config.c +++ b/bsps/arm/stm32h7/start/mpu-config.c

[PATCH] score/arm: improve printed exception information for Cortex-Mx CPUs

Sponsored-By: Precidata --- .../score/cpu/arm/arm-exception-frame-print.c | 101 ++ .../cpu/arm/include/rtems/score/armv7m.h | 11 ++ 2 files changed, 112 insertions(+) diff --git a/cpukit/score/cpu/arm/arm-exception-frame-print.c b/cpukit/score/cpu/arm/arm-exception-fram

Re: [PATCH 0/1] Fix a typo in the stm32h7 BSP Documentation

Thanks! Applied with a slightly modified commit message. Karel On 3/15/23 05:38, Ruturaj Nanoti wrote: Hi, I found a small typo while going through the BSP documentation for stm32h7 and fixed it in this commit. Thank You Ruturaj Nanoti (1): Fixed a typo in the /user/bsps/arm/stm32h7.rst

Re: RISC-V link warning :base_sp.exe has a LOAD segment with RWX permissions

Probably a new binutils made by: commit c58857dfdd8830871236261a3ef8399eff3b9b68 Author: Joel Sherrill Date: Tue Feb 21 09:24:37 2023 -0600 Update to binutils 2.40 for rtems 6 Karel On 3/14/23 15:45, Alan Cudmore wrote: Hi, I noticed that my RISC-V builds with the RTEMS master and R

Re: Problem when in booting amd64 BSP

Read https://www.mail-archive.com/devel@rtems.org/msg28484.html Also, if you modify /boot/kernel/kernel on FBSD you can't really expect it to boot back for you magically. You have basically sent FBSD kernel to void...:-) On 3/12/23 15:11, Siddharth Khattar wrote: Hello all, So recently I wa

Re: Help regarding Building x86_64 BSP

On 3/8/23 11:08, Frank Kühndel wrote: Hello, On 3/8/23 01:42, Joel Sherrill wrote: Subject: Re: Help regarding Building x86_64 BSP From: Joel Sherrill Date: 3/8/23, 01:42 To: Karel Gardas CC: "rtems-de...@rtems.org" Did you build the x86_64 tools and qemu using the RTEMS Sour

[PATCH] bsps/stm32h7: fix propagation of configured HSE freq. value into the code

Sponsored-By: Precidata --- .../arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c | 4 .../stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c | 4 .../stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c | 6 ++ .../stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.

Re: Help regarding Building x86_64 BSP

pc686-2021-11-20/share/qemu/edk2-licenses.txt ./6-tools-pc686-2021-11-20/share/qemu/edk2-x86_64-code.fd ./6-tools-pc686-2021-11-20/share/qemu/edk2-x86_64-secure-code.fd Karel On Tue, Mar 7, 2023, 11:39 AM Karel Gardas wrote: On 3/7/23 19:24, Karel Gardas wrote: > On 3/7/23 15:

Re: Help regarding Building x86_64 BSP

On 3/7/23 19:24, Karel Gardas wrote: On 3/7/23 15:05, Siddharth Khattar wrote: Hello all, So I was aiming to make a project to improve the amd64 BSP for RTEMS (modify it according to ACPI standards along with other stuff) but first I would need to build it. Unfortunately there was no way to

Re: Help regarding Building x86_64 BSP

On 3/7/23 15:05, Siddharth Khattar wrote: Hello all, So I was aiming to make a project to improve the amd64 BSP for RTEMS (modify it according to ACPI standards along with other stuff) but first I would need to build it. Unfortunately there was no way to build it natively within RTEMS source.

Re: [PATCH rtems-libbsd v2 0/2] Update the CGEM driver

One remark as an random observer here. "branch 6-freebsd-12" has caught my eyes. Let me ask shouldn't development patches go into the master branch from which they may be later cherry-picked if needed and pushed into 6-freebsd-12 branch? Just few weeks ago guys were having a discussion how to

Re: Rust for RTEMS [was: Re: Interested for GSoC 2023]

On 2/27/23 12:00, Karel Gardas wrote: On 2/27/23 02:16, Joel Sherrill wrote: Another GCC related project could be Rust RTEMS Support but I don't know what that entails beyond turning it on and seeing what goes wrong. I tried to build it last year and got far enough to decide to wait b

Re: Rust for RTEMS [was: Re: Interested for GSoC 2023]

On 2/27/23 15:44, Joel Sherrill wrote: On Mon, Feb 27, 2023 at 5:00 AM Karel Gardas wrote: adjusting subject based on Jan request. Keeping whole Rust relevant comments in. On 2/27/23 11:07, jan.som...@dlr.de <mailto:jan.som...@dlr.de>

Rust for RTEMS [was: Re: Interested for GSoC 2023]

adjusting subject based on Jan request. Keeping whole Rust relevant comments in. On 2/27/23 11:07, jan.som...@dlr.de wrote: -Original Message- From: devel On Behalf Of Karel Gardas Sent: Montag, 27. Februar 2023 09:16 To: j...@rtems.org; Vihas Makwana Cc: rtems-de...@rtems.org

Re: Interested for GSoC 2023

On 2/27/23 02:16, Joel Sherrill wrote: Another GCC related project could be Rust RTEMS Support but I don't know what that entails beyond turning it on and seeing what goes wrong. I tried to build it last year and got far enough to decide to wait before trying again. Not sure how far you went.

Re: Jetson Nano BSP

Hi Prakhar, On 2/23/23 20:23, Prakhar Agrawal wrote: I completely agree with all your points, but my rationale for introducing the jetson nano or jetson AGX orin was because of their GPU power. it's really nice what Nvidia achieved here, right? Unfortunately this GPU potential is fully lock

Re: warnings report on builder wrong?

On 2/14/23 05:34, Chris Johns wrote: On 14/2/2023 10:47 am, Joel Sherrill wrote: Chris.. see below On Mon, Feb 13, 2023 at 5:42 PM Karel Gardas wrote: On 2/14/23 00:33, Joel Sherrill wrote: > With fresh tools on CentOS 7, I have 5 warnings in beaglebonewhite. Log > at

Re: warnings report on builder wrong?

On 2/14/23 00:33, Joel Sherrill wrote: With fresh tools on CentOS 7, I have 5 warnings in beaglebonewhite. Log attached. Sorry it took so long. I ran out of disk space, then got distracted. I have no idea why the rtems-bsp-builder isn't tripping these unless it isn't actually hitting the defa

warnings report on builder wrong?

Hello, looking into the last bsp-builder report here: https://lists.rtems.org/pipermail/build/2023-February/041799.html and I'm surprised by the fact that beaglebonewhile shows 0 warnings while I remember well to fix 3 warnings this weekend. I even rerun build just a minute ago and they

[PATCH] bsps/stm32h7: fix compilation failure of stm32h757i-eval-m4 BSP

--- spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml index 5e9819a308..fc15630c93 100644 --- a/spec/build/bsps

[PATCH 3/3] bsps/beagle: fix warning on possibly uninitialized clock control in pwmss.

--- bsps/arm/beagle/pwmss/pwmss.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/bsps/arm/beagle/pwmss/pwmss.c b/bsps/arm/beagle/pwmss/pwmss.c index 0fde3db5a9..f3aaf8fc3f 100644 --- a/bsps/arm/beagle/pwmss/pwmss.c +++ b/bsps/arm/beagle/pwmss/pwmss.c @@ -38,7 +38,7

[PATCH 1/3] bsps/beagle: do not set values already set by spec file(s).

The patch fixes few symbol already defined warnings here. --- bsps/arm/beagle/include/bsp.h | 10 -- 1 file changed, 10 deletions(-) diff --git a/bsps/arm/beagle/include/bsp.h b/bsps/arm/beagle/include/bsp.h index 58c7a8850a..a5c9bc0459 100644 --- a/bsps/arm/beagle/include/bsp.h +++ b/bsp

[PATCH 2/3] bsps/beagle: fix warning on missing cast

--- bsps/arm/beagle/start/bspstart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/arm/beagle/start/bspstart.c b/bsps/arm/beagle/start/bspstart.c index 83138f29dd..1a3593a6f8 100644 --- a/bsps/arm/beagle/start/bspstart.c +++ b/bsps/arm/beagle/start/bspstart.c @@ -121,7 +

Re: [PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals

On 2/6/23 05:16, Chris Johns wrote: + * A lot of different hardware uses LibBSD as network or USB stack or maybe in + the future even only for other subsystems. Some of the targets have + hundreds of megabytes memory. Others can only have a few megabytes (like + the ATSAMV71). M

Re: libbsd development policy clarification needed?

Hello Christian, On 2/3/23 07:24, Christian MAUDERER wrote: If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html oh, I've seen that and ignored so far not knowing this will bite

libbsd development policy clarification needed?

Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project:

[PATCH] fix DHCPCD link

--- README.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.rst b/README.rst index 9b328078..4d81f8de 100644 --- a/README.rst +++ b/README.rst @@ -331,7 +331,7 @@ The following features are available in LibBSD. Some features need device driver support for a particu

Re: Question w.r.t. crash inside select call from libbsd.

On 1/31/23 07:30, Sebastian Huber wrote: so with zone being NULL the crash is expected here. However I'm still curious if this is libbsd issue or my issue with naive configuration? Did you use select() before libbsd is initialized? Do you have more than 64 file descriptors? In this case the fd

  1   2   3   4   >