Re: Naming convention for Rust target platforms

[Karel Gardas]

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 
here the current list: 
https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3).
The Rust ARM targets usually have the instruction set version and ABI as part 
of the name, e.g. armv7a-none-eabihf.
In RTEMS the arm-rtems6-gcc covers all supported ARM versions and different 
ABIs (i.e. hard-float or soft-float) collectively.

So, for the Zynq and similar BSPs this would yield for the Rust target 
something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
Similarly, for other ARM BSPs additional Rust targets would need to be added. 
Which might add up to quite a  number of Rust targets over time.
Is this fine or do you see another solution?


As I wrote in reply to Frank. I would go with 'armv7-rtems-eabi/hf' 
here. I'm not even sure about eabi/hf thing. Do you know about any armv7 
target *supported* by RTEMS which does not provide FPU? If not, then 
waiting/mentally allocating 'eabi' and hurting others with a need to 
type 'eabihf' for this case does not make sense and I would strip 
'eabihf' too...


Thanks,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Naming convention for Rust target platforms

[Karel Gardas]

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 
correct when it is based on RTEMS? For example, a Linux target would be 
"x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.


This is not completely fair to Jan as the x86_64 example is quite the 
exception instead of a common norm in rust platforms names. But you 
started with Linux so let's continue with Linux -- see the listing below.


Also IMHO this convention is not about rust per se, but IMHO about LLVM 
way of doing things. GCC does that differently. So no C vs Rust, but GCC 
vs. LLVM. Once Rust in GCC happen it'll be done in GCC more RTEMS used 
way probably...


So for Rust/LLVM I think Jan's proposal is about right except that I 
would strip '6' from rtems6. Neither OS (Linux, FreeBSD, NetBSD, 
Windows, OpenBSD, VxWorks, etc) uses any version notion in the OS name 
anyway... And also would strip 'a' from arm7a. We do not need to mention 
'a' here explicitly since for 'm' we do have whole family of 'thumb*' 
platform names... E.g. VxWorks in this particular case (ARMv7-A) uses: 
armv7-wrs-vxworks-eabihf



Cheers,
Karel



$ rustc --print target-list|grep linux
aarch64-linux-android
aarch64-unknown-linux-gnu
aarch64-unknown-linux-gnu_ilp32
aarch64-unknown-linux-musl
aarch64-unknown-linux-ohos
aarch64_be-unknown-linux-gnu
aarch64_be-unknown-linux-gnu_ilp32
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armeb-unknown-linux-gnueabi
armv4t-unknown-linux-gnueabi
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv5te-unknown-linux-uclibceabi
armv7-linux-androideabi
armv7-unknown-linux-gnueabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabi
armv7-unknown-linux-musleabihf
armv7-unknown-linux-ohos
armv7-unknown-linux-uclibceabi
armv7-unknown-linux-uclibceabihf
csky-unknown-linux-gnuabiv2
hexagon-unknown-linux-musl
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-linux-android
i686-unknown-linux-gnu
i686-unknown-linux-musl
loongarch64-unknown-linux-gnu
m68k-unknown-linux-gnu
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips-unknown-linux-uclibc
mips64-openwrt-linux-musl
mips64-unknown-linux-gnuabi64
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-gnuabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
mipsel-unknown-linux-uclibc
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
powerpc-unknown-linux-gnu
powerpc-unknown-linux-gnuspe
powerpc-unknown-linux-musl
powerpc64-unknown-linux-gnu
powerpc64-unknown-linux-musl
powerpc64le-unknown-linux-gnu
powerpc64le-unknown-linux-musl
riscv32gc-unknown-linux-gnu
riscv32gc-unknown-linux-musl
riscv64-linux-android
riscv64gc-unknown-linux-gnu
riscv64gc-unknown-linux-musl
s390x-unknown-linux-gnu
s390x-unknown-linux-musl
sparc-unknown-linux-gnu
sparc64-unknown-linux-gnu
thumbv7neon-linux-androideabi
thumbv7neon-unknown-linux-gnueabihf
thumbv7neon-unknown-linux-musleabihf
x86_64-linux-android
x86_64-unikraft-linux-musl
x86_64-unknown-linux-gnu
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl
x86_64-unknown-linux-ohos

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 results are based on what I
have working:

Builds:

   Sonoma
   Montery
   Big Sur

Fails:

   Ventura

The failure on Ventura is in GMP called from MPFR. Running the GMP tests a
number fail and removing --disable-shared improves the test results but GCC does
not build. I have not looked any further.


Just a rant.

IIRC when Ventura cames it was a disaster for RSB since on Monterey this 
worked and on Ventura it stopped. IIRC less RAM on system shows more 
sensibility to Ventura problems. And IIRC you were the person who solved 
this somehow.
Does this mean we're back to the original state with Ventura making 
troubles again? I'm not sure if this is even technically possible 
(partly due to how Apple supports OS reverts) to test every version of 
Ventura released by Apple to see reliably if whole family is sick or 
there are some versions which may be recommended for use. E.g. Ventura 
spans from 13.0 to 13.5 already...

Perhaps doable on VM...

Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

  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 microelectronics. And ST is still actively playing with this 
family. E.g. the SPC564 is still equipped with the eTPU. So the legend 
lives on ;-)


indeed, but even ST Micro probably plans to migrate their customers 
slowly to their brand new ARM-based chips for automotive: Stellar 32-bit 
Automotive MCUs [1]. Although I must add that "Longetivity" is extended 
to 20 years for your mentioned SPC56x, whatever that means exactly...


Anyway, I'm afraid, sun is setting on PPC even in automotive business...

Cheers,
Karel

[1]: 
https://www.st.com/en/automotive-microcontrollers/stellar-32-bit-automotive-mcus.html

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 |  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.cfg
new file mode 100644
index 000..b9cd278
--- /dev/null
+++ b/bare/config/textproc/gsed-4.9.cfg
@@ -0,0 +1,12 @@
+#
+# GNU sed 4.8
+#
+
+%include %{_configdir}/base.cfg
+
+%define gsed_version 4.9
+
+%hash sha512 sed-%{gsed_version}.tar.gz \
+   
a474390ff34fe41dea6c97855493d3674bf754387024630ac3b704264810e7d33ecbf957f9e903f0c4474522d7c27276cc861b9c8d8b6eedcfa253a6d7f3af9c
+
+%include %{_configdir}/gsed-1.cfg
diff --git a/bare/config/textproc/gsed.cfg b/bare/config/textproc/gsed.cfg
index 8287c74..68d8b40 100644
--- a/bare/config/textproc/gsed.cfg
+++ b/bare/config/textproc/gsed.cfg
@@ -4,5 +4,5 @@
  #
  %define has_gnu_sed %(sed --version > /dev/null 2>&1; echo $?)
  %if %{has_gnu_sed} != 0
- %include %{_configdir}/textproc/gsed-4.8.cfg
+ %include %{_configdir}/textproc/gsed-4.9.cfg
  %endif


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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.cfg
new file mode 100644
index 000..b9cd278
--- /dev/null
+++ b/bare/config/textproc/gsed-4.9.cfg
@@ -0,0 +1,12 @@
+#
+# GNU sed 4.8
+#
+
+%include %{_configdir}/base.cfg
+
+%define gsed_version 4.9
+
+%hash sha512 sed-%{gsed_version}.tar.gz \
+   
a474390ff34fe41dea6c97855493d3674bf754387024630ac3b704264810e7d33ecbf957f9e903f0c4474522d7c27276cc861b9c8d8b6eedcfa253a6d7f3af9c
+
+%include %{_configdir}/gsed-1.cfg
diff --git a/bare/config/textproc/gsed.cfg b/bare/config/textproc/gsed.cfg
index 8287c74..68d8b40 100644
--- a/bare/config/textproc/gsed.cfg
+++ b/bare/config/textproc/gsed.cfg
@@ -4,5 +4,5 @@
 #
 %define has_gnu_sed %(sed --version > /dev/null 2>&1; echo $?)
 %if %{has_gnu_sed} != 0
- %include %{_configdir}/textproc/gsed-4.8.cfg
+ %include %{_configdir}/textproc/gsed-4.9.cfg
 %endif
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Karel Gardas]

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 tickets give 
me any hope on it. Hence asking directly.


Thanks!
Karel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

On 8/1/23 16:12, Joel Sherrill wrote:

Yes, go ahead.



Thanks,


But would it be more useful it the report included a hash?


Of course, but this is single-liner right?
Depending on what you like:

- git log -n 1
- git log -n 1|grep "^commit"|cut -d ' ' -f 2-

Karel



On Tue, 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/pipermail/devel/2023-July/076043.html
<https://lists.rtems.org/pipermail/devel/2023-July/076043.html>

If you ok that, I may push...

Thanks,
Karel


On 8/1/23 15:55, Joel Sherrill wrote:
 >
 > I think this started before the fix was pushed but since there is no
 > hash in this report, it is impossible to be sure.
 >
 > Since it already has to know about the rtems source tree, could it
 > include a hash? How hard is that to implement?
 >
 > --joel
 > -- Forwarded message -
 > From: *OAR Tester for CentOS 7* mailto:rtems-tes...@oarcorp.com>
 > <mailto:rtems-tes...@oarcorp.com <mailto:rtems-tes...@oarcorp.com>>>
 > Date: Tue, Aug 1, 2023 at 5:24 AM
 > Subject: [rtems-bsp-builder] 2023-07-31 17:37:34: Profile(s):
everything
 > To: mailto:bu...@rtems.org>
<mailto:bu...@rtems.org <mailto:bu...@rtems.org>>>
 >
 >
 > RTEMS Tools Project - RTEMS Kernel BSP Builder, 6.0.not_released
 > 
 >
 > Host: #1 SMP Tue Jun 20 11:48:01 UTC 2023
 >
 > command: /home/tester/rtems-cron-6/tools/6/bin/rtems-bsp-builder\
 >           --rtems=/home/tester/rtems-cron-6/rtems
--build-path=/home/tester\
 >           /rtems-cron-6/build --prefix=/home/tester/rtems-\
 >           cron-6/tools/6/bsps --log=/home/tester/rtems-cron-6/bsp-\
 >           builder.log --warnings-report=warnings.log --mail
--use-gitconfig\
 >           --profiles=everything
 >
 > Total Time            : 6:57:10.027015 for 1298 completed job(s)
 > Average BSP Build Time: 0:00:19.283533
 >
 > Builds
 > ==
 >   debug
 >   no-posix
 >   posix
 >   posix-debug
 >   posix-profiling
 >   profiling
 >   smp
 >   smp-debug
 >
 > Failures Report
 > ===
 >     1 debug arm/beagleboardorig build:
 >        configure: /home/tester/rtems-cron-6/rtems/waf configure\
 >        --prefix=/home/tester/rtems-cron-6/tools/6/bsps
--top=/home/tester\
 >        /rtems-cron-6/rtems
--rtems-config=config-arm-beagleboardorig-\
 >        debug.ini
 >       error:
home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
 >              fatal error: dev/can/can.h: No such file or directory
 >       error:
home/tester/bsps/arm/beagle/dcan/am335x-dcan.c:37:10: fatal
 >              error: dev/can/can.h: No such file or directory
 >
 >     2 no-posix arm/beagleboardorig build:
 >        configure: /home/tester/rtems-cron-6/rtems/waf configure\
 >        --prefix=/home/tester/rtems-cron-6/tools/6/bsps
--top=/home/tester\
 >        /rtems-cron-6/rtems
--rtems-config=config-arm-beagleboardorig-no-\
 >        posix.ini
 >       error:
home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
 >              fatal error: dev/can/can.h: No such file or directory
 >
 >     3 posix arm/beagleboardorig build:
 >        configure: /home/tester/rtems-cron-6/rtems/waf configure\
 >        --prefix=/home/tester/rtems-cron-6/tools/6/bsps
--top=/home/tester\
 >        /rtems-cron-6/rtems
--rtems-config=config-arm-beagleboardorig-\
 >        posix.ini
 >       error:
home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
 >              fatal error: dev/can/can.h: No such file or directory
 >
 >     4 posix-debug arm/beagleboardorig build:
 >        configure: /home/tester/rtems-cron-6/rtems/waf configure\
 >        --prefix=/home/tester/rtems-cron-6/tools/6/bsps
--top=/home/tester\
 >        /rtems-cron-6/rtems
--rtems-config=config-arm-beagleboardorig-posix-\
 >        debug.ini
 >       error:
home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
 >              fatal error: dev/can/can.h: No such file or directory
 >
 >     5 posix-profiling arm/beagleboardorig build:
 >        configure: /home/tester/rtems-cron-6/rtems/waf configure\
 >        -

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

[Karel Gardas]

  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/23 15:55, Joel Sherrill wrote:


I think this started before the fix was pushed but since there is no 
hash in this report, it is impossible to be sure.


Since it already has to know about the rtems source tree, could it 
include a hash? How hard is that to implement?


--joel
-- Forwarded message -
From: *OAR Tester for CentOS 7* >

Date: Tue, Aug 1, 2023 at 5:24 AM
Subject: [rtems-bsp-builder] 2023-07-31 17:37:34: Profile(s): everything
To: mailto:bu...@rtems.org>>


RTEMS Tools Project - RTEMS Kernel BSP Builder, 6.0.not_released


Host: #1 SMP Tue Jun 20 11:48:01 UTC 2023

command: /home/tester/rtems-cron-6/tools/6/bin/rtems-bsp-builder\
          --rtems=/home/tester/rtems-cron-6/rtems --build-path=/home/tester\
          /rtems-cron-6/build --prefix=/home/tester/rtems-\
          cron-6/tools/6/bsps --log=/home/tester/rtems-cron-6/bsp-\
          builder.log --warnings-report=warnings.log --mail --use-gitconfig\
          --profiles=everything

Total Time            : 6:57:10.027015 for 1298 completed job(s)
Average BSP Build Time: 0:00:19.283533

Builds
==
  debug
  no-posix
  posix
  posix-debug
  posix-profiling
  profiling
  smp
  smp-debug

Failures Report
===
    1 debug arm/beagleboardorig build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardorig-\
       debug.ini
      error: home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
             fatal error: dev/can/can.h: No such file or directory
      error: home/tester/bsps/arm/beagle/dcan/am335x-dcan.c:37:10: fatal
             error: dev/can/can.h: No such file or directory

    2 no-posix arm/beagleboardorig build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardorig-no-\
       posix.ini
      error: home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
             fatal error: dev/can/can.h: No such file or directory

    3 posix arm/beagleboardorig build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardorig-\
       posix.ini
      error: home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
             fatal error: dev/can/can.h: No such file or directory

    4 posix-debug arm/beagleboardorig build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardorig-posix-\
       debug.ini
      error: home/tester/bsps/arm/beagle/include/bsp/am335x_dcan.h:42:10:
             fatal error: dev/can/can.h: No such file or directory

    5 posix-profiling arm/beagleboardorig build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardorig-posix-\
       profiling.ini
      error: home/tester/bsps/arm/beagle/dcan/am335x-dcan.c:37:10: fatal
             error: dev/can/can.h: No such file or directory

    6 profiling arm/beagleboardorig build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardorig-\
       profiling.ini
      error: home/tester/bsps/arm/beagle/dcan/am335x-dcan.c:37:10: fatal
             error: dev/can/can.h: No such file or directory

    7 debug arm/beagleboardxm build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardxm-\
       debug.ini
      error: home/tester/bsps/arm/beagle/dcan/am335x-dcan.c:37:10: fatal
             error: dev/can/can.h: No such file or directory

    8 no-posix arm/beagleboardxm build:
       configure: /home/tester/rtems-cron-6/rtems/waf configure\
       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
       /rtems-cron-6/rtems --rtems-config=config-arm-beagleboardxm-no-\
       posix.ini
      error: home/tester/bsps/arm/beagle/dcan/am335x-dcan.c:37:10: fatal
             

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

[Karel Gardas]

  Folks,

this patch revert was missing in Gedare's series of reverting CAN-based 
patches in preparation for RTEMS 6 release. Due to this all beagleboard 
based BSPs fail to build due to error like:


Failures:
   1 debug arm/beagleboardorig build:
  configure: /export/home/rtems/git/rtems/ACTIVE_ZONE/stm32h7-new-\
  hal/waf configure --prefix=/tmp/rtems-test.1033228\
  --top=/export/home/rtems/git/rtems/ACTIVE_ZONE/stm32h7-new-hal\
  --rtems-config=config-arm-beagleboardorig-debug.ini
 error: export/home/rtems/git/bsps/arm/beagle/dcan/am335x-
dcan.c: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/dcan.c   |  646 --
  bsps/arm/beagle/dcan/hw_cm_per.h  | 1407 ---
  bsps/arm/beagle/dcan/hw_dcan.h| 1289 ---
  bsps/arm/beagle/include/bsp/am335x_dcan.h |  106 -
  .../beagle/include/bsp/hw_control_AM335x.h| 7794 -
  bsps/arm/beagle/include/bsp/soc_AM335x.h  |  206 -
  spec/build/bsps/arm/beagle/obj.yml|2 -
  8 files changed, 11554 deletions(-)
  delete mode 100644 bsps/arm/beagle/dcan/am335x-dcan.c
  delete mode 100644 bsps/arm/beagle/dcan/dcan.c
  delete mode 100755 bsps/arm/beagle/dcan/hw_cm_per.h
  delete mode 100755 bsps/arm/beagle/dcan/hw_dcan.h
  delete mode 100644 bsps/arm/beagle/include/bsp/am335x_dcan.h
  delete mode 100755 bsps/arm/beagle/include/bsp/hw_control_AM335x.h
  delete mode 100755 bsps/arm/beagle/include/bsp/soc_AM335x.h


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Pushing to 6.1

[Karel Gardas]

  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 closing some previous tickets.


+ 32 in progress
+ 10 new

I do not know if the milestone for any of these can be changed but we 
need to work on this.


Please look through the tickets and see if you can resolve any or think 
it should not be included as a blocker for 6.1. It could be moved to 
6.2, 7.1, or indefinite.


Resolution is better than bumping the milestone.

We need to get this out. It has been "almost ready" for probably over 
a year now.


Please and thank you.

--joel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] eng: add Apache License 2.0 restriction

[Karel Gardas]

---
 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 +98,33 @@ these guidelines:
 * Advertising obligations are not acceptable.
 
 * Some license restrictions may be permissible. These will be considered
