This means:
SDRAM 1: 0
SDRAM 2: 32 MB
Sponsored-By: Precidata
---
spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml | 1 +
spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml | 1 +
2 files changed, 2 insertions(+)
diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
This patch disables all U(S)ARTs which are not supported by the board
itself and its provided connectors.
Sponsored-By: Precidata
---
spec/build/bsps/arm/stm32h7/optenuart4.yml | 1 +
spec/build/bsps/arm/stm32h7/optenuart5.yml | 1 +
spec/build/bsps/arm/stm32h7/optenuart7.yml | 1 +
: stm32h757i-eval-m4
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2022 Karel Gardas
+cppflags: []
+enabled-by: true
+family: stm32h7
+includes: []
+install: []
+links:
+- role: build-dependency
+ uid: grp
+- role: build-dependency
+ uid: tststm32h757i-eval
+source:
+- bsps/arm/stm32h7/boards
compilation issues on M1, but I think it would be silly if I provide a
patch for rtems-tools to be included in source builder instead of
directly fixing the issue in the git.
Thanks!
Karel
On 5/12/22 09:19, Karel Gardas wrote:
This fixes compilation issue on Apple M1.
---
.../elftoolchain/libelf
On 5/16/22 17:33, Andreas Enge wrote:
Hello Karel,
Am Mon, May 16, 2022 at 04:33:42PM +0200 schrieb Karel Gardas:
Could you be so kind and in next release use latest available autotools to
generate configure script and associated files? This way, problematic
config.sub file is generated
On 5/16/22 16:45, Paul Zimmermann wrote:
Dear Karel,
yes, we'll take care of that in the next release of MPC.
Thanks for assurance. That's perfectly fine for us since now we may
apply patch locally and schedule its removal on another MPC release.
Perfect!
Karel
On 5/13/22 15:57, Joel Sherrill wrote:
We do not put patches in RTEMS repos. File an rtems ticket, attach them,
and reference them from there.
If they are needed upstream, please submit them to the appropriate projects.
Joel,
based on the discussion I've created
Hello Duc,
one reminder, your API should be more or less portable. That means the
example which you produce as a testing example should be API-wise
portable between various BSPs. Is that clear?
I know, I know, sometimes user led 1 on F4 is on different port/pin on
F7 and then on H7 you
On 7/7/22 14:02, Sebastian Huber wrote:
+Performa the following steps to do a FreeBSD baseline update:
Small typo here.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 7/7/22 13:11, Duc Doan wrote:
Maybe it's as simple as renaming the identifiers from stm32f4_gpio =>
stm32_gpio for clarity for most functions, and declaring these files
in
the H7 scripts.
I think I will wait for Karel's opinion about that.
I just need to catch a bit of breath and then
Hello Duc,
just two notes which bothers me most.
On 7/7/22 13:34, Duc Doan wrote:
This is the new GPIO API. The header file is
gpio2.h.
---
bsps/include/bsp/gpio2.h| 538
bsps/shared/dev/gpio/gpio.c | 196 +
spec/build/bsps/obj.yml
Hello Duc,
just one remark.
On 6/27/22 05:34, Duc Doan wrote:
rtems_gpio_ctrl_t *ctrl0 = bsp_gpio_get_ctrl(60); //corresponds to
GPIOD pin 12 on F4
^ if your ctrl structure knows you are working with pin 60
rtems_gpio_write(ctrl, 60, RTEMS_GPIO_PIN_SET);
then you do not need to use it
On 6/26/22 10:49, Duc Doan wrote:
#define rtems_gpio_get_ctrl(_driver, _arg, _out) \
_driver##_gpio_get_ctrl( _arg , _out )
In the application code:
rtems_gpio_get_ctrl(stm32f4, GPIOD, _ctrl);
rtems_gpio_get_ctrl(stm32f4, GPIOA, _ctrl);
It's only a different method of writing the same.
Sponsored-By: Precidata
---
.../stm/Components/mt25tl01g/mt25tl01g.c | 1046 +
.../stm/Components/mt25tl01g/mt25tl01g.h | 362 ++
.../stm/Components/mt25tl01g/mt25tl01g_conf.h | 68 ++
3 files changed, 1476 insertions(+)
create mode 100644
Sponsored-By: Precidata
---
.../stm32h757i-eval/stm32h747i_eval_conf.h| 130 ++
.../stm32h757i-eval/stm32h747i_eval_errno.h | 105 ++
.../stm32h757i-eval/stm32h747i_eval_qspi.c| 1088 +
.../stm32h757i-eval/stm32h747i_eval_qspi.h| 284 +
4 files changed, 1607
The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.
Sponsored-By: Precidata
---
Sponsored-By: Precidata
---
.../stm32h747i_discovery_conf.h | 119 ++
.../stm32h747i_discovery_errno.h | 106 ++
.../stm32h747i_discovery_qspi.c | 1100 +
.../stm32h747i_discovery_qspi.h | 286 +
4 files changed, 1611
The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.
Sponsored-By: Precidata
---
---
config/rtems-bsps-arm.ini | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/config/rtems-bsps-arm.ini b/config/rtems-bsps-arm.ini
index 85067ff..1d38f1a 100644
--- a/config/rtems-bsps-arm.ini
+++ b/config/rtems-bsps-arm.ini
@@ -44,7 +44,8 @@ bsps = altcycv_devkit,
---
config/rtems-bsps-tiers.ini | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/config/rtems-bsps-tiers.ini b/config/rtems-bsps-tiers.ini
index d5ebc39..512ebcb 100644
--- a/config/rtems-bsps-tiers.ini
+++ b/config/rtems-bsps-tiers.ini
@@ -70,7 +70,8 @@ bsps_arm =
---
spec/build/bsps/arm/grp.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index a8ebe07f15..b45f9a8c12 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -9,6 +9,7 @@ install:
source:
-
Nucleo board does not provide any external memory so code does not have
any function here anyway.
Sponsored-By: Precidata
---
.../boards/stm/nucleo-h743zi/ext-mem-ctl.c| 478 --
.../stm/nucleo-h743zi/stm32h7-bspstarthooks.c | 1 -
.../bsps/arm/stm32h7/bspnucleoh743zi.yml
The idea here is to prepare for better per-board specialization
of the hooks function code.
Sponsored-By: Precidata
---
.../stm/nucleo-h743zi/stm32h7-bspstarthooks.c | 78 +++
.../stm32h743i-eval/stm32h7-bspstarthooks.c | 78 +++
On 6/15/22 17:05, Gedare Bloom wrote:
+#endif
+
+void stm32h7_init_qspi(void)
Also, is this function declared somewhere?
Probably what you should do is to add this function declaration to
stm32h747i_eval_qspi.h, and include that file here always?
Yes, it is in
On 6/15/22 17:00, Gedare Bloom wrote:
On Fri, Jun 10, 2022 at 6:49 AM Karel Gardas wrote:
The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage
Sponsored-By: Precidata
---
.../stm/Components/mt25tl01g/mt25tl01g.c | 1046 +
.../stm/Components/mt25tl01g/mt25tl01g.h | 362 ++
.../stm/Components/mt25tl01g/mt25tl01g_conf.h | 68 ++
3 files changed, 1476 insertions(+)
create mode 100644
Sponsored-By: Precidata
---
.../stm32h757i-eval/stm32h747i_eval_conf.h| 130 ++
.../stm32h757i-eval/stm32h747i_eval_errno.h | 105 ++
.../stm32h757i-eval/stm32h747i_eval_qspi.c| 1088 +
.../stm32h757i-eval/stm32h747i_eval_qspi.h| 284 +
4 files changed, 1607
The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.
Sponsored-By: Precidata
---
IIRC Pavel asked to always being on cc to get CAN related email right to
his inbox instead of email list boxes...
On 6/20/22 18:37, Prashanth S wrote:
Hi All,
This is a request for suggestions and feedback for the CAN message
structure.
*CAN message structure that represents the can
On 6/13/22 18:27, Joel Sherrill wrote:
This impacts other imports from STM so I am curious what Karel,
Sebastian, and Andrei are seeing for the license in the code they are
importing and what they plan to do.
So far on H7, the HAL used is older code base which is clearly BSD-3
license:
Besides C files for the BSP variant the patch also provides license
clarification on system_stm32h7xx.c file which is provided
in boards/stm/nucleo-h7a3zi directory.
The files comes from STM32CubeH7 project and references "root directory"
in its license comment and it's not clear where this points
The board and hosted MCU do not provide any Ethernet support anyway.
---
bsps/arm/stm32h7/start/stm32h7-hal-eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
b/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
index 5fc75f0147..173d97c31f
---
.../bsps/arm/stm32h7/bspnucleoh7a3zi.yml | 25 +++
spec/build/bsps/arm/stm32h7/opthse.yml| 1 +
spec/build/bsps/arm/stm32h7/optlinkcmds.yml | 1 +
.../bsps/arm/stm32h7/optmemflashlatency.yml | 1 +
.../build/bsps/arm/stm32h7/optmemsdram1sz.yml | 1 +
Duc,
where have you taken F4 HAL exactly? I'm asking since your import is
full of CRLF line endings which we try hard to eliminate in RTEMS while
original is not. Proof:
$ git clone https://github.com/STMicroelectronics/STM32CubeF4.git
Cloning into 'STM32CubeF4'...
remote: Enumerating
On 4/28/22 10:04, Sebastian Huber wrote:
More releases means more maintenance overhead. Since GCC 12 is under
active upstream maintenance, compiler issues can be fixed by the GCC
maintainers in contrast to GCC 10.
JFYI: gcc 12 was branched, rc1 is being built. More info here:
Hello,
I'd go with 12 if only a bit possible. Any major compiler change during
the minor RTEMS release would not look good IMHO. It's way better to do
major RTEMS version bump together with major compiler version bump and
stick to that during the RTEMS release live cycle. That's my gut
Hello Sebastian,
thanks a lot for dealing with GCC 12 update. I'm just curious is there
any reason to use GCC from git (post release version) and not vanilla
12.1 release tarball from gcc.gnu.org?
Thanks!
Karel
On 5/9/22 14:54, Sebastian Huber wrote:
Hello,
I updated the RSB to use the
On 5/5/22 11:35, Chris Johns wrote:
I think this is a use case where something added to the RSB may be required to
make this easier. For example logic in a bset file would be nice.
Your idea is excellent, but I think we also may need something more simple and
history preserving for the time
On 5/5/22 11:15, Karel Gardas wrote:
Hence I sent a patch series creating config/6.1 as a preparation for 6.1
release with gcc 10 and update 6 (as a 6 branch dev) with Sebastian's
updated GCC 12).
Oh, and I do not mean 6.1 should be done with GCC 10. Just we do have
two sets now for testing
This patch series creates 6.1 config directory and updates its files
to not use any from 6. It also updates 6's GCC to GCC 12 (gcc-head)
to easy testing and comparing for gcc 10 and 12 in preparation
of RTEMS 6.1 release.
General idea is that we will create config/
for any RTEMS release and that
---
rtems/config/6.1/rtems-aarch64.bset| 4
rtems/config/6.1/rtems-all.bset| 18 ++
rtems/config/6.1/rtems-arm.bset| 4
rtems/config/6.1/rtems-base.bset | 13 +
rtems/config/6.1/rtems-bfin.bset | 3 +++
---
rtems/config/6/rtems-default.bset | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtems/config/6/rtems-default.bset
b/rtems/config/6/rtems-default.bset
index 731c9d8..381f916 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -15,5
---
rtems/config/6.1/rtems-aarch64.bset| 2 +-
rtems/config/6.1/rtems-arm.bset| 2 +-
rtems/config/6.1/rtems-bfin.bset | 2 +-
rtems/config/6.1/rtems-default.bset| 2 +-
rtems/config/6.1/rtems-i386.bset | 2 +-
rtems/config/6.1/rtems-lm32.bset | 2 +-
On 5/5/22 01:32, Chris Johns wrote:
On 4/5/2022 8:57 pm, Sebastian Huber wrote:
On 04/05/2022 09:11, Chris Johns wrote:
I updated the RTEMS 7 tools to use the GCC 12 release branch with a gcov back
port. You can test GCC 12 with a local patch for RTEMS 6:
diff --git
On 4/27/22 19:25, Frank Kühndel wrote:
I do not need ADA but ADA may be worth considering. With GCC 10 one
needed to have a GNAT 10 compiler installed to build the tools incl.
--with_ada. I presume, one would need a GNAT 12 to build ADA with the
GCC 12 sources? The current Fedora 35 has GNAT 11.
On 4/27/22 20:12, Frank Kühndel wrote:
Hi Karel,
On 4/27/22 19:46, Karel Gardas wrote:
On 4/27/22 19:25, Frank Kühndel wrote:
I do not need ADA but ADA may be worth considering. With GCC 10 one
needed to have a GNAT 10 compiler installed to build the tools incl.
--with_ada. I presume, one
On 4/27/22 08:48, Sebastian Huber wrote:
On 27.04.22 08:45, Karel Gardas wrote:
On 4/27/22 06:46, Sebastian Huber wrote:
On 26.04.22 22:57, Karel Gardas wrote:
On 4/25/22 10:10, Sebastian Huber wrote:
Hello Heinz,
you are probably one of the first persons building GCC 12 on this
platform
On 7/30/22 16:32, o...@c-mauderer.de wrote:
bsps/arm/include/cmsis_compiler.h | 266 +
bsps/arm/include/cmsis_gcc.h | 3460 +--
bsps/arm/include/cmsis_version.h | 39 +
bsps/arm/include/core_cm4.h | 524 +-
SIS compiles on Mac OS X fine, but without providing --host/--build
configure options. Removing them solves the issue of configure not being
able to recognize arm64-darwin platform.
---
source-builder/config/sis-2-1.cfg | 1 -
1 file changed, 1 deletion(-)
diff --git
GNU sed compiles on Mac OS X fine, but without providing --host/--build
configure options. Hence removing them solved the issue of configure
not being able to recognize arm64-darwin platform.
---
source-builder/config/gsed-1.cfg | 1 -
1 file changed, 1 deletion(-)
diff --git
The problem is that we still need to discuss licensing here. Randomly
checked files from the HAL patch contains this as a license:
* This software is licensed under terms that can be found in the
LICENSE file
* in the root directory of this software component.
* If no LICENSE file
On 9/21/22 15:48, Karel Gardas wrote:
On the bright side, it looks like STM still holds on BSD-3 for their HAL
code for F4?
https://github.com/STMicroelectronics/STM32CubeF4/blob/master/LICENSE.md
Would be great indeed.
After very quick investigation, everything under CMSIS is under Apache
On 9/22/22 00:00, Gedare Bloom wrote:
On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill wrote:
On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas wrote:
The problem is that we still need to discuss licensing here. Randomly
checked files from the HAL patch contains this as a license
On 9/22/22 10:41, Sebastian Huber wrote:
On 22/09/2022 10:30, Karel Gardas wrote:
On 9/22/22 00:00, Gedare Bloom wrote:
On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill wrote:
On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas
wrote:
The problem is that we still need to discuss licensing here
On 9/23/22 18:35, Sebastian Huber wrote:
Hello,
I have a question for the waf experts. How can I use the GCC
-frandom-seed= option with the waf build system?
https://stackoverflow.com/questions/73829827/how-can-i-use-the-gcc-frandom-seed-file-name-option-with-the-waf-build-system
Unix?
On 10/6/22 20:14, Kinsey Moore wrote:
+Raspberry Pi uses a different mechanism to boot. First the GPU
initializes,
A different mechanism as compared to what? Is this sentence important to
users?
Should GPU be CPU, instead?
Sorry for hijacking, but no, this sentence is right. GPU core on
Sorry to hijack that thread, but correction is needed here.
On 1/20/23 01:03, Chris Johns wrote:
The FreeBSD single repo is about the kernel and base runtime. The ports are not
part of this so the analogy breaks down.
Certainly all BSDs have separated ports repos, but AFAIK all of them
On 1/30/23 16:13, Gedare Bloom wrote:
On Fri, Jan 27, 2023 at 11:41 AM Karel Gardas wrote:
Sponsored-By: Precidata
---
No issue with the patch, but I think it is awkward to have this
"Sponsored-By" in an import patch.
Was also thinking about that. Whole work was sponsored
Hello,
I'm debugging crash inside the select call from libbsd library. The code
comes from few days old RTEMS and few days old libbsd trees. My naive
configuration for the RTEMS is below.
The crash backtrace is:
_CPU_Fatal_halt (source=source@entry=9, error=,
error@entry=604203640) at
Sponsored-By: Precidata
---
.../stm/Components/mt25tl01g/mt25tl01g.c | 1046 +
.../stm/Components/mt25tl01g/mt25tl01g.h | 362 ++
.../stm/Components/mt25tl01g/mt25tl01g_conf.h | 68 ++
3 files changed, 1476 insertions(+)
create mode 100644
Sponsored-By: Precidata
---
.../stm32h757i-eval/stm32h747i_eval_conf.h| 130 ++
.../stm32h757i-eval/stm32h747i_eval_errno.h | 105 ++
.../stm32h757i-eval/stm32h747i_eval_qspi.c| 1088 +
.../stm32h757i-eval/stm32h747i_eval_qspi.h| 284 +
4 files changed, 1607
The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.
Sponsored-By: Precidata
---
Folks,
upgraded to Ventura from Monterey and this breaks RSB for unknown
reason. The issue looks like segfault/internal compiler error in GCC
while compiling newlib.
6/rtems-sparc:
CC libc/stdlib/libc_a-strtoll_r.o
CC libm/complex/libm_a-cpowf.o
Side note before answering : the email was motivated by the fact that I
provided few patches to RSB to make that working well on Monterey
running on M1. This was just few weeks ago so I know, this was running
well. Last week I've updated to Ventura and things felt apart. Hence the
report
to compile it would work. But there's not a real
solution.
Seems like an issue which needs reporting to gcc.
On Sun, Nov 6, 2022, 5:25 AM Karel Gardas wrote:
Folks,
upgraded to Ventura from Monterey and this breaks RSB for unknown
reason. The issue looks like segfault/internal compiler
On 11/6/22 22:42, Chris Johns wrote:
indeed, the report here is probably minimal thing I should do.
Sebastian has pushed updates to the tools to the RSB. Did you happen to pick up
those?
Not at all! I'm still on:
...
Karel
On 11/8/22 10:15, Karel Gardas wrote:
More info on this issue:
(1) the issue (internal compiler error) does not happen all the time. In
fact there are builds which even complete. The ratio failure/ok is 10/30
so far -- building in a loop 6/rtems-sparc.
(2) attempt to bootstrap
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
-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, Siddha
On 3/8/23 11:08, Frank Kühndel wrote:
Hello,
On 3/8/23 01:42, Joel Sherrill wrote:
Subject:
Re: Help regarding Building x86_64 BSP
From:
Joel Sherrill
Date:
3/8/23, 01:42
To:
Karel Gardas
CC:
"rtems-de...@rtems.org"
Did you build the x86_64 tools and qemu using the RTEMS Sour
---
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 @@
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
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
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
---
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
+++
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
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:
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 +-
/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
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
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.
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
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
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
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 ++
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
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
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
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
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
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
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>
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
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
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
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 ->
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
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
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
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
201 - 300 of 383 matches
Mail list logo
