Add currently best clang-format configuration to repository?
Hello, even though the clang-format support for RTEMS is not yet perfect, I think it would still make sense to already add the clang format file to the RTEMS repository. This helps to get the currently best thing available and for example use it for new code (BSPs). -- 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?
Hello Sebastian, so what is the best way to test GCC 13.2 with RTEMS 6? Is ../source-builder/sb-set-builder --prefix= --with-rtems-gcc=tools/rtems-gcc-13-newlib-head 6/rtems-all canonical way how to build those tools for RTEMS 6? Or is there some trickery involved I do not see yet? Thanks, Karel On 6/30/23 08:26, 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tool versions for RTEMS 6.1 release?
Hello Karel, On 30.06.23 11:40, Karel Gardas wrote: so what is the best way to test GCC 13.2 with RTEMS 6? Is ../source-builder/sb-set-builder --prefix= --with-rtems-gcc=tools/rtems-gcc-13-newlib-head 6/rtems-all canonical way how to build those tools for RTEMS 6? Or is there some trickery involved I do not see yet? yes, this should work. Once GCC 13.2 is release I will add a rtems-gcc-13.2-newlib-head configuration. -- 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: [PATCH] bsps/stm32h7: disable MPU alignment for M4-based BSP variants
On 29.06.23 22:47, Karel Gardas wrote: There is no point in wasting precious memory space on enforced section alignment for the purpose of MPU which is not implemented on M4 core anyway. Thanks, looks good. -- 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?
On Fri, Jun 30, 2023 at 1:26 AM Sebastian Huber < 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. > > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tool versions for RTEMS 6.1 release?
On Fri, Jun 30, 2023 at 11:58 AM Joel Sherrill wrote: > > > On Fri, Jun 30, 2023 at 1:26 AM Sebastian Huber < > 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. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tool versions for RTEMS 6.1 release?
How hard are the microblaze patches going to be to apply? On Fri, Jun 30, 2023 at 1:19 PM 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 < >> 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. > > Kinsey > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Sincerely, Sam Price ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tool versions for RTEMS 6.1 release?
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. --joel > > On Fri, Jun 30, 2023 at 1:19 PM 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 < >>> 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. >> >> Kinsey >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > -- > Sincerely, > > Sam Price > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS_SYSINIT_ITEM not working sometimes?
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 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. I'm using following tool-chain: gcc version 12.2.1 20230224 (RTEMS 6, RSB 7153c2f1dcfb83b154b976298699c26e793a33dd, Newlib 17ac400) (GCC) GNU assembler version 2.40 (arm-rtems6) using BFD version (GNU Binutils) 2.40 GNU ld (GNU Binutils) 2.40 I'm using following configuration of the testing app: #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER #define CONFIGURE_MAXIMUM_TASKS1 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE #define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION #define CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION #define CONFIGURE_INIT #include Since RTEMS_SYSINIT_ITEM & Co. are used quite a lot thorough source code I cannot believe that just H7 BSP is that unlucky to be hit by this issue. Has anybody seeing similar behavior? Or am I doing anything stupid? Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