-  on a case-by-case basis.
+  on a case-by-case basis. See below for a list of such restrictions.
 
 In practice, these guidelines are not hard to follow. Critically,
 they protect the freedom of the RTEMS source code and that of end users
 to select the license and distribution terms they prefer for their
 RTEMS-based application.
+
+License restrictions
+
+
+* Apache License 2.0 in section 4 (b) requires modified files to carry
+  prominent notice about performed modification. In case you modify such
+  file and the notice is not there yet you are required to put notice
+  below at the top of the modified file. If the notice is already
+  there you don't need to add it second time.
+  The notice should look:
+
+  .. code-block:: c
+
+ /*
+  * The file was modified by RTEMS contributors.
+  */
+
+ .. warning:: Do not import any project or files covered by the Apache
+  License 2.0 into the RTEMS project source tree without
+  discussing first with developers on the mailing list!
+  Handling of Apache License 2.0 projects is a bit
+  sensitive manner and RTEMS project is not prepared to
+  handle one kind of those projects yet. E.g. the projects
+  with NOTICE file present in the source tree.
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] eng: add Apache License 2.0 restriction

[Karel Gardas]

---
 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 @@ these guidelines:
 * Advertising obligations are not acceptable.
 
 * Some license restrictions may be permissible. These will be considered
-  on a case-by-case basis.
+  on a case-by-case basis. See below for a list of such restrictions.
 
 In practice, these guidelines are not hard to follow. Critically,
 they protect the freedom of the RTEMS source code and that of end users
 to select the license and distribution terms they prefer for their
 RTEMS-based application.
+
+License restrictions
+
+
+* Apache License 2.0 in section 4 (b) requires modified files to carry
+  prominent notice about performed modification. In case you modify such
+  file and the notice is not there yet you are required to put notice
+  below at the top of the modified file. If the notice is already
+  there you don't need to add it second time.
+  The notice should look:
+
+  .. code-block:: c
+
+ /*
+  * The file was modified by RTEMS contributors.
+  */
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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/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 GCC diagnostic ignored "-Wsign-conversion"
  #pragma GCC diagnostic ignored "-Wconversion"
  #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
  /* Fallback for __has_builtin */
  #ifndef __has_builtin
    #define __has_builtin(x) (0)


I would disable this warning only in __cmsis_start() with a push/pop 
pragma.


Done!

Ideally, the guidelines would be in the RTEMS Software Engineering 
manual before we added the Apache 2.0 files. We should avoid that every 
contributor has to figure out what to do. I you think that this 
__rtems__ stuff is enough, then just document it. Zephyr for example has 
a clear process to add new licenses:


https://docs.zephyrproject.org/latest/contribute/external.html


Indeed, but we're not living in ideal world unfortunately. Zephyr is 
completely different league in terms of man-power available to the 
project. We need to live with what we have.


Anyway, I've submitted new version of the patch and hopefully also be 
more compliant with the terms of the Apache 2.0 license.


Thanks!
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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 was modified by RTEMS contributors.
+ */
 /**//**
  * @file cmsis_gcc.h
  * @briefCMSIS compiler GCC header file
@@ -136,6 +139,10 @@
  */
 __STATIC_FORCEINLINE __NO_RETURN void __cmsis_start(void)
 {
+#ifdef __rtems__
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
   extern void _start(void) __NO_RETURN;
 
   typedef struct __copy_table {
@@ -154,6 +161,10 @@ __STATIC_FORCEINLINE __NO_RETURN void __cmsis_start(void)
   extern const __zero_table_t __zero_table_start__;
   extern const __zero_table_t __zero_table_end__;
 
+#ifdef __rtems__
+#pragma GCC diagnostic pop
+#endif /* __rtems__ */
+
   for (__copy_table_t const* pTable = &__copy_table_start__; pTable < 
&__copy_table_end__; ++pTable) {
 for(uint32_t i=0u; iwlen; ++i) {
   pTable->dest[i] = pTable->src[i];
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] import Apache License 2.0 text file

[Karel Gardas]

---
 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,0 +1,202 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf of, the
+  Licensor for the purpose of discussing and improving the Work, but
+  excluding communication that is conspicuously marked or otherwise
+  designated in writing by the copyright owner as "Not a Contribution."
+
+  "Contributor" shall mean Licensor and any individual or Legal Entity
+  on behalf of whom a Contribution has been received by Licensor and
+  subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+  this License, each Contributor hereby grants to You a perpetual,
+  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+  copyright license to reproduce, prepare Derivative Works of,
+  publicly display, publicly perform, sublicense, and distribute the
+  Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+  this License, each Contributor hereby grants to You a perpetual,
+  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+  (except as stated in this section) patent license to make, have made,
+  use, offer to sell, sell, import, and otherwise transfer the Work,
+  where such license applies only to those patent claims licensable
+  by such Contributor that are necessarily infringed by their
+  Contribution(s) alone or by combination of their Contribution(s)
+  with the Work to which such Contribution(s) was submitted. If You
+  institute patent litigation against 

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

[Karel Gardas]

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/arm/include/cmsis_gcc.h
+++ b/bsps/arm/include/cmsis_gcc.h
@@ -30,7 +30,9 @@
  #pragma GCC diagnostic ignored "-Wsign-conversion"
  #pragma GCC diagnostic ignored "-Wconversion"
  #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
  /* Fallback for __has_builtin */
  #ifndef __has_builtin
    #define __has_builtin(x) (0)


I would disable this warning only in __cmsis_start() with a push/pop 
pragma.


Will look into it. The way it was done was to reuse as much as possible 
of the current file infrastructure.



I think you have to add also a

  * Modifications Copyright (C) Karel Gardas

if you change the file, see also:


It's a shame to need to copyright single liners. IMHO license does not 
require that precisely. What about to just add:


/* The file was modified for the purposes of RTEMS project */

right at the beginning (1st line) of file?


https://softwareengineering.stackexchange.com/questions/220068/file-with-apache-2-0-and-my-modifications

In general, some advice for dealing with Apache 2.0 files in the RTEMS 
Software Engineering manual would be nice.


That would be great to have, but who would do that? Or perhaps we may 
distill right behavioral patterns from our competitors: Zephyr/NuttX?


E.g. 
https://github.com/apache/nuttx/commits/master/net/tcp/tcp_getsockopt.c 
-- file modified by several persons and none is mentioned (do all of 
them have signed contributor agreement with ASF?)


and

https://github.com/zephyrproject-rtos/zephyr/commits/main/kernel/paging/statistics.c 
-- file modified by jfisher-no (from Nordic Semiconductor) and yet, file 
clearly copyrighted by Intel and no message about modification by anyone 
else.


Another idea my be to go with what Joel suggested in the original 
CMSISv5 inclusion thread: put any modification into #ifdef __rtems__ / 
#endif and make that clearly visible that file was changed this way. 
Nothing more needed...


Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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


Given that, I now understand the confusion. I have a board in hand that 
will never see an upstream BSP and I was hoping to be able to configure 
the base STM32H7 BSP for it, but what I interpreted as the "base" 
STM32H7 BSP is not actually a generic base BSP. I was also contemplating 
moving more of the peripheral configuration into shared files since the 
enable/disable configuration items are already there and it would be 
convenient for the various BSPs to exist as some custom code and then a 
selection of presets for those configuration items. I'll have to think 
about the best way forward for the project I'm working with.


I guess the philosophy in stm32h7 is to avoid cpp directives even in 
case of a bit more code duplication.


So if I may ask, just copy board directory structure, name it after your 
board and tweak the copied files there. No need to #ifdefing in 
different board which would not use that.


And btw, I'm using the same for Precidata SL-3011 (board on market, but 
BSP and firmware not ready for RTEMS 6, will be submitted for RTEMS 7 
probably) and for Arduino Portenta H7 (ditto but even less mature codewise).


Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

Hello Christian,

the patch fixing warnings is already submitted for review.

https://lists.rtems.org/pipermail/devel/2023-July/075881.html

Thanks,
Karel

On 7/25/23 12:07, Christian MAUDERER wrote:

Hello Karel,

I tested with the patch from Chris (which is identical to yours) and I 
have no problems building and installing the imx7, imxrt1052 and 
imxrt1166-cm7-saltshaker BSP and libbsd from master for these BSPs.


The only point that I have noted are a lot of new warnings when building 
the BSP. Example:


../../../../../rtems-sources/rtems/bsps/arm/include/cmsis_gcc.h:139:15: 
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,
Karel

On 7/25/23 03:34, Chris Johns wrote:

Hi Karel,

I did not see this and made and pushed a similar patch. Thanks for 
this and

sorry for not checking closely as I missed it on the 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/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -10,12 +10,13 @@ includes: []
  install:
  - destination: ${BSP_INCLUDEDIR}
    source:
+  - bsps/arm/include/cachel1_armv7.h
+  - bsps/arm/include/cmsis_compiler.h
    - bsps/arm/include/cmsis_gcc.h
+  - bsps/arm/include/cmsis_version.h
    - bsps/arm/include/core_cm7.h
    - bsps/arm/include/core_cm4.h
-  - bsps/arm/include/core_cmFunc.h
-  - bsps/arm/include/core_cmInstr.h
-  - bsps/arm/include/core_cmSimd.h
+  - bsps/arm/include/mpu_armv7.h
    - bsps/arm/include/uart.h
  - destination: ${BSP_INCLUDEDIR}/bsp
    source:


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

Sure! Not a problem, I was just waiting for Christian to confirm its 
also working on his side.


Thanks,
Karel

On 7/25/23 03:34, Chris Johns wrote:

Hi Karel,

I did not see this and made and pushed a similar patch. Thanks for this and
sorry for not checking closely as I missed it on the 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/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -10,12 +10,13 @@ includes: []
  install:
  - destination: ${BSP_INCLUDEDIR}
source:
+  - bsps/arm/include/cachel1_armv7.h
+  - bsps/arm/include/cmsis_compiler.h
- bsps/arm/include/cmsis_gcc.h
+  - bsps/arm/include/cmsis_version.h
- bsps/arm/include/core_cm7.h
- bsps/arm/include/core_cm4.h
-  - bsps/arm/include/core_cmFunc.h
-  - bsps/arm/include/core_cmInstr.h
-  - bsps/arm/include/core_cmSimd.h
+  - bsps/arm/include/mpu_armv7.h
- bsps/arm/include/uart.h
  - destination: ${BSP_INCLUDEDIR}/bsp
source:


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

 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 added 
support for nucleo with h743zi and Robin Mueller fixed several things on 
that. So this was 2 boards supported. Then I came and added support for 
3 more boards where two was with 2 BSPs variants each (one for M7 and 
one for M4). Due to amount of code in #ifdef for various boards we (my 
customer and me) have decided to de-cpp code a bit and divide it into 
different supported board directories. Basically we have also followed a 
lead by embedded brains guys and their imxrt bsps family (and boards 
directory). This was accepted and now you have this boards directory 
with different boards providing just as lean as possible configuration 
in C files sharing some common generic in bspstarthooks.c from start 
subdirectory.


So basically the idea was to avoid complex #ifdefs and rather copy clean 
C files around. (as much as possible, realistically).


Now, your patch seems to be going a bit in reverse direction and I do 
not see clearly the motivation behind it, why do you do that this way?


I mean, you edit peripherals clock for stm32h743-eval(2) board BSP. 
AFAIK this file is not reused on any other BSP variant (different board) 
at all.
The board in question (stm32h743-eval) supports only UART1 on its 
ST-Link or DB-9 canon connection. The UART1 is shared between those two 
mechanisms, which one is used, you define by jumper placed on the board. 
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 heading...


Thanks!
Karel



On 7/24/23 20:28, Kinsey Moore wrote:

This change allows configuration of all enabled UART clocks without
direct modificaton of the exiting BSP.
---
  .../stm/stm32h743i-eval/stm32h7-config-per.c  | 41 +--
  1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
index 8ca665915f..dcce247a51 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
@@ -32,9 +32,34 @@
  #include 
  
  const RCC_PeriphCLKInitTypeDef stm32h7_config_peripheral_clocks = {

-  .PeriphClockSelection = RCC_PERIPHCLK_RTC | RCC_PERIPHCLK_USART3
-| RCC_PERIPHCLK_FDCAN | RCC_PERIPHCLK_USART1 | RCC_PERIPHCLK_I2C1
-| RCC_PERIPHCLK_USB | RCC_PERIPHCLK_FMC | RCC_PERIPHCLK_RNG,
+  .PeriphClockSelection = RCC_PERIPHCLK_RTC
+| RCC_PERIPHCLK_FDCAN | RCC_PERIPHCLK_I2C1
+| RCC_PERIPHCLK_USB | RCC_PERIPHCLK_FMC | RCC_PERIPHCLK_RNG
+#ifdef STM32H7_CONSOLE_ENABLE_USART1
+| RCC_PERIPHCLK_USART1
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART2
+| RCC_PERIPHCLK_USART2
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART3
+| RCC_PERIPHCLK_USART3
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART4
+| RCC_PERIPHCLK_UART4
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART5
+| RCC_PERIPHCLK_UART5
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART6
+| RCC_PERIPHCLK_USART6
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART7
+| RCC_PERIPHCLK_UART7
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART8
+| RCC_PERIPHCLK_UART8
+#endif
+  ,
.PLL2.PLL2M = 3,
.PLL2.PLL2N = 48,
.PLL2.PLL2P = 1,
@@ -53,8 +78,18 @@ const RCC_PeriphCLKInitTypeDef 
stm32h7_config_peripheral_clocks = {
.PLL3.PLL3FRACN = 0,
.FmcClockSelection = RCC_FMCCLKSOURCE_PLL2,
.FdcanClockSelection = RCC_FDCANCLKSOURCE_PLL,
+#if defined(STM32H7_CONSOLE_ENABLE_USART2) \
+  || defined(STM32H7_CONSOLE_ENABLE_USART3) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART4) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART5) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART7) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART8)
.Usart234578ClockSelection = RCC_USART234578CLKSOURCE_D2PCLK1,
+#endif
+#if defined(STM32H7_CONSOLE_ENABLE_USART1) \
+  || defined(STM32H7_CONSOLE_ENABLE_USART6)
.Usart16ClockSelection = RCC_USART16CLKSOURCE_D2PCLK2,
+#endif
.I2c123ClockSelection = RCC_I2C123CLKSOURCE_D2PCLK1,
.UsbClockSelection = RCC_USBCLKSOURCE_PLL3,
.RTCClockSelection = RCC_RTCCLKSOURCE_LSE,


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 
which is not supported by RTEMS due to missing MCU support in old HAL 
code. I submitted new HAL patches last week but they are not in yet. So 
if this is not company secrete let me ask, what board you are using with 
UART7 connection?


Thanks,
Karel

On 7/24/23 20:28, Kinsey Moore wrote:

This change allows for the pins assigned to UART7 to be reconfigured via
config.ini.
---
  bsps/arm/stm32h7/console/console-uart7-cfg.c|  4 ++--
  spec/build/bsps/arm/stm32h7/grp.yml |  4 
  .../build/bsps/arm/stm32h7/optuart7gpiopins.yml | 17 +
  .../build/bsps/arm/stm32h7/optuart7gpioregs.yml | 17 +
  4 files changed, 40 insertions(+), 2 deletions(-)
  create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
  create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml

