Hi
https://docs.rtems.org/branches/master/c-user/rate-monotonic/background.html#schedulability-analysis
has a bullet list which does not have bullets. But they are there in the
PDF version:
https://docs.rtems.org/branches/master/c-user.pdf
Is there something wrong with the markup? Is something
Sorry as I sent this I could see the subject and 7M.
Chris
On 9/2/2024 1:33 pm, Chris Johns wrote:
> On 8/2/2024 9:55 pm, Sebastian Huber wrote:
>> On 08.02.24 11:43, Cedric Berger wrote:
>>> On 08.02.2024 11:09, Sebastian Huber wrote:
On 08.02.24 10:53, Cedric Berger wrote:
>
>
On 8/2/2024 9:55 pm, Sebastian Huber wrote:
> On 08.02.24 11:43, Cedric Berger wrote:
>> On 08.02.2024 11:09, Sebastian Huber wrote:
>>> On 08.02.24 10:53, Cedric Berger wrote:
This would also simplify the context switching code, by centralizing of the
saving of the FPU context in
On 08.02.24 11:43, Cedric Berger wrote:
Hello Sebastian,
On 08.02.2024 11:09, Sebastian Huber wrote:
Hello Cedric,
On 08.02.24 10:53, Cedric Berger wrote:
Hello,
I've a question: does RTEMS really wants to support FPU operations in
ISRs?
Because if the answer is "no", then I believe
Hello Sebastian,
On 08.02.2024 11:09, Sebastian Huber wrote:
Hello Cedric,
On 08.02.24 10:53, Cedric Berger wrote:
Hello,
I've a question: does RTEMS really wants to support FPU operations in
ISRs?
Because if the answer is "no", then I believe that we could simplify
the RTEMS code (and
Hello Cedric,
On 08.02.24 10:53, Cedric Berger wrote:
Hello,
I've a question: does RTEMS really wants to support FPU operations in ISRs?
Because if the answer is "no", then I believe that we could simplify the
RTEMS code (and for me the mental model of the whole thing) by running
the FPU
Hello,
I've a question: does RTEMS really wants to support FPU operations in ISRs?
Because if the answer is "no", then I believe that we could simplify the
RTEMS code (and for me the mental model of the whole thing) by running
the FPU with both FPCCR.ASPEN and FPCCR.LSPEN = 0.
This mean
Hello Cedric,
thanks for having a look at this.
On 06.02.24 16:37, Cedric Berger wrote:
Hello,
I've started to investigate bug #4923.
A first problem can be found after applying the following patch to the
paranoia.exe test:
On 5/2/2024 9:13 pm, Sebastian Huber wrote:
> Hello Chris,
>
> thanks for having a look at it.
>
> On 02.02.24 00:14, Chris Johns wrote:
>> Hi,
>>
>> Thanks for the updated documentation, protocol and use cases. It has helped.
>> Now
>> I understand some of the context I have raised further
Hello,
I've started to investigate bug #4923.
A first problem can be found after applying the following patch to the
paranoia.exe test:
https://devel.rtems.org/attachment/ticket/4923/bug-1-make-paranoia-test-fail.patch
The test fails because of the added sleep(1) at the beginning of Init()
On Mon, Feb 5, 2024 at 2:36 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello Kinsey,
>
> On 02.02.24 23:03, Kinsey Moore wrote:
> > On JFFS2 file systems on NOR flash or dataflash that does not have spare
> > area for metadata and thus does not invoke delayed writes, it is
> Thanks, I checked in this patch with some changes since it didn't apply
on the master branch. I guess you have some additional local modifications.
Great!
Yes, we indeed have some changes, sorry for the conflicts. I'll see if anything
is worth upstreaming.
Regards,
Adrien
Hi Sebastian, Chris,
> I am not sure about this patch. It changes the initialization. The code
> you remove was added by:
> commit 691d0edd34f25a883c5dd0a56051d087b88e4fa4
> Author: Chris Johns
> Date: Tue Aug 17 17:57:41 2021 +1000
> arm/xilinx: Fix zynq-uart interrupt receive
> -
Hello Chris,
thanks for having a look at it.
On 02.02.24 00:14, Chris Johns wrote:
Hi,
Thanks for the updated documentation, protocol and use cases. It has helped. Now
I understand some of the context I have raised further questions about it I feel
we should resolve. Without a protocol
Hello Kinsey,
On 02.02.24 23:03, Kinsey Moore wrote:
On JFFS2 file systems on NOR flash or dataflash that does not have spare
area for metadata and thus does not invoke delayed writes, it is
possible to put the file system into a state where all blocks have been
written to and all files have
Ignoring any specific technical comments from others.
(1) Should this have a ticket? Seems impactful and odd enough to since that
shows up in release notes.
(2) Should it also be applied to 5.x with a separate ticket?
--joel
On Fri, Feb 2, 2024 at 4:40 PM Kinsey Moore
wrote:
> On JFFS2 file
On JFFS2 file systems on NOR flash or dataflash that does not have spare
area for metadata and thus does not invoke delayed writes, it is
possible to put the file system into a state where all blocks have been
written to and all files have been deleted from the filesystem. There is
a bug in the
Hi,
Thanks for the updated documentation, protocol and use cases. It has helped. Now
I understand some of the context I have raised further questions about it I feel
we should resolve. Without a protocol version number being exchanged it limits
how we can grow and develop this protocol beyond
OK to push
Chris
On 31/1/2024 8:37 am, Kinsey Moore wrote:
> QEMU used to honor LDFLAGS and CFLAGS and has since moved to accepting
> them via --extra-cflags and --extra-ldflags options to configure.
> ---
> source-builder/config/qemu-common-2.cfg | 4 ++--
> 1 file changed, 2 insertions(+), 2
On 31/1/2024 8:36 am, Kinsey Moore wrote:
> Modern versions of pkg-config include new architecture-specific symlinks
> that are sometimes checked before "pkg-config".
Oh that is a shame they have done this. Seems messy to me.
> This causes builds to
> detect the system pkg-config instead of the
This is for 6-freebsd-12. How is that specified? I don't see [PATCH
libbsd-6-freebsd-12] etc.
> On Feb 1, 2024, at 6:00 AM, dufa...@hda.com wrote:
>
> From: Peter Dufault
>
> - safe_pause_us() and safe_pause_ms() depend on the clock tick. Use DELAY().
> ---
>
From: Peter Dufault
- safe_pause_us() and safe_pause_ms() depend on the clock tick. Use DELAY().
---
freebsd/sys/dev/e1000/e1000_osdep.h | 12
1 file changed, 12 insertions(+)
diff --git a/freebsd/sys/dev/e1000/e1000_osdep.h
b/freebsd/sys/dev/e1000/e1000_osdep.h
index
Hello,
any comments to the second version of this patch set?
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Hello Adrien,
On 31.01.24 18:35, Adrien Chardon wrote:
While testing the counterpart of my protocol on a Zynq, I found a
similar issue
where the UART is assumed to be used for printable text only. The second
patch
fixes it.
I am not sure about this patch. It changes the initialization.
On 31.01.24 18:35, Adrien Chardon wrote:
You will find attached the Git patch file for the SCI bug. I've taken into
account your suggestions.
Thanks, I checked in this patch with some changes since it didn't apply
on the master branch. I guess you have some additional local modifications.
OK
Thanks
Chris
On 1/2/2024 6:30 am, Kinsey Moore wrote:
> ---
> bare/config/devel/qemu-5.2.0-1.cfg | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/bare/config/devel/qemu-5.2.0-1.cfg
> b/bare/config/devel/qemu-5.2.0-1.cfg
> index 3c8186b..ac476ad 100644
> ---
---
bare/config/devel/qemu-5.2.0-1.cfg | 7 +++
1 file changed, 7 insertions(+)
diff --git a/bare/config/devel/qemu-5.2.0-1.cfg
b/bare/config/devel/qemu-5.2.0-1.cfg
index 3c8186b..ac476ad 100644
--- a/bare/config/devel/qemu-5.2.0-1.cfg
+++ b/bare/config/devel/qemu-5.2.0-1.cfg
@@ -43,6
Hi Sebastian,
(I believe I forgot to include devel@rtems.org in my previous answer, sorry for
the duplicate email)
Sorry for the delayed answer, we were quite busy at work.
You will find attached the Git patch file for the SCI bug. I've taken into
account your suggestions.
While testing the
Hm. Somehow Outlook botched the inline quotes of the html mail.
Does it work now?
Von: Joel Sherrill
Gesendet: Mittwoch, 31. Januar 2024 16:57
An: Karel Gardas
Cc: Frank Kühndel ; Sommer, Jan
; devel@rtems.org
Betreff: Re: Naming convention for Rust target platforms
On Wed, Jan 31, 2024 at
Von: Joel Sherrill
Gesendet: Mittwoch, 31. Januar 2024 16:57
An: Karel Gardas
Cc: Frank Kühndel ; Sommer, Jan
; devel@rtems.org
Betreff: Re: Naming convention for Rust target platforms
On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas
mailto:karel@functional.vision>> wrote:
On 1/30/24 18:13,
> -Ursprüngliche Nachricht-
> Von: Frank Kühndel
> Gesendet: Dienstag, 30. Januar 2024 18:14
> An: Sommer, Jan ; devel@rtems.org
> Betreff: Re: Naming convention for Rust target platforms
>
> Hello Jan,
>
> On 1/29/24 19:41, jan.som...@dlr.de wrote:
> > Hi everyone,
> >
> > As
> -Ursprüngliche Nachricht-
> Von: Sebastian Huber
> Gesendet: Mittwoch, 31. Januar 2024 08:08
> An: Sommer, Jan ; devel@rtems.org
> Betreff: Re: AW: Naming convention for Rust target platforms
>
> On 30.01.24 13:45, jan.som...@dlr.de wrote:
> >> -Ursprüngliche Nachricht-
> >>
On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas
wrote:
> 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
> >
On 30.01.24 13:45, jan.som...@dlr.de wrote:
-Ursprüngliche Nachricht-
Von: Sebastian Huber
Gesendet: Dienstag, 30. Januar 2024 11:08
An: devel
Cc: Sommer, Jan
Betreff: Re: Naming convention for Rust target platforms
Hello Jan,
On 29.01.24 19:41,jan.som...@dlr.de wrote:
So, for the
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
Modern versions of pkg-config include new architecture-specific symlinks
that are sometimes checked before "pkg-config". This causes builds to
detect the system pkg-config instead of the local overridden pkg-config
and fail to build properly. This overrides those new symlinks to restore
build
QEMU used to honor LDFLAGS and CFLAGS and has since moved to accepting
them via --extra-cflags and --extra-ldflags options to configure.
---
source-builder/config/qemu-common-2.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/source-builder/config/qemu-common-2.cfg
On Tue, Jan 30, 2024 at 3:15 PM Joel Sherrill wrote:
>
>
> On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
>
>> Hello Jan,
>>
>> On 1/29/24 19:41, jan.som...@dlr.de wrote:
>> > Hi everyone,
>> >
>> > As mentioned in the other Rust thread, I am working
On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:
> Hello Jan,
>
> 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
Hello Jan,
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
> -Ursprüngliche Nachricht-
> Von: Sebastian Huber
> Gesendet: Dienstag, 30. Januar 2024 11:08
> An: devel
> Cc: Sommer, Jan
> Betreff: Re: Naming convention for Rust target platforms
>
> Hello Jan,
>
> On 29.01.24 19:41, jan.som...@dlr.de wrote:
> > So, for the Zynq and similar
Hello Jan,
On 29.01.24 19:41, jan.som...@dlr.de wrote:
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
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:
~/development/rtems/5.3/arm-rtems5/raspberrypi/lib/pkgconfig/libpng16.pc
@@ -8,5 +8,5 @@
Version: 1.6.37
Requires: zlib
Libs: -L${libdir} -lpng16
-Libs.private: -lz -lbsd -lm -lz -lrtemsdefaultconfig
+Libs.private: -lbsd -lm -lz -lrtemsdefaultconfig
Cflags: -I${includedir}
On 25.01.24 21:24, Kinsey Moore wrote:
This alters the API for rtems_cache_coherent_add_area to allow reporting
of failures that can occur during the process of adding a new area to
the coherent cache heap.
Looks good, thanks.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr.
This alters the API for rtems_cache_coherent_add_area to allow reporting
of failures that can occur during the process of adding a new area to
the coherent cache heap.
---
cpukit/include/rtems/rtems/cache.h | 7 -
cpukit/libcsupport/src/cachecoherentalloc.c | 30
On Thu, Jan 25, 2024 at 1:04 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 25.01.24 16:00, Kinsey Moore wrote:
> > -void rtems_cache_coherent_add_area(
> > +rtems_status_code rtems_cache_coherent_add_area(
> > void *area_begin,
> > uintptr_t area_size
> > )
> >
Hello Adrien,
the change looks good. I would remove the
tms570_sci_read_received_chars() and TMS570_SCI_BUFFER_SIZE:
static void tms570_sci_interrupt_handler(void * arg)
{
rtems_termios_tty *tty = arg;
tms570_sci_context *ctx = rtems_termios_get_device_context(tty);
/*
* Check if we
From: Matthew Joyce
---
cpukit/base64/base64-decode.c | 165
cpukit/include/rtems/base64.h | 63 ++
spec/build/cpukit/librtemscpu.yml | 1 +
.../build/testsuites/unit/unit-no-clock-0.yml | 1 +
The RTEMS Test Framework packet processor provides a simple mechanism to
exchange reliable and in-order data through transmitting and receiving
one character at a time.
The packet processor does not buffer data. The processor uses a
stop-and-wait automatic repeat request method. There is at most
---
cpukit/crc/crc24q.c | 148 ++
cpukit/include/rtems/crc.h| 106 +
spec/build/cpukit/librtemscpu.yml | 2 +
.../build/testsuites/unit/unit-no-clock-0.yml | 2 +
testsuites/unit/tc-crc.c
The RTEMS Test Framework packet processor provides a simple mechanism to
exchange reliable and in-order data through transmitting and receiving
one character at a time.
The packet processor does not buffer data. The processor uses a
stop-and-wait automatic repeat request method. There is at most
---
.../iobase64.c => base64/base64-encode.c} | 48 +++
cpukit/include/rtems/base64.h | 125 ++
cpukit/include/rtems/dev/io.h | 62 -
cpukit/libtest/gcovdumpinfobase64.c | 6 +-
cpukit/libtest/t-test-hash-sha256.c
This makes them reusable. Change the character type to uint8_t.
---
cpukit/base64/base64-encode.c | 24 +---
cpukit/include/rtems/base64.h | 10 ++
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/cpukit/base64/base64-encode.c
On 25.01.24 16:00, Kinsey Moore wrote:
-void rtems_cache_coherent_add_area(
+rtems_status_code rtems_cache_coherent_add_area(
void *area_begin,
uintptr_t area_size
)
{
+ rtems_status_code sc;
+
if ( _System_state_Is_up( _System_state_Get()) ) {
_RTEMS_Lock_allocator();
+
This changes the return type for rtems_cache_coherent_add_area from void
to rtems_status_code so that the function can report errors when they
occur.
---
spec/rtems/cache/if/coherent-add-area.yml | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
This alters the API for rtems_cache_coherent_add_area to allow reporting
of failures that can occur during the process of adding a new area to
the coherent cache heap.
---
cpukit/include/rtems/rtems/cache.h | 7 +-
cpukit/libcsupport/src/cachecoherentalloc.c | 27
On Thu, Jan 25, 2024 at 2:17 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 24.01.24 18:19, Kinsey Moore wrote:
> > This changes the return type for rtems_cache_coherent_add_area from void
> > to rtems_status_code so that the function can report errors when they
> >
Hi all,
(First time posting on a Mailing List, I apologize if I'm breaking any rule)
(For the record: this work is done during my work hours at Reflex Aerospace)
I believe that I found a bug in the TMS570 BSP, more specifically the receiving
part of the SCI driver. Please find attached the git
On 24.01.24 18:19, Kinsey Moore wrote:
This changes the return type for rtems_cache_coherent_add_area from void
to rtems_status_code so that the function can report errors when they
occur.
---
spec/rtems/cache/if/coherent-add-area.yml | 14 --
1 file changed, 12 insertions(+), 2
On 24.01.24 18:19, Kinsey Moore wrote:
-static void add_area(
+static int add_area(
void *area_begin,
uintptr_t area_size
)
If you return a status code here, you can directly return it in
rtems_cache_coherent_add_area().
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
On 25/1/2024 12:33 am, Sebastian Huber wrote:
> - Am 24. Jan 2024 um 0:55 schrieb Chris Johns chr...@rtems.org:
>
>> On 23/1/2024 5:55 pm, Sebastian Huber wrote:
>>> - Am 22. Jan 2024 um 22:56 schrieb Chris Johns chr...@rtems.org:
> [...]
>>> The usage of LLVM for the RTEMS Tools is
---
cpukit/libblock/src/bdbuf.c | 2 +-
cpukit/libblock/src/blkdev-imfs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/libblock/src/bdbuf.c b/cpukit/libblock/src/bdbuf.c
index ee98ada85f..ee6f1d9347 100644
--- a/cpukit/libblock/src/bdbuf.c
+++
This is already in the error path.
---
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 1ab7dd2034..cc6bb70f91 100644
--- a/cpukit/libblock/src/media.c
+++ b/cpukit/libblock/src/media.c
This changes the return type for rtems_cache_coherent_add_area from void
to rtems_status_code so that the function can report errors when they
occur.
---
spec/rtems/cache/if/coherent-add-area.yml | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git
This alters the API for rtems_cache_coherent_add_area to allow reporting
of failures that can occur during the process of adding a new area to
the coherent cache heap.
---
cpukit/include/rtems/rtems/cache.h | 12 -
cpukit/libcsupport/src/cachecoherentalloc.c | 27
Patches 1 and 3 look good. I need to spend more time reviewing patch 2 than
I have right at this moment.
Kinsey
On Tue, Jan 23, 2024 at 11:22 PM wrote:
> Hi All,
>
> Attached are V2 of the patches that adds a wrapper around Xilinx's$
> XQspiPsu flash driver to rtems_flashdev. This has been
- Am 24. Jan 2024 um 0:55 schrieb Chris Johns chr...@rtems.org:
> On 23/1/2024 5:55 pm, Sebastian Huber wrote:
>> - Am 22. Jan 2024 um 22:56 schrieb Chris Johns chr...@rtems.org:
[...]
>> The usage of LLVM for the RTEMS Tools is optional. You can build them without
>> LLVM. However, this
From: Peter Dufault
- Fix detection of timeout in rtems_shell_term_wait_for().
- Use the "termios" VTIME inter-character timeout.
The previous version depends on the BSP clock tick and can be long.
- Add debugging regarding terminal size sequences.
Updates #4763
---
> On Jan 23, 2024, at 7:09 PM, Chris Johns wrote:
>
> On 23/1/2024 9:00 pm, Peter Dufault wrote:
>>> On Jan 22, 2024, at 1:51 PM, Peter Dufault wrote:
On Jan 22, 2024, at 12:16 PM, Gedare Bloom wrote:
I have a couple minor notes below. More important, does this change
From: Aaron Nyholm
---
cpukit/libmisc/shell/main_flashdev.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/cpukit/libmisc/shell/main_flashdev.c
b/cpukit/libmisc/shell/main_flashdev.c
index ca2454b33c..dc73d3f9db 100644
--- a/cpukit/libmisc/shell/main_flashdev.c
From: Aaron Nyholm
---
bsps/aarch64/xilinx-versal/include/bsp/irq.h | 1 +
bsps/include/dev/spi/xqspi_flash.h| 65 ++
bsps/include/dev/spi/xqspipsu-flash-helper.h | 20 ++
bsps/shared/dev/spi/xqspi_flash.c | 210 ++
From: Aaron Nyholm
---
spec/build/bsps/aarch64/xilinx-versal/grp.yml| 2 ++
.../bsps/aarch64/xilinx-versal/optxilversal.yml | 16
2 files changed, 18 insertions(+)
create mode 100644 spec/build/bsps/aarch64/xilinx-versal/optxilversal.yml
diff --git
Hi All,
Attached are V2 of the patches that adds a wrapper around Xilinx's$
XQspiPsu flash driver to rtems_flashdev. This has been placed in$
bsp/shared. The JFFS2 driver has been removed as it is outdated.
Thanks,
Aaron.
___
devel mailing list
On 23/1/2024 9:00 pm, Peter Dufault wrote:
>> On Jan 22, 2024, at 1:51 PM, Peter Dufault wrote:
>>> 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
On 23/1/2024 5:55 pm, Sebastian Huber wrote:
> - 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
---
rtemsbsd/rtems/rtems-bsd-mountroot.c | 4 ++--
rtemsbsd/rtems/rtems-bsd-rc-conf.c | 14 ++
rtemsbsd/rtems/rtems-routes.c| 4 +++-
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/rtemsbsd/rtems/rtems-bsd-mountroot.c
---
rtemsbsd/rtems/rtems-bsd-rc-conf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/rtemsbsd/rtems/rtems-bsd-rc-conf.c
b/rtemsbsd/rtems/rtems-bsd-rc-conf.c
index f4cc987b..d34aafd9 100644
--- a/rtemsbsd/rtems/rtems-bsd-rc-conf.c
+++ b/rtemsbsd/rtems/rtems-bsd-rc-conf.c
---
rtemsbsd/rtems/rtems-bsd-rc-conf-net.c | 10 ++
rtemsbsd/rtems/rtems-bsd-syscall-api.c | 9 ++---
rtemsbsd/rtems/rtems-kernel-init.c | 4 +++-
rtemsbsd/rtems/rtems-kernel-pager.c| 4 +++-
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git
This moves the ZynqMP-specific variable initialization to the start of
the function to avoid Coverity warnings.
---
rtemsbsd/sys/dev/sdhci/arasan_sdhci.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/rtemsbsd/sys/dev/sdhci/arasan_sdhci.c
---
rtemsbsd/rtems/rtems-kernel-lockmgr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/rtemsbsd/rtems/rtems-kernel-lockmgr.c
b/rtemsbsd/rtems/rtems-kernel-lockmgr.c
index 518f6831..de5d9d8a 100644
--- a/rtemsbsd/rtems/rtems-kernel-lockmgr.c
+++ b/rtemsbsd/rtems/rtems-kernel-lockmgr.c
@@
This is the 6-freebsd-12 version of the cleanup patch set. Coverity was
actually run against 6-freebsd-12, so this patch set is slightly larger
than the master patch set.
___
devel mailing list
devel@rtems.org
---
rtemsbsd/rtems/rtems-bsd-rc-conf.c | 14 ++
rtemsbsd/rtems/rtems-routes.c | 4 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/rtemsbsd/rtems/rtems-bsd-rc-conf.c
b/rtemsbsd/rtems/rtems-bsd-rc-conf.c
index d34aafd9..88d98c3e 100644
---
---
rtemsbsd/rtems/rtems-bsd-rc-conf-net.c | 10 ++
rtemsbsd/rtems/rtems-kernel-init.c | 4 +++-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/rtemsbsd/rtems/rtems-bsd-rc-conf-net.c
b/rtemsbsd/rtems/rtems-bsd-rc-conf-net.c
index 23ee15db..8ffaa914 100644
---
---
rtemsbsd/rtems/rtems-bsd-rc-conf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/rtemsbsd/rtems/rtems-bsd-rc-conf.c
b/rtemsbsd/rtems/rtems-bsd-rc-conf.c
index f4cc987b..d34aafd9 100644
--- a/rtemsbsd/rtems/rtems-bsd-rc-conf.c
+++ b/rtemsbsd/rtems/rtems-bsd-rc-conf.c
This patch set cleans up several issues found by Coverity on the master
branch.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
> On Jan 22, 2024, at 1:51 PM, Peter Dufault wrote:
>
>
>
>> 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
From: Sebastian Huber
---
freebsd/sys/powerpc/mpc85xx/mpc85xx.c | 38 +++
freebsd/sys/powerpc/mpc85xx/mpc85xx.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/freebsd/sys/powerpc/mpc85xx/mpc85xx.c
b/freebsd/sys/powerpc/mpc85xx/mpc85xx.c
index
From: Sebastian Huber
---
freebsd/sys/dev/ofw/ofwpci.c | 16
freebsd/sys/dev/pci/pci.c | 2 +
freebsd/sys/kern/subr_bus.c | 2 +-
freebsd/sys/powerpc/include/machine/spr.h | 3 ++
freebsd/sys/powerpc/mpc85xx/mpc85xx.c | 4 ++
From: Sebastian Huber
---
rtemsbsd/include/machine/resource.h | 1 +
.../include/machine/rtems-bsd-kernel-space.h | 8 +++
rtemsbsd/rtems/rtems-kernel-nexus.c | 21 +++
3 files changed, 30 insertions(+)
diff --git a/rtemsbsd/include/machine/resource.h
From: Sebastian Huber
---
rtemsbsd/rtems/rtems-kernel-pci_bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/rtemsbsd/rtems/rtems-kernel-pci_bus.c
b/rtemsbsd/rtems/rtems-kernel-pci_bus.c
index d344e7a3..67324dd8 100644
--- a/rtemsbsd/rtems/rtems-kernel-pci_bus.c
+++
From: Sebastian Huber
---
freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
b/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
index beaf96e8..47879e68 100644
--- a/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
+++
From: Sebastian Huber
---
Makefile.todo | 10 ++
rtemsbsd/include/rtems/bsd/local/pic_if.h | 133 ++
rtemsbsd/local/pic_if.c | 69 +++
3 files changed, 212 insertions(+)
create mode 100644
From: Sebastian Huber
---
freebsd/sys/dev/pci/pci.c | 2 --
rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h | 1 +
rtemsbsd/rtems/rtems-kernel-pci_bus.c | 1 +
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git
The CFG_ADDR has to be written before reading or writing the CFG_DATA.
---
freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
b/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
index 47879e68..b479eb33 100644
From: Sebastian Huber
---
buildset/default.ini | 1 +
buildset/everything.ini | 3 +
libbsd.py| 17
rtemsbsd/include/bsp/nexus-devices.h | 4 +
rtemsbsd/sys/dev/vme/tsi148.c| 123 +++
5 files
From: Sebastian Huber
---
freebsd/sys/dev/ofw/ofwpci.c | 677 +
freebsd/sys/dev/ofw/ofwpci.h | 87 ++
freebsd/sys/dev/pci/pci_subr.c| 388 +++
freebsd/sys/powerpc/include/machine/hid.h | 224
The glue layer provides the necessary function so that the Tsi148 driver
in the BSP can use the PCI functionality from libbsd.
---
libbsd.py | 1 +
rtemsbsd/sys/dev/vme/tsi148.c | 24 +++-
rtemsbsd/sys/dev/vme/vme-rtems-compat.c | 143
Note: This test currently only works with a board with a Tsi148 like the
MVME2500. For other boards it will print only a message.
---
libbsd.py | 2 +
testsuite/vme01/test_main.c | 80 +
2 files changed, 82 insertions(+)
create mode 100644
601 - 700 of 41539 matches
Mail list logo
