date:20210907

Re: [PATCH 6/7] score: Always validate ticks in _TOD_Validate()

2021-09-07 Thread Chris Johns

On 7/9/21 3:34 pm, Sebastian Huber wrote:
> On 07/09/2021 05:11, Chris Johns wrote:
>> On 6/9/21 6:11 pm, Sebastian Huber wrote:
>>> On 06/09/2021 09:55, Chris Johns wrote:
 On 6/9/21 3:49 pm, Sebastian Huber wrote:
> On 04/09/2021 06:20, Joel Sherrill wrote:
>>    > -    sc = _TOD_Validate(&temp_tod, TOD_ENABLE_TICKS_VALIDATION);
>>    > +    sc = _TOD_Validate(&temp_tod);
>>
>>   This has leaked out of the internal implementation interface. 
>> Should
>> it?
>>
>>   I prefer this does not happen and BSPs use an API.
>>
>>
>> I noticed this also. It needs an API.
> There is no RTEMS API to support writing realtime clock drivers currently.
 Where did the RTC API connection comes from? I was only thinking of a call 
 in
 `rtems/clock.h` to validate time. I would not expect an RTC API to result 
 in
 the
 validate call being moved from where it is.
>>>
>>> This is not the only _TOD_* stuff used by RTC drivers.
>>
>> A check shows there are 2 calls used and the bfin bsp can be ignored. Maybe 
>> I am
>> missing something here. Am I?
> 
> Yes, you missed the other uses of _TOD_* stuff:
> 
> bsps/arm/lpc32xx/rtc/rtc-config.c:  lpc32xx_rtc_set(_TOD_To_seconds(tod));
> bsps/shared/dev/rtc/ds1375.c:  secs = _TOD_To_seconds( time );
> bsps/shared/dev/rtc/ds1375.c:  secs = _TOD_To_seconds( &rtod );
> bsps/shared/dev/rtc/rtc-support.c:  rtems_time = _TOD_To_seconds( &rtems_tod 
> );
> bsps/shared/dev/rtc/rtc-support.c:  rtc_time = _TOD_To_seconds( &rtc_tod );
> bsps/bfin/shared/dev/rtc.c: _TOD_Days_to_date[1][tod_temp.month] + 
> tod_temp.day
> - 1;
> bsps/bfin/shared/dev/rtc.c:    if (days <= _TOD_Days_to_date[Leap_year][n+1]) 
> {
> bsps/bfin/shared/dev/rtc.c:  tod_temp.day = days -
> _TOD_Days_to_date[Leap_year][n];
> bsps/bfin/shared/dev/rtc.c:  rtems_time = _TOD_To_seconds( &rtems_tod );
> bsps/bfin/shared/dev/rtc.c:  rtc_time = _TOD_To_seconds( &rtc_tod );
> 

This is what I saw and it not much that needs to be added to the header file.

>>
> I am not that sure if this is really a high priority issue.
 If you mean an RTC API, sure I agree with that. If this is about dipping
 directly into the score, I do not agree, it is always a priority.
>>>
>>> The _TOD_* stuff is probably used for decades in RTC drivers. Adding RTEMS 
>>> API
>>> functions is a bit of work and all core developers are busy. I think it is
>>> unrealistic that someone will have time to work on this topic.
>>
>> I think our goals are not aligned. I am only asking the call be protected by 
>> an
>> API signature placed in rtems/clock.h. Is there a problem with doing this?
>>
>> /**
>>   * @brief Validates the time of day.
>>   *
>>   * @param tod is the reference to the time of day structure to validate or
>>   *   NULL.
>>   *
>>   * @retval RTEMS_SUCCESSFUL @a tod references a valid time of day.
>>   * @retval RTEMS_INVALID_CLOCK @a tod references an invalid time of day.
>>   * @retval RTEMS_INVALID_ADDRESS @a tod reference is @c NULL.
>>   */
>> rtems_status rtems_time_of_day_validate(rtems_time_of_day* tod);
>>
>> And the implementation is:
>>
>> rtems_status rtems_time_of_day_validate(
>>    rtems_time_of_day* tod
>> )
>> {
>>    return _TOD_Validate(tod);
>> }
> 
> The RTEMS API should be documented in the Classic API Guide. There should be
> also separate tests for API functions. API functions should be stable and 
> cover
> important use cases of applications. I am really not sure if a function used
> only by two device drivers should be moved to the API.
> 

static void test_leap_year(void)
{
rtems_status_code test_status;
const rtems_time_of_day *problem = &problem_2100;
const rtems_time_of_day *problem2 = &problem_2100_2;
// 2100 is not a leap year, so it should have 28 days
test_status = rtems_time_of_day_validate(problem);
rtems_test_assert(test_status == RTEMS_SUCCESSFUL);
test_status = rtems_time_of_day_validate(problem2);
rtems_test_assert(test_status == RTEMS_INVALID_CLOCK);
}

?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Does the arm/xilinx-zynqmp BSP work?

2021-09-07 Thread Chris Johns

On 8/9/21 4:43 am, Kinsey Moore wrote:
> This bit of information also applies to the aarch64/xilinx-zynqmp BSP, but
> starting recommendation for that is to use the prebuilt u-boot BOOT.bin which
> includes the ATF bl31 binary and so it isn't critical knowledge for getting
> started.

Thank you for this. I think this is an important piece to add to the 
documentation.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ticket 4503

2021-09-07 Thread zack leung

I was wondering about ticket 4503. I was wondering where The required
functionality should be in the underlying score/ capability used can be
found to write this function. Also how does this relate  to

Add common malloc family extension method malloc_usable_size()
?
Thanks
Zack
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] improve the format error reporting on i386