diff --git a/bsps/arm/stm32h7/console/console-uart7-cfg.c 
b/bsps/arm/stm32h7/console/console-uart7-cfg.c
index dca19e652d..2ced4cf9c2 100644
--- a/bsps/arm/stm32h7/console/console-uart7-cfg.c
+++ b/bsps/arm/stm32h7/console/console-uart7-cfg.c
@@ -33,9 +33,9 @@
  
  const stm32h7_uart_config stm32h7_uart7_config = {

.gpio = {
-.regs = GPIOB,
+.regs = STM32H7_UART7_GPIO_REGS,
  .config = {
-  .Pin = GPIO_PIN_3 | GPIO_PIN_4,
+  .Pin = STM32H7_UART7_GPIO_PINS,
.Mode = GPIO_MODE_AF_PP,
.Pull = GPIO_NOPULL,
.Speed = GPIO_SPEED_FREQ_LOW,
diff --git a/spec/build/bsps/arm/stm32h7/grp.yml 
b/spec/build/bsps/arm/stm32h7/grp.yml
index 595762c665..239df9b898 100644
--- a/spec/build/bsps/arm/stm32h7/grp.yml
+++ b/spec/build/bsps/arm/stm32h7/grp.yml
@@ -106,6 +106,10 @@ links:
uid: optusart3gpiopins
  - role: build-dependency
uid: optusart3gpioregs
+- role: build-dependency
+  uid: optuart7gpiopins
+- role: build-dependency
+  uid: optuart7gpioregs
  - role: build-dependency
uid: optvariant
  - role: build-dependency
diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml 
b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
new file mode 100644
index 00..0252bdab7c
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
@@ -0,0 +1,17 @@
+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 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: ( GPIO_PIN_3 | GPIO_PIN_4 )
+description: |
+  GPIO pins used for the UART7 pin configuration.
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_UART7_GPIO_PINS
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml 
b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
new file mode 100644
index 00..16ce3bf526
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
@@ -0,0 +1,17 @@
+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 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: GPIOB
+description: |
+  GPIO registers used for the UART7 pin configuration.
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_UART7_GPIO_REGS
+type: build


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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: []
 install:
 - destination: ${BSP_INCLUDEDIR}
   source:
+  - bsps/arm/include/cachel1_armv7.h
+  - bsps/arm/include/cmsis_compiler.h
   - bsps/arm/include/cmsis_gcc.h
+  - bsps/arm/include/cmsis_version.h
   - bsps/arm/include/core_cm7.h
   - bsps/arm/include/core_cm4.h
-  - bsps/arm/include/core_cmFunc.h
-  - bsps/arm/include/core_cmInstr.h
-  - bsps/arm/include/core_cmSimd.h
+  - bsps/arm/include/mpu_armv7.h
   - bsps/arm/include/uart.h
 - destination: ${BSP_INCLUDEDIR}/bsp
   source:
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 6: Use GDB 13.2

[Karel Gardas]

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 macOS. GBD from 7/rtems-* complains about 
missing libmpfr.


[...]
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... no
configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
Try the --with-gmp and/or --with-mpfr options to specify
their locations.  If you obtained GMP and/or MPFR from a vendor
distribution package, make sure that you have installed both the libraries
and the header files.  They may be located in separate packages.
shell cmd failed: /bin/sh -ex 
/usr/home/karel/git/rtems-source-builder/rtems/build/aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1/do-build

error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1

Obviusly gdb from 6/ does not hence there is probably some bit missing 
in 7/ which is already fixed in 6/


Thanks,
Karel

On 7/24/23 10:54, Sebastian Huber wrote:

Prepare for RTEMS 6.1 release.

Update #4921.
---
  rtems/config/6/rtems-default.bset |  2 +-
  rtems/config/6/rtems-microblaze.bset  |  2 +-
  rtems/config/tools/rtems-gdb-13.2.cfg | 17 +
  3 files changed, 19 insertions(+), 2 deletions(-)
  create mode 100644 rtems/config/tools/rtems-gdb-13.2.cfg

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index b1c81a0..4416c65 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -12,7 +12,7 @@
  %defineifnot with_rtems_dtc  devel/dtc-1.6.1-1
  %defineifnot with_rtems_expatdevel/expat-2.4.8-1
  %defineifnot with_rtems_gmp  devel/gmp-6.2.1
-%defineifnot with_rtems_gdb  tools/rtems-gdb-13.1
+%defineifnot with_rtems_gdb  tools/rtems-gdb-13.2
  %defineifnot with_rtems_binutils tools/rtems-binutils-2.39
  %defineifnot with_rtems_gcc  tools/rtems-gcc-12-newlib-head
  %defineifnot with_rtems_toolstools/rtems-tools-6
diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index 95fe17e..1870935 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -13,7 +13,7 @@
  
  devel/expat-2.4.8-1

  devel/gmp-6.2.1
-tools/rtems-gdb-13.1
+tools/rtems-gdb-13.2
  
  tools/rtems-xilinx-binutils-2.36

  tools/rtems-xilinx-gcc-10-newlib-head
diff --git a/rtems/config/tools/rtems-gdb-13.2.cfg 
b/rtems/config/tools/rtems-gdb-13.2.cfg
new file mode 100644
index 000..655ffe2
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-13.2.cfg
@@ -0,0 +1,17 @@
+#
+# GDB 13.2
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 13.2
+%define gdb_src_ext xz
+%hash sha512 gdb-%{gdb_version}.tar.xz \
+   
gYXT4Rq2Da//WGClAWV3v+fddUfvAevIZ7wkdgPYK3T/dMTylJLH0q7lcHb1K+M+KJ9Ma0FKS4cNSzAEkJ9MNA==
+
+%patch add gdb -p1 --rsb-file=gdb-14067-python-config.diff 
https://sourceware.org/bugzilla/attachment.cgi?id=14783=raw
+%hash sha512 gdb-14067-python-config.diff \
+   
HiCV0eQulk0W+G5uu1gCvUn5Ns6bF6RxqOO9kcSi8zpfEHOMzphlOv5cz0IDN5Q8m94na1kRVy++4z6qc43t3w==
+
+%include %{_configdir}/gdb-common-1.cfg


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 type issue due to not checking option type for presence of a field, 
e.g. python bites here -- hence type issue.


Anyway, I'll change that to typo as you prefer. :-)

Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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):
'configure RTEMS with --disable-networking')
 rtems_libbsd_path = conf.options.rtems_libbsd
 if rtems_libbsd_path is None:
-if conf.options.rtems is None:
-rtems_libbsd_path = conf.options.rtems
+if conf.options.rtems_path is not None:
+rtems_libbsd_path = conf.options.rtems_path
 else:
 rtems_libbsd_path = conf.env.PREFIX
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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 GCC diagnostic ignored "-Wsign-conversion"
 #pragma GCC diagnostic ignored "-Wconversion"
 #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
 /* Fallback for __has_builtin */
 #ifndef __has_builtin
   #define __has_builtin(x) (0)
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH series for review] STM32 H7 HAL update.

[Karel Gardas]

  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/rtems/commits/stm32h7-hal-update-2023-07

Few notes:

- part of HAL files got relicensed by STMicro from BSD-3 to Apache-2.0. 
Fortunately the project does not contain NOTICE file so we do not need 
to organize anything about it.

https://github.com/karelfv/rtems/commit/ec59116a2e8c1b637cc59d2ef619880ce507816e

- I've tried to apply all Sebastian's and Christian's patches done to 
original HAL. All is done except doxygenization patch which I needed to 
do completely new due to a lot of hunks aborting and also a lot of new 
occurrences where it should be applied.

https://github.com/karelfv/rtems/commit/04936e21b0daeaa43082c73919fbf3274e9482ca

- new HAL code breaks compilation of libbsd (for this particular 
platform! Not in general). This is due to inclusion of math.h. I've 
solved that by crude hack.

https://github.com/karelfv/rtems/commit/a1035ba3cee4dc6967bb978aa04ef763c9d2fcfd


Otherwise I hope the patch set is tolerable for RTEMS-6 as for RTEM-7 we 
plan to remove that code completely to a separate module anyway...


Thanks for review!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: HEADS UP: git repo WRONG push landed.

[Karel Gardas]

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.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 sorry for this mess...

Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

HEADS UP: git repo WRONG push landed.

[Karel Gardas]

  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 sorry for this mess...

Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Libbsd situation.

[Karel Gardas]

  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 to be EoLed soon, e.g. December 31, 
2023 as claimed on https://www.freebsd.org/security/#sup


(2) 6-freebsd-12 branch latest commit in freebsd-org is from Feb 9 
22:15:35 2020. Based on that it looks like 6-freebsd-12 branch is >6k 
commits behind the FreeBSD's stable/12 branch.


May this outage be solved by using libbsd master branch? It does not 
look like as:


(i) latest commit in freebsd-org in libbsd master branch is even older 
than in 6-freebsd-12 and it is from Sep 24 01:58:54 2019.


(ii) even if I consider Sebastian's own master-update branch available 
on his github.com account, it seem this branch synced with what is in 
6-freebsd-12 and ends exactly on 2020-02-09. So, it looks like master is 
also missing few thousands patches from FreeBSD development...


Anyway, my biggest worry is that RTEMS 6 libbsd may be based on source 
code which will lose upstream project support soon after the RTEMS 6 
release (assuming RTEMS 6 will happen before Dec 31 2023). So I'm 
curious if with all those outdatnes it would not be good to jump and 
update master which would be supported by another 5 years (assuming this 
is stable/14 branch).
E.g. the situation is exactly like with GCC where Sebastian clearly 
warned about it and project moved from 10 to 12 and now it looks like we 
will even move to GCC 13 release for RTEMS 6... Except that in case of 
libbsd it has not happened yet.


Am I missing something or is this really a situation with libbsd as of 
today?


Thanks!
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 really matter" worries me a little bit. I'm not sure 
this functionality is even supported hence my question above if you 
have tested it yourself.


Yes, I use that regularly. For an (old) example, take a look at a branch 
in the repo that I use to test GSoC work:


   https://gitlab.com/c-mauderer/rtems-bbb/-/tree/6

I have a libs/rtems-libbsd submodule there that uses the revision 
c9474c0b which is on a cm/20200726_fix branch in my clone of 
rtems-libbsd. In the .gitmodules the branch is still set to "master". 
Despite that, git can find thre right commit ID.


Cool! So it didn't work for me due to (i) my git bug or (ii) my git 
doesn't supporting whatever or simply due to (iii) me making silly 
mistake somewhere.


Will need to recheck this. Thanks for the info!

Karel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

  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 way. Yes, it is intended to 
remove CMSIS v4 *just* to proof compilation is working with CMSIS 5 from 
outside module! This is just dirty PoC nothing more. A tree structure 
looks a bit different as (folowing zephyr example) I keep modules 
outside the rtems tree. Hence result for west init command below is tree:


modules/hal/stm32h7/stm32h7xx_hal_driver
modules/hal/stm32h7/cmsis_device_h7
modules/hal/stm32h7/CMSIS_5
rtems/...


So if you like to see thing, then install west:

$ pip3 install --user west
$ export PATH=$PATH:$HOME/.local/bin

go into some testing directory and:

$ west init -m https://github.com/karelfv/rtems --mr 
rtems-west-stm32h7-hal rtems-workspace


$ cd rtems-workspace/
$ west update

Compilation again produces working samples. In comparison with git 
submodule approach I find west a bit more civilized (user friendly). 
Nothing is shooting in my own feet etc.


What may resonate in RTEMS devs is:

- yaml format for module configuration
- west implemented in python3
- west extensible

It probably will not be big issue to implement custom:

- west bsplist
- west bspdefaults
- west configure
- west build

which would just delegate to waf for actual work if needed...

Comments welcome!

Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 something 
similar.


Thanks for confirmation. Have the same feeling about it.

I think that depends heavily on how the upstream project works. If the 
upstream project uses a typical git workflow and is quite active, 
merging is most likely the better solution because we don't get big 
amounts of branches with that.


But this means we still merge to some rtems specific branch since master 
is used to sync with upstream, right?


On the other hand I know that some semiconductor manufacturers tend to 
just dump code into a repo and they don't care whether files move around 
or change heavily. They happily mix changes with reformatting the 
complete code. In that case you have no chance of a useful merge-commit. 
I think in these cases it's most likely better to create a new branch on 
every update and rebase the patches.




Anyway, still this is a branch based workflow. How would you do that 
workflow with just fixed commit IDs?


I'm asking since so far commit IDs on submodules were always obtain 
from master branch which is what we basically fork and does not give 
us ability to patch with RTEMS changes...


So I'm curious how would you do that?


I think I have put that in the wrong words. I assumed you mean that you 
want to use some feature that always uses the latest commit of a branch 
(also I don't know whether git even has that feature).


What I wanted to say is that if I check out a RTEMS version from two 
months back, it should check out the revisions of the submodules that 
have been used in RTEMS two months back too. It must not use the latest 
HEAD of the branch from today. It's just part of having a version of the 
code that can be reproduced later.


Right! Now crucial question: is that even supported in git? I'm asking 
since so far I've seen only:


- use fixed commit ids, but those are obtained only from master branch
or
- use branch and then this is always branch HEAD

I've not seen anything like "use fixed commit ID from branch XXX". So 
question for you as an git expert: are you absolutely sure that this 
workflow is supported by git at all? And by this I mean have you tested 
that actually? :-)


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 really matter" worries me a little bit. I'm not sure 
this functionality is even supported hence my question above if you have 
tested it yourself.


Thanks!
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 feature they accumulated some more.


- submodules started as way to get commit id of the external project 
to the tree. But only master branch was supported. (not suitable for 
RTEMS)


- later submodules added capability to use tag (still not suitable for 
RTEMS)


- later submodules added capability to use different branch from the 
project, but only a head of it. (finally what RTEMS need).


I don't like using branches instead of fixed commit IDs. Otherwise, it's 
not possible to reliable re-build a fixed version.


And this is most important detail, so let's discuss this alone.

I have a hal library, let's consider this to be 
https://github.com/karelfv/stm32h7xx_hal_driver -- just one project for now.


This is a fork of ST Micro project of the same name which is a slow 
development project. Few accumulated commits over one year let say.


This project needs few RTEMS related patches and there is a chance they 
also need to kind of adapt to the new development. So let's branch as:


- master branch -- this is fork of ST Micro
- rtems-6-branch -- this is a branch from master at one point of time 
accumulating RTEMS related changes.


Now, let's assume this was done 6 months ago and now you would like to 
update from ST Micro upstream. How would you do that? I see:


- git fetch upstream inside the master
- git push master

that's update of master in fork and now:

- pull/merge master
or
- rebase master

in the rtems-6-branch? I'm afraid rebase is dangerous in shared setup so 
probably pull/merge?


Anyway, still this is a branch based workflow. How would you do that 
workflow with just fixed commit IDs?


I'm asking since so far commit IDs on submodules were always obtain from 
master branch which is what we basically fork and does not give us 
ability to patch with RTEMS changes...


So I'm curious how would you do that?

Thanks!
Karel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 follow related BSP code location.


I think I would prefer "contrib/hals", "external/hals" or some other 
more generic top directory name. It would allow to use that for other 
parts like for example zlib in "contrib/libs/zlib" in the future (if we 
agree on having libs like that there too).


Indeed, name is not the problem here. Both looks fine, somewhat prefer 
external a bit.



At the moment, you have absolute URLs for your submodules:

   url = https://github.com/ARM-software/CMSIS_5.git
   url = https://github.com/karelfv/stm32h7xx_hal_driver.git
   url = https://github.com/karelfv/cmsis_device_h7.git

If we use submodules, I would go for relative paths and clone the 
repositories to our git.rtems.org and to all mirrors. It has the 
advantage that even if some upstream URL changes, we won't be affected.


This is dirty PoC not a final solution. Due to this I've settled on 
absolute urls and not relative. For final solution relative are needed, 
but both url (relative/abolute) and name/location in RTEMS tree is very 
easy to change based on decision.


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 feature they accumulated some more.


- submodules started as way to get commit id of the external project to 
the tree. But only master branch was supported. (not suitable for RTEMS)


- later submodules added capability to use tag (still not suitable for 
RTEMS)


- later submodules added capability to use different branch from the 
project, but only a head of it. (finally what RTEMS need).


- in the field you can see gits supporting different sets of submodule 
features described above.


- submodules are easy to be broken. Personal experience from Haskell 
compiler (GHC) project which uses submodules a lot. I have git 2.25 and 
I always have an issue to pull from GHC repo since alwyas for me one 
submodule (when changed) will be broken for me. Conclusion: clone with 
submodules may kind of work, but later pull may be tricky.


- besides submodules are not supported in 'got' which is 3rd party 
independent implementation of git like SCM with more sane UI


- due to submodules trickiness development policy for external 
integration with project code modification (aka HAL patches) needs to be 
very well written. I smell horrible increase in cognitive load here...


Nonetheless, we should take a look at some of the reasons why other 
projects decided against them. For example Google has the "repo" tool 
used in Android. Zephyr has the "west" tool. OpenWRT uses "feeds" for 
something similar. I'm sure there are more.


   https://gerrit.googlesource.com/git-repo/
   https://docs.zephyrproject.org/latest/develop/west/why.html#
   https://openwrt.org/docs/guide-developer/feeds

All solve a similar problem. Part of them even overlap already with 
functionality from our waf based build system. We should consider 
whether we need any of the functionality of these tools and whether we 
want to re-implement it or whether we just want to use one of the tools 
and integrate with it.


Oh, do I sense starting academic debate now? The point of my dirty PoC 
was to ground that a bit and show real stuff to get a feel of possibilities.


Anyway, based on my PoC experience I would probably prefer something 
more KISS and also more flexible by tool(s) being also aware of RTEMS BSPs


- first lets start with just 'boot' and 'update' scripts hosted in the 
repo and used to clone/update externals would be needed. And put 
'external' into git ignore.


- later boot/update my be made BSP aware. I mean when doing development 
on H7 I do not need HALs for Xilinx and other ARM/v8/Rx stuff. Neither I 
need HAL for NXP/Microchip chips.


- may this boot/update functionality be made part of ./waf tooling? 
Perhaps it may


So based on this I can see how Zephyr gravitated to west...


I've also completely removed HAL code from the BSP directory and also 
CMSIS v4 files from bsps/arm/include to verify compilation is really 
using submodules.


I think the CMSIS headers are used by some other BSPs too. So that's 
fine for a prototype. But for the final solution, we need something 
different.


The PoC needs to prove some things hence removal of CMSIS from the tree. 
Nothing more. It's a "gain experience" vehicle, not a final solution. 
And btw, you will not be able to find final solution without 
touching/testing stuff and getting your hands dirty with it.


Everything has its own price: (i) ad

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

