- 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
24 matches
Mail list logo