2021-09-07 Thread zack leung

- thread id is printed as a hex value
- EBP ESP is now printed as a address pointer %p
- Program counter is printed as a pinter
Part of ticket #4203

On Wed, 8 Sept 2021 at 00:17, Zacchaeus Leung 
wrote:

> ---
>  cpukit/score/cpu/i386/cpu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..3c5b7db316 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>  {
>unsigned int faultAddr = 0;
>printk("--\n");
> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRId32 "\n",
> +  printk("Exception %" PRIu32 " caught at PC %p" " by thread 0x%" PRIx32
> "\n",
>  ctx->idtIndex,
>  ctx->eip,
>  _Thread_Executing->Object.id);
> @@ -224,7 +224,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>printk("--\n");
>printk(" EAX = %" PRIx32 "   EBX = %" PRIx32 "   ECX = %" PRIx32 "
>  EDX = %" PRIx32 "\n",
>  ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> -  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %" PRIx32 "
>  ESP = %" PRIx32 "\n",
> +  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %p" "
>  ESP = %p" "\n",
>  ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>printk("--\n");
>printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> "\n",
> @@ -250,7 +250,7 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
> printk("Call Stack Trace of EIP:\n");
> if ( fp ) {
> for ( i=1; fp->up; fp=fp->up, i++ ) {
> -   printk("0x%08" PRIx32 " ",fp->pc);
> +   printk("0x%08"PRIx32 " ",fp->pc);
> if ( ! (i&3) )
> printk("\n");
> }
> --
> 2.33.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] improve the format error reporting on i386

2021-09-07 Thread Zacchaeus Leung

---
 cpukit/score/cpu/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
index 77b7a7161c..3c5b7db316 100644
--- a/cpukit/score/cpu/i386/cpu.c
+++ b/cpukit/score/cpu/i386/cpu.c
@@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const CPU_Exception_frame 
*ctx)
 {
   unsigned int faultAddr = 0;
   printk("--\n");
-  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" PRId32 
"\n",
+  printk("Exception %" PRIu32 " caught at PC %p" " by thread 0x%" PRIx32 "\n",
 ctx->idtIndex,
 ctx->eip,
 _Thread_Executing->Object.id);
@@ -224,7 +224,7 @@ void _CPU_Exception_frame_print (const CPU_Exception_frame 
*ctx)
   printk("--\n");
   printk(" EAX = %" PRIx32 "   EBX = %" PRIx32 "   ECX = %" PRIx32 "   
EDX = %" PRIx32 "\n",
 ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
-  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %" PRIx32 "   
ESP = %" PRIx32 "\n",
+  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %p" " ESP = 
%p" "\n",
 ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
   printk("--\n");
   printk("Error code pushed by processor itself (if not 0) = %" PRIx32 "\n",
@@ -250,7 +250,7 @@ void _CPU_Exception_frame_print (const CPU_Exception_frame 
*ctx)
printk("Call Stack Trace of EIP:\n");
if ( fp ) {
for ( i=1; fp->up; fp=fp->up, i++ ) {
-   printk("0x%08" PRIx32 " ",fp->pc);
+   printk("0x%08"PRIx32 " ",fp->pc);
if ( ! (i&3) )
printk("\n");
}
-- 
2.33.0

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Chris Johns

On 8/9/21 4:08 am, Gedare Bloom wrote:
> Has this issue been raised with newlib? I didn't see anything on their
> ml. The temporary workaround is fine with me.

I would like to understand how temporary this will be.

Chris

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Chris Johns

On 8/9/21 3:27 am, Joel Sherrill wrote:
> On Tue, Sep 7, 2021, 12:18 PM Mr. Andrei Chichak  > wrote:
> 
> Hey Joel,
> 
> I don’t suppose this update will be in the places where the build system
> decides on the instruction set that newlib uses for Cortex-M4
> 
> No. This one is just to patch over a big in some of the aarch64 assembly
> language methods in newlib.>
> I don't know that it does much as a flag except pick the C versions over
> assembly language ones.

This comment has made me check the patch and I have asked in the ticket some
questions. It would good to know the performance difference for IPL64 and then
if IPL32 is going to be fixed before we head down this path.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Does the arm/xilinx-zynqmp BSP work?

2021-09-07 Thread Kinsey Moore

I know of someone who has run this BSP on hardware and I'm not aware of 
any usage with xen (though it could very well be the case). It really 
needs more documentation which is something I guess I should sit down 
and do at some point. The ILP32 AArch64 BSP isn't a direct replacement 
for this BSP since ILP32 is still AArch64 but using the ARMv7 data model 
instead of the full 64-bit data model that AArch64 typically uses.


The secret to using this BSP is to know that JTAG boot mode/application 
loader pokes some bits that the FSBL does not poke by default, so if 
you're going to configure it to boot from media in BOOT.bin instead of 
JTAG then you also need to bundle in the ARM Trusted Firmware (ATF) bl31 
binary.


This bit of information also applies to the aarch64/xilinx-zynqmp BSP, 
but starting recommendation for that is to use the prebuilt u-boot 
BOOT.bin which includes the ATF bl31 binary and so it isn't critical 
knowledge for getting started.



Kinsey

On 9/7/2021 13:19, Gedare Bloom wrote:

Hi Chris,

What I understand about the arm/xilinx-zynqmp BSP is that it was made
to run RTEMS paravirtualized under Xen. It drops into aarch32 mode. It
probably can be replaced by the aarch64 version using the ilp32 once
that is stable, and someone can confirm the PV use case works.

Gedare

On Fri, Sep 3, 2021 at 9:51 PM Chris Johns  wrote:

Hi,

I am testing the console driver with the aarch64/xilinx_zynqmp_lp64_zu3eg BSP
when I saw the BSP.

Is this BSP still valid?

Does this BSP work on real hardware?

Who is looking after this BSP?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH RSB v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Ryan Long

Kinsey got the fix merged upstream from newlib, so now we just have to wait 
till newlib pulls those changes.

-Original Message-
From: Gedare Bloom  
Sent: Tuesday, September 7, 2021 1:09 PM
To: Ryan Long 
Cc: devel@rtems.org
Subject: Re: [PATCH RSB v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

Has this issue been raised with newlib? I didn't see anything on their ml. The 
temporary workaround is fine with me.

On Fri, Sep 3, 2021 at 11:17 AM Ryan Long  wrote:
>
> Adds patch to add the -DPREFER_SIZE_OVER_SPEED flag to AArch64 tools 
> builds with newlib. This forces the generation of AArch64 assembly 
> from C sources instead of using the hand-optimized code in newlib 
> since it does not support ILP32. This can be removed when it is fixed 
> upstream.
>
> Updates #4510
> ---
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> index 4939ca5..c17895b 100644
> --- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> @@ -12,6 +12,9 @@
>  %define newlib_expand_name 
> sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.
> gz/%{newlib_version}  %hash sha512 newlib-%{newlib_version}.tar.gz 
> 9ded46b3077508ef05bbb4bf424777a0baa5aab9c7c0c902fb5529bb73b5b5034c3528
> 2e2dbf270cbcd44d84940a20ee270e329db4e4b501046978c18f78a11c
> +%
> +%patch add newlib -p1 
> +https://devel.rtems.org/raw-attachment/ticket/4510/0001-configure.hos
> +t-Add-DPREFER_SIZE_OVER_SPEED.patch
> +%hash sha512 0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch 
> +rRg7bJoWjR11FQXmSHPxF8EfsFmBnTQcXXFWGZhbKFwyTvJ8EXfGMACI33u+OuvX+gNAN
> +MOJLyv27FcyTJseKg==
>
>  %define with_threads 1
>  %define with_plugin 0
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Does the arm/xilinx-zynqmp BSP work?

2021-09-07 Thread Gedare Bloom

Hi Chris,

What I understand about the arm/xilinx-zynqmp BSP is that it was made
to run RTEMS paravirtualized under Xen. It drops into aarch32 mode. It
probably can be replaced by the aarch64 version using the ilp32 once
that is stable, and someone can confirm the PV use case works.

Gedare

On Fri, Sep 3, 2021 at 9:51 PM Chris Johns  wrote:
>
> Hi,
>
> I am testing the console driver with the aarch64/xilinx_zynqmp_lp64_zu3eg BSP
> when I saw the BSP.
>
> Is this BSP still valid?
>
> Does this BSP work on real hardware?
>
> Who is looking after this BSP?
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Gedare Bloom

Has this issue been raised with newlib? I didn't see anything on their
ml. The temporary workaround is fine with me.

On Fri, Sep 3, 2021 at 11:17 AM Ryan Long  wrote:
>
> Adds patch to add the -DPREFER_SIZE_OVER_SPEED flag to AArch64 tools
> builds with newlib. This forces the generation of AArch64 assembly from
> C sources instead of using the hand-optimized code in newlib since it
> does not support ILP32. This can be removed when it is fixed upstream.
>
> Updates #4510
> ---
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> index 4939ca5..c17895b 100644
> --- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> @@ -12,6 +12,9 @@
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz 
> 9ded46b3077508ef05bbb4bf424777a0baa5aab9c7c0c902fb5529bb73b5b5034c35282e2dbf270cbcd44d84940a20ee270e329db4e4b501046978c18f78a11c
> +%
> +%patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch
> +%hash sha512 0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch 
> rRg7bJoWjR11FQXmSHPxF8EfsFmBnTQcXXFWGZhbKFwyTvJ8EXfGMACI33u+OuvX+gNANMOJLyv27FcyTJseKg==
>
>  %define with_threads 1
>  %define with_plugin 0
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Joel Sherrill

On Tue, Sep 7, 2021, 12:18 PM Mr. Andrei Chichak  wrote:

> Hey Joel,
>
> I don’t suppose this update will be in the places where the build system
> decides on the instruction set that newlib uses for Cortex-M4
>

No. This one is just to patch over a big in some of the aarch64 assembly
language methods in newlib.

I don't know that it does much as a flag except pick the C versions over
assembly language ones.

You'd be better off trying to change the target gcc flags to -Os. I think
Ryan knows how to do that. Chris can answer that also

It is a shame that AFAIK every multilib gets the same optimisation flags
and macros  some of the smaller parts would be better off defaulting to
size over speed.

--joel

>
> A
>
> > On 2021-September-07, at 08:56, Joel Sherrill  wrote:
> >
> > On Tue, Sep 7, 2021 at 8:04 AM Ryan Long  wrote:
> >>
> >> Alright, I’ll have that in the next version.
> >
> > I have a patch ready for this and already posted. Just ran out of disk
> space
> > testing it on all architectures on CentOS.
> >
> > When that build finishes, unless someone complains, I will push it.
> >
> > --joel
> >
> >
> >>
> >>
> >> From: Joel Sherrill 
> >> Sent: Saturday, September 4, 2021 3:31 PM
> >> To: Chris Johns 
> >> Cc: Ryan Long ; rtems-de...@rtems.org <
> devel@rtems.org>
> >> Subject: Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Sep 3, 2021, 9:05 PM Chris Johns  wrote:
> >>
> >> Can we please join onto this an rtems-tools update so the recent fixes
> I pushed
> >> can be picked up?
> >>
> >>
> >>
> >> Ryan can you make that a second patch in this series?
> >>
> >>
> >>
> >> --joel
> >>
> >>
> >> Thanks
> >> Chris
> >>
> >> On 4/9/21 2:40 am, Joel Sherrill wrote:
> >>> You also should add the patch in the gcc-head-newlib-head
> >>> configuration as well for rtems7 tools.
> >>>
> >>> --joel
> >>>
> >>> On Fri, Sep 3, 2021 at 11:01 AM Joel Sherrill  wrote:
> 
>  On Fri, Sep 3, 2021 at 9:27 AM Ryan Long 
> wrote:
> >
> > Adds patch to add the -DPREFER_SIZE_OVER_SPEED flag to aarch64 tool
> > builds with newlib.
> 
>  This doesn't explain why. This patch is needed to prevent the use of
>  the assembly
>  versions of some methods in newlib which are incorrect for ilp32. This
>  can be removed
>  when those methods are updated from ARM. Newlib is quite behind ARM
> for these
>  methods and that will require work from an ARM Newlib person.
> 
>  Updates #4215,
> 
>  Improve the comment and ensure the ticket is clear that this is
> temporary for
>  those reasons.
> 
> > ---
> > rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > index 69c4fb5..3594d1c 100644
> > --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > @@ -13,6 +13,9 @@
> > %patch add gcc -p1
> https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
> > %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch
> afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
> >
> > +%patch add newlib -p1
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch
> > +%hash sha512 0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch
> ad183b6c9a168d1d751505e64873f117c11fb059819d341c5d715619985b285c324ef27c1177c6300088df7bbe3aebd7fa034034c3892f2bf6ec57324c9b1e2a
> > +
> 
>  Looks like you forgot to use sha512-base64
> 
> 
> > %define newlib_version 4f81149
> > %define newlib_external 1
> > %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >>>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Mr. Andrei Chichak

Hey Joel,

I don’t suppose this update will be in the places where the build system 
decides on the instruction set that newlib uses for Cortex-M4

A

> On 2021-September-07, at 08:56, Joel Sherrill  wrote:
> 
> On Tue, Sep 7, 2021 at 8:04 AM Ryan Long  wrote:
>> 
>> Alright, I’ll have that in the next version.
> 
> I have a patch ready for this and already posted. Just ran out of disk space
> testing it on all architectures on CentOS.
> 
> When that build finishes, unless someone complains, I will push it.
> 
> --joel
> 
> 
>> 
>> 
>> From: Joel Sherrill 
>> Sent: Saturday, September 4, 2021 3:31 PM
>> To: Chris Johns 
>> Cc: Ryan Long ; rtems-de...@rtems.org 
>> 
>> Subject: Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch
>> 
>> 
>> 
>> 
>> 
>> On Fri, Sep 3, 2021, 9:05 PM Chris Johns  wrote:
>> 
>> Can we please join onto this an rtems-tools update so the recent fixes I 
>> pushed
>> can be picked up?
>> 
>> 
>> 
>> Ryan can you make that a second patch in this series?
>> 
>> 
>> 
>> --joel
>> 
>> 
>> Thanks
>> Chris
>> 
>> On 4/9/21 2:40 am, Joel Sherrill wrote:
>>> You also should add the patch in the gcc-head-newlib-head
>>> configuration as well for rtems7 tools.
>>> 
>>> --joel
>>> 
>>> On Fri, Sep 3, 2021 at 11:01 AM Joel Sherrill  wrote:
 
 On Fri, Sep 3, 2021 at 9:27 AM Ryan Long  wrote:
> 
> Adds patch to add the -DPREFER_SIZE_OVER_SPEED flag to aarch64 tool
> builds with newlib.
 
 This doesn't explain why. This patch is needed to prevent the use of
 the assembly
 versions of some methods in newlib which are incorrect for ilp32. This
 can be removed
 when those methods are updated from ARM. Newlib is quite behind ARM for 
 these
 methods and that will require work from an ARM Newlib person.
 
 Updates #4215,
 
 Improve the comment and ensure the ticket is clear that this is temporary 
 for
 those reasons.
 
> ---
> rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index 69c4fb5..3594d1c 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -13,6 +13,9 @@
> %patch add gcc -p1 
> https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
> %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch 
> afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
> 
> +%patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch
> +%hash sha512 0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch 
> ad183b6c9a168d1d751505e64873f117c11fb059819d341c5d715619985b285c324ef27c1177c6300088df7bbe3aebd7fa034034c3892f2bf6ec57324c9b1e2a
> +
 
 Looks like you forgot to use sha512-base64
 
 
> %define newlib_version 4f81149
> %define newlib_external 1
> %define newlib_expand_name 
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> --
> 1.8.3.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Joel Sherrill

On Tue, Sep 7, 2021 at 8:04 AM Ryan Long  wrote:
>
> Alright, I’ll have that in the next version.

I have a patch ready for this and already posted. Just ran out of disk space
testing it on all architectures on CentOS.

When that build finishes, unless someone complains, I will push it.

--joel


>
>
> From: Joel Sherrill 
> Sent: Saturday, September 4, 2021 3:31 PM
> To: Chris Johns 
> Cc: Ryan Long ; rtems-de...@rtems.org 
> Subject: Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch
>
>
>
>
>
> On Fri, Sep 3, 2021, 9:05 PM Chris Johns  wrote:
>
> Can we please join onto this an rtems-tools update so the recent fixes I 
> pushed
> can be picked up?
>
>
>
> Ryan can you make that a second patch in this series?
>
>
>
> --joel
>
>
> Thanks
> Chris
>
> On 4/9/21 2:40 am, Joel Sherrill wrote:
> > You also should add the patch in the gcc-head-newlib-head
> > configuration as well for rtems7 tools.
> >
> > --joel
> >
> > On Fri, Sep 3, 2021 at 11:01 AM Joel Sherrill  wrote:
> >>
> >> On Fri, Sep 3, 2021 at 9:27 AM Ryan Long  wrote:
> >>>
> >>> Adds patch to add the -DPREFER_SIZE_OVER_SPEED flag to aarch64 tool
> >>> builds with newlib.
> >>
> >> This doesn't explain why. This patch is needed to prevent the use of
> >> the assembly
> >> versions of some methods in newlib which are incorrect for ilp32. This
> >> can be removed
> >> when those methods are updated from ARM. Newlib is quite behind ARM for 
> >> these
> >> methods and that will require work from an ARM Newlib person.
> >>
> >> Updates #4215,
> >>
> >> Improve the comment and ensure the ticket is clear that this is temporary 
> >> for
> >> those reasons.
> >>
> >>> ---
> >>>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 3 +++
> >>>  1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> >>> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> >>> index 69c4fb5..3594d1c 100644
> >>> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> >>> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> >>> @@ -13,6 +13,9 @@
> >>>  %patch add gcc -p1 
> >>> https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
> >>>  %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch 
> >>> afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
> >>>
> >>> +%patch add newlib -p1 
> >>> https://devel.rtems.org/raw-attachment/ticket/4510/0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch
> >>> +%hash sha512 0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch 
> >>> ad183b6c9a168d1d751505e64873f117c11fb059819d341c5d715619985b285c324ef27c1177c6300088df7bbe3aebd7fa034034c3892f2bf6ec57324c9b1e2a
> >>> +
> >>
> >> Looks like you forgot to use sha512-base64
> >>
> >>
> >>>  %define newlib_version 4f81149
> >>>  %define newlib_external 1
> >>>  %define newlib_expand_name 
> >>> sourceware-mirror-newlib-cygwin-%{newlib_version}
> >>> --
> >>> 1.8.3.1
> >>>
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Ryan Long

Alright, I’ll have that in the next version.

From: Joel Sherrill 
Sent: Saturday, September 4, 2021 3:31 PM
To: Chris Johns 
Cc: Ryan Long ; rtems-de...@rtems.org 
Subject: Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch


On Fri, Sep 3, 2021, 9:05 PM Chris Johns 
mailto:chr...@rtems.org>> wrote:
Can we please join onto this an rtems-tools update so the recent fixes I pushed
can be picked up?

Ryan can you make that a second patch in this series?

--joel

Thanks
Chris

On 4/9/21 2:40 am, Joel Sherrill wrote:
> You also should add the patch in the gcc-head-newlib-head
> configuration as well for rtems7 tools.
>
> --joel
>
> On Fri, Sep 3, 2021 at 11:01 AM Joel Sherrill 
> mailto:j...@rtems.org>> wrote:
>>
>> On Fri, Sep 3, 2021 at 9:27 AM Ryan Long 
>> mailto:ryan.l...@oarcorp.com>> wrote:
>>>
>>> Adds patch to add the -DPREFER_SIZE_OVER_SPEED flag to aarch64 tool
>>> builds with newlib.
>>
>> This doesn't explain why. This patch is needed to prevent the use of
>> the assembly
>> versions of some methods in newlib which are incorrect for ilp32. This
>> can be removed
>> when those methods are updated from ARM. Newlib is quite behind ARM for these
>> methods and that will require work from an ARM Newlib person.
>>
>> Updates #4215,
>>
>> Improve the comment and ensure the ticket is clear that this is temporary for
>> those reasons.
>>
>>> ---
>>>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
>>> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
>>> index 69c4fb5..3594d1c 100644
>>> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
>>> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
>>> @@ -13,6 +13,9 @@
>>>  %patch add gcc -p1 
>>> https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
>>>  %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch 
>>> afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
>>>
>>> +%patch add newlib -p1 
>>> https://devel.rtems.org/raw-attachment/ticket/4510/0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch
>>> +%hash sha512 0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch 
>>> ad183b6c9a168d1d751505e64873f117c11fb059819d341c5d715619985b285c324ef27c1177c6300088df7bbe3aebd7fa034034c3892f2bf6ec57324c9b1e2a
>>> +
>>
>> Looks like you forgot to use sha512-base64
>>
>>
>>>  %define newlib_version 4f81149
>>>  %define newlib_external 1
>>>  %define newlib_expand_name 
>>> sourceware-mirror-newlib-cygwin-%{newlib_version}
>>> --
>>> 1.8.3.1
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 6/7] score: Always validate ticks in _TOD_Validate()

Re: Does the arm/xilinx-zynqmp BSP work?

Ticket 4503

Re: [PATCH] improve the format error reporting on i386

[PATCH] improve the format error reporting on i386

Re: [PATCH RSB v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

Re: Does the arm/xilinx-zynqmp BSP work?

RE: [PATCH RSB v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

Re: Does the arm/xilinx-zynqmp BSP work?

Re: [PATCH RSB v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

Re: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

RE: [PATCH RSB] rtems-gcc-10-newlib-head.cfg: Add newlib patch

15 matches

Site Navigation

Mail list logo

Footer information