This enables the VME support for the MVME2500. Note that the PCIe
support from libbsd is used. So you need the related libbsd patches for
this to work.
If the drivers in libbsd are not enabled, the linker should not pick up
anything from this patch.
---
bsps/powerpc/qoriq/include/bsp/VMEConfig.h
Hello,
the attached patch set for RTEMS and libbsd adds initial support of the
Tsi148 VME bridge on the MVME2500 board using the qoriq BSP. Basically
it consists of the following parts:
- Add PCIe ranges to the qoriq MMU configuration (based on FDT).
- Add the existing VME support files to the
From: Sebastian Huber
---
freebsd/sys/sys/buf.h | 4
1 file changed, 4 insertions(+)
diff --git a/freebsd/sys/sys/buf.h b/freebsd/sys/sys/buf.h
index 209174b4..dfe3eaa6 100644
--- a/freebsd/sys/sys/buf.h
+++ b/freebsd/sys/sys/buf.h
@@ -497,7 +497,11 @@ extern int cluster_pbuf_freecnt;
Add a function that allows to set the polarity (active-low / negative
edge triggered or active-high / positive edge triggered) and sense
(level or edge sensitive) of the external interrupts.
---
bsps/powerpc/qoriq/include/bsp/irq.h | 27 ++
bsps/powerpc/qoriq/irq/irq.c | 56
Get the memory ranges for the PCIe from the FDT and add them to the MMU.
This is necessary so that the PCIe driver in libbsd can work.
---
bsps/powerpc/qoriq/start/mmu-config.c | 88 +++
1 file changed, 88 insertions(+)
diff --git a/bsps/powerpc/qoriq/start/mmu-config.c
From: Sebastian Huber
---
freebsd/sys/dev/pci/pci.c | 3 ++-
freebsd/sys/dev/pci/pci_pci.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/freebsd/sys/dev/pci/pci.c b/freebsd/sys/dev/pci/pci.c
index 0cc72dba..3789a73e 100644
--- a/freebsd/sys/dev/pci/pci.c
+++
- Am 22. Jan 2024 um 22:56 schrieb Chris Johns chr...@rtems.org:
> On 22/1/2024 6:18 pm, Sebastian Huber wrote:
>> On 22.01.24 00:47, Chris Johns wrote:
>>> On 22/1/2024 3:42 am, Sebastian Huber wrote:
Does XCode ship a Symbolize.h and llvm-config?
>>>
>>> No ...
>>>
>>> % uname -a
>>>
On 22/1/2024 6:18 pm, Sebastian Huber wrote:
> On 22.01.24 00:47, Chris Johns wrote:
>> On 22/1/2024 3:42 am, Sebastian Huber wrote:
>>> Does XCode ship a Symbolize.h and llvm-config?
>>
>> No ...
>>
>> % uname -a
>> Darwin weka.contemporary.net.au 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov
>>
---
cpukit/libblock/src/media.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libblock/src/media.c b/cpukit/libblock/src/media.c
index 482cdc4fb0..1ab7dd2034 100644
--- a/cpukit/libblock/src/media.c
+++ b/cpukit/libblock/src/media.c
@@ -519,7 +519,7 @@ static
On 23/1/2024 5:27 am, Sebastian Huber wrote:
> - Am 22. Jan 2024 um 0:22 schrieb Chris Johns chr...@rtems.org:
>
>> On 17/1/2024 11:39 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> attached is a proof of concept. Using a ./waf bootimages command didn't work
>>> since you don't have a build
On 23/1/2024 8:01 am, Gedare Bloom wrote:
> On Mon, Jan 22, 2024 at 11:13 AM Sebastian Huber
> wrote:
>>
>> Hello Gedare,
>>
>> - Am 22. Jan 2024 um 17:49 schrieb Gedare Bloom ged...@rtems.org:
>>
>>> Similar to the other patch, this looks mostly useful.
>>>
>>> I think a lot of these kind of
On Mon, Jan 22, 2024 at 11:13 AM Sebastian Huber
wrote:
>
> Hello Gedare,
>
> - Am 22. Jan 2024 um 17:49 schrieb Gedare Bloom ged...@rtems.org:
>
> > Similar to the other patch, this looks mostly useful.
> >
> > I think a lot of these kind of support code have been imported as
> > libraries
Remove and simplify __rtems__ ifdefs in files that are now
authoritatively owned by rtems-lwip.
---
rtemslwip/common/sys_arch.c | 8
rtemslwip/include/arch/sys_arch.h | 21 -
rtemslwip/tms570/include/phy_dp83848h.h | 2 --
There have been some SMP compatibility issues seen on ZynqMP systems,
even with the recent patch to manage the active pbuf pool. It was
confirmed with Xilinx that this driver was never intended to run with
multiple cores available even though lwIP has multi-core support and
there doesn't appear to
> On Jan 22, 2024, at 12:16 PM, Gedare Bloom wrote:
>
> I have a couple minor notes below. More important, does this change
> require updating documentation?
I'd have to look to see if this window size detection is documented, I wanted
to fix the problem it caused me.
>
> I know we have
- Am 22. Jan 2024 um 0:22 schrieb Chris Johns chr...@rtems.org:
> On 17/1/2024 11:39 pm, Sebastian Huber wrote:
>> Hello,
>>
>> attached is a proof of concept. Using a ./waf bootimages command didn't work
>> since you don't have a build context in this case. I added a new option:
>>
>> # If
- Am 22. Jan 2024 um 17:52 schrieb Gedare Bloom ged...@rtems.org:
> On Tue, Jan 16, 2024 at 8:44 AM Sebastian Huber
> wrote:
>>
>> Switch back to the idle thread if no watchdogs are active. In some tests,
>> the
>> idle thread may do some non-blocking work.
>> ---
>>
Hello Gedare,
- Am 22. Jan 2024 um 17:49 schrieb Gedare Bloom ged...@rtems.org:
> Similar to the other patch, this looks mostly useful.
>
> I think a lot of these kind of support code have been imported as
> libraries through cpukit/libmisc.
>
> I'd be fine if we have our own versions, to
On Mon, Jan 22, 2024 at 11:05 AM Gedare Bloom wrote:
> On Wed, Jan 17, 2024 at 1:48 AM wrote:
> >
> > From: Chengxiang Li
> >
> > avoid pclint err
> > ---
> > cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
Peter,
On Fri, Jan 19, 2024 at 5:18 AM wrote:
>
> From: Peter Dufault
>
> This is my first submission of a patch using format-patch and
> send-email from my Linux system. Let me know if anything is wrong.
>
The patch itself came through great, thanks! For future single-patch
submissions, you
I have a couple minor notes below. More important, does this change
require updating documentation?
I know we have a somewhat aging shell-specific guide:
https://docs.rtems.org/branches/master/shell/index.html
On Fri, Jan 19, 2024 at 5:19 AM wrote:
>
> From: Peter Dufault
>
> - Fix detection
On Wed, Jan 17, 2024 at 7:47 AM Sebastian Huber
wrote:
>
> On 17.01.24 15:31, Kinsey Moore wrote:
> > Change extend_count to uint32_t from uint16_t to avoid a possible
> > premature integer overflow when it is later used for multiplication.
>
> Thanks, looks good.
>
I would have preferred a cast
On Wed, Jan 17, 2024 at 1:48 AM wrote:
>
> From: Chengxiang Li
>
> avoid pclint err
> ---
> cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
>
On Sat, Jan 13, 2024 at 1:23 PM John Howard wrote:
>
> Greetings. New developer here.
>
Thanks for the report.
> I used RSB 5.3 to target RTEMS to RaspberryPi with an AMD64 Debian bullseye.
>
> sha512sum rtems-libbsd-5.3.tar.xz listed in VERSION is hash mismatch.
>
This appears to be a mismatch
On Tue, Jan 16, 2024 at 8:44 AM Sebastian Huber
wrote:
>
> Switch back to the idle thread if no watchdogs are active. In some tests, the
> idle thread may do some non-blocking work.
> ---
> bsps/shared/dev/clock/clockimpl.h | 16
> 1 file changed, 16 insertions(+)
>
> diff
Similar to the other patch, this looks mostly useful.
I think a lot of these kind of support code have been imported as
libraries through cpukit/libmisc.
I'd be fine if we have our own versions, to define a cpukit/lib**
But cpukit/dev has so far been for device-specific frameworks and I
would
Sorry, it already was pushed.
On Mon, Jan 22, 2024 at 9:47 AM Gedare Bloom wrote:
>
> someone can push this.
>
> next time, add
>
> bsps/include:
>
> as the tag. We should define the set of desirable tags for the commit
> messages.
>
> On Mon, Jan 8, 2024 at 12:26 PM Will wrote:
> >
> > Looks
someone can push this.
next time, add
bsps/include:
as the tag. We should define the set of desirable tags for the commit messages.
On Mon, Jan 8, 2024 at 12:26 PM Will wrote:
>
> Looks good to me. There is generally no need for a 0/X email when X is small
> unless you think it is necessary.
This seems to be generically useful by itself. I'd probably be OK with
it, if it has a suitable (non device-related) home.
On Mon, Jan 15, 2024 at 2:46 AM Sebastian Huber
wrote:
>
> From: Matthew Joyce
>
> ---
> cpukit/dev/iobase64decode.c | 166
>
On Sun, Jan 21, 2024 at 4:43 PM Chris Johns wrote:
>
> Hi,
>
> There are a few things I do not understand about this addition. I brief review
> of the code seems OK but I am struggling to understand the requirements
> driving
> this addition. Can a ticket please be created with the requirements
On 22.01.24 00:47, Chris Johns wrote:
On 22/1/2024 3:42 am, Sebastian Huber wrote:
Does XCode ship a Symbolize.h and llvm-config?
No ...
% uname -a
Darwin weka.contemporary.net.au 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15
21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020
On 22/1/2024 3:42 am, Sebastian Huber wrote:
> Does XCode ship a Symbolize.h and llvm-config?
No ...
% uname -a
Darwin weka.contemporary.net.au 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15
21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020 arm64
% c++ -v
Apple clang version 15.0.0
Hi,
There are a few things I do not understand about this addition. I brief review
of the code seems OK but I am struggling to understand the requirements driving
this addition. Can a ticket please be created with the requirements and a real
world use case of how it would be used and what
On 15/1/2024 8:45 pm, Sebastian Huber wrote:
> This makes them reusable. Change the character type to uint8_t.
> ---
> cpukit/dev/iobase64.c | 24 +---
I do not understand why a base64 encoder/decoder is in the devices sources tree?
I have never encountered a base64
Looks good
Thanks
Chris
On 16/1/2024 5:44 pm, Sebastian Huber wrote:
> Restore the previous section, otherwise the generated code may end up in
> a wrong section.
> ---
> linkers/rtems-syms.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/linkers/rtems-syms.cpp
On 17/1/2024 11:39 pm, Sebastian Huber wrote:
> Hello,
>
> attached is a proof of concept. Using a ./waf bootimages command didn't work
> since you don't have a build context in this case. I added a new option:
>
> # If this option is enabled, then boot images for the test programs
> # are
On 20.01.24 16:25, Sebastian Huber wrote:
On 19.01.24 10:13, Sebastian Huber wrote:
On 19.01.24 09:09, Cedric Berger wrote:
On 19.01.2024 08:55, Sebastian Huber wrote:
On 19.01.24 07:58, Sebastian Huber wrote:
This patch fixes bugs #4908 and #4965 which were reported by RTMES
users. The
Update #4982.
---
config/rtems-bsps-arm.ini | 4 ++--
config/rtems-bsps-tiers.ini | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/config/rtems-bsps-arm.ini b/config/rtems-bsps-arm.ini
index 1d38f1a..571fae9 100644
--- a/config/rtems-bsps-arm.ini
+++
Looksike some of the rece t activities around the tms750 BSP have not been
fully accounted for.
Remember that if the set of BSPs has changed, the tiers definition files in
rtems-tools need to be updated
-- Forwarded message -
From: OAR Tester for Ubuntu 22.04
Date: Sat, Jan 20,
On 20.01.2024 16:49, Sebastian Huber wrote:
On 19.01.24 21:31, Bernd Moessner wrote:
Dear all,
I'm currently encountering an issue with the latest RTEMS toolchain
(GCC 13) while attempting to build GoogleTest.
Simple example, test.cpp with the following content:
#include
#include
On 19.01.24 21:31, Bernd Moessner wrote:
Dear all,
I'm currently encountering an issue with the latest RTEMS toolchain (GCC
13) while attempting to build GoogleTest.
Simple example, test.cpp with the following content:
#include
#include
compiled with
On 19.01.24 10:13, Sebastian Huber wrote:
On 19.01.24 09:09, Cedric Berger wrote:
On 19.01.2024 08:55, Sebastian Huber wrote:
On 19.01.24 07:58, Sebastian Huber wrote:
This patch fixes bugs #4908 and #4965 which were reported by RTMES
users. The patch is from 19 May 2023 and was blocked
Dear all,
I'm currently encountering an issue with the latest RTEMS toolchain (GCC
13) while attempting to build GoogleTest.
Simple example, test.cpp with the following content:
#include
#include
compiled with
~/quick-start/install/tools/toolchain-arm/bin/arm-rtems6-g++ test.cpp
gives
From: Peter Dufault
- Fix detection of timeout in rtems_shell_term_wait_for().
- Switch to using "termios" VTIME inter-character timeout.
The previous implementation is dependent on the BSP clock tick value.
Updates #4763
---
cpukit/libmisc/shell/shell.c | 101
From: Peter Dufault
This is my first submission of a patch using format-patch and
send-email from my Linux system. Let me know if anything is wrong.
Peter Dufault (1):
libmisc/shell: Fix timeout in getting terminal size
cpukit/libmisc/shell/shell.c | 101
On 19.01.24 09:09, Cedric Berger wrote:
On 19.01.2024 08:55, Sebastian Huber wrote:
On 19.01.24 07:58, Sebastian Huber wrote:
This patch fixes bugs #4908 and #4965 which were reported by RTMES
users. The patch is from 19 May 2023 and was blocked due to missing
tests on macOS. I have no
Hello,
On 19.01.2024 08:55, Sebastian Huber wrote:
On 19.01.24 07:58, Sebastian Huber wrote:
This patch fixes bugs #4908 and #4965 which were reported by RTMES
users. The patch is from 19 May 2023 and was blocked due to missing
tests on macOS. I have no macOS system for tests. Would someone
On 19.01.24 07:58, Sebastian Huber wrote:
This patch fixes bugs #4908 and #4965 which were reported by RTMES
users. The patch is from 19 May 2023 and was blocked due to missing
tests on macOS. I have no macOS system for tests. Would someone mind
testing this patch? It would be nice to build
Use the latest C++ standard available up to C++20.
Close #4908.
Close #4965.
---
trace/wscript | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/trace/wscript b/trace/wscript
index 0c0e4b4..b632291 100644
--- a/trace/wscript
+++ b/trace/wscript
@@ -45,7
This patch fixes bugs #4908 and #4965 which were reported by RTMES
users. The patch is from 19 May 2023 and was blocked due to missing
tests on macOS. I have no macOS system for tests. Would someone mind
testing this patch? It would be nice to build the RTEMS Tools on modern
Linux systems with
On 17.01.24 15:31, Kinsey Moore wrote:
Change extend_count to uint32_t from uint16_t to avoid a possible
premature integer overflow when it is later used for multiplication.
Thanks, looks good.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email:
Change extend_count to uint32_t from uint16_t to avoid a possible
premature integer overflow when it is later used for multiplication.
---
cpukit/score/src/objectextendinformation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/score/src/objectextendinformation.c
Fair enough. I'll update the patch. Thanks!
On Wed, Jan 17, 2024 at 12:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 16.01.24 21:02, Kinsey Moore wrote:
> > The two operands are 16 bit and the result is being saved into a
> > larger type. Reduce the possibility of an
Hello,
attached is a proof of concept. Using a ./waf bootimages command didn't
work since you don't have a build context in this case. I added a new
option:
# If this option is enabled, then boot images for the test programs
# are built.
BUILD_BOOT_IMAGES = False
If this option is enabled,
We have to use a custom dictorary to be able to set the "value" argument
in the exec() context.
---
wscript | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/wscript b/wscript
index a71e0d3f10..6c81083b2c 100755
--- a/wscript
+++ b/wscript
@@ -1026,8 +1026,14 @@ class
From: Chengxiang Li
avoid pclint err
---
cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
index aa4f90f1a8..569b6bcee2
Hello,
the RTEMS 6 build system only produces test executables in ELF format.
For example, if you want to run the tests using U-Boot, then you have to
convert the ELF file with the U-Boot mkimage tool to an U-Boot image
using BSP-specific command line arguments. For other bootloaders you
On 16.01.24 21:02, Kinsey Moore wrote:
The two operands are 16 bit and the result is being saved into a
larger type. Reduce the possibility of an overflow during multiplication
by using the larger type as an operand.
---
cpukit/score/src/objectextendinformation.c | 3 ++-
1 file changed, 2
The tmp_fat_fd variable is unconditionally opened in the branch where it
is used within the loop and so must be closed or else risk a resource
leak.
---
cpukit/libfs/src/dosfs/msdos_dir.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
---
cpukit/libmisc/uuid/gen_uuid.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/cpukit/libmisc/uuid/gen_uuid.c b/cpukit/libmisc/uuid/gen_uuid.c
index 71b8a569bb..9b8dbeaa2e 100644
--- a/cpukit/libmisc/uuid/gen_uuid.c
+++ b/cpukit/libmisc/uuid/gen_uuid.c
@@ -343,11 +343,17 @@ static
Cast getpid() before shifting to avoid truncation of upper bits before
the 64bit XOR occurs.
---
cpukit/libmisc/uuid/gen_uuid.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/cpukit/libmisc/uuid/gen_uuid.c b/cpukit/libmisc/uuid/gen_uuid.c
index 9b8dbeaa2e..5601c887c9 100644
---
The two operands are 16 bit and the result is being saved into a
larger type. Reduce the possibility of an overflow during multiplication
by using the larger type as an operand.
---
cpukit/score/src/objectextendinformation.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
---
cpukit/libfs/src/dosfs/fat_fat_operations.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpukit/libfs/src/dosfs/fat_fat_operations.c
b/cpukit/libfs/src/dosfs/fat_fat_operations.c
index 1d94beb26a..fe6bbf03ce 100644
---
Hello Martin,
the patch removes the UT699 reference. Is this workaround also valid for
the UT699?
On 12.01.24 20:02, Martin Åberg wrote:
This updates the implementation of the LEON3 processor power-down
function.
It now contains the workaround for the GR712RC power-down errata
described in
Hello Martin,
we have also the Cache Manager support in
bsps/sparc/leon3/start/cache.c. At least the lock should be shared
between these two implementations to ensure that there is no concurrent
access.
What is the use case for this driver in grlib? Is it used by the Cache
Manager API?
Switch back to the idle thread if no watchdogs are active. In some tests, the
idle thread may do some non-blocking work.
---
bsps/shared/dev/clock/clockimpl.h | 16
1 file changed, 16 insertions(+)
diff --git a/bsps/shared/dev/clock/clockimpl.h
Accesses to the L2C registers performed by the L2C driver are now
serialized with spin locks. This avoids concurrent access to the L2C
registers by multiple processors. Proposed by GRLIB-TN-0021.
Update #4925.
---
bsps/shared/grlib/l2c/l2c.c | 35 ---
1 file
---
bsps/shared/grlib/l2c/l2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bsps/shared/grlib/l2c/l2c.c b/bsps/shared/grlib/l2c/l2c.c
index ef2a524d33..d3832cdd51 100644
--- a/bsps/shared/grlib/l2c/l2c.c
+++ b/bsps/shared/grlib/l2c/l2c.c
@@ -2107,8 +2107,8 @@ int
All writes to the L2C flush registers performed by the driver are now
done using atomic write instructions. Proposed by GRLIB-TN-0021.
Update #4925.
---
bsps/shared/grlib/l2c/l2c.c | 64 +
1 file changed, 50 insertions(+), 14 deletions(-)
diff --git
---
bsps/shared/grlib/l2c/l2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/shared/grlib/l2c/l2c.c b/bsps/shared/grlib/l2c/l2c.c
index 4be29c56a4..ef2a524d33 100644
--- a/bsps/shared/grlib/l2c/l2c.c
+++ b/bsps/shared/grlib/l2c/l2c.c
@@ -50,7 +50,7 @@
/*#define DEBUG
Implement workarounds for GRLIB-TN-0021 ("Level-2 Cache Issues H1
2023") in the GRLIB L2C driver manager device driver.
Martin Åberg (5):
grlib/l2c: Fix whitespace
grlib/l2c: Use printk for debug print
grlib/l2c: Access registers with helper functions
grlib/l2c: Write to flush registers
No functional change
---
bsps/shared/grlib/l2c/l2c.c | 168 ++--
1 file changed, 84 insertions(+), 84 deletions(-)
diff --git a/bsps/shared/grlib/l2c/l2c.c b/bsps/shared/grlib/l2c/l2c.c
index 17d96874ae..4be29c56a4 100644
--- a/bsps/shared/grlib/l2c/l2c.c
+++
On 15.01.24 17:38, Joel Sherrill wrote:
Looks like one of the commits has the wrong ticket number.
It seems everything which matches with #[0-9]+ is associated with a
ticket, here it was the subject:
bsp/tms570: TMS570LC4x Errata DEVICE#60
--
embedded brains GmbH & Co. KG
Herr Sebastian
Restore the previous section, otherwise the generated code may end up in
a wrong section.
---
linkers/rtems-syms.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
index 699c014..ecdcd15 100644
--- a/linkers/rtems-syms.cpp
+++
And this is the other half of the ticket number.
-- Forwarded message -
From: RTEMS trac
Date: Mon, Jan 15, 2024, 3:37 AM
Subject: Re: [RTEMS Project] #45: shsim does not build
To:
Cc:
#45: shsim does not build
---+-
Looks like one of the commits has the wrong ticket number.
And this ticket should be closed anyway. We haven't used GNATS in a long
time.
-- Forwarded message -
From: RTEMS trac
Date: Mon, Jan 15, 2024, 3:37 AM
Subject: Re: [RTEMS Project] #60: GNATS: Additional state
To:
Cc:
---
cpukit/dev/iocrc24q.c | 148 ++
cpukit/include/rtems/dev/io.h | 41 +
spec/build/cpukit/librtemscpu.yml | 1 +
.../build/testsuites/unit/unit-no-clock-0.yml | 2 +
testsuites/unit/tc-io-packet.c| 42
From: Matthew Joyce
---
cpukit/dev/iobase64decode.c | 166
cpukit/include/rtems/dev/io.h | 63 ++
spec/build/cpukit/librtemscpu.yml | 1 +
.../build/testsuites/unit/unit-no-clock-0.yml | 1 +
The I/O packet processor provides a simple mechanism to exchange
reliable and in-order data through transmitting and receiving one
character at a time.
The I/O packet processor does not buffer data. The processor uses a
stop-and-wait automatic repeat request method. There is at most one packet
This makes them reusable. Change the character type to uint8_t.
---
cpukit/dev/iobase64.c | 24 +---
cpukit/include/rtems/dev/io.h | 10 ++
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/cpukit/dev/iobase64.c b/cpukit/dev/iobase64.c
index
The I/O packet processor provides a simple mechanism to exchange
reliable and in-order data through transmitting and receiving one
character at a time.
The I/O packet processor does not buffer data. The processor uses a
stop-and-wait automatic repeat request method. There is at most one packet
Hello Pavel,
I checked in the patch set with an update commit message for
[PATCH 24/47] bsp/tms570: Remove double pin configuration
and an updated README patch. I still have to review the chip errata for
the TMS570LC4357. This will likely result in some changes in the system
initialization
Greetings. New developer here.
I used RSB 5.3 to target RTEMS to RaspberryPi with an AMD64 Debian bullseye.
sha512sum rtems-libbsd-5.3.tar.xz listed in VERSION is hash mismatch.
Correct is:
This updates the implementation of the LEON3 processor power-down
function.
It now contains the workaround for the GR712RC power-down errata
described in GR712RC-UM, version 2.16, section 1.7.8. The workaround is
compatible with other LEON3/LEON4 components.
Update #4875.
---
On 12/1/2024 12:59 am, Peter Dufault wrote:
>> On Jan 10, 2024, at 7:05 PM, Chris Johns wrote:
>>
>>> I changed the code to use VTIME of 1 (1/10 second, or 100 msec) instead of
>>> 0. That lets TERMIOS do the character arrival timeout instead of using a
>>> delay in a loop that resets -
Hi
I was trying to test rc1 and all of the tool builds fail like this:
==
script: 86: source_dir_rtems_tools=${rtems_tools_source}
source setup: rtems-tools-6.1-rc1-1: source rtems-tools -q -n
${rtems_tools_source}
making dir:
> On Jan 10, 2024, at 7:05 PM, Chris Johns wrote:
>
>> I changed the code to use VTIME of 1 (1/10 second, or 100 msec) instead of
>> 0. That lets TERMIOS do the character arrival timeout instead of using a
>> delay in a loop that resets - essentially duplicating VTIME != 0 VMIN == 0.
>>
Hello all,
We will again plan to apply to GSoC. Please take a few minutes to
check on https://devel.rtems.org/wiki/Developer/OpenProjects to see if
any projects should be closed/removed from that list, and whether
you'd like to add any new projects.
Thanks!
Gedare
On 6/1/2024 7:56 am, Peter Dufault wrote:
>> On Jan 5, 2024, at 1:36 PM, Peter Dufault wrote:
>>
>> I "#if 0"d out the call to "rtems_shell_term_row_column_swapped()" that
>> checks for a broken "tmux" terminal. That is what sends "\033[>0q" to the
>> console. I no longer see "0q" on the
On 10/1/2024 3:38 am, Joel Sherrill wrote:
> Chris.. an RSB feature submission question at the bottom.
If virtual env is possible then I recommend that. Anything the RSB does breaks
when `waf` runs as it wants `python`.
> Rest inlined.
Same
>
> On Tue, Jan 9, 2024 at 9:30 AM Michael G. South
On 25/12/2023 8:16 am, Joel Sherrill wrote:
> Hi
>
> Trying to bring up Coverity builds on a Centos 8 machine, I ran into this:
>
> + ../source-builder/sb-set-builder --log=l-sparc.txt
> --prefix=/home/joel/rtems-cron-coverity/tools/6 --mail
> --mail-to=bu...@rtems.org
>
This patch looks good. This was also previously approved by Joel pending
the ticket number addition which is now there.
Kinsey
On Sun, Jan 7, 2024 at 12:18 PM wrote:
> From: Bernd Moessner
>
> Updates #4981
> ---
> cpukit/include/dev/flash/flashdev.h | 9 +
> 1 file changed, 9
This patch looks good to me.
Kinsey
On Sun, Jan 7, 2024 at 12:19 PM wrote:
> From: Bernd Moessner
>
> Updates #4981
> ---
> cpukit/dev/flash/flashdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
> index
This patch looks good.
Kinsey
On Sun, Jan 7, 2024 at 12:19 PM wrote:
> From: Bernd Moessner
>
> Updates #4981
> ---
> cpukit/dev/flash/flashdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
> index
Typo in the commit message. I don't know this code very well so I'll leave
content review for someone else for now.
On Sun, Jan 7, 2024 at 12:19 PM wrote:
> From: Bernd Moessner
>
> When the region feature is active, flashdev assumes that
> a relative address is provided. It computes the abs.
On Mon, Jan 8, 2024 at 9:13 AM Frank Kühndel
wrote:
>
> Hi Joel,
>
> have a great 2024!
>
> On 12/24/23 22:16, Joel Sherrill wrote:
> > Hi
> >
> > Trying to bring up Coverity builds on a Centos 8 machine, I ran into
> this:
> >
> > + ../source-builder/sb-set-builder --log=l-sparc.txt
> >
Chris.. an RSB feature submission question at the bottom.
Rest inlined.
On Tue, Jan 9, 2024 at 9:30 AM Michael G. South wrote:
>
> > On Jan 8, 2024, at 10:53 , Joel Sherrill wrote:
> >
> >
> >
> > On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
> >
> On Jan 8, 2024, at 10:53 , Joel Sherrill wrote:
>
>
>
> On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel
> wrote:
> Hi Joel,
>
> have a great 2024!
>
> On 12/24/23 22:16, Joel Sherrill wrote:
> > Hi
> >
> > Trying to bring up Coverity builds on a Centos 8 machine, I ran into
> this:
>
This avoids a dependency on the non-standard libxml2 module.
---
testsuites/tmtests/tmfine01/init.c | 30 +-
testsuites/tmtests/tmtimer01/init.c| 35 +-
testsuites/tmtests/tmtimer01/plot.py | 52 +--
testsuites/tmtests/tmtimer01/tmtimer01.scn | 389 +
This avoids a dependency on the non-standard libxml2 module.
---
testsuites/smptests/smpopenmp01/init.c| 36 +++--
.../smptests/smpopenmp01/smpopenmp01.py | 71 +
.../smptests/smpopenmp01/smpopenmp01.scn | 137 --
3 files changed, 118 insertions(+),
701 - 800 of 41539 matches
Mail list logo
