Re: Tool versions for RTEMS 6.1 release?

[Chris Johns]

On 3/7/2023 5:35 pm, Sebastian Huber wrote:
> On 03.07.23 01:17, Chris Johns wrote:
>> On 30/6/2023 4:26 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> it seems the RTEMS 6.1 release is getting closer. We should think about the 
>>> tool
>>> versions for the release.
>>>
>>> For GCC, my preferred choice would be GCC 13.2:
>>>
>>> https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html
>>>
>>> In GCC 12 a big change was enabling the vectorization support with -O2. This
>>> should have stabilized in GCC 13. GCC 13 contains some RTEMS-specific
>>> improvements for Ada.
>>>
>>> For Binutils and GDB I would just use the latest release available at the 
>>> RTEMS
>>> 6 branch point.
>>
>> If someone can please raise a ticket when the versions details have been 
>> decided
>> with the versions and assign to me I will update the RSB and test RSB from 
>> git
>> and RSB release builds.
> 
> I added a ticket for this:
> 
> https://devel.rtems.org/ticket/4921

Thanks. I have linked it to https://devel.rtems.org/ticket/4768.

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

Re: GIT Issues?

[Joel Sherrill]

On Mon, Jul 3, 2023 at 11:29 AM Christian Mauderer 
wrote:

> Hello Cedric,
>
> Am 03.07.23 um 08:47 schrieb Cedric Berger:
> > Hello,
> >
> > Two issues here:
> >
> > 1) When looking at RTEMS on github, it seems everything stopped being
> > updated on March 23.
> >  > 2) Then going to https://www.rtems.org, clicking "Git" yield this
> page:
> >
> >  Trac Error
> >  Page Developer/Git not found
> >
>
> Sounds like a broken link on the homepage. As a workaround, you can
> reach https://git.rtems.org directly.
>

It was trying to guide you to what is now in the Users Guide somewhere
around here (https://docs.rtems.org/branches/master/user/start/sources.html)
but also that old content included some of the git instructions from the
Software
Engineering Guide.

Anyway, I changed it to a direct link to git.rtems.org.

That doesn't resolve the issue of updating github but that's a different
problem.

--joel

>
> Best regards
>
> Christian
>
> > Is there something we can do to help with this situation?
> >
> > Cedric
> >
> >
> > ___
> > 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: GIT Issues?

[Christian Mauderer]

Hello Cedric,

Am 03.07.23 um 08:47 schrieb Cedric Berger:

Hello,

Two issues here:

1) When looking at RTEMS on github, it seems everything stopped being 
updated on March 23.

 > 2) Then going to https://www.rtems.org, clicking "Git" yield this page:

     Trac Error
     Page Developer/Git not found



Sounds like a broken link on the homepage. As a workaround, you can 
reach https://git.rtems.org directly.


Best regards

Christian


Is there something we can do to help with this situation?

Cedric


___
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: Tool versions for RTEMS 6.1 release?

[Sebastian Huber]

On 03.07.23 01:17, Chris Johns wrote:

On 30/6/2023 4:26 pm, Sebastian Huber wrote:

Hello,

it seems the RTEMS 6.1 release is getting closer. We should think about the tool
versions for the release.

For GCC, my preferred choice would be GCC 13.2:

https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html

In GCC 12 a big change was enabling the vectorization support with -O2. This
should have stabilized in GCC 13. GCC 13 contains some RTEMS-specific
improvements for Ada.

For Binutils and GDB I would just use the latest release available at the RTEMS
6 branch point.


If someone can please raise a ticket when the versions details have been decided
with the versions and assign to me I will update the RSB and test RSB from git
and RSB release builds.


I added a ticket for this:

https://devel.rtems.org/ticket/4921


--
embedded brains GmbH
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
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Tool versions for RTEMS 6.1 release?

[Sebastian Huber]

On 30.06.23 22:50, Joel Sherrill wrote:
On Fri, Jun 30, 2023 at 12:20 PM Sam Price > wrote:


How hard are the microblaze patches going to be to apply?


Alex is out today but the Microblaze gcc and binutils are based off 
versions Xilinx has

patches for. Right now, the microblaze is using this.

tools/rtems-xilinx-binutils-2.36
tools/rtems-xilinx-gcc-10-newlib-head

The first question is what's the latest gcc Xilinx has patches for.


