On 15/6/2022 2:42 am, Joel Sherrill wrote:
> This is OK. Changed in newlib here:
>
> commit 6226bad0eafe762b811c62d1dc096bc0858b0d1a
> Author: Mike Frysinger mailto:vap...@gentoo.org>>
> Date: Mon Nov 8 22:22:27 2021 -0500
>
> change _COMPILING_NEWLIB to _LIBC
>
> Use the same name
On 14/6/2022 11:44 pm, Gedare Bloom wrote:
> On Mon, Jun 13, 2022 at 7:39 PM wrote:
>>
>> From: Chris Johns
>>
>> ---
>> bsps/include/dev/irq/arm-gicv3.h | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/include/dev/irq/arm-gicv3.h
>> b/bsps/in
On 15/6/2022 2:43 am, Joel Sherrill wrote:
> OK but the commit message could be a bit more enlightening.
What about:
bsp/versal: Make RAM base 64bit to support more than 4G of RAM
> It took me a minute to realize that all this did was change the type
> of the memory length parameter. It actual
Correct the URL in the commit message and push it.
--joel
On Mon, Jun 13, 2022 at 8:57 PM Chris Johns wrote:
> On 14/6/2022 11:24 am, chr...@rtems.org wrote:
> > From: Chris Johns
> >
> > The false trigger is covered in:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104657
>
> This is t
OK but the commit message could be a bit more enlightening.
It took me a minute to realize that all this did was change the type
of the memory length parameter. It actually does not change any
lengths to > 4 GB.
--joel
On Mon, Jun 13, 2022 at 8:39 PM wrote:
> From: Chris Johns
>
> ---
> spec
This is OK. Changed in newlib here:
commit 6226bad0eafe762b811c62d1dc096bc0858b0d1a
Author: Mike Frysinger
Date: Mon Nov 8 22:22:27 2021 -0500
change _COMPILING_NEWLIB to _LIBC
Use the same name as glibc & gnulib to indicate "newlib itself is
being compiled". This also harmonizes
On Mon, Jun 13, 2022, 8:38 PM Chris Johns wrote:
> On 10/6/2022 12:09 am, Joel Sherrill wrote:
> > With Matthew addressing new warnings from GCC 12,
>
> I have posted some warning fixes for the arm and aarch64. They let those
> archs
> build warning free without the testsuite. I hope it helps.
>
Dear all,
I am proposing a new GPIO API for RTEMS. The current API is kind of tailored to
some specific hardware and therefore may require some overhead to make it fit
for others. The one I am proposing is not finished but it is aimed to be simple
and generic. It has some opaque type structures
On Mon, Jun 13, 2022 at 7:39 PM wrote:
>
> From: Chris Johns
>
> ---
> bsps/include/dev/irq/arm-gicv3.h | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/bsps/include/dev/irq/arm-gicv3.h
> b/bsps/include/dev/irq/arm-gicv3.h
> index 0d3ef9a1c1..a79368eb
