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
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
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
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
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
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
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
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/2
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
: 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
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
---
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
---
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
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
---
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
---
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
@@
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
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
:
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
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
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
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
---
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 @@
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 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
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):
---
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
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:
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
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
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
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
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
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
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
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
one 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 n
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
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
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
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
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
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
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
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
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
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
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,
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?
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
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
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 ->
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
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
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
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
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
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:
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
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/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
---
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/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
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/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
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:
---
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
+++
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
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
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
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
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
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 ++
-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/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.
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>
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
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
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/14/23 05:34, Chris Johns wrote:
On 14/2/2023 10:47 am, Joel Sherrill wrote:
Chris.. see below
On Mon, Feb 13, 2023 at 5:42 PM Karel Gardas wrote:
On 2/14/23 00:33, Joel Sherrill wrote:
> With fresh tools on CentOS 7, I have 5 warnings in beaglebonewhite. Log
> at
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
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
---
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
---
---
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
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
+++
---
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
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).
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
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:
---
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
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
1 - 100 of 383 matches
Mail list logo