It seems that the MicroBlaze support is not that well maintained in the 
upstream projects, for example:


https://support.xilinx.com/s/question/0D54U6lA691SAC/microblaze-gcc-needs-proper-lra-support?language=en_US

I guess the trend is to use RISC-V soft cores instead.

--
embedded brains GmbH
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
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Tool versions for RTEMS 6.1 release?

[Sebastian Huber]

On 30.06.23 18:57, Joel Sherrill wrote:



On Fri, Jun 30, 2023 at 1:26 AM Sebastian Huber 
> wrote:


Hello,

it seems the RTEMS 6.1 release is getting closer. We should think about
the tool versions for the release.

For GCC, my preferred choice would be GCC 13.2:

https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html


In GCC 12 a big change was enabling the vectorization support with -O2.
This should have stabilized in GCC 13. GCC 13 contains some
RTEMS-specific improvements for Ada.


I think I am generally ok with moving to 13.2 since we want to be reasonably
current when the branch happens.

Do you know of any Ada users with Adacore support for GNAT/RTEMS?
I am aware of one case and they are using GCC 11 as a base so we already
have a mismatch. The user builds RSB tools with TLS disabled for 
compatibility.
  I know this isn't a community concern but if we have more Ada users, 
we want to do

right by them.


I have no idea who sponsored the recent RTEMS-specific work of AdaCore. 
I thought it had to do with some of your projects.


--
embedded brains GmbH
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
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Tool versions for RTEMS 6.1 release?

[Sebastian Huber]

On 30.06.23 19:18, Kinsey Moore wrote:
On Fri, Jun 30, 2023 at 11:58 AM Joel Sherrill > wrote:




On Fri, Jun 30, 2023 at 1:26 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:

Hello,

it seems the RTEMS 6.1 release is getting closer. We should
think about
the tool versions for the release.

For GCC, my preferred choice would be GCC 13.2:

https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html


In GCC 12 a big change was enabling the vectorization support
with -O2.
This should have stabilized in GCC 13. GCC 13 contains some
RTEMS-specific improvements for Ada.


I think I am generally ok with moving to 13.2 since we want to be
reasonably
current when the branch happens.

Do you know of any Ada users with Adacore support for GNAT/RTEMS?
I am aware of one case and they are using GCC 11 as a base so we already
have a mismatch. The user builds RSB tools with TLS disabled for
compatibility.
  I know this isn't a community concern but if we have more Ada
users, we want to do
right by them.

I also was asked about using FORTRAN recently.

I'd like to say the same thing about Rust users. :)


For Binutils and GDB I would just use the latest release
available at
the RTEMS 6 branch point.


Be aware that I have recently rolled 6.1 binutils back from 2.40 to 2.39 
due to a regression in the AArch64 toolchain. The latest release is 
still 2.40, so please don't roll that forward until the 2.41 release is 
out and is verified to have the fix.


The Binutils 2.41 release is close:

https://sourceware.org/pipermail/binutils/2023-June/127930.html

Could you please check, that the fixes are included.

--
embedded brains GmbH
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
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS_SYSINIT_ITEM not working sometimes?

[Sebastian Huber]

Hello Karel,

On 01.07.23 00:41, Karel Gardas wrote:


   Hello,

while working on STM32H7 I've noticed that rng is not working well. 
Tracked that down to stm32h7_rng_enable function not being properly 
called as it should be. The function call should be enforced by:


RTEMS_SYSINIT_ITEM(
   stm32h7_rng_enable,
   RTEMS_SYSINIT_DEVICE_DRIVERS,
   RTEMS_SYSINIT_ORDER_LAST_BUT_5
);

but it is not. The problematic code is here: 
https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/start/getentropy-rng.c


So far it looks like linker is GCing whole file.


The linker garbage collection doesn't work on a file granularity. It 
operates with linker input section. This is why we use the 
-ffunction-sections and -fdata-sections GCC options.


The only workaround for 
the issue which I've found so far is to add some "hook" function in the 
file and call that hook from BSP starting code. This way linker is 
enforced to link the file in and then RTEMS_SYSININT_ITEM is correctly 
doing its business.


Do you use a custom linker command file? It is important that the KEEP() 
directive is used for the linker set:


KEEP (*(SORT(.rtemsroset.*)))

You can look at the linker map file to get more information about what 
is going on.


--
embedded brains GmbH
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
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel