Hi
If you have any patches that are still pending on the mailing list, please
get yourself an account on gitlab.rtems.org and submit them as a merge
request.
Instructions are linked to in Chris' emails.
Help is available on devel@ and Discord.
Thanks.
-
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_flashd
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
`tsi148` is set to on in the buildset
in libbsd. Otherwise, no VME parts will be linked into the application.
Please note that the libbsd patches currently can only be applied to
6-freebsd-12. The master branch is a few months behind the 6-freebsd-12
in the FreeBSD development. Unluckily, the PCIe driver
On Thu, Dec 7, 2023 at 12:19 AM Sebastian Huber
wrote:
>
> Hello,
>
> it seems we still have no tool and configuration to get satisfying
> results when applied to existing RTEMS source files. May I suggest a
> more pragmatic approach which focuses on new files. Would it be an
> option to simply us
Hello,
it seems we still have no tool and configuration to get satisfying
results when applied to existing RTEMS source files. May I suggest a
more pragmatic approach which focuses on new files. Would it be an
option to simply use automatic formatting for all new files specifically
written fo
Hello,
I noted some minor bugs in the first version of the patches while using
them. So here is a second version.
That are BSP specific patches and I now used the driver in this
configuration for some time and found no further problems. So if no one
objects, I will push the patches in a few days
Hello,
with this patch set, the LPSPI of the imxrt BSPs now can use a GPIO as a
chip select pin. The documentation is updated to show how it works.
Additionally a minor fix for the iomux for the imxrt1166 is added. On
that BSP some pins have been initialized that shouldn't be initialized
unless s
On Thu, Jul 27, 2023, 1:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 26.07.23 17:17, Gedare Bloom wrote:
> > On Tue, Jul 25, 2023 at 11:15 PM Sebastian Huber
> > wrote:
> >>
> >> On 25.07.23 23:41, Gedare Bloom wrote:
&
On 26.07.23 17:17, Gedare Bloom wrote:
On Tue, Jul 25, 2023 at 11:15 PM Sebastian Huber
wrote:
On 25.07.23 23:41, Gedare Bloom wrote:
I have sent two initial patches to begin the style reformat. The
clang-format file is not quite 100%, and it's also not usable by
anyone else (as I wai
On Tue, Jul 25, 2023 at 11:15 PM Sebastian Huber
wrote:
>
> On 25.07.23 23:41, Gedare Bloom wrote:
> > I have sent two initial patches to begin the style reformat. The
> > clang-format file is not quite 100%, and it's also not usable by
> > anyone else (as I wa
On 25.07.23 23:41, Gedare Bloom wrote:
I have sent two initial patches to begin the style reformat. The
clang-format file is not quite 100%, and it's also not usable by
anyone else (as I wait for changes to be accepted upstream).
A few things to note:
* We can always manually override
https://git.rtems.org/gedare/rtems.git/log/?h=aarch64-reformat
https://git.rtems.org/gedare/rtems.git/log/?h=arm-reformat
On Tue, Jul 25, 2023 at 3:56 PM Chris Johns wrote:
>
> On 26/7/2023 7:41 am, Gedare Bloom wrote:
> > I have sent two initial patches to begin the style r
On 26/7/2023 7:41 am, Gedare Bloom wrote:
> I have sent two initial patches to begin the style reformat. The
> clang-format file is not quite 100%, and it's also not usable by
> anyone else (as I wait for changes to be accepted upstream).
>
> A few things to note:
> *
I have sent two initial patches to begin the style reformat. The
clang-format file is not quite 100%, and it's also not usable by
anyone else (as I wait for changes to be accepted upstream).
A few things to note:
* We can always manually override style with good reason. If you see
something
Hi,
This verison:
1. Fixes the comment after the review
2. The nfs01 test exits when finished rather than stopping in the shell
3. Add a fix to allow multiple mounts with the same mount basename
Chris
___
devel mailing list
devel@rtems.org
http://list
Hello,
some weeks back, I mentioned that I want to add a new BSP variant to the
i.MXRT family. Now I have finally a version that is clean enough to
publish it. I'm sure that some more patches for further components will
follow (like USB). But the current version is stable and usable enou
Reapply patches used in the old version of the NXP library and apply
patches necessary for the new version of the library.
---
.../devices/MIMXRT1052/fsl_device_registers.h | 3 +
.../MIMXRT1052/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1166/fsl_device_registers.h | 3
Reapply patches used in the old version of the NXP library and apply
patches necessary for the new version of the library.
---
.../devices/MIMXRT1011/fsl_device_registers.h | 3 +
.../MIMXRT1011/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1015/fsl_device_registers.h | 3
bot that adds a comment to pull requests,
that patches should be sent to the mailing list as soon as they are tested. It
will close pull requests after 30 days. That can be disabled again with removing
that action.
All artefacts can be removed by everyone with enough rights in the RTEMS GitHub
ts, we will have a bot that adds a comment to pull
> requests,
> that patches should be sent to the mailing list as soon as they are tested. It
> will close pull requests after 30 days. That can be disabled again with
> removing
> that action.
>
> All artefacts can b
(because we have
found and implemented a proper CI/CD that we officially want to use and
not only have in a test phase), we can just remove the scripts with a
new commit.
If we use both commits, we will have a bot that adds a comment to pull
requests, that patches should be sent to the mailing list
On 19.01.23 15:42, Gedare Bloom wrote:
Nice. I would like some time to look at this and think about it a
little more. What would be the plan for removing this capability? Will
it leave any artifacts behind in the RTEMS github mirror?
It seems by default stuff is kept for about 90 days:
https:/
I created a GitHub Actions based CI script that we
> (embedded brains) wanted to use to test patches (see
> https://github.com/embedded-brains/rtems/tree/ci). I don't think much of
> the RTEMS community noted these. I would like to suggest adding the
> scripts to the official R
Hello,
some weeks ago I created a GitHub Actions based CI script that we
(embedded brains) wanted to use to test patches (see
https://github.com/embedded-brains/rtems/tree/ci). I don't think much of
the RTEMS community noted these. I would like to suggest adding the
scripts to the official
t; Software).
>> > > 2. Consistent capitalization of Copyright (C) in file header blocks as
>> > > per #4637.
>> > > * Style Updates as per #3860.
>> > >
>> > > This effort will include documentation, inclusion of automation tools,
>> >
t; per #4637.
> > > * Style Updates as per #3860.
> > >
> > > This effort will include documentation, inclusion of automation tools,
> > > and 3rd party software management. I will send patches and give notice
> > > before any changes hit, but I wanted to give
ntation, inclusion of automation tools,
> > and 3rd party software management. I will send patches and give notice
> > before any changes hit, but I wanted to give a heads up here that this
> > process will be taking place. If you have any specific requests or
> > patches p
y
> Software).
> 2. Consistent capitalization of Copyright (C) in file header blocks as
> per #4637.
> * Style Updates as per #3860.
>
> This effort will include documentation, inclusion of automation tools,
> and 3rd party software management. I will send patches and give notic
ools,
> and 3rd party software management. I will send patches and give notice
> before any changes hit, but I wanted to give a heads up here that this
> process will be taking place. If you have any specific requests or
> patches pending in an area that I should avoid
file header blocks as
per #4637.
* Style Updates as per #3860.
This effort will include documentation, inclusion of automation tools,
and 3rd party software management. I will send patches and give notice
before any changes hit, but I wanted to give a heads up here that this
process will be taking
Hi Christian,
I squashed the commits and pushed to the same branch.
https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-dev-squashed1
Regards
Prashanth S
On Wed, 26 Oct, 2022, 10:56 pm , wrote:
> Hello Prashanth,
>
> from my point of view the patches look good and I think you
Hello Prashanth,
from my point of view the patches look good and I think you processed
Gedares feedback too. So if no one objects I'll pus the patches on the
weekend.
Last version is this one:
https://gitlab.com/slpp95prashanth/gsoc-2022/-/commits/30199c2af1c65f05f820a/
Like discuss
Hi All,
This is a review request for the DCAN patch, I have updated the files based
on review comments.
Attaching the patch as a zip file.
Regards
Prashanth S
DCAN.tar.lzma
Description: application/lzma
___
devel mailing list
devel@rtems.org
http://li
Hi,
For these patches I fixed some of the warnings and added pragmas to ignore
some of the others. These were the warnings I got when building
AArch64/xilinx_zynqmp_lp64_qemu. If you have any feedback on fixing some of
these warnings instead of just ignoring them, please let me know and I can
get
i Kinsey,
> >
> > This patchset is looking great. Thank you!
> > Unfortunately, I won't be able to test the BBB right away but I see
> > that most patches are probably from the devel branch of lwip, which I
> >
> > correction: most of BBB related changes. :)
From: Michael Tuexen
No functional change.
Submitted by: Richard Scheffenegger
Reviewed by: rgrimes@, tuexen@
Differential Revision: https://reviews.freebsd.org/D22429
---
newlib/libc/sys/rtems/include/netinet/tcp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/newlib/li
est the BBB right away but I see
> that most patches are probably from the devel branch of lwip, which I
>
> correction: most of BBB related changes. :)
>
> It should actually be all of the BBB related changes, I just squashed some of
> them together since I was doing a p
On 7/1/2022 18:50, Vijay Kumar Banerjee wrote:
On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee wrote:
Hi Kinsey,
This patchset is looking great. Thank you!
Unfortunately, I won't be able to test the BBB right away but I see
that most patches are probably from the devel branch of
On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee wrote:
>
> Hi Kinsey,
>
> This patchset is looking great. Thank you!
> Unfortunately, I won't be able to test the BBB right away but I see
> that most patches are probably from the devel branch of lwip, which I
correcti
Hi Kinsey,
This patchset is looking great. Thank you!
Unfortunately, I won't be able to test the BBB right away but I see
that most patches are probably from the devel branch of lwip, which I
tested before. I am going to wait till Tuesday, to get any comments or
objections from others.
This brings in a significantly cleaned up version of the remaining
patches on the devel branch and adds support for ZynqMP CGEMs. I have
tested CGEM0 on QEMU and CGEM3 on hardware. I am unable to test on the
BeagleBoneBlack at the moment, so I'd appreciate a double-check to
ensure I haven
On 4/22/2022 07:28, Sebastian Huber wrote:
On 17/03/2022 13:30, Kinsey Moore wrote:
On 3/17/2022 05:00, Sebastian Huber wrote:
Hello,
the current Newlib build fails for aarch64 due to RTEMS-specific
patches:
CC libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc
On 17/03/2022 13:30, Kinsey Moore wrote:
On 3/17/2022 05:00, Sebastian Huber wrote:
Hello,
the current Newlib build fails for aarch64 due to RTEMS-specific patches:
CC libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10:
fatal
On 3/17/2022 10:43, Sebastian Huber wrote:
On 17/03/2022 16:40, Kinsey Moore wrote:
with current newlib (ed32020)
This is not the current Newlib. There are a couple of build system
patches on top of it.
I guess the problem is that one location in the patch uses #include
<...> a
On 17/03/2022 16:40, Kinsey Moore wrote:
with current newlib (ed32020)
This is not the current Newlib. There are a couple of build system
patches on top of it.
I guess the problem is that one location in the patch uses #include
<...> and not #include "...'.
--
embedded
On 3/17/2022 07:30, Kinsey Moore wrote:
On 3/17/2022 05:00, Sebastian Huber wrote:
Hello,
the current Newlib build fails for aarch64 due to RTEMS-specific
patches:
CC libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10:
fatal error
On 3/17/2022 05:00, Sebastian Huber wrote:
Hello,
the current Newlib build fails for aarch64 due to RTEMS-specific patches:
CC libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10:
fatal error: ../asmdefs.h: No such file or directory
Hello,
the current Newlib build fails for aarch64 due to RTEMS-specific patches:
CC libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10:
fatal error: ../asmdefs.h: No such file or directory
29 | #include <../asmdef
for these in the last two weeks. I assume there
> >> are no further objections and I can push the patches to master in about
> >> a week so that the bug is fixed at least for 6.
> >>
> > Yeah, that's fine with me, thanks for getting it tested on another
&
Hello Gedare,
Am 07.02.22 um 16:40 schrieb Gedare Bloom:
On Wed, Feb 2, 2022 at 8:20 AM Christian MAUDERER
wrote:
Hello,
I received no comments for these in the last two weeks. I assume there
are no further objections and I can push the patches to master in about
a week so that the bug is
On Wed, Feb 2, 2022 at 8:20 AM Christian MAUDERER
wrote:
>
> Hello,
>
> I received no comments for these in the last two weeks. I assume there
> are no further objections and I can push the patches to master in about
> a week so that the bug is fixed at least for 6.
>
Yeah
Hello,
I received no comments for these in the last two weeks. I assume there
are no further objections and I can push the patches to master in about
a week so that the bug is fixed at least for 6.
Best regards
Christian
Am 27.01.22 um 13:25 schrieb Christian MAUDERER:
Hello,
again: What
Hello,
again: What can I do to make the patches acceptable?
Best regards
Christian
Am 21.01.22 um 11:57 schrieb Christian MAUDERER:
Ping.
Am 18.01.22 um 12:22 schrieb Christian MAUDERER:
Hello,
I noted that I still have this patch set open. I first posted it in
August 2021 and later
Ping.
Am 18.01.22 um 12:22 schrieb Christian MAUDERER:
Hello,
I noted that I still have this patch set open. I first posted it in
August 2021 and later pinged it in September 2021. Both times no
conclusion has been found. I would like to finally finish this topic and
get the patches in an
Hello,
I noted that I still have this patch set open. I first posted it in
August 2021 and later pinged it in September 2021. Both times no
conclusion has been found. I would like to finally finish this topic and
get the patches in an acceptable state. To simplify it a bit, let's
OK and thanks for the split.
Thanks
Chris
On 14/12/21 3:09 am, Ryan Long wrote:
> Hi,
>
> For this patchset I made the formatting more consistent.
>
> This included:
>
> - adding whitespace
> - adding curly braces to if statements or loops
> - fixing the layout of long lists of function parame
Hi,
For this patchset I made the formatting more consistent.
This included:
- adding whitespace
- adding curly braces to if statements or loops
- fixing the layout of long lists of function parameters
Thanks,
Ryan
Ryan Long (6):
ObjdumpProcessor.cc: Fix formatting
TargetFactory.cc: Fix for
On 10/12/21 10:00 am, Ryan Long wrote:
> For this round of changes, I made some revisions that were recommended
> in ConfigFile.cc
>
> - deleted a library include
> - changed a function call from sscanf to std::sscanf
> - consolidated some error messages into a function
OK to push.
Thanks
Chris
Hi,
For this round of changes, I made some revisions that were recommended
in ConfigFile.cc
- deleted a library include
- changed a function call from sscanf to std::sscanf
- consolidated some error messages into a function
Thanks,
Ryan
Ryan Long (4):
TargetFactory.cc: Convert to C++
Target
Hi,
For this series of patches, I
- Changed char * parameters and variables to a string
- Changed C functions to corresponding C++ functions
- Switched C file handling out for C++ file handling
Thanks,
Ryan
Ryan Long (4):
TargetFactory.cc: Convert to C++
Target: Convert to C++
ConfigFile
These patches add patches that fix the build issues preventing qemu4
from building on Ubuntu.
Closes #4561
---
bare/config/devel/glib-2.46.2-1.cfg | 2 ++
bare/config/devel/qemu4-git-1.cfg | 2 ++
2 files changed, 4 insertions(+)
diff --git a/bare/config/devel/glib-2.46.2-1.cfg
b/bare/config
r acceptable especially since
thunderbird may always malformat the patch.
I'm setting up git email framework to better work with rtems-devel@.
Once done, I'll resubmit the patches again.
Thanks for your patience,
Karel
___
devel mailing lis
OK for both
On 8/10/21 12:40 am, Ryan Long wrote:
> Hi,
>
> These patches fix the "Uncaught exception" Coverity issues. To fix this,
> I just added a try and catch for the exception that Coverity identified.
>
> Thanks,
> Ryan
>
> Ryan Long (2):
> Tr
Hi,
These patches fix the "Uncaught exception" Coverity issues. To fix this,
I just added a try and catch for the exception that Coverity identified.
Thanks,
Ryan
Ryan Long (2):
TraceConverter.cc: Add catch for exception
rld-rapp.cpp: Add catch for exception
rtemstoolkit/r
?
Of course.
Is there still an open point left of can I push the patches?
What happens if another BSP needs the same change? Is it also OK for the same
reasons or is this the only one?
As the PPPD code needs specific drivers can the build in LibBSD be restricted to
the BSPs that support it and
sh the patches?
What happens if another BSP needs the same change? Is it also OK for the same
reasons or is this the only one?
As the PPPD code needs specific drivers can the build in LibBSD be restricted to
the BSPs that support it and no others?
> Chris: Back when I posted the patch set you menti
patches?
Best regards
Christian
Am 12.08.21 um 13:41 schrieb Christian Mauderer:
Hello,
this set of patches fixes PPP. Basically the current implementation in
libbsd can't work with console drivers that can't buffer a lot of
characters. The pppstart() function just assumes that the
Hello,
this set of patches fixes PPP. Basically the current implementation in
libbsd can't work with console drivers that can't buffer a lot of
characters. The pppstart() function just assumes that the low level
console write can send an arbitrary number of characters without
checkin
OK to push.
Thanks
Chris
On 12/8/21 7:09 am, Ryan Long wrote:
> Hi,
>
> In this series of patches, I just added ostream_guards where there were
> "Restore ostream format" errors. This won't make the error go away, but
> we're going to start ign
Hi,
In this series of patches, I just added ostream_guards where there were
"Restore ostream format" errors. This won't make the error go away, but
we're going to start ignoring those errors and just placing
ostream_guards as was done here.
Thanks,
Ryan
Ryan Long (3)
of memset() with 0:
int some_array[10] = {0};
On Wed, Aug 4, 2021 at 2:53 AM wrote:
>
> Hi,
>
> This the first group of patches for the NFSv4 port. This is the only
> part of the patches posted to devel, the complete series of patches
> can be downloaded from:
>
> http
Hi,
This the first group of patches for the NFSv4 port. This is the only
part of the patches posted to devel, the complete series of patches
can be downloaded from:
https://ftp.rtems.org/pub/rtems/people/chrisj/nfsv4/patches/4/
I have pushed the patch series to my personal repo:
https
On 28/7/21 12:13 am, Alex White wrote:
> On Tue, Jul 27, 2021 at 12:46 AM Chris Johns wrote:
>>
>> On 27/7/21 3:39 pm, Sebastian Huber wrote:
>> > On 27/07/2021 05:30, Alex White wrote:
>> >> This prevents patches with the same name from conflicting
On Tue, Jul 27, 2021 at 12:46 AM Chris Johns wrote:
>
> On 27/7/21 3:39 pm, Sebastian Huber wrote:
> > On 27/07/2021 05:30, Alex White wrote:
> >> This prevents patches with the same name from conflicting and causing
> >> the build to fail.
> >
> > Why
On 27/7/21 3:39 pm, Sebastian Huber wrote:
> On 27/07/2021 05:30, Alex White wrote:
>> This prevents patches with the same name from conflicting and causing
>> the build to fail.
>
> Why can't the patches have a unique file name?
Yeap and if specific to Xilinx an
On 27/07/2021 05:30, Alex White wrote:
This prevents patches with the same name from conflicting and causing
the build to fail.
Why can't the patches have a unique file name?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@emb
Hi Ryan,
Why is this needed?
Does this change effect all builds and does a user end up with copies of the
same patches?
Have you built a full release with this change? It will be required for me to
consider accepting any part of these patches.
Chris
On 27/7/21 1:30 pm, Alex White wrote
This prevents patches with the same name from conflicting and causing
the build to fail.
---
source-builder/defaults.mc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/source-builder/defaults.mc b/source-builder/defaults.mc
index 98775e8..d24d969 100644
--- a/source-builder
Hi,
The following patches update the Strong APA Scheduler, the existing
test for the scheduler and add two more test for the scheduler that
use different number of cpus. The scheduler has been tested on rtems-test
with Strong APA scheduler set as the default scheduler; It performs as good
as
Unless there is an objection over the weekend, I will push these Monday.
Then we can begin to wade through the ones with commentary
that have lingered. Probably one at a time now.
--joel
On Fri, May 28, 2021 at 2:11 PM Ryan Long wrote:
> Hi,
>
> These patches are from various patc
Hi,
In these patches, I added missing fclose()'s and converted some pointers
to be of the data type that they were pointing to.
Thanks,
Ryan
Ryan Long (6):
Explanations.cc: Fix resource leaks
TraceReaderLogQEMU.cc: Fix resource leak
GcovData.cc: Fix resource leak
TraceWriterQEMU.cc
Hi,
These patches are from various patch sets to fix Coverity issues.
These were previously acked, but other patches in the corresponding
patch sets prevented them from getting pushed.
Thanks,
Ryan
Ryan Long (4):
rtems-fdt.c: Fix Resource leak (CID #1437645)
main_rtrace.c: Add error return
This patch set is the culmination of the recent inquiry into why
some BSPs have a minimum.exe around 32K of text and others are
twice that. This addresses two unnecessary dependencies that
resulted in ~25K reductions in minimum.exe for the jmr3904
and psim BSPs.
I plan to make a sweep in the near
All 3 are fine with me, thanks
On Mon, Apr 5, 2021 at 7:28 AM Ryan Long wrote:
>
> Hi,
>
> For these patches, I just added #ifdefs and (void)'s to get rid of the
> issues.
>
> Thanks,
> Ryan
>
> Ryan Long (3):
> gen_uuid.c: Ignore return values from fcnt
Hi,
For these patches, I just added #ifdefs and (void)'s to get rid of the
issues.
Thanks,
Ryan
Ryan Long (3):
gen_uuid.c: Ignore return values from fcntl()
main_cp.c: Ignore return value from stat()
main_help.c: Do not care what char is returned by getchar()
cpukit/libmisc/
Hi,
For these patches, I just added #ifdefs and (void)'s to get rid of the issues.
Thanks,
Ryan
Ryan Long (3):
gen_uuid.c: Ignore return values from fcntl()
main_cp.c: Ignore return value from stat()
main_help.c: Do not care what char is returned by getchar()
cpukit/libmisc/
Hi
There has been a flurry of patches which, quite frankly, have made the core
developers delighted and a bit overwhelmed.
If you have a patch outstanding that you think has slipped through the
cracks, please ping the patch and let's make sure it gets the review it
needs.
Hopefully there
On Wed, Mar 24, 2021 at 11:04 AM Joel Sherrill wrote:
>
>
>
> On Wed, Mar 24, 2021 at 10:52 AM Gedare Bloom wrote:
>>
>> On Wed, Mar 24, 2021 at 7:56 AM Alex White wrote:
>> > My plan is to resend the patches that have not been reviewed and meter
>> &
On Wed, Mar 24, 2021 at 10:52 AM Gedare Bloom wrote:
> On Wed, Mar 24, 2021 at 7:56 AM Alex White wrote:
> >
> > Hi,
> >
> >
> >
> > Here is the status of the rtems-tools patches I have sent out over the
> past few weeks (an X means t
On Wed, Mar 24, 2021 at 7:56 AM Alex White wrote:
>
> Hi,
>
>
>
> Here is the status of the rtems-tools patches I have sent out over the past
> few weeks (an X means the latest patch revision has been reviewed):
>
>
>
> [ ] tester: Limit branch coverage percentag
Hi,
Here is the status of the rtems-tools patches I have sent out over the past few
weeks (an X means the latest patch revision has been reviewed):
[ ] tester: Limit branch coverage percentage precision
[ ] coverage: Fix option processing on FreeBSD
[ ] coverage/symbol-sets.ini : Add libtrace
Yes, that looks right. Joel, you can push his grlib patches and the
case fall-throughs.
On Fri, Mar 5, 2021 at 11:19 AM Ryan Long wrote:
>
> Hi,
>
>
>
> Since I’ve sent a lot of patches this week, I just want to verify which are
> ready to be merged and what ne
Hi,
Since I've sent a lot of patches this week, I just want to verify which are
ready to be merged and what needs to be resubmitted.
Ready to be merged:
Grlib patches:
* grspw.c
* gr_rasta_spw_router.c
* gr_rasta_tmtc.c
* gr_leon4_n2x.c
* gr_
t; > Hi
> >
> > Phillip Smith pinged me at the FSW via Slack about this set of patches
> he
> proposed be added to the 4.10 branch.
> >
> > https://lists.rtems.org/pipermail/devel/2019-April/025610.html
> <https://lists.rtems.org/p
On Thu, Feb 11, 2021 at 1:47 PM Gedare Bloom wrote:
> Hi Joel,
>
> On Thu, Feb 11, 2021 at 12:30 PM Joel Sherrill wrote:
> >
> > Hi
> >
> > Phillip Smith pinged me at the FSW via Slack about this set of patches
> he proposed be added to the 4.10 branch.
>
Hi Joel,
On Thu, Feb 11, 2021 at 12:30 PM Joel Sherrill wrote:
>
> Hi
>
> Phillip Smith pinged me at the FSW via Slack about this set of patches he
> proposed be added to the 4.10 branch.
>
> https://lists.rtems.org/pipermail/devel/2019-April/025610.html
>
> I ass
Hi
Phillip Smith pinged me at the FSW via Slack about this set of patches he
proposed be added to the 4.10 branch.
https://lists.rtems.org/pipermail/devel/2019-April/025610.html
I assume this matches what their project requires. Given that 4.10 is the
last unirprocessor version and we appear to
based BSPs) would
be better to allow a user to overwrite the table if he has a board with
a slightly different memory configuration.
On Tue, Nov 17, 2020 at 4:04 AM Christian Mauderer
wrote:
Hello,
the following patches add a BSP for IMXRT1050-EVKB. In case the import
patch is too big: I
Everything except 5 looks good. I or someone else should take a closer
look at that.
On Tue, Nov 17, 2020 at 4:04 AM Christian Mauderer
wrote:
>
> Hello,
>
> the following patches add a BSP for IMXRT1050-EVKB. In case the import
> patch is too big: I pushed the patches here
1 - 100 of 333 matches
Mail list logo