[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 follow related BSP code location.

I've also completely removed HAL code from the BSP directory and also 
CMSIS v4 files from bsps/arm/include to verify compilation is really 
using submodules.


If you like to see how this is looking, just:

$ git clone https://github.com/karelfv/rtems.git rtems
$ cd rtems
$ git checkout rtems-stm32h7-hal-git-submodules
$ git submodule update --init

And see bsps/arm/stm32h7/ and hals/arm/stm32h7/ and bsps/arm/include 
subdirectories.


You can also compile if you have arm tools:

$ ./waf bspdefaults --rtems-bsps=arm/stm32h757i-eval > stm32h757i-eval.ini
$ ./waf configure --rtems-bsps=arm/stm32h757i-eval 
--rtems-config=./stm32h757i-eval.ini --rtems-tools= --prefix=

$ ./waf

CAVEAT: only STM32H757i-eval BSP is supported and only compilation. 
Installation is not supported yet.


Note: HAL is updated to latest STMicro code and all related changes done 
in the past by Sebastian and Christian are merged into submodules 
projects except Doxygen 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 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 needed anymore. It 
depends on resolution to following questions:


- stm32h7 hal contains Sebastian's modification/additions of Doxygen 
tags. Do we need to preserve that in the submodule? I guess not, but I'm 
not sure and this question of Doxygen markups was not solved in this 
thread yet AFAIK.


- all ARMs HALs probably also depends on particular version of CMSIS 
files, so I guess we should use separate submodules of CMSIS per HAL. At 
least STM recommends that: 
https://htmlpreview.github.io/?https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Release_Notes.html -- this would certainly be improvement in comparison with current state of the art besides update of CMSIS alone we would also support manufacture tested CMSIS version for their HAL...


- where to put submodules? What is preferred location? For stm32h7 case!
   (i) hals/arm/stm32h7
  or
   (ii) deps/arm/stm32h7
  or
   (iii) contrib/arm/stm32h7
  or
   (iv) anything else preferred?


I may do stm32h7 hal + its CMSIS dependency now (or next week), but only 
if the chance of inclusion into RTEMS 6 is reasonably high. Otherwise I 
would need to go more safer route of manual in-tree HAL update assuming 
this is still acceptable for RTEMS 6 release.


Testing of stm32h7 changes is on my shoulders, hardware is here and 
customer is using the platform in field. Offering this as an opportunity 
to test the submodule vehicle ASAP on some part of RTEMS...


Thanks,
Karel

On 5/23/23 09:26, Christian MAUDERER wrote:

Hello,

I recently updated the HAL in the i.MXRT BSP. I used the same approach 
that we use for a lot of similar cases: Import the sources into RTEMS 
and adapt them slightly so that they work for us. So basically a 
Clone-and-Own approach.


During the discussion of the patches, some concerns were raised, 
whether we should find a better solution to handle HALs, SDKs and 
similar cases. We should start discussing a solution that can be used 
after the 6 release so that maybe someone can start to work on a 
prototype.


Some example cases are:

- the mcux_sdk in the imxrt BSP
- the hal in the stm32h7 BSP
- general ARM CMSIS files
- zlib
- libfdt

One solution could be to build these libraries external and only link 
RTEMS with them. There are disadvantages to this aproach:


- Also in my experience, the API of the HALs / SDKs / libraries seems 
to be quite stable, it's possible that there are combinations where 
some unexpected change breaks a driver or makes it impossible to link 
the applications.


- BSPs rely on basic drivers from these libraries (like console or 
clock driver). If we link against the libraries, the testsuite 
wouldn't build any more without preinstalled libraries.


Another solution could be to include libraties like that as submodules 
and build them using the RTEMS build system. We could clone the repos 
onto the RTEMS git server, and add necessary patches. Advantage would 
be that it is more similar to the process that we currently have. 
Another advantage is that we have a known-working version of the 
files. Upstream updates could be either merged or we could rebase our 
patches to a new version.


 From my point of view, the second option would be the better one 
especially because we have a tested, fixed vers

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

[Karel Gardas]

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 needed anymore. It 
depends on resolution to following questions:


- stm32h7 hal contains Sebastian's modification/additions of Doxygen 
tags. Do we need to preserve that in the submodule? I guess not, but I'm 
not sure and this question of Doxygen markups was not solved in this 
thread yet AFAIK.


- all ARMs HALs probably also depends on particular version of CMSIS 
files, so I guess we should use separate submodules of CMSIS per HAL. At 
least STM recommends that: 
https://htmlpreview.github.io/?https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Release_Notes.html 
-- this would certainly be improvement in comparison with current state 
of the art besides update of CMSIS alone we would also support 
manufacture tested CMSIS version for their HAL...


- where to put submodules? What is preferred location? For stm32h7 case!
  (i) hals/arm/stm32h7
 or
  (ii) deps/arm/stm32h7
 or
  (iii) contrib/arm/stm32h7
 or
  (iv) anything else preferred?


I may do stm32h7 hal + its CMSIS dependency now (or next week), but only 
if the chance of inclusion into RTEMS 6 is reasonably high. Otherwise I 
would need to go more safer route of manual in-tree HAL update assuming 
this is still acceptable for RTEMS 6 release.


Testing of stm32h7 changes is on my shoulders, hardware is here and 
customer is using the platform in field. Offering this as an opportunity 
to test the submodule vehicle ASAP on some part of RTEMS...


Thanks,
Karel

On 5/23/23 09:26, Christian MAUDERER wrote:

Hello,

I recently updated the HAL in the i.MXRT BSP. I used the same approach 
that we use for a lot of similar cases: Import the sources into RTEMS 
and adapt them slightly so that they work for us. So basically a 
Clone-and-Own approach.


During the discussion of the patches, some concerns were raised, whether 
we should find a better solution to handle HALs, SDKs and similar cases. 
We should start discussing a solution that can be used after the 6 
release so that maybe someone can start to work on a prototype.


Some example cases are:

- the mcux_sdk in the imxrt BSP
- the hal in the stm32h7 BSP
- general ARM CMSIS files
- zlib
- libfdt

One solution could be to build these libraries external and only link 
RTEMS with them. There are disadvantages to this aproach:


- Also in my experience, the API of the HALs / SDKs / libraries seems to 
be quite stable, it's possible that there are combinations where some 
unexpected change breaks a driver or makes it impossible to link the 
applications.


- BSPs rely on basic drivers from these libraries (like console or clock 
driver). If we link against the libraries, the testsuite wouldn't build 
any more without preinstalled libraries.


Another solution could be to include libraties like that as submodules 
and build them using the RTEMS build system. We could clone the repos 
onto the RTEMS git server, and add necessary patches. Advantage would be 
that it is more similar to the process that we currently have. Another 
advantage is that we have a known-working version of the files. Upstream 
updates could be either merged or we could rebase our patches to a new 
version.


 From my point of view, the second option would be the better one 
especially because we have a tested, fixed version of the library 
instead telling the user to just use some random version that might or 
might not work.


Regardless which aproach we use: We have to think about how to handle 
that on releases. In the link aproach (first case), we have to somehow 
archive source tar balls and some kind of build recipe. In the submodule 
aproach, we could checkout all submodules and pack the files into the 
RTEMS release tar ball. So I would expect that the second aproach has 
less impact here too.


Comments? Improvements? Better suggestions?

Best regards

Christian


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 (ii) without any NOTICE file.


The absence of a NOTICE file is OK. If they had one, we would just have
to pass it along.

I recall the issue is that "You must cause any modified files to carry 
prominent

notices stating that You changed the files"



OK, but this is even easier since I have not modified files at all. They 
are just verbatim copy.



My reading is that we would need to pass the NOTICE file along. I personally
do not see that as a burden unless it contains more than credit or 
permissively

license info.


OK! I think decision process itself of "unless it contains more than..." 
may be seen as a burden. But, fortunately no NOTICE file there, hence no 
issue...



The patch itself is clear replace of existing files with a new files,
plus required files added and old one not needed anymore removed.

The patch was very lightly tested by building several ARM BSPs
especially those affected by the change.


Did you have any BSPs to actually test on? What ones can be tested
for this?


Yes, I can run testsuite on 2 boards I have sitting idle here: 
stm32h747i-disco and stm32h7b3i-dk where 747 would test both M7 and M4 
variants. By comparing results from current tree and current tree + 
patch we may see any unexpected breakage...



Thanks for any comments!


I'm happy with the update and think it is OK license wise. Technically, 
it you

trust it, I'm ok with it.


Cool! Thanks,

Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

 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 (ii) without any NOTICE file.


I hope technical advantages are huge and there is no hinder involved 
like with other possible Apache2 licensed projects with NOTICE file 
presented.


The patch itself is clear replace of existing files with a new files, 
plus required files added and old one not needed anymore removed.


The patch was very lightly tested by building several ARM BSPs 
especially those 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 located inside the CMSIS/Core/Include
project sub-directory.

The project does not provide any NOTICE file in its root directory nor
in the directory of the imported files.
The NOTICE file and its usage in the Apache 2 license was/is
so far the only issue mentioned in discussion of RTEMS developers/users
when considering inclusion of the code under Apache 2 license
into the RTEMS project.
Since the CMSIS v5 project is free from this legal hinder, we may freely
use it and update files to the latest version.

Technical: the patch replaces code from 2015 with the latest version
which brings quite a lot of bug fixes and most importantly opens
possibilities to support MCUs based on new ARM cores.
---


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

 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 we 
just give up on those mirrors and create our own based on git.rtems.org?


Thanks!
Karel

[1]: https://github.com/RTEMS/rtems
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 (remap 
of SDRAM_2). If you fix SDRAM_1 to be real SDRAM_1, then we will need 
SDRAM_2_REMAP defined and fix also all SDRAM_1 occurances in linker 
scripts and replace those with SDRAM_2_REMAP.


Or that at least how I understand it...

Thanks,
Karel

On 7/12/23 18:00, Kinsey Moore wrote:

According to the documentation in STM reference manuals RM0399 and
RM0433, the standard memory space for SDRAM bank 1 is 0xc000 to
0xcfff.
---
  spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml 
b/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
index 88dd4e8c91..2b3aacce5d 100644
--- a/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
+++ b/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
@@ -14,9 +14,9 @@ content: |
  SRAM_BACKUP : ORIGIN = 0x3880, LENGTH = 
${STM32H7_MEMORY_SRAM_BACKUP_SIZE:#010x}
  PERIPHERAL  : ORIGIN = 0x4000, LENGTH = 
${STM32H7_MEMORY_PERIPHERAL_SIZE:#010x}
  NOR : ORIGIN = 0x6000, LENGTH = 
${STM32H7_MEMORY_NOR_SIZE:#010x}
-SDRAM_1 : ORIGIN = 0x7000, LENGTH = 
${STM32H7_MEMORY_SDRAM_1_SIZE:#010x}
  NAND: ORIGIN = 0x8000, LENGTH = 
${STM32H7_MEMORY_NAND_SIZE:#010x}
  QUADSPI : ORIGIN = 0x9000, LENGTH = 
${STM32H7_MEMORY_QUADSPI_SIZE:#010x}
+SDRAM_1 : ORIGIN = 0xc000, LENGTH = 
${STM32H7_MEMORY_SDRAM_1_SIZE:#010x}
  SDRAM_2 : ORIGIN = 0xd000, LENGTH = 
${STM32H7_MEMORY_SDRAM_2_SIZE:#010x}
}
  


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 otherwise be duplicated
files from the stm32h747i-disco BSP. Note that system_stm32h7xx.c has
been imported from the STM repository with two minor changes wrapped
with #if __rtems__. This hardware has been tested with hello and ticker.


Nice! So with a just little bit of tweak I may get my stm32h745-disco 
up as your 750 is on the same disco kit. Sweet! :-)



diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
index bd1053db38..56ec66a64f 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
@@ -14,6 +14,9 @@ default:
- arm/stm32h757i-eval-m4
- arm/stm32h7b3i-dk
value: 0x
+- enabled-by:
+  - arm/stm32h750b-dk
+  value: 0x0100
  - enabled-by: true
value: 0x0200
  description: |


Have you actually tested writing to the SDRAM 1 memory region? Asking 
since IIRC several of STMicro data sheets were wrong about specifying 
RAM to be SDRAM 1 while in fact it was in SDRAM 2 region by default. And 
your system*.c does not contain (if I've not overlooked it) any 
remapping from SDRAM 2 to SDRAM 1 -- so just asking for to be sure, you 
actually tested putting some data into it.


E.g. "An 8M x 32-bit SDRAM is connected to the SDRAM bank1 of the FMC 
interface of the STM32H7x7XI microcontroller." -- this comes from um2525 
for stm32h757i-eval and no, by default SDRAM is mapped to bank2.


Thanks,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 squashed 
commits together as they are related anyway.


Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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/arm-exception-frame-print.c
index 7bc6795ea5..b089648184 100644
--- a/cpukit/score/cpu/arm/arm-exception-frame-print.c
+++ b/cpukit/score/cpu/arm/arm-exception-frame-print.c
@@ -41,11 +41,14 @@
 #include 
 
 #include 
+#if defined(ARM_MULTILIB_ARCH_V7M)
+#include 
+#endif
 #include 
 
 static void _ARM_VFP_context_print( const ARM_VFP_context *vfp_context )
 {
-#ifdef ARM_MULTILIB_VFP_D32
+#ifdef ARM_MULTILIB_VFP
   if ( vfp_context != NULL ) {
 const uint64_t *dx = _context->register_d0;
 int i;
@@ -56,7 +59,14 @@ static void _ARM_VFP_context_print( const ARM_VFP_context 
*vfp_context )
   vfp_context->register_fpscr
 );
 
-for ( i = 0; i < 32; ++i ) {
+#if defined(ARM_MULTILIB_VFP_D32)
+int regcount = 32;
+#elif defined(ARM_MULTILIB_VFP_D16)
+int regcount = 16;
+#else
+int regcount = 0;
+#endif
+for ( i = 0; i < regcount; ++i ) {
   uint32_t low = (uint32_t) dx[i];
   uint32_t high = (uint32_t) (dx[i] >> 32);
 
@@ -66,6 +76,136 @@ static void _ARM_VFP_context_print( const ARM_VFP_context 
*vfp_context )
 #endif
 }
 
+static void _ARM_Cortex_M_fault_info_print( void )
+{
+#if defined(ARM_MULTILIB_ARCH_V7M)
+  /*
+   * prints content of additional debugging registers
+   * available on Cortex-Mx where x > 0 cores.
+   */
+  uint32_t cfsr = _ARMV7M_SCB->cfsr;
+  uint8_t mmfsr = ARMV7M_SCB_CFSR_MMFSR_GET( cfsr );
+  uint8_t bfsr = ( ARMV7M_SCB_CFSR_BFSR_GET( cfsr ) >> 8 );
+  uint16_t ufsr = ( ARMV7M_SCB_CFSR_UFSR_GET( cfsr ) >> 16 );
+  uint32_t hfsr = _ARMV7M_SCB->hfsr;
+  if ( mmfsr > 0 ) {
+printk( "MMFSR= 0x%08" PRIx32 " (memory fault)\n", mmfsr );
+if ( ( mmfsr & 0x1 ) != 0 ) {
+  printk( "  IACCVIOL   : 1  (instruction access violation)\n" );
+}
+if ( ( mmfsr & 0x2 ) != 0 ) {
+  printk( "  DACCVIOL   : 1  (data access violation)\n" );
+}
+if ( (mmfsr & 0x8 ) != 0 ) {
+  printk(
+"  MUNSTKERR  : 1  (fault on unstacking on exception return)\n"
+  );
+}
+if ( ( mmfsr & 0x10 ) != 0 ) {
+  printk( "  MSTKERR: 1  (fault on stacking on exception entry)\n" );
+}
+if ( (mmfsr & 0x20 ) != 0 ) {
+  printk( "  MLSPERR: 1  (fault during lazy FP stack preservation)\n" 
);
+}
+if ( (mmfsr & 0x80 ) != 0 ) {
+  printk(
+"  MMFARVALID : 1 -> 0x%08" PRIx32 " (error address)\n",
+   _ARMV7M_SCB->mmfar
+  );
+}
+else {
+  printk( "  MMFARVALID : 0  (undetermined error address)\n" );
+}
+  }
+  if ( bfsr > 0 ) {
+printk( "BFSR = 0x%08" PRIx32 " (bus fault)\n", bfsr );
+if ( ( bfsr & 0x1 ) != 0 ) {
+  printk( "  IBUSERR: 1  (instruction fetch error)\n" );
+}
+if ( (bfsr & 0x2 ) != 0 ) {
+  printk(
+"  PRECISERR  : 1  (data bus error with known exact location)\n"
+  );
+}
+if ( ( bfsr & 0x4) != 0 ) {
+  printk(
+"  IMPRECISERR: 1  (data bus error without known exact location)\n"
+  );
+}
+if ( (bfsr & 0x8 ) != 0 ) {
+  printk(
+"  UNSTKERR   : 1  (fault on unstacking on exception return)\n"
+  );
+}
+if ( ( bfsr & 0x10 ) != 0 ) {
+  printk( "  STKERR : 1  (fault on stacking on exception entry)\n" );
+}
+if ( ( bfsr & 0x20 ) != 0 ) {
+  printk( "  LSPERR : 1  (fault during lazy FP stack preservation)\n" 
);
+}
+if ( (bfsr & 0x80 ) != 0 ) {
+  printk(
+"  BFARVALID  : 1 -> 0x%08" PRIx32 "  (error address)\n",
+   _ARMV7M_SCB->bfar
+  );
+}
+else {
+  printk( "  BFARVALID  : 0  (undetermined error address)\n" );
+}
+  }
+  if ( ufsr > 0 ) {
+printk( "UFSR = 0x%08" PRIx32 " (usage fault)\n", ufsr);
+if ( (ufsr & 0x1 ) != 0 ) {
+  printk( "  UNDEFINSTR : 1  (undefined instruction issued)\n");
+}
+if ( (ufsr & 0x2 ) != 0 ) {
+  printk(
+"  INVSTATE   : 1"
+"  (invalid instruction state"
+" (Thumb not set in EPSR or invalid IT state in EPSR))\n"
+  );
+}
+if ( (ufsr & 0x4 ) != 0 ) {
+  printk( "  INVPC  : 1  (integrity check failure on EXC_RETURN)\n" );
+}
+if ( (ufsr & 0x8 ) != 0 ) {
+  printk(
+"  NOCP   : 1"
+"  (coprocessor instruction issued"
+" but coprocessor disabled or non existent)\n"
+  );
+}
+if ( ( ufsr & 0x100) != 0 ) {
+  printk( "  UNALIGNED  : 1  (unaligned access operation occurred)\n" );
+}
+if ( ( ufsr & 0x200) != 0 ) {
+  printk( "  DIVBYZERO  : 1  (division by zero)" );
+}
+  }
+  if ( (hfsr & (
+ARMV7M_SCB_HFSR_VECTTBL_MASK
+| ARMV7M_SCB_HFSR_DEBUGEVT_MASK
+| ARMV7M_SCB_HFSR_FORCED_MASK
+) ) != 0 ) {
+printk( "HFSR = 0x%08" PRIx32 " 

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

[Karel Gardas]

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-frame-print.c
index 7bc6795ea5..32e9c723d9 100644
--- a/cpukit/score/cpu/arm/arm-exception-frame-print.c
+++ b/cpukit/score/cpu/arm/arm-exception-frame-print.c
@@ -41,6 +41,9 @@
 #include 
 
 #include 
+#if defined(ARM_MULTILIB_ARCH_V7M)
+#include 
+#endif
 #include 
 
 static void _ARM_VFP_context_print( const ARM_VFP_context *vfp_context )
@@ -66,6 +69,103 @@ static void _ARM_VFP_context_print( const ARM_VFP_context 
*vfp_context )
 #endif
 }
 
+static void _ARM_Cortex_M_fault_info_print(void)
+{
+#if defined(ARM_MULTILIB_ARCH_V7M)
+/* prints content of additional debugging registers
+ * available on Cortex-Mx where x > 0 cores.
+ */
+uint32_t cfsr = _ARMV7M_SCB->cfsr;
+uint8_t mmfsr = ARMV7M_SCB_CFSR_MMFSR_GET(cfsr);
+uint8_t bfsr = (ARMV7M_SCB_CFSR_BFSR_GET(cfsr) >> 8);
+uint16_t ufsr = (ARMV7M_SCB_CFSR_UFSR_GET(cfsr) >> 16);
+uint32_t hfsr = _ARMV7M_SCB->hfsr;
+if (mmfsr > 0) {
+printk("MMFSR= 0x%08" PRIx32 " (memory fault)\n", mmfsr);
+if ((mmfsr & 0x1) != 0) {
+printk("  IACCVIOL   : 1  (instruction access violation)\n");
+}
+if ((mmfsr & 0x2) != 0) {
+printk("  DACCVIOL   : 1  (data access violation)\n");
+}
+if ((mmfsr & 0x8) != 0) {
+printk("  MUNSTKERR  : 1  (fault on unstacking on exception 
return)\n");
+}
+if ((mmfsr & 0x10) != 0) {
+printk("  MSTKERR: 1  (fault on stacking on exception 
entry)\n");
+}
+if ((mmfsr & 0x20) != 0) {
+printk("  MLSPERR: 1  (fault during lazy FP stack 
preservation)\n");
+}
+if ((mmfsr & 0x80) != 0) {
+printk("  MMFARVALID : 1 -> 0x%08" PRIx32 " (error address)\n", 
_ARMV7M_SCB->mmfar);
+}
+else {
+printk("  MMFARVALID : 0  (undetermined error address)\n");
+}
+}
+if (bfsr > 0) {
+printk("BFSR = 0x%08" PRIx32 " (bus fault)\n", bfsr);
+if ((bfsr & 0x1) != 0) {
+printk("  IBUSERR: 1  (instruction fetch error)\n");
+}
+if ((bfsr & 0x2) != 0) {
+printk("  PRECISERR  : 1  (data bus error with known exact 
location)\n");
+}
+if ((bfsr & 0x4) != 0) {
+printk("  IMPRECISERR: 1  (data bus error without known exact 
location)\n");
+}
+if ((bfsr & 0x8) != 0) {
+printk("  UNSTKERR   : 1  (fault on unstacking on exception 
return)\n");
+}
+if ((bfsr & 0x10) != 0) {
+printk("  STKERR : 1  (fault on stacking on exception 
entry)\n");
+}
+if ((bfsr & 0x20) != 0) {
+printk("  LSPERR : 1  (fault during lazy FP stack 
preservation)\n");
+}
+if ((bfsr & 0x80) != 0) {
+printk("  BFARVALID  : 1 -> 0x%08" PRIx32 "  (error address)\n", 
_ARMV7M_SCB->bfar);
+}
+else {
+printk("  BFARVALID  : 0  (undetermined error address)\n");
+}
+}
+if (ufsr > 0) {
+printk("UFSR = 0x%08" PRIx32 " (usage fault)\n", ufsr);
+if ((ufsr & 0x1) != 0) {
+printk("  UNDEFINSTR : 1  (undefined instruction issued)\n");
+}
+if ((ufsr & 0x2) != 0) {
+printk("  INVSTATE   : 1  (invalid instruction state (Thumb not 
set in EPSR or invalid IT state in EPSR))\n");
+}
+if ((ufsr & 0x4) != 0) {
+printk("  INVPC  : 1  (integrity check failure on 
EXC_RETURN)\n");
+}
+if ((ufsr & 0x8) != 0) {
+printk("  NOCP   : 1  (coprocessor instruction issued but 
coprocessor disabled or non existent)\n");
+}
+if ((ufsr & 0x100) != 0) {
+printk("  UNALIGNED  : 1  (unaligned access operation 
occurred)\n");
+}
+if ((ufsr & 0x200) != 0) {
+printk("  DIVBYZERO  : 1  (division by zero)");
+}
+}
+if ((hfsr & (ARMV7M_SCB_HFSR_VECTTBL_MASK | ARMV7M_SCB_HFSR_DEBUGEVT_MASK 
| ARMV7M_SCB_HFSR_FORCED_MASK)) != 0) {
+printk("HFSR = 0x%08" PRIx32 " (hard fault)\n", hfsr);
+if ((hfsr & ARMV7M_SCB_HFSR_VECTTBL_MASK) != 0) {
+printk("  VECTTBL: 1  (error in address located in vector 
table)\n");
+}
+if ((hfsr & ARMV7M_SCB_HFSR_FORCED_MASK) != 0) {
+printk("  FORCED : 1  (configurable fault escalated to hard 
fault)\n");
+}
+if ((hfsr & ARMV7M_SCB_HFSR_DEBUGEVT_MASK) != 0) {
+printk("  DEBUGEVT   : 1  (debug event occurred with debug system 
disabled)\n");
+}
+}
+#endif
+}
 void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
 {
   printk(
@@ -109,4 +209,5 @@ 

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

[Karel Gardas]

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
--- a/cpukit/score/cpu/arm/arm-exception-frame-print.c
+++ b/cpukit/score/cpu/arm/arm-exception-frame-print.c
@@ -48,7 +48,7 @@
 
 static void _ARM_VFP_context_print( const ARM_VFP_context *vfp_context )
 {
-#ifdef ARM_MULTILIB_VFP_D32
+#ifdef ARM_MULTILIB_VFP
   if ( vfp_context != NULL ) {
 const uint64_t *dx = _context->register_d0;
 int i;
@@ -59,7 +59,14 @@ static void _ARM_VFP_context_print( const ARM_VFP_context 
*vfp_context )
   vfp_context->register_fpscr
 );
 
-for ( i = 0; i < 32; ++i ) {
+#if defined(ARM_MULTILIB_VFP_D32)
+int regcount = 32;
+#elif defined(ARM_MULTILIB_VFP_D16)
+int regcount = 16;
+#else
+int regcount = 0;
+#endif
+for ( i = 0; i < regcount; ++i ) {
   uint32_t low = (uint32_t) dx[i];
   uint32_t high = (uint32_t) (dx[i] >> 32);
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS_SYSINIT_ITEM not working sometimes?

[Karel Gardas]

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

but it is not. The problematic code is here: 
https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/start/getentropy-rng.c


So far it looks like linker is GCing whole file. The only workaround for 
the issue which I've found so far is to add some "hook" function in the 
file and call that hook from BSP starting code. This way linker is 
enforced to link the file in and then RTEMS_SYSININT_ITEM is correctly 
doing its business.


I'm using following tool-chain:

gcc version 12.2.1 20230224 (RTEMS 6, RSB 
7153c2f1dcfb83b154b976298699c26e793a33dd, Newlib 17ac400) (GCC)


GNU assembler version 2.40 (arm-rtems6) using BFD version (GNU Binutils) 
2.40


GNU ld (GNU Binutils) 2.40

I'm using following configuration of the testing app:

#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
#define CONFIGURE_MAXIMUM_TASKS1
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
#define CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION
#define CONFIGURE_INIT
#include 


Since RTEMS_SYSINIT_ITEM & Co. are used quite a lot thorough source code 
I cannot believe that just H7 BSP is that unlucky to be hit by this issue.


Has anybody seeing similar behavior? Or am I doing anything stupid?

Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Tool versions for RTEMS 6.1 release?

[Karel Gardas]

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?


Thanks,
Karel


On 6/30/23 08:26, Sebastian Huber wrote:

Hello,

it seems the RTEMS 6.1 release is getting closer. We should think about 
the tool versions for the release.


For GCC, my preferred choice would be GCC 13.2:

https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html

In GCC 12 a big change was enabling the vectorization support with -O2. 
This should have stabilized in GCC 13. GCC 13 contains some 
RTEMS-specific improvements for Ada.


For Binutils and GDB I would just use the latest release available at 
the RTEMS 6 branch point.




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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.yml 
b/spec/build/bsps/arm/stm32h7/optenmpualign.yml
index 874385956c..60e45c708d 100644
--- a/spec/build/bsps/arm/stm32h7/optenmpualign.yml
+++ b/spec/build/bsps/arm/stm32h7/optenmpualign.yml
@@ -7,6 +7,10 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH & Co. KG
 default:
+- enabled-by:
+  - arm/stm32h747i-disco-m4
+  - arm/stm32h757i-eval-m4
+  value: false
 - enabled-by: true
   value: true
 description: |
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB repo commits need approval

[Karel Gardas]

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 is the most close to that and available 
for running by anyone?
As an observer on another project with GitLab (GHC Haskell compiler) 
I've seen this solution is not free as a work free, but requires some 
man-hours investments...


So the question after "yes" to migrate (if the consensus is found!) is 
"who will pay the price and do the job"...


Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Karel Gardas]

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 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 not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like 
to provide some DSL + compiler which would generates those? Or would 
you just like to keep JSON and have developers editing those?


I would keep the JSON and have developer editing those.

An alternative to changing the format could be to use the CSafeLoader of 
the system yaml module if it is available. It is not as fast as the JSON 
loader, but acceptable (0.65s to 0.2s on my machine for loading the items).


Sorry for perhaps silly question, but why do you invest that much energy 
in optimizing build speed -- by fraction of seconds here? I so far fail 
so to see driving motivation force hence my question...


Thanks,
Karel




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Karel Gardas]

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


Let me ask for clarification. Does this yaml -> json transition 
include (or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like to 
provide some DSL + compiler which would generates those? Or would you 
just like to keep JSON and have developers editing those?


Thanks,
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Karel Gardas]

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 not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec

Thanks!
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Qemu and missing dynamic libraries

[Karel Gardas]

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  2434866 Apr  2 03:18 libglib-2.0.a
lrwxr-xr-x  1 root  wheel       16 Apr  2 03:19 libglib-2.0.so
<http://libglib-2.0.so> ->
libglib-2.0.so.0
lrwxr-xr-x  1 root  wheel       23 Apr  2 03:19 libglib-2.0.so.0 ->
libglib-2.0.so.0.7600.1
-rwxr-xr-x  1 root  wheel  1332424 Apr  2 03:19 libglib-2.0.so.0.7600.1
karel@rtems:/usr/local/lib $ ls -la libintl.*
-rw-r--r--  1 root  wheel  115868 Jan  3 02:12 libintl.a
lrwxr-xr-x  1 root  wheel      16 Jan  3 02:12 libintl.so ->
libintl.so.8.3.0
lrwxr-xr-x  1 root  wheel      16 Jan  3 02:12 libintl.so.8 ->
libintl.so.8.3.0
-rw-r--r--  1 root  wheel   2 Jan  3 02:12 libintl.so.8.3.0
karel@rtems:/usr/local/lib $ ldd libglib-2.0.so.0.7600.1
libglib-2.0.so.0.7600.1:
          libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x1385d09a2000)
          libintl.so.8 => /usr/local/lib/libintl.so.8 (0x1385d19dc000)
          libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0
(0x1385d23ff000)
          libutil.so.9 => /lib/libutil.so.9 (0x1385d27d9000)
          libthr.so.3 => /lib/libthr.so.3 (0x1385d2e51000)
          libc.so.7 => /lib/libc.so.7 (0x1385cdce8000)


so in the worst case you would need to do some house cleaning...


Just got this to repeat with someone in the class this week with Ubuntu 
22 in a VM. The needed dynamic libraries are installed with the RTEMS 
tools in lib64. Weird


This sounds strange. First of all, your original report was about FBSD 
13.1-p6. Obviously you have not been lucky and glib package maintainer 
published library requiring libintl.so.9 and then probably reverted to 
.8. So high chance is pkg update; pkg upgrade may solve the issue.


W.r.t. RTEMS tools installing glib/libintl ? Never heard/seen anything 
like that and Ubuntu is pretty close to home call here...


Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Qemu and missing dynamic libraries

[Karel Gardas]

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
lrwxr-xr-x  1 root  wheel   23 Apr  2 03:19 libglib-2.0.so.0 -> 
libglib-2.0.so.0.7600.1

-rwxr-xr-x  1 root  wheel  1332424 Apr  2 03:19 libglib-2.0.so.0.7600.1
karel@rtems:/usr/local/lib $ ls -la libintl.*
-rw-r--r--  1 root  wheel  115868 Jan  3 02:12 libintl.a
lrwxr-xr-x  1 root  wheel  16 Jan  3 02:12 libintl.so -> 
libintl.so.8.3.0
lrwxr-xr-x  1 root  wheel  16 Jan  3 02:12 libintl.so.8 -> 
libintl.so.8.3.0

-rw-r--r--  1 root  wheel   2 Jan  3 02:12 libintl.so.8.3.0
karel@rtems:/usr/local/lib $ ldd libglib-2.0.so.0.7600.1
libglib-2.0.so.0.7600.1:
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x1385d09a2000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x1385d19dc000)
libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x1385d23ff000)
libutil.so.9 => /lib/libutil.so.9 (0x1385d27d9000)
libthr.so.3 => /lib/libthr.so.3 (0x1385d2e51000)
libc.so.7 => /lib/libc.so.7 (0x1385cdce8000)


so in the worst case you would need to do some house cleaning...

And while doing that, you may as well upgrade 13.1 -> 13.2.

Good luck!
Karel

On 4/24/23 20:28, Joel Sherrill wrote:

Hi

It looks like something has broken recently with building qemu via the 
RSB and dynamic libraries. All invocations of qemu are failing


https://lists.rtems.org/pipermail/build/2023-April/044792.html 



Not sure what to do. Maybe LD_LIBRARY_PATH but that wasn't needed before

--joel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 
 bsps/shared/freebsd/stand/efi/include/efi.h   |   87 ++
 .../shared/freebsd/stand/efi/include/efiapi.h | 1204 +
 .../shared/freebsd/stand/efi/include/eficon.h |  527 
 .../freebsd/stand/efi/include/eficonsctl.h|  134 ++
 .../shared/freebsd/stand/efi/include/efidef.h |  224 +++
 .../freebsd/stand/efi/include/efidevp.h   |  511 +++
 .../shared/freebsd/stand/efi/include/efierr.h |   68 +
 .../shared/freebsd/stand/efi/include/efigop.h |  121 ++
 .../shared/freebsd/stand/efi/include/efilib.h |  172 +++
 bsps/shared/freebsd/stand/efi/libefi/libefi.c |   63 +
 bsps/shared/freebsd/stand/efi/libefi/wchar.c  |   73 +
 13 files changed, 3495 insertions(+)
 create mode 100644 bsps/shared/freebsd/stand/efi/include/README
 create mode 100644 bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efi.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efiapi.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/eficon.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/eficonsctl.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efidef.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efidevp.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efierr.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efigop.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efilib.h
 create mode 100644 bsps/shared/freebsd/stand/efi/libefi/libefi.c
 create mode 100644 bsps/shared/freebsd/stand/efi/libefi/wchar.c

diff --git a/bsps/shared/freebsd/stand/efi/include/README 
b/bsps/shared/freebsd/stand/efi/include/README
new file mode 100644
index 00..bf821fae7e
--- /dev/null
+++ b/bsps/shared/freebsd/stand/efi/include/README
@@ -0,0 +1,36 @@
+/* $FreeBSD$ */
+/*-
+
+Files in this directory and subdirectories are subject to the following
+copyright unless superceded or supplemented by additional specific license
+terms found in the file headers of individual files.
+
+Copyright (c) 1998-2000 Intel Corporation
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+
+Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL INTEL BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+OF THE POSSIBILITY OF SUCH DAMAGE. THE EFI SPECIFICATION AND ALL
+OTHER INFORMATION ON THIS WEB SITE ARE PROVIDED "AS IS" WITH NO
+WARRANTIES, AND ARE SUBJECT TO CHANGE WITHOUT NOTICE.
+
+*/
diff --git a/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h 
b/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
new file mode 100644
index 00..97b4a04865
--- /dev/null
+++ b/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
@@ -0,0 +1,275 @@
+/* $FreeBSD$ */
+/*++
+
+Copyright (c)  1999 - 2003 Intel Corporation. All rights reserved
+This software and associated documentation (if any) is furnished
+under a license and may only be used or copied in accordance
+with the terms of the license. Except as permitted by such
+license, no part of this software or documentation may be
+reproduced, stored in a retrieval system, or transmitted in any
+form or by any means without the express written consent of
+Intel Corporation.
+
+Module Name:
+
+efefind.h
+
+Abstract:
+
+EFI to compile bindings
+
+
+
+
+Revision History
+
+--*/
+
+#pragma pack()
+
+
+#ifdef __FreeBSD__
+#include 
+#elif __rtems__
+#include 
+#else
+//
+// Basic int types of various widths
+//
+
+#if (__STDC_VERSION__ < 199901L )
+
+// No ANSI C 1999/2000 stdint.h integer width declarations 
+
+#ifdef _MSC_EXTENSIONS
+
+// Use Microsoft C compiler integer width declarations 
+
+typedef unsigned __int64uint64_t;
+typedef __int64 

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

[Karel Gardas]

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 2671c607a7..b26fb4c8ad 100644
--- a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
@@ -144,7 +144,7 @@ typedef struct {
 #define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
 #define CPU_STACK_MINIMUM_SIZE  (1024*4)
 #define CPU_SIZEOF_POINTER 8
-#define CPU_ALIGNMENT  8
+#define CPU_ALIGNMENT  16
 #define CPU_HEAP_ALIGNMENT CPU_ALIGNMENT
 #define CPU_STACK_ALIGNMENT16
 #define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

How to get amd64efi BSP running.

[Karel Gardas]

 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 between kernel, newlib and gcc 
which causes SSE aligned isns to work on unaligned data causing general 
protection fault. This issue is serious and needs to be investigated in 
the future by anyone working on amd64. To workaround the issue I did:


- few "fixes" here and there as required by GP crash reports on 
hello/ticker/malloctest tests. Those are only tests I have working here. 
The patch for those fixes is attached. This is *NOT* something for 
review or commit, this is just *WORKAROUND* to get interested people up 
& running!


- unfortunately the issue above not only affects RTEMS kernel, but also 
tools' newlib. Hence there is a need to build a new newlib. I simply 
obtained newlib from git as the 6/rtems-x86_64 is pretty close to HEAD 
of newlib anway and compile that with RTEMS GCC (installed by RSB). When 
this is compiled I touched newlib/libc/stdio/findfp.c and recompile it 
again, but this time with adding '-mgeneral-regs-only' GCC option. This 
is needed since unalignment of data happens when using this:


 30
 31 __FILE __sf[3];
 32

and the GCC does not have any attribute which would help with this 
unless the code is rewritten to get rid of array construct here.

Anyway, using only general purpose regs here is quick and easy workaround...

And that's about all needed to get hello/ticker/malloctest working. Just:
- configure (config file defaults should be more or less sane)
- build
- either copy test.exe to real hardware with GRUB setup or
- use tools' grub to generate EFI-based GRUB image for you and use Qemu 
virtual drive/dir support to boot from it directly.


Note: the configure provides plethora of options especially for EFI 
console. You may also use BSP's command line arguments:


  graphic_mode=
or
  text_mode=

this is especially useful when seeing well nothing on the target platform.

Tested platforms:
- Qemu 7.2.0
- Kontron D3598-B
- Kontron D3641-S (only graphic_mode works here, when text is involved I 
get GP somewhere inside UEFI)

- Lenovo B5400
- ASRock B450M Pro4
- Lenovo Ideapad Creator 5 -- does not work at all
- HP Pro x2 612 G2 -- does not work at all

The problem with last two laptops is that there is no PC-AT serial port 
available there which would throw at me nice GP complain and I would be 
able to investigate like I did in case of D3641-S.


Cheers,
Kareldiff --git a/cpukit/rtems/src/taskconstruct.c b/cpukit/rtems/src/taskconstruct.c
index 531d64903d..d88bdb539c 100644
--- a/cpukit/rtems/src/taskconstruct.c
+++ b/cpukit/rtems/src/taskconstruct.c
@@ -136,7 +136,7 @@ rtems_status_code _RTEMS_tasks_Create(
 )
 {
   Thread_Control  *the_thread;
-  Thread_Configuration thread_config;
+  Thread_Configuration thread_config RTEMS_ALIGNED(32);
 #if defined(RTEMS_MULTIPROCESSING)
   Objects_MP_Control  *the_global_object = NULL;
   bool is_global;
diff --git a/cpukit/score/src/threadcreateidle.c b/cpukit/score/src/threadcreateidle.c
index 4f16a57099..023e612022 100644
--- a/cpukit/score/src/threadcreateidle.c
+++ b/cpukit/score/src/threadcreateidle.c
@@ -58,7 +58,7 @@ static void _Thread_Create_idle_for_CPU(
   uintptr_tstorage_size
 )
 {
-  Thread_Configuration  config;
+  Thread_Configuration  config RTEMS_ALIGNED(32);
   Thread_Control   *idle;
   Status_Controlstatus;
 
diff --git a/testsuites/libtests/malloctest/init.c b/testsuites/libtests/malloctest/init.c
index ae3719c2cd..5bc5deeab0 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -1419,7 +1419,7 @@ rtems_task Init(
 )
 {
   void *p1;
-  rtems_time_of_day time;
+  rtems_time_of_day time RTEMS_ALIGNED(32);
   rtems_status_code status;
 
   TEST_BEGIN();
diff --git a/testsuites/samples/ticker/init.c b/testsuites/samples/ticker/init.c
index 86f87ad736..2f2929376f 100644
--- a/testsuites/samples/ticker/init.c
+++ b/testsuites/samples/ticker/init.c
@@ -47,7 +47,7 @@ rtems_task Init(
 )
 {
   rtems_status_code status;
-  rtems_time_of_day time;
+  rtems_time_of_day time RTEMS_ALIGNED(32);
 
   TEST_BEGIN();
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 2671c607a7..b26fb4c8ad 100644
--- a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
@@ -144,7 +144,7 @@ typedef struct {
 #define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
 #define CPU_STACK_MINIMUM_SIZE  (1024*4)
 #define CPU_SIZEOF_POINTER 8
-#define CPU_ALIGNMENT  8
+#define CPU_ALIGNMENT  16
 #define CPU_HEAP_ALIGNMENT CPU_ALIGNMENT
 #define CPU_STACK_ALIGNMENT16
 #define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 
 bsps/shared/freebsd/stand/efi/include/efi.h   |   87 ++
 .../shared/freebsd/stand/efi/include/efiapi.h | 1204 +
 .../shared/freebsd/stand/efi/include/eficon.h |  527 
 .../freebsd/stand/efi/include/eficonsctl.h|  134 ++
 .../shared/freebsd/stand/efi/include/efidef.h |  224 +++
 .../freebsd/stand/efi/include/efidevp.h   |  511 +++
 .../shared/freebsd/stand/efi/include/efierr.h |   68 +
 .../shared/freebsd/stand/efi/include/efigop.h |  121 ++
 .../shared/freebsd/stand/efi/include/efilib.h |  172 +++
 bsps/shared/freebsd/stand/efi/libefi/libefi.c |   63 +
 bsps/shared/freebsd/stand/efi/libefi/wchar.c  |   73 +
 13 files changed, 3495 insertions(+)
 create mode 100644 bsps/shared/freebsd/stand/efi/include/README
 create mode 100644 bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efi.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efiapi.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/eficon.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/eficonsctl.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efidef.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efidevp.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efierr.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efigop.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efilib.h
 create mode 100644 bsps/shared/freebsd/stand/efi/libefi/libefi.c
 create mode 100644 bsps/shared/freebsd/stand/efi/libefi/wchar.c

diff --git a/bsps/shared/freebsd/stand/efi/include/README 
b/bsps/shared/freebsd/stand/efi/include/README
new file mode 100644
index 00..bf821fae7e
--- /dev/null
+++ b/bsps/shared/freebsd/stand/efi/include/README
@@ -0,0 +1,36 @@
+/* $FreeBSD$ */
+/*-
+
+Files in this directory and subdirectories are subject to the following
+copyright unless superceded or supplemented by additional specific license
+terms found in the file headers of individual files.
+
+Copyright (c) 1998-2000 Intel Corporation
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+
+Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+
+THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL INTEL BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+OF THE POSSIBILITY OF SUCH DAMAGE. THE EFI SPECIFICATION AND ALL
+OTHER INFORMATION ON THIS WEB SITE ARE PROVIDED "AS IS" WITH NO
+WARRANTIES, AND ARE SUBJECT TO CHANGE WITHOUT NOTICE.
+
+*/
diff --git a/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h 
b/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
new file mode 100644
index 00..97b4a04865
--- /dev/null
+++ b/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
@@ -0,0 +1,275 @@
+/* $FreeBSD$ */
+/*++
+
+Copyright (c)  1999 - 2003 Intel Corporation. All rights reserved
+This software and associated documentation (if any) is furnished
+under a license and may only be used or copied in accordance
+with the terms of the license. Except as permitted by such
+license, no part of this software or documentation may be
+reproduced, stored in a retrieval system, or transmitted in any
+form or by any means without the express written consent of
+Intel Corporation.
+
+Module Name:
+
+efefind.h
+
+Abstract:
+
+EFI to compile bindings
+
+
+
+
+Revision History
+
+--*/
+
+#pragma pack()
+
+
+#ifdef __FreeBSD__
+#include 
+#elif __rtems__
+#include 
+#else
+//
+// Basic int types of various widths
+//
+
+#if (__STDC_VERSION__ < 199901L )
+
+// No ANSI C 1999/2000 stdint.h integer width declarations 
+
+#ifdef _MSC_EXTENSIONS
+
+// Use Microsoft C compiler integer width declarations 
+
+typedef unsigned __int64uint64_t;
+typedef __int64 

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

[Karel Gardas]

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-builder/config/gdb-common-1.cfg 
b/source-builder/config/gdb-common-1.cfg
index a52e64d..0fea334 100644
--- a/source-builder/config/gdb-common-1.cfg
+++ b/source-builder/config/gdb-common-1.cfg
@@ -109,8 +109,8 @@
%define gdb-host-libs -L '%{host_ldflags}'
  %endif
  %if %{gdb-python-config} != %{nil}
-  %define gdb-python-lib-filter awk 'BEGIN{FS=" 
"}/python/{for(i=1;i

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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.org/branches/master/user/bsps/bsps-aarch64.html#raspberry-pi-4b

If you would like to work on that, then please clone the docs repo from 
here: git://git.rtems.org/rtems-docs.git


and edit user/bsps/aarch64/raspberrypi4.rst file

You will also need to have some tools installed in order to work on 
that, it is well described in the first paragraph here: 
https://docs.rtems.org/


If you are unsure, wait for official deny or confirmation of the info 
provided by me...


Thanks,
Karel

On 4/9/23 09:53, Mohd Noor Aman wrote:

The readme file includes all links and steps for setting up developping
environment for the raspberry pi 4. Added cheap JTAG adapters list which are
tried and tested. Links for references for raspberry pi 4 are also added.
---
  bsps/aarch64/raspberrypi/README | 86 +
  1 file changed, 86 insertions(+)
  create mode 100644 bsps/aarch64/raspberrypi/README

diff --git a/bsps/aarch64/raspberrypi/README b/bsps/aarch64/raspberrypi/README
new file mode 100644
index 00..9c6465fd5e
--- /dev/null
+++ b/bsps/aarch64/raspberrypi/README
@@ -0,0 +1,86 @@
+BSP for the Raspberry Pi aarch64 ArmV8 board
+
+It currently supports the following peripheral:
+-- Console using the PL011 UART0 Raspberry Pi 4 has 6 UARTs, 5 PL011 based and 
1
+   miniuart based. Only PL011 UART0 is supported. No support for Mini-UART. The
+   console driver only works with polled mode right now.
+
+-- The clock driver uses the ARM Generic Timer.
+
+-- GIC-400 is compatible with gicv2 headers and is supported by bsp
+
+
+How to boot: Steps on how to boot RTEMS on raspberry pi 4B is given here.
+
+
https://docs.rtems.org/branches/master/user/bsps/bsps-aarch64.html#raspberry-pi-4b
+
+
+To do list: It would be nice to get support in the BSP for the following:
+-- SD card
+-- SPI
+-- I2C
+-- GPIO
+-- Graphics console
+-- Sound
+
+
+JTAG debugging: OpenOCD supports bcm2711 as a target. Many interfaces are
+supported to work with bcm2711. A few of them which I have tested personally
+are.
+
+FT232H: Nice and cheap adapter which supports SPI, I2C JTAG using MPSSE engine.
+It can either be used as a UART-to-USB or JTAG adapter at a time.
+
+Esp-prog: its just a FT2232H breakout board which can connect using FT2232H
+derivatives cfg
+
+Raspberry Pi SBC: Yes, you can use a raspberry pi to debug another raspberry pi
+
+Raspberry Pi Pico: As of now, openocd support for Raspberry pi Pico is under
+review, in the meantime you can just build forked version of OpenOCD, and use
+pico-dirtyJTAG.uf2 for raspberry pi pico.
+https://sourceforge.net/u/phdussud/openocd
+https://github.com/phdussud/pico-dirtyJtag
+
+Some of the interfaces which I have not used personally but can most probably 
be
+used are:
+
+FT2XXXH series :  They are of same family as FT232H, just have different amount
+of MPSSE engine, Which determines how many many protocols can be ran
+simultaneously.
+
+BeagleBone Black: It can be used with OpenOCDs am335xgpio drivers to be used as
+JTAG/SWD programmer
+
+Almost every SBC with GPIO: It can be used by openOCD through libgpiod library
+
+
+Openocd compilation steps for Raspberry pi:
+
+git clone http://openocd.zylin.com/openocd
+cd openocd
+./bootstrap
+./configure --enable-sysfsgpio --enable-bcm2835gpio
+make -j$(nproc)
+
+
+Credits and links:
+
+  A bare metal example which includes examples for interrupts, SMP, bluetooth
+  https://github.com/isometimes/rpi4-osdev/
+
+  A Raspberry pi 4 port for RT-Thread which support Ethernet, mailbox and UARTs
+  https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64
+
+  Vxworks is a Real-Time OS which has a public SDK for development,not open
+  source. The steps for booting Vxworks is given here.
+  
https://labs.windriver.com/downloads/wrsdk-vxworks7-docs/2203/README_raspberrypi4b.html
+
+  s-matyukevich has done a great job for baremetal examples for raspberry pi 
3B,
+  and rhythm16 port all that code for raspberry pi 4B. Worth checking out.
+  https://s-matyukevich.github.io/raspberry-pi-os/
+  https://github.com/rhythm16/rpi4-bare-metal/
+
+  There are also some examples from valvers about bare metal for raspberrypi
+  family
+  
https://www.valvers.com/open-software/raspberry-pi/bare-metal-programming-in-c-part-1/
\ No newline at end of file


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

FreeBSD libefi import -- how to proceed?

[Karel Gardas]

  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 foreseeable future or even ever


- as minimalistic as possible. Include only files really needed by 
RTEMS. Where making compilation issues #ifdef __rtems__ as usual.


What exactly I need to import is:

https://github.com/freebsd/freebsd-src/tree/main/stand/efi/include
https://github.com/freebsd/freebsd-src/tree/main/stand/efi/libefi

In 'include' I'd like to omit risc/arm/arm64 platform specific 
subdirectories for now.


Anyway, plan is to put both those directories into 
bsps/shared/freebsd/stand/efi to mimic perfectly location in FBSD tree 
and to have them ready to be reusable later for arm64 and risc-v BSPs 
consumption.



Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 then marked as failed although otherwise it may run
well to its end.
Adding handle of SIGTRAP as a nostop means that GDB will not exit
after receiving SIGTRAP but rather be forced to continue as nothing
would happen and the running testcase will have a chance to finish
its business.
---
 tester/rtems/testing/bsps/stm32h7-stlink.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tester/rtems/testing/bsps/stm32h7-stlink.ini 
b/tester/rtems/testing/bsps/stm32h7-stlink.ini
index bf57bee..2c375f5 100644
--- a/tester/rtems/testing/bsps/stm32h7-stlink.ini
+++ b/tester/rtems/testing/bsps/stm32h7-stlink.ini
@@ -40,4 +40,5 @@ gdb_script = bsp_gdb_script
 requires   = bsp_tty_dev, bsp_gdb_script, target_pretest_command, 
target_posttest_command
 bsp_gdb_script = target extended-remote :61234
  load
+ handle SIGTRAP nostop
  cont
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help regarding Building x86_64 BSP

[Karel Gardas]

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 function ‘grub_install_generate_image’:
util/mkimage.c:1386:41: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
  1386 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 
(header_

size);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
   857 |   __typeof__((o64)->field) tmp_;    \
   |    ^~~~
util/mkimage.c:1386:9: note: in expansion of macro ‘PE_OHDR’
  1386 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 
(header_

size);
   | ^~~
util/mkimage.c:1387:40: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
  1387 | PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 
(layout.s

tart_address);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
   857 |   __typeof__((o64)->field) tmp_;    \
   |    ^~~~
util/mkimage.c:1387:9: note: in expansion of macro ‘PE_OHDR’
  1387 | PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 
(layout.s

tart_address);
   | ^~~

Maybe one needs a new version of grub sources for gcc 12?


GRUB 2.06 is the last available release. The release cadence is 2 years 
and next version should be released around this summer. I would not like 
to go to git version in the meantime, but rather stick to released version.


Possible and working (tested on Fedora 37 and Ubuntu 20.04) workaround 
is to use --disable-werror as all the related errors are just warnings.


The patch already sent, testing and reporting from your side would be 
highly appreciated.


Thanks,
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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 @@ URL: https://www.gnu.org/software/grub/index.html
 --mandir=%{_mandir} --infodir=%{_infodir} \
 --with-platform=%{grub2_platform} \
 --target=%{grub2_target} \
---disable-libzfs   # broken on FreeBSD and not needed at all
+--disable-libzfs \ # broken on FreeBSD and not needed at all
+--disable-werror   # fixes compilation by GCC 12
 
   %{__make} %{?_smp_mflags} all
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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-eval
+  value: (ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA)
+- enabled-by: true
+  value: ARMV7M_MPU_CTRL_ENABLE


The patch set looks good, but please make the current value 
(ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA) the default value.


Done. I also fixed imxrt by moving mpu opt before bspopts in order to 
get define generated into the bspopts.h.


Thanks for the review and suggestion on this!
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c | 2 +-
 .../boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c| 2 +-
 .../stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c | 2 +-
 .../stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c   | 2 +-
 cpukit/score/cpu/arm/include/rtems/score/armv7m.h  | 3 ++-
 7 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/bsps/arm/imxrt/start/bspstarthooks.c 
b/bsps/arm/imxrt/start/bspstarthooks.c
index 684c263152..482300a1bc 100644
--- a/bsps/arm/imxrt/start/bspstarthooks.c
+++ b/bsps/arm/imxrt/start/bspstarthooks.c
@@ -46,7 +46,7 @@ BSP_START_TEXT_SECTION void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(imxrt_config_mpu_region, imxrt_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, imxrt_config_mpu_region, 
imxrt_config_mpu_region_count);
 }
 
 BSP_START_TEXT_SECTION void bsp_start_hook_1(void)
diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
index eda503925f..636a124d64 100644
--- a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
@@ -62,7 +62,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
index 8d34e357ee..0a25253215 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
@@ -63,7 +63,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
index 8d34e357ee..0a25253215 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
@@ -63,7 +63,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
index 1bb81e3b60..1fa8563477 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
@@ -79,7 +79,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c
index 8d34e357ee..0a25253215 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c
@@ -63,7 +63,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
index 10b3955671..2b1e785cf7 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
@@ -691,6 +691,7 @@ static inline void _ARMV7M_MPU_Disable_region(
 }
 
 static inline void _ARMV7M_MPU_Setup(
+  uint32_t ctrl,
   const ARMV7M_MPU_Region_config *cfg,
   size_t cfg_count
 )
@@ -726,7 +727,7 @@ static inline void _ARMV7M_MPU_Setup(
 _ARMV7M_MPU_Disable_region(mpu, region);
   }
 
-  mpu->ctrl = ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA;
+  mpu->ctrl = ctrl;
   scb->shcsr |= 

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

[Karel Gardas]

The patch also enables usage of the option on imxrt and stm32h7 based BSPs.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/imxrt/bspimxrt.yml |  2 ++
 spec/build/bsps/arm/optmpuctrl.yml | 25 +
 spec/build/bsps/arm/stm32h7/grp.yml|  2 ++
 3 files changed, 29 insertions(+)
 create mode 100644 spec/build/bsps/arm/optmpuctrl.yml

diff --git a/spec/build/bsps/arm/imxrt/bspimxrt.yml 
b/spec/build/bsps/arm/imxrt/bspimxrt.yml
index b666be5241..e05ceeccd9 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt.yml
@@ -165,6 +165,8 @@ links:
   uid: linkcmdsmemory
 - role: build-dependency
   uid: ../../bspopts
+- role: build-dependency
+  uid: ../optmpuctrl
 source:
 - bsps/arm/imxrt/console/console.c
 - bsps/arm/imxrt/dts/imxrt1050-evkb.c
diff --git a/spec/build/bsps/arm/optmpuctrl.yml 
b/spec/build/bsps/arm/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 Gardas
+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-eval
+  value: (ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA)
+- enabled-by: true
+  value: ARMV7M_MPU_CTRL_ENABLE
+enabled-by: true
+format: '{}'
+links: []
+name: ARMV7M_MPU_CTRL_DEFAULT
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/grp.yml 
b/spec/build/bsps/arm/stm32h7/grp.yml
index 9735b6734c..c415a7a71d 100644
--- a/spec/build/bsps/arm/stm32h7/grp.yml
+++ b/spec/build/bsps/arm/stm32h7/grp.yml
@@ -24,6 +24,8 @@ links:
   uid: ../../objmem
 - role: build-dependency
   uid: optenmpualign
+- role: build-dependency
+  uid: ../optmpuctrl
 - role: build-dependency
   uid: optenuart4
 - role: build-dependency
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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. Compatibility with previous behavior and API
is preserved.


Is this really a BSP-specific choice or more a user option which should 
be controlled by a BSP option (through config.ini)?


config.ini would be even more generic and probably more elegant too. 
However for upstreaming I took a more conservative approach to have a 
chance.


Let me ask what do you prefer and what will you support? I'm happy to 
write that as long as it is reasonable simple and makes chance to 
upstream higher.


My goal is simple:
I'm working on BSP for Precidata SL-3011 board. The board is using 
STM32H747. Board firmware responsible for hardware management runs on 
CM4 while RTEMS and app code will run on CM7 and will be using firmware 
services by calling some API. For communication between both domains we 
use SRAM4. To be able to print hard fault from RTEMS on CM7 I need either:


- keep cache disabled for SRAM4 region even for hard fault (hence MPU 
change proposed)


or

- disable cache in print exception frame directly which involves quite a 
bit of hacking around and looks to be more source code invasive than MPU 
change.


Thanks!
Karel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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:   Precidata
---
 cpukit/score/cpu/arm/include/rtems/score/armv7m.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
index 744dca26d3..cfd676cce7 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
@@ -701,7 +701,8 @@ static inline void _ARMV7M_MPU_Disable_region(
   mpu->rasr = 0;
 }
 
-static inline void _ARMV7M_MPU_Setup(
+static inline void _ARMV7M_MPU_Setup_with_ctrl(
+  uint32_t ctrl,
   const ARMV7M_MPU_Region_config *cfg,
   size_t cfg_count
 )
@@ -737,13 +738,21 @@ static inline void _ARMV7M_MPU_Setup(
 _ARMV7M_MPU_Disable_region(mpu, region);
   }
 
-  mpu->ctrl = ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA;
+  mpu->ctrl = ctrl;
   scb->shcsr |= ARMV7M_SCB_SHCSR_MEMFAULTENA;
 
   _ARM_Data_synchronization_barrier();
   _ARM_Instruction_synchronization_barrier();
 }
 
+static inline void _ARMV7M_MPU_Setup(
+  const ARMV7M_MPU_Region_config *cfg,
+  size_t cfg_count
+)
+{
+  _ARMV7M_MPU_Setup_with_ctrl(ARMV7M_MPU_CTRL_ENABLE | 
ARMV7M_MPU_CTRL_PRIVDEFENA, cfg, cfg_count);
+}
+
 #endif /* ASM */
 
 #endif /* ARM_MULTILIB_ARCH_V7M */
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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
@@ -31,6 +31,10 @@
 
 const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = {
 {
+ /*| memory  | shareability  | privileged | unprivileged | executability |
+   |  type   |   |   perms|perms |   |
+   +-+---++--+---+ 
*/
+ /*  normal  | not shareable | RW | RW   | NO */
   .begin = stm32h7_memory_sram_axi_begin,
   .end = stm32h7_memory_sram_axi_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -38,6 +42,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RW  | RW   | NO */
   .begin = stm32h7_memory_sdram_1_begin,
   .end = stm32h7_memory_sdram_1_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -45,6 +50,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RW  | RW   | NO */
   .begin = stm32h7_memory_sdram_2_begin,
   .end = stm32h7_memory_sdram_2_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -52,12 +58,14 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] 
= {
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RO | no access| YES */
   .begin = bsp_section_start_begin,
   .end = bsp_section_text_end,
   .rasr = ARMV7M_MPU_RASR_AP(0x5)
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RO | no access| NO */
   .begin = bsp_section_rodata_begin,
   .end = bsp_section_rodata_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -65,6 +73,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* device  | not shareable | RW | RW   | NO */
   .begin = bsp_section_nocache_begin,
   .end = bsp_section_nocachenoload_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -72,6 +81,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x2)
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* n/a | n/a   | n/a| n/a  | NO */
   .begin = stm32h7_memory_null_begin,
   .end = stm32h7_memory_null_end,
   .rasr = ARMV7M_MPU_RASR_XN | ARMV7M_MPU_RASR_ENABLE,
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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-frame-print.c
index 4bb1efedec..6a773d9e2d 100644
--- a/cpukit/score/cpu/arm/arm-exception-frame-print.c
+++ b/cpukit/score/cpu/arm/arm-exception-frame-print.c
@@ -32,6 +32,9 @@
 #include 
 
 #include 
+#if defined(ARM_MULTILIB_ARCH_V7M)
+#include 
+#endif
 #include 
 
 static void _ARM_VFP_context_print( const ARM_VFP_context *vfp_context )
@@ -57,6 +60,103 @@ static void _ARM_VFP_context_print( const ARM_VFP_context 
*vfp_context )
 #endif
 }
 
+static void _ARM_Cortex_M_fault_info_print(void)
+{
+#if defined(ARM_MULTILIB_ARCH_V7M)
+/* prints content of additional debugging registers
+ * available on Cortex-Mx where x > 0 cores.
+ */
+uint32_t cfsr = _ARMV7M_SCB->cfsr;
+uint8_t mmfsr = ARMV7M_SCB_CFSR_MMFSR_GET(cfsr);
+uint8_t bfsr = (ARMV7M_SCB_CFSR_BFSR_GET(cfsr) >> 8);
+uint16_t ufsr = (ARMV7M_SCB_CFSR_UFSR_GET(cfsr) >> 16);
+uint32_t hfsr = _ARMV7M_SCB->hfsr;
+if (mmfsr > 0) {
+printk("MMFSR= 0x%08" PRIx32 " (memory fault)\n", mmfsr);
+if ((mmfsr & 0x1) != 0) {
+printk("  IACCVIOL   : 1  (instruction access violation)\n");
+}
+if ((mmfsr & 0x2) != 0) {
+printk("  DACCVIOL   : 1  (data access violation)\n");
+}
+if ((mmfsr & 0x8) != 0) {
+printk("  MUNSTKERR  : 1  (fault on unstacking on exception 
return)\n");
+}
+if ((mmfsr & 0x10) != 0) {
+printk("  MSTKERR: 1  (fault on stacking on exception 
entry)\n");
+}
+if ((mmfsr & 0x20) != 0) {
+printk("  MLSPERR: 1  (fault during lazy FP stack 
preservation)\n");
+}
+if ((mmfsr & 0x80) != 0) {
+printk("  MMFARVALID : 1 -> 0x%08" PRIx32 " (error address)\n", 
_ARMV7M_SCB->mmfar);
+}
+else {
+printk("  MMFARVALID : 0  (undetermined error address)\n");
+}
+}
+if (bfsr > 0) {
+printk("BFSR = 0x%08" PRIx32 " (bus fault)\n", bfsr);
+if ((bfsr & 0x1) != 0) {
+printk("  IBUSERR: 1  (instruction fetch error)\n");
+}
+if ((bfsr & 0x2) != 0) {
+printk("  PRECISERR  : 1  (data bus error with known exact 
location)\n");
+}
+if ((bfsr & 0x4) != 0) {
+printk("  IMPRECISERR: 1  (data bus error without known exact 
location)\n");
+}
+if ((bfsr & 0x8) != 0) {
+printk("  UNSTKERR   : 1  (fault on unstacking on exception 
return)\n");
+}
+if ((bfsr & 0x10) != 0) {
+printk("  STKERR : 1  (fault on stacking on exception 
entry)\n");
+}
+if ((bfsr & 0x20) != 0) {
+printk("  LSPERR : 1  (fault during lazy FP stack 
preservation)\n");
+}
+if ((bfsr & 0x80) != 0) {
+printk("  BFARVALID  : 1 -> 0x%08" PRIx32 "  (error address)\n", 
_ARMV7M_SCB->bfar);
+}
+else {
+printk("  BFARVALID  : 0  (undetermined error address)\n");
+}
+}
+if (ufsr > 0) {
+printk("UFSR = 0x%08" PRIx32 " (usage fault)\n", ufsr);
+if ((ufsr & 0x1) != 0) {
+printk("  UNDEFINSTR : 1  (undefined instruction issued)\n");
+}
+if ((ufsr & 0x2) != 0) {
+printk("  INVSTATE   : 1  (invalid instruction state (Thumb not 
set in EPSR or invalid IT state in EPSR))\n");
+}
+if ((ufsr & 0x4) != 0) {
+printk("  INVPC  : 1  (integrity check failure on 
EXC_RETURN)\n");
+}
+if ((ufsr & 0x8) != 0) {
+printk("  NOCP   : 1  (coprocessor instruction issued but 
coprocessor disabled or non existent)\n");
+}
+if ((ufsr & 0x100) != 0) {
+printk("  UNALIGNED  : 1  (unaligned access operation 
occurred)\n");
+}
+if ((ufsr & 0x200) != 0) {
+printk("  DIVBYZERO  : 1  (division by zero)");
+}
+}
+if ((hfsr & (ARMV7M_SCB_HFSR_VECTTBL_MASK | ARMV7M_SCB_HFSR_DEBUGEVT_MASK 
| ARMV7M_SCB_HFSR_FORCED_MASK)) != 0) {
+printk("HFSR = 0x%08" PRIx32 " (hard fault)\n", hfsr);
+if ((hfsr & ARMV7M_SCB_HFSR_VECTTBL_MASK) != 0) {
+printk("  VECTTBL: 1  (error in address located in vector 
table)\n");
+}
+if ((hfsr & ARMV7M_SCB_HFSR_FORCED_MASK) != 0) {
+printk("  FORCED : 1  (configurable fault escalated to hard 
fault)\n");
+}
+if ((hfsr & ARMV7M_SCB_HFSR_DEBUGEVT_MASK) != 0) {
+printk("  DEBUGEVT   : 1  (debug event occurred with debug system 
disabled)\n");
+}
+}
+#endif
+}
 void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
 {
   printk(
@@ -100,4 +200,5 @@ 

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

[Karel Gardas]

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

  user/bsps/arm/stm32h7.rst | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 RSB master now 
have this warning on each link:

[3405/4331] Linking build/riscv/rv64imafdc/testsuites/samples/minimum.exe
/home/alan/rtems/tools/6/lib/gcc/riscv-rtems6/12.2.1/../../../../riscv-rtems6/bin/ld:
 warning: 
/home/alan/rtems/rtems/build/riscv/rv64imafdc/testsuites/samples/base_sp.exe 
has a LOAD segment with RWX permissions

I was trying to back up commits in the RTEMS and RSB repositories to see 
when it started, but I have not figured it out yet.


My host is Ubuntu 20.04.1 LTS x86_64.

Thanks,
Alan

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problem when in booting amd64 BSP

[Karel Gardas]

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 was trying to run the amd64 BSP of RTEMS in 
order to be able to test on it for my GSoC 2023 project and was 
following the guide on RTEMS User Manual 9.18, it took me a few days to 
follow all the steps on it but after finally putting the hello.exe file 
(built for x86_64 & amd64) and copying it into /boot/kernel/kernel of 
the FreeBSD 11.2 virtual system, it crashed and now doesn't boot up at 
all. I tried doing the same even on a FreeBSD 13 virtual machine but it 
had the same problem and didn't end up booting for me. I also 
double-checked everything to make sure I wasn't making a silly mistake 
or having a small problem. The attached screenshot is from trying to 
boot it on the FreeBSD 13 virtual machine. If somebody has some idea why 
this error is occurring, I would really appreciate their help!


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help regarding Building x86_64 BSP

[Karel Gardas]

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 Source Builder?


The only information I can contribute to this discussion are the results 
our Continuous Integration Server currently creates when building x86_64 
tools with the RTEMS Source Builder:


almalinux 8.7: OK   [gcc (GCC) 8.5.0]
debian 11: OK   [gcc (Debian 10.2.1-6) 10.2.1]
fedora 37: Failure  [gcc (GCC) 12.2.1]
opensuse-leap 15.4: Failure [gcc (SUSE Linux) 12.2.1]
ubuntu 22.04: Failure   [gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0]

These builds were for RTEMS 6 and RSB 


Just a remark to table above. Ubuntu 22.04 LTS default GCC is 11.x and 
it's perfectly able to build x86_64 tools (tested by me).


On RHEL8, default gcc is 8.5.x and it should be ok.
On RHEL9, default gcc is 11.3.x and it should also be able to build 
tools fine.


The only issue on RHELx is that makeinfo is missing so you either need 
to install from different repo or by hand.


SLES testing in whatever form is out of my reach.

Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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.c   | 4 
 .../arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c | 4 
 5 files changed, 22 insertions(+)

diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
index a8a9ff0b4b..2d53f114c1 100644
--- a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
@@ -49,6 +49,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
index a8a9ff0b4b..2d53f114c1 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
@@ -49,6 +49,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
index 2dc9542597..269288d2c0 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
@@ -91,7 +91,13 @@
 
 #include "stm32h7xx.h"
 #include 
+#ifdef __rtems__
+#include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
 
+#endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
 #endif /* HSE_VALUE */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
index 1260694d8b..59e66e133e 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
@@ -93,6 +93,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
index db11aa19b1..52e8eaafc4 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
@@ -48,6 +48,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2400) /*!< Value of the External 
oscillator in Hz */
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help regarding Building x86_64 BSP

[Karel Gardas]

On 3/8/23 01:42, Joel Sherrill wrote:

Did you build the x86_64 tools and qemu using the RTEMS Source Builder?


Honestly, I do not remember, this is more than year old, but since this 
is in 6-tools directory, in fact in two incarnation, I would bet this 
was done by RSB:


$ find . -name 'edk2*'
./6-tools-2021-12-09-x86_64/share/qemu/edk2-i386-secure-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-licenses.txt
./6-tools-2021-12-09-x86_64/share/qemu/edk2-x86_64-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-x86_64-secure-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-i386-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-i386-vars.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-aarch64-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-arm-vars.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-arm-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-arm-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-i386-vars.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-aarch64-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-i386-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-arm-vars.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-i386-secure-code.fd
./6-tools-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: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. So, I needed to install QEMU
 >> and had to build the UEFI firmware,OVMF by Tianocore in order to
build
 >> it.
 >
 > Indeed, they still list Ubutnu 16.04 LTS as a build OS. Hmm, I
would go
 > with VM for this. You need to build it just once...

Investigating more, it looks like qemu build those too, so there is no
need to deal with TianoCore alone anymore. My 7.2.0 install contains:

$ find qemu-7.2.0/share/qemu/ -name 'edk2*'
qemu-7.2.0/share/qemu/edk2-arm-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-code.fd
qemu-7.2.0/share/qemu/edk2-arm-vars.fd
qemu-7.2.0/share/qemu/edk2-i386-secure-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-secure-code.fd
qemu-7.2.0/share/qemu/edk2-aarch64-code.fd
qemu-7.2.0/share/qemu/edk2-i386-code.fd
qemu-7.2.0/share/qemu/edk2-i386-vars.fd
qemu-7.2.0/share/qemu/edk2-licenses.txt

Ditto for Qemu build by RSB. Will send you tarball of scripts I'm using
for building and running rtems.exe on those...



Karel
___
devel mailing list
devel@rtems.org <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help regarding Building x86_64 BSP

[Karel Gardas]

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 
build it natively within RTEMS source. So, I needed to install QEMU 
and had to build the UEFI firmware,OVMF by Tianocore in order to build 
it. 


Indeed, they still list Ubutnu 16.04 LTS as a build OS. Hmm, I would go 
with VM for this. You need to build it just once...


Investigating more, it looks like qemu build those too, so there is no 
need to deal with TianoCore alone anymore. My 7.2.0 install contains:


$ find qemu-7.2.0/share/qemu/ -name 'edk2*'
qemu-7.2.0/share/qemu/edk2-arm-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-code.fd
qemu-7.2.0/share/qemu/edk2-arm-vars.fd
qemu-7.2.0/share/qemu/edk2-i386-secure-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-secure-code.fd
qemu-7.2.0/share/qemu/edk2-aarch64-code.fd
qemu-7.2.0/share/qemu/edk2-i386-code.fd
qemu-7.2.0/share/qemu/edk2-i386-vars.fd
qemu-7.2.0/share/qemu/edk2-licenses.txt

Ditto for Qemu build by RSB. Will send you tarball of scripts I'm using 
for building and running rtems.exe on those...


Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help regarding Building x86_64 BSP

[Karel Gardas]

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. So, I needed to install QEMU and had to 
build the UEFI firmware,OVMF by Tianocore in order to build it. 


Indeed, they still list Ubutnu 16.04 LTS as a build OS. Hmm, I would go 
with VM for this. You need to build it just once...


Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 sync branches 
since they diverged due to patches pushed into both directions without a 
proper syncing...


Thanks,
Karel

On 3/3/23 21:35, Kinsey Moore wrote:

These patches look good to me. Thanks for this contribution!

Kinsey


On Fri, Mar 3, 2023 at 9:54 AM Padmarao Begari 
mailto:padmarao.beg...@microchip.com>> 
wrote:


Update the CGEM driver with adding the phy address and
the clock to read it from the device tree.

The patches are based upon latest rtems-libbsd tree at 6-freebsd-12
(https://git.rtems.org/rtems-libbsd.git
 branch 6-freebsd-12)
at commit id 1aa4cb8568594aa54238c9fbf2cc0f3ea4edec7f

v2:
- Add changes gated behind #ifdef __rtems__
- Use braces {} with if/else for a single line
- Drop weak symbol patch

Padmarao Begari (2):
   freebsd/cgem: Add phy address to read it from device tree
   freebsd/cgem: Read clock frequency from device tree

  freebsd/sys/dev/cadence/if_cgem.c | 72 +--
  1 file changed, 69 insertions(+), 3 deletions(-)

-- 
2.25.1


___
devel mailing list
devel@rtems.org 
http://lists.rtems.org/mailman/listinfo/devel



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 before trying again.


Not sure how far you went. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific 
hardware/os

platform. So basically you get no_std capable compiler

(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
sharp edges for RTEMS.

Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not 
cortex-

mX).


Something is running:

silence:/tmp$ cat hello-rtems.rs

#![no_std]
#![no_main]

use core::panic::PanicInfo;
use core::ffi::c_char;
use core::ffi::c_int;

extern "C" {
fn puts(str: *const c_char) -> c_int;
}

#[no_mangle]
pub fn main() -> ! {
unsafe {
puts(b"Rust says hello to hosting RTEMS\n\0".as_ptr() as *const 
i8);

}
loop {}
}

#[panic_handler]
fn panic(_: ) -> ! {
  loop {}
}

silence:/tmp$ /tmp/rustc-rtems-arm/bin/rustc -g -Z verbose 
--target=arm-rtems hello-rtems.rs -lrtemscpu -lrtemsbsp -lrtemsdefaultconfig


silence:/tmp$ file hello-rtems.exe
hello-rtems.exe: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
statically linked, with debug_info, not stripped


silence:/tmp$ ~rtems/sfw/qemu-7.2.0/bin/qemu-system-arm -serial null 
-serial mon:stdio -nographic -M xilinx-zynq-a9 -m 512M -kernel 
/tmp/hello-rtems.exe

Rust says hello to hosting RTEMS

QEMU 7.2.0 monitor - type 'help' for more information
(qemu) q
silence:/tmp$


Note: this is hacked rust-lang.org rust compiler, not gccrs project and 
soon to be released GCC 13.


The biggest problem and probably soon to be source of headaches is 
mixture of LLVM's compiler-rt and GCC's libgcc binaries. This means once 
you employ for example arithmetic you need to add
-C link-arg=-Wl,--allow-multiple-definition otherwise you would get 
multiple definitions symbols error.


Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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> wrote:
 >
 >
 >> -Original Message-
 >> From: devel mailto:devel-boun...@rtems.org>> On Behalf Of Karel Gardas
 >> Sent: Montag, 27. Februar 2023 09:16
 >> To: j...@rtems.org <mailto:j...@rtems.org>; Vihas Makwana
mailto:makvi...@gmail.com>>
 >> Cc: rtems-de...@rtems.org <mailto:rtems-de...@rtems.org>
mailto:devel@rtems.org>>
 >> Subject: 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. The process is generally:
 >>
 >> (1) tune Rust compiler to cross-compile correctly for specific
hardware/os
 >> platform. So basically you get no_std capable compiler


You should be able to compile gcc rust NOW to target CPU-rtems. I would
expect minor tweaking of configuration both in configure scripting and 
likely

in the Rust run-time libraries. For example, with the Standard C++ Library
there are configuration settings for *-rtems which pick the threading and
synchronization model. Rust's run-time adapter with GCC should be similar.


There is a slight misunderstanding going here. I'm not talking about 
gccrs rust frond-end project which got merged into GCC to become part of 
GCC 13 in autumn last year to be released this spring probably. I'm 
talking and AFAIK Jan too about real Rust as distributed/provided by 
https://www.rust-lang.org/.


The messages from gccrs project are kind of mixed and clearly warns that 
even with GCC 13, the front-end would be good just for GCC rust ongoing 
development and not yet for let say Rust code in Linux kernel. I write 
that not to play that attempt down, in fact gccrs people work is 
outstanding, I write that just to remark that it may take some time 
before it's ready for general "consumption".


Hence, when investigating Rust for RTEMS, I went to rust-lang.org and 
investigated that because after all, this is still reference Rust 
implementation...



Not sure if I did not confused you with my (2) libc remark. I of course
mean Rust's libc (that means rust code) to be build on top of
RTEMS/Newlib/libbsd combination. It'll be interesting project
especially
if the requirement later would be to support both binary targets: e.g.
RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for
full-blown configuration. Anyway, for now, I would start with libbsd as
this should make project proceeding faster IMHO.


You shouldn't need RTEMS or libbsd built until you link real executables
you want to run. All needed POSIX headers are present from newlib.


But I'm at the stage I'd like to link my Rust hello world with RTEMS 
BSP, that's what someone expects at the end anyway. :-)



I was test building rust just like C, C++, and Ada. Build the toolchain and
then build RTEMS.


So you liked rust + RTEMS well? Cool!

Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 
Subject: 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. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific hardware/os
platform. So basically you get no_std capable compiler

(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
sharp edges for RTEMS.

Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not cortex-
mX).



Hi Karel,

Very interesting work. I am currently trying to reach the same goal.
The steps I came up with are a bit different:
A.) Build working llvm toolchain for RTEMS (figure out all flags etc., maybe 
building RTEMS with llvm as a bonus)
B.) Build rustc with the "RTEMS-llvm" as backend


Honestly I'm not so sure (A) and (B) are necessary for rustc port. Or 
perhaps I do not precisely follow what you mean, but IMHO what you need 
is to get ABI and linking with RTEMS binaries right. And this applies 
also to RTEMS being build by GCC toolchain. This is objective of my (1) 
work.



C.) Start with no_std and then inch forward to building the stdlib

I work currently on step A (see my llvm experiments in the other thread) and 
started to look at the build stages for rustc.
If you have any tips for the configuration from your step (1), it would be 
greatly appreciated.
My hope is that with the results of step A I can reuse the libc from the 
standard rtems-gcc build environment as this is provided conveniently via rsb.


Not sure if I did not confused you with my (2) libc remark. I of course 
mean Rust's libc (that means rust code) to be build on top of 
RTEMS/Newlib/libbsd combination. It'll be interesting project especially 
if the requirement later would be to support both binary targets: e.g. 
RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for 
full-blown configuration. Anyway, for now, I would start with libbsd as 
this should make project proceeding faster IMHO.



I am really looking forward to seeing rust supported on RTEMS.


Me too!

Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Interested for GSoC 2023

[Karel Gardas]

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. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific 
hardware/os platform. So basically you get no_std capable compiler


(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth 
sharp edges for RTEMS.


Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not 
cortex-mX).


Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Jetson Nano BSP

[Karel Gardas]

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 locked up by binary driver NVidia provides only 
for selected number of platforms --- if not just for the only one: 
Linux. So very questionable how you would unlock that on RTEMS during 
the limited time of GSoC. Just see what Nouveau folks are doing: 
https://nouveau.freedesktop.org/ -- for years and they just barely got 
to 3D acceleration. Just clone their git repo, see number of patches, 
lines of code provided and number of people involved and I think you 
will get an idea how mamooth task this is...




In the case of large hobby projects or maybe the initial days of a 
startup(seed ones), a real-time system that can work with boards having 
good GPU can do wonders.
For example, for an autonomous vehicle L2, L3 autonomy can be achieved 
using a 60W Jetson AGX orin, hence if RTEMS support is added to the 
board, it might help create an awesome system to handle all the critical 
time constraints necessary for the vehicle and give it the ability to 
coordinate a large number of concurrent activities.


If you are interested in machine vision based on AI and robotics, why 
not to look around for more open-source friendly solution? Recently just 
found i.MX 8M Plus and their claimed 2.3 TOPS NPU. Certainly not that 
powerful like NVidia, but NXP is historically more friendly to 3rd party 
OSes. Not sure about NPU, have not had a time to investigate that yet, 
but perhaps you do?


Also, with i.MX 8M Plus you still do have a chance to use AI Vision in 
non-real time manner running on top of Linux and run RTEMS real-time 
tasks on built in Cortex-M7 -- I mean if you decide that this particular 
BSP may be your GSoC. :-)


https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS


Honestly I'd rather see a new BSP for a decent RISC-V board.


I was reading about RISC-V and their comparison with ARM SBC and in one 
blog I read this - "ARM processors have benefited from a lot more 
research, funding, and development than RISC-V. This means that it can 
be argued that RISC-V is being left behind"


Do not worry about it. RISC-V is here and will stay. A lot was already 
invested into it and much more will still be...


Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: warnings report on builder wrong?

[Karel Gardas]

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
 > 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 default build settings. But these warnings
 > looked pretty generic at first glance.
 >

 Don't worry about delay, I was just reporting those as you IIRC asked
 for warnings fixes and I just saw evidence that builder is not showing
 actual state.

 Is it possible that software building the table for the report is a bit
 buggy and ignores warnings or it assign those into wrong category? If
 you would have build logs from those then such judgment is easy to do...


Chris wrong the bsp builder so I have no idea. But I saw ones which were
triggered in bsp specific files along with some tests. The tests might have
gotten counted elsewhere. Fix them if you see them.


It could do with some love. I am not able to take a look for a few weeks.

I suggest a ticket is created.


https://devel.rtems.org/ticket/4856

Karel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: warnings report on builder wrong?

[Karel Gardas]

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 default build settings. But these warnings 
looked pretty generic at first glance.




Don't worry about delay, I was just reporting those as you IIRC asked 
for warnings fixes and I just saw evidence that builder is not showing 
actual state.


Is it possible that software building the table for the report is a bit 
buggy and ignores warnings or it assign those into wrong category? If 
you would have build logs from those then such judgment is easy to do...


Thanks,
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

warnings report on builder wrong?

[Karel Gardas]

 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 are still here in full glory:

In file included from ../../../bsps/arm/beagle/start/bspstart.c:41:
../../../bsps/arm/beagle/start/bspstart.c: In function 
'beagle_get_node_unit':
../../../bsps/arm/beagle/start/bspstart.c:124:26: warning: array 
subscript has type 'char' [-Wchar-subscripts]

  124 | if (!isdigit(prop[i]))
  |  ^~~



In file included from ../../../bsps/arm/beagle/pwmss/pwmss.c:38:
../../../bsps/arm/beagle/include/bsp.h: In function 
'pwmss_module_clk_config':
../../../bsps/arm/beagle/include/bsp.h:66:16: warning: 'clkctrl' may be 
used uninitialized [-Wmaybe-uninitialized]

   66 | #define REG(x)(*((volatile uint32_t *)(x)))
  |^
../../../bsps/arm/beagle/pwmss/pwmss.c:59:14: note: 'clkctrl' was 
declared here

   59 | uint32_t clkctrl;
  |  ^~~



So, why is that builder does not report those? This is default 
beaglebonewhite configuration so it should be pretty close to what 
builder builds. Also the toolchain is 6/rtems-arm build last week...


Thanks,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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/arm/stm32h7/bspstm32h757i-eval-m4.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml
@@ -8,7 +8,8 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: stm32h7
-includes: []
+includes:
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval
 install: []
 links:
 - role: build-dependency
@@ -16,6 +17,8 @@ links:
 - role: build-dependency
   uid: tststm32h757i-eval
 source:
+- bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-clk.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-osc.c
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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 @@
 #include 
 #include 
 #include 
-
+#include 
 
 /**
  * @brief   This function configures the L3 and L4_PER system clocks.
@@ -56,7 +56,10 @@
  */
 rtems_status_code pwmss_module_clk_config(BBB_PWMSS pwmss_id)
 {
-uint32_t clkctrl;
+/* we initialize clkctrl here to nonsentical value as this is going
+ * to be assigned later anyway. Here assigning 0 is just to kill
+ * warning emitted by the C compiler. */
+uint32_t clkctrl = 0;
 
 /* calculate the address of the clock control register for the PWMSS
  * module we are configuring */
@@ -66,6 +69,9 @@ rtems_status_code pwmss_module_clk_config(BBB_PWMSS pwmss_id)
 clkctrl = AM335X_CM_PER_ADDR + AM335X_CM_PER_EPWMSS1_CLKCTRL;
 } else if(pwmss_id == BBB_PWMSS2) {
 clkctrl = AM335X_CM_PER_ADDR + AM335X_CM_PER_EPWMSS2_CLKCTRL;
+} else {
+   /* wrong clock configuration, let's panic here. */
+   rtems_error(RTEMS_ERROR_PANIC, "beagle: unsupported pwmss module clock 
configuration value!");
 }
 
 /* when the module is functional the IDLEST bits (16 -17) of the
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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/bsps/arm/beagle/include/bsp.h
@@ -350,16 +350,6 @@ static inline void write_ttbr0(uint32_t bar)
 refresh_tlb();
 }
 
-/* Behaviour on fatal error; default: test-friendly.
- * set breakpoint to bsp_fatal_extension.
- */
-/* Enabling BSP_PRESS_KEY_FOR_RESET prevents noninteractive testing */
-/*#define  BSP_PRESS_KEY_FOR_RESET 1 */
-#defineBSP_PRINT_EXCEPTION_CONTEXT 1
-/* human-readable exception info */
-#defineBSP_RESET_BOARD_AT_EXIT 1
-/* causes qemu to exit, signaling end of test */
-
 /**
  * @brief Beagleboard specific set up of the MMU.
  *
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

---
 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 +121,7 @@ int beagle_get_node_unit(phandle_t node)
 
 if (strstr(prop_val, name) != NULL) {
   for (i = strlen(prop) - 1; i >= 0; i--) {
-if (!isdigit(prop[i]))
+if (!isdigit((int)prop[i]))
   break;
   }
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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).  Make sure that changes don't increase the RAM / Flash size
+ of the default build so that it can't be used on the small targets.


This is not realistic or achievable and I find confusing the reasons it is being
pushed over and over. I would have not have agreed to this being added before
now and nothing has changed. The central reason for rejecting this statement is
a change in FreeBSD may add a few meg of memory to the footprint and this type
of statement would conflict with that addition and that in turn would conflict
with the need for transparency of source. And as stated before transparency must
be preferred.

System requirements are for the developers of those systems and not RTEMS.
Derating designs is an important part of system design and not the domain of
this project. Memory constrained systems can consider another networking stack
option or bespoke changes internally maintained. That is a cost trade off no one
here can help make.


From the discussion it looks like guys from embedded brains push that 
policy forward I mean policy that memory consumption is somehow 
important metric for patch acceptance. Seeing their commit track log I 
would not oppose that rule that much as at the end of the day somebody 
needs to do the job and from the log it looks like embedded brains stay 
behind their word.


As an RTEMS user here, I'm curious if this discussion about few 
paragraphs in CONTRIBUTING file is not too much over-thinking of the 
issue. So far majority of patches were done by just three subjects: 
embedded brains, aorcorp and you. So I would assume that engineering 
discussion with respect for each other contribution and energy spent 
should result in a policy which may be vague and compromise but working 
well for what you all guys do for us RTEMS users here...


Thanks!
Karel

rtems@silence:~/git/rtems/ssh-rtems-libbsd$ git shortlog -s -n --all 
--no-merges

  1554  Sebastian Huber
   242  Christian Mauderer
   242  Joel Sherrill
   175  Chris Johns
   163  Jennifer Averett
31  Kevin Kirspel
31  Kinsey Moore
25  Vijay Kumar Banerjee
21  Jan Sommer
12  Moyano, Gabriel
12  Sichen Zhao

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd development policy clarification needed?

[Karel Gardas]

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 me that 
soon.


Thank you for clarification and big thanks to all involved and dealing 
with this libbsd issue.


Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

libbsd development policy clarification needed?

[Karel Gardas]

  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:


"This branch must be used for libbsd development. Back ports to the 
6-freebsd-12 are allowed."


I was surprised to be proven wrong then by Fabrizio here:
https://devel.rtems.org/ticket/4723

and by later investigation which shows that 6-freebsd-12 branch 
accumulated NFS work by Chris done in 2021 which is not presented on 
master. I've investigated just NFS as this was my focus here.


So if 6-freebsd-12 became development branch of some sort, then it would 
be great to have that clarified in the project README file to prevent 
users confusion? Or if the policy is still the same, then perhaps some 
branch sync is needed here?


I'm fine with either way, as a user I just need clear not confusing 
project message...


Thanks!
Karel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] fix DHCPCD link

[Karel Gardas]

---
 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 particular target platform.
 
 * `BPF(4) `_: Berkeley 
Packet Filter
-* `DHCPCD(8) `_: DHCP client
+* `DHCPCD(8) `_: DHCP client
 * `dns_sd.h `_: DNS Service Discovery
 * `GETHOSTBYNAME(3) 
`_: Get 
network host entry
 * `IF_BRIDGE(4) 
`_: Network 
bridge device
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Karel Gardas]

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 set type is too small and you 
have a stack overflow.


And this is exactly what was happening and why I increase STACK size 
insanely. Anyway, thanks to your help, this is no longer happening.


Which branch of libbsd do you use? Maybe try out 
the other branch as well.


master. I've thought this is were development happens, isn't it?

Also noted interesting thing. If I modify buildset to remove all USB, I 
still get linked error USB related (missing functions) due to functions 
being used from device-nexus.h. Is this current behavior or have I did 
anything wrong again?


E.g. stm32h7 USB setup in libbsd is wrong for my board (causes RTEMS 
crash) so I've tried to disable that by build set modification (all 
dev_usb* = off) and this does not helped hence I've modified 
device-nexus.h also to not use dwg at all.
Hmm, looks like patch like attach may solve the issue? At least it did 
for my case here. But I don't know if this is the right way to attack 
this issue.


 From the 16MiB you already waste 4MiB for unused features if you use 
the latest 6-freebsd-12 branch of libbsd.


No, master here. Also I've not attempted to optimize for size yet as the 
project is currently still not done yet.


Thanks!
Karel

diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h
index d98e6f76..11f74771 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -187,6 +187,7 @@ RTEMS_BSD_DRIVER_USB_MASS;
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(stmac, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 
+#if defined(RTEMS_BSD_MODULE_DEV_USB_CONTROLLER)
 static const rtems_bsd_device_resource dwcotg_res[] = {
 	{
 		.type = RTEMS_BSD_RES_MEMORY,
@@ -200,6 +201,8 @@ static const rtems_bsd_device_resource dwcotg_res[] = {
 };
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(dwcotg, 0, RTEMS_ARRAY_SIZE(dwcotg_res),
 dwcotg_res);
+#endif
+
 RTEMS_BSD_DRIVER_ST_SDMMC(0, SDMMC1_BASE, DLYB_SDMMC1_BASE, SDMMC1_IRQn);
 RTEMS_BSD_DRIVER_MMC;
 RTEMS_BSD_DRIVER_USB;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel