Re: [PATCH 0/2 v3] Refactor the aarch64/raspberryp4b BSP
Changes can also be seen on my fork: https://github.com/UtkarshVerma/rtems/tree/refactor On Wed, Aug 9, 2023 at 9:18 AM Utkarsh Verma wrote: > This patch series refactors the BSP and build spec for Raspberry Pi 4B > with the following goals in mind: > > - IWYU(include what you use) includes > - Modularity in BSP and the build spec > - Strict MMU mapping > > This is my first code contribution to RTEMS, therefore suggestions of > any kind would be highly appreciated. > > Regards, > Utkarsh > > Utkarsh Verma (2): > bsps/aarch64/raspberrypi: Refactor the BSP > build: Modularize the aarch64/raspberrypi spec > > bsps/aarch64/raspberrypi/console/console.c| 39 +- > bsps/aarch64/raspberrypi/include/bsp.h| 37 +- > .../aarch64/raspberrypi/include/bsp/bcm2711.h | 96 > bsps/aarch64/raspberrypi/include/bsp/irq.h| 102 ++-- > .../raspberrypi/include/bsp/raspberrypi.h | 471 -- > .../include/bsp/start/bspstartmmu.h | 45 ++ > bsps/aarch64/raspberrypi/include/tm27.h | 5 +- > bsps/aarch64/raspberrypi/start/bspstart.c | 16 +- > .../aarch64/raspberrypi/start/bspstarthooks.c | 26 +- > bsps/aarch64/raspberrypi/start/bspstartmmu.c | 66 +-- > spec/build/bsps/aarch64/raspberrypi/abi.yml | 39 +- > spec/build/bsps/aarch64/raspberrypi/bsp4b.yml | 23 + > .../aarch64/raspberrypi/bspraspberrypi4.yml | 72 --- > spec/build/bsps/aarch64/raspberrypi/grp.yml | 25 + > spec/build/bsps/aarch64/raspberrypi/grp4b.yml | 26 + > .../{linkercmds.yml => linkcmds.yml} | 27 +- > spec/build/bsps/aarch64/raspberrypi/obj.yml | 40 ++ > .../bsps/aarch64/raspberrypi/objcache.yml | 23 + > .../bsps/aarch64/raspberrypi/objclock.yml | 24 + > .../bsps/aarch64/raspberrypi/objconsole.yml | 20 + > .../build/bsps/aarch64/raspberrypi/objirq.yml | 27 + > .../bsps/aarch64/raspberrypi/objstart.yml | 35 ++ > 22 files changed, 553 insertions(+), 731 deletions(-) > create mode 100644 bsps/aarch64/raspberrypi/include/bsp/bcm2711.h > delete mode 100644 bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h > create mode 100644 > bsps/aarch64/raspberrypi/include/bsp/start/bspstartmmu.h > create mode 100644 spec/build/bsps/aarch64/raspberrypi/bsp4b.yml > delete mode 100644 spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml > create mode 100644 spec/build/bsps/aarch64/raspberrypi/grp.yml > create mode 100644 spec/build/bsps/aarch64/raspberrypi/grp4b.yml > rename spec/build/bsps/aarch64/raspberrypi/{linkercmds.yml => > linkcmds.yml} (88%) > create mode 100644 spec/build/bsps/aarch64/raspberrypi/obj.yml > create mode 100644 spec/build/bsps/aarch64/raspberrypi/objcache.yml > create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml > create mode 100644 spec/build/bsps/aarch64/raspberrypi/objconsole.yml > create mode 100644 spec/build/bsps/aarch64/raspberrypi/objirq.yml > create mode 100644 spec/build/bsps/aarch64/raspberrypi/objstart.yml > > -- > 2.41.0 > > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] build: Modularize the aarch64/raspberrypi spec
--- spec/build/bsps/aarch64/raspberrypi/abi.yml | 39 ++ spec/build/bsps/aarch64/raspberrypi/bsp4b.yml | 23 ++ .../aarch64/raspberrypi/bspraspberrypi4.yml | 75 --- spec/build/bsps/aarch64/raspberrypi/grp.yml | 25 +++ spec/build/bsps/aarch64/raspberrypi/grp4b.yml | 26 +++ .../{linkercmds.yml => linkcmds.yml} | 27 --- spec/build/bsps/aarch64/raspberrypi/obj.yml | 40 ++ .../bsps/aarch64/raspberrypi/objcache.yml | 23 ++ .../bsps/aarch64/raspberrypi/objclock.yml | 24 ++ .../bsps/aarch64/raspberrypi/objconsole.yml | 20 + .../build/bsps/aarch64/raspberrypi/objirq.yml | 27 +++ .../bsps/aarch64/raspberrypi/objstart.yml | 35 + 12 files changed, 285 insertions(+), 99 deletions(-) create mode 100644 spec/build/bsps/aarch64/raspberrypi/bsp4b.yml delete mode 100644 spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/grp.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/grp4b.yml rename spec/build/bsps/aarch64/raspberrypi/{linkercmds.yml => linkcmds.yml} (88%) create mode 100644 spec/build/bsps/aarch64/raspberrypi/obj.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objcache.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objconsole.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objirq.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objstart.yml diff --git a/spec/build/bsps/aarch64/raspberrypi/abi.yml b/spec/build/bsps/aarch64/raspberrypi/abi.yml index 38a8d8bc8f..0e365f0146 100644 --- a/spec/build/bsps/aarch64/raspberrypi/abi.yml +++ b/spec/build/bsps/aarch64/raspberrypi/abi.yml @@ -1,19 +1,28 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause -actions: -- get-string: null -- split: null -- env-append: null -build-type: option copyrights: -- Copyright (C) 2022 Mohd Noor Aman -default: -- enabled-by: true - value: - - -mcpu=cortex-a72 - - -march=armv8-a -description: | - ABI flags + - Copyright (C) 2022 Mohd Noor Aman + - Copyright (C) 2023 Utkarsh Verma + +type: build enabled-by: true -links: [] + +build-type: option name: ABI_FLAGS -type: build +description: ABI flags + +actions: + - get-string: null + - split: null + - env-append: null + +default: + - enabled-by: + - aarch64/raspberrypi4b +value: + - -mcpu=cortex-a72 + - -march=armv8-a + - -mstrict-align + +links: + - role: build-dependency +uid: ../../opto2 diff --git a/spec/build/bsps/aarch64/raspberrypi/bsp4b.yml b/spec/build/bsps/aarch64/raspberrypi/bsp4b.yml new file mode 100644 index 00..058f97d1eb --- /dev/null +++ b/spec/build/bsps/aarch64/raspberrypi/bsp4b.yml @@ -0,0 +1,23 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +copyrights: + - Copyright (C) 2022 Mohd Noor Aman + - Copyright (C) 2023 Utkarsh Verma + +type: build +enabled-by: true + +build-type: bsp +arch: aarch64 +bsp: raspberrypi4b +family: raspberrypi +cflags: [] +cppflags: [] +includes: [] +install: [] +source: [] + +links: + - role: build-dependency +uid: grp4b + - role: build-dependency +uid: linkcmds diff --git a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml deleted file mode 100644 index d49e12a7f0..00 --- a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml +++ /dev/null @@ -1,75 +0,0 @@ -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause -arch: aarch64 -bsp: raspberrypi4b -build-type: bsp -cflags: [] -copyrights: -- Copyright (C) 2022 Mohd Noor Aman -cppflags: [] -enabled-by: true -family: raspberrypi -includes: [] -install: -- destination: ${BSP_INCLUDEDIR} - source: - - bsps/aarch64/raspberrypi/include/bsp.h - - bsps/aarch64/raspberrypi/include/tm27.h -- destination: ${BSP_INCLUDEDIR}/bsp - source: - - bsps/aarch64/raspberrypi/include/bsp/irq.h - - bsps/aarch64/raspberrypi/include/bsp/bcm2711.h -- destination: ${BSP_INCLUDEDIR}/bsp/start - source: - - bsps/aarch64/raspberrypi/include/bsp/start/bspstartmmu.h -links: -- role: build-dependency - uid: ../grp -- role: build-dependency - uid: ../start -- role: build-dependency - uid: ../optmmupages -- role: build-dependency - uid: ../optgtusevirt -- role: build-dependency - uid: ../optgtuseps -- role: build-dependency - uid: abi -- role: build-dependency - uid: ../../optcachedata -- role: build-dependency - uid: ../../optcacheinst -- role: build-dependency - uid: ../../opto2 -- role: build-dependency - uid: ../../bspopts -- role: build-dependency - uid: linkercmds -- role: build-dependency - uid: ../../obj -- role: build-dependency - uid: ../../objirq -source: -- bsps/aarch64/raspberrypi/console/console.c -- bsps/aarch64/raspberrypi/start/bspstart.c -- bsps/aarch64/raspberrypi/start/bspstarthooks.c -- bsps/aarch64/raspberrypi/start/bspstartmmu.c -- bsps/aarch
[PATCH 1/2] bsps/aarch64/raspberrypi: Refactor the BSP
This commit restructures the BSP to be more modular and introduces IWYU(include what you use) includes alongwith some formatting changes. build: Update spec for aarch64/raspberrypi --- bsps/aarch64/raspberrypi/console/console.c| 39 +- bsps/aarch64/raspberrypi/include/bsp.h| 37 +- .../aarch64/raspberrypi/include/bsp/bcm2711.h | 96 bsps/aarch64/raspberrypi/include/bsp/irq.h| 102 ++-- .../raspberrypi/include/bsp/raspberrypi.h | 471 -- .../include/bsp/start/bspstartmmu.h | 45 ++ bsps/aarch64/raspberrypi/include/tm27.h | 5 +- bsps/aarch64/raspberrypi/start/bspstart.c | 16 +- .../aarch64/raspberrypi/start/bspstarthooks.c | 26 +- bsps/aarch64/raspberrypi/start/bspstartmmu.c | 66 +-- .../aarch64/raspberrypi/bspraspberrypi4.yml | 5 +- 11 files changed, 272 insertions(+), 636 deletions(-) create mode 100644 bsps/aarch64/raspberrypi/include/bsp/bcm2711.h delete mode 100644 bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h create mode 100644 bsps/aarch64/raspberrypi/include/bsp/start/bspstartmmu.h diff --git a/bsps/aarch64/raspberrypi/console/console.c b/bsps/aarch64/raspberrypi/console/console.c index 73bb0036ff..294fdba022 100644 --- a/bsps/aarch64/raspberrypi/console/console.c +++ b/bsps/aarch64/raspberrypi/console/console.c @@ -3,13 +3,14 @@ /** * @file * - * @ingroup RTEMSBSPsAArch64Raspberrypi4 + * @ingroup RTEMSBSPsAArch64RaspberryPi * * @brief Console Configuration */ /* * Copyright (C) 2022 Mohd Noor Aman + * Copyright (C) 2023 Utkarsh Verma * * * Redistribution and use in source and binary forms, with or without @@ -34,36 +35,32 @@ * POSSIBILITY OF SUCH DAMAGE. */ -#include - -#include -#include #include +#include +#include -#include +#include "bsp.h" -arm_pl011_context raspberrypi_4_context = { - .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"), - .regs = (volatile pl011 *) BSP_RPI4_PL011_BASE, - .initial_baud = 115200 +arm_pl011_context uart0 = { +.base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"), +.regs = (volatile pl011*)BSP_UART0_BASE, +.initial_baud = 115200, }; const console_device console_device_table[] = { - { -.device_file = "/dev/ttyS0", -.probe = console_device_probe_default, -.handler = &arm_pl011_fns, -.context = &raspberrypi_4_context.base - } +{ +.device_file = "/dev/ttyAMA0", +.probe = console_device_probe_default, +.handler = &arm_pl011_fns, +.context = &uart0.base, +}, }; const size_t console_device_count = RTEMS_ARRAY_SIZE(console_device_table); -static void output_char( char c ) -{ - arm_pl011_write_polled(&raspberrypi_4_context.base, c); +static void output_char(char c) { +arm_pl011_write_polled(&uart0.base, c); } -BSP_output_char_function_type BSP_output_char = output_char; - +BSP_output_char_function_type BSP_output_char = output_char; BSP_polling_getchar_function_type BSP_poll_char = NULL; diff --git a/bsps/aarch64/raspberrypi/include/bsp.h b/bsps/aarch64/raspberrypi/include/bsp.h index 4fa81edd40..b4dbb39223 100644 --- a/bsps/aarch64/raspberrypi/include/bsp.h +++ b/bsps/aarch64/raspberrypi/include/bsp.h @@ -3,13 +3,14 @@ /** * @file * - * @ingroup RTEMSBSPsAArch64Raspberrypi4 + * @ingroup RTEMSBSPsAArch64RaspberryPi * - * @brief Core BSP definitions + * @brief Core BSP Definitions */ /* * Copyright (C) 2022 Mohd Noor Aman + * Copyright (C) 2023 Utkarsh Verma * * * Redistribution and use in source and binary forms, with or without @@ -34,8 +35,8 @@ * POSSIBILITY OF SUCH DAMAGE. */ -#ifndef LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H -#define LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H +#ifndef LIBBSP_AARCH64_RASPBERRYPI_BSP_H +#define LIBBSP_AARCH64_RASPBERRYPI_BSP_H /** * @addtogroup RTEMSBSPsAArch64 @@ -48,29 +49,21 @@ #ifndef ASM #include -#include -#include +#if RTEMS_BSP == raspberrypi4b +#include "bsp/bcm2711.h" -/*Raspberry pi MMU initialization */ -BSP_START_TEXT_SECTION void raspberrypi_4_setup_mmu_and_cache(void); +#define BSP_GIC_BASE BCM2711_GIC_BASE +#define BSP_GIC_SIZE BCM2711_GIC_SIZE +#define BSP_ARM_GIC_CPUIF_BASE BCM2711_GIC_CPUIF_BASE +#define BSP_ARM_GIC_DIST_BASE BCM2711_GIC_DIST_BASE -#ifdef __cplusplus -extern "C" { -#endif /* __cplusplus */ - -#define BSP_ARM_GIC_CPUIF_BASE 0xFF842000 -#define BSP_ARM_GIC_DIST_BASE 0xFF841000 - -#define BSP_RPI4_PL011_BASE 0xFE201000 -#define BSP_RPI4_PL011_LENGTH 0x200 - -#ifdef __cplusplus -} -#endif /* __cplusplus */ +#define BSP_UART0_BASE BCM2711_UART0_BASE +#define BSP_UART0_SIZE BCM2711_UART0_SIZE +#endif /* raspberrypi4b */ #endif /* ASM */ /** @} */ -#endif /* LIBBSP_AARCH64_RASPBERRYPI_4_BSP_H */ +#endif /* LIBBSP_AARCH64_RASPBERRYPI_BSP_H */ diff --git a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h new file mode 100644 index 00..5f
[PATCH 0/2 v3] Refactor the aarch64/raspberryp4b BSP
This patch series refactors the BSP and build spec for Raspberry Pi 4B with the following goals in mind: - IWYU(include what you use) includes - Modularity in BSP and the build spec - Strict MMU mapping This is my first code contribution to RTEMS, therefore suggestions of any kind would be highly appreciated. Regards, Utkarsh Utkarsh Verma (2): bsps/aarch64/raspberrypi: Refactor the BSP build: Modularize the aarch64/raspberrypi spec bsps/aarch64/raspberrypi/console/console.c| 39 +- bsps/aarch64/raspberrypi/include/bsp.h| 37 +- .../aarch64/raspberrypi/include/bsp/bcm2711.h | 96 bsps/aarch64/raspberrypi/include/bsp/irq.h| 102 ++-- .../raspberrypi/include/bsp/raspberrypi.h | 471 -- .../include/bsp/start/bspstartmmu.h | 45 ++ bsps/aarch64/raspberrypi/include/tm27.h | 5 +- bsps/aarch64/raspberrypi/start/bspstart.c | 16 +- .../aarch64/raspberrypi/start/bspstarthooks.c | 26 +- bsps/aarch64/raspberrypi/start/bspstartmmu.c | 66 +-- spec/build/bsps/aarch64/raspberrypi/abi.yml | 39 +- spec/build/bsps/aarch64/raspberrypi/bsp4b.yml | 23 + .../aarch64/raspberrypi/bspraspberrypi4.yml | 72 --- spec/build/bsps/aarch64/raspberrypi/grp.yml | 25 + spec/build/bsps/aarch64/raspberrypi/grp4b.yml | 26 + .../{linkercmds.yml => linkcmds.yml} | 27 +- spec/build/bsps/aarch64/raspberrypi/obj.yml | 40 ++ .../bsps/aarch64/raspberrypi/objcache.yml | 23 + .../bsps/aarch64/raspberrypi/objclock.yml | 24 + .../bsps/aarch64/raspberrypi/objconsole.yml | 20 + .../build/bsps/aarch64/raspberrypi/objirq.yml | 27 + .../bsps/aarch64/raspberrypi/objstart.yml | 35 ++ 22 files changed, 553 insertions(+), 731 deletions(-) create mode 100644 bsps/aarch64/raspberrypi/include/bsp/bcm2711.h delete mode 100644 bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h create mode 100644 bsps/aarch64/raspberrypi/include/bsp/start/bspstartmmu.h create mode 100644 spec/build/bsps/aarch64/raspberrypi/bsp4b.yml delete mode 100644 spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/grp.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/grp4b.yml rename spec/build/bsps/aarch64/raspberrypi/{linkercmds.yml => linkcmds.yml} (88%) create mode 100644 spec/build/bsps/aarch64/raspberrypi/obj.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objcache.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objconsole.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objirq.yml create mode 100644 spec/build/bsps/aarch64/raspberrypi/objstart.yml -- 2.41.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 8/8/2023 11:14 pm, Sebastian Huber wrote: > On 08.08.23 08:06, Chris Johns wrote: >> n 7/8/2023 4:06 pm, Sebastian Huber wrote: >>> On 07.08.23 00:25, Chris Johns wrote: On 4/8/2023 4:39 pm, Sebastian Huber wrote: > On 04.08.23 08:22, Chris Johns wrote: >> On 4/8/2023 3:16 pm, Sebastian Huber wrote: >>> On 04.08.23 00:27, Chris Johns wrote: On 2/8/2023 6:49 pm, Chris Johns wrote: > I am concerned about the compatibility to the ecosystem we have. Have you built > all the tests in the testsuite with this value set to something that > is > not > RTEMS default? I think a few things will break because of hard coding > in > them. I have asked for test results and I have not seen any yet the patch has been merged? The change was not approved my me and is still not approved. >>> Sorry I thought it was fine after answering your questions. >> All good, I would like to finish the discusion. 🙂 >> >>> Yes, I have tested this with the rtems7 tools. It was possible to build >>> with >>> the rtems7 tools >>> before, however, the PROGRAM_PREFIX approach is better, since it allows >>> also the >>> build using vendor tools. We had some fixes for this recently: >>> >>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html >>> >>> This is something the user need. >> What if a user adds or uses a prefix that does not conform to the >> standard >> format? I am assuming this is possible to do this, eg Gaisler's special >> prefix? >> >> Possible breakage is >> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457  ? >> >> Do we need to document any constraints around this option? > There will be always problems left to fix. I do not see this as a problem, I see an incomplete change pushed without the review being completed. >>> Sometimes it is not 100% clear when a review is finished. >> Yes it is all a bit fragile and there is lots of guess work. >> > A basic build and the normal tests > work fine with non-standard tools. For the Gaisler tools, you would need: > > PROGRAM_PREFIX = sparc-gaisler-rtems5- > > I guess the rld-cc.cpp will also have issues with a clang build. Yes it would and libdl is a part of RTEMS and breaking it again is something I would like to avoid. I consider the change incomplete because one part says use PROGRAM_PREFIX to change the tools prefix however doing so may break other parts. There is nothing to warn the user PROGRAM_PREFIX may not work as expected. >>> I don't use vendor tool chains, but it seems that some users would like to >>> use >>> them. They were supported by the old build system, so a lacking support in >>> the >>> new build system would be a regression. But if you don't like this change, >>> then >>> we can also revert the patch. >> I think the change is fine and I am not suggesting it is reverted. It is not >> clear to me if more work is needed to complete what this has started because >> I >> do not know where we stand with vendor tools. >> >> I think supporting vendor tools is something we should consider and either >> accept it and sort out what is needed or we clearly state vendors are on >> their >> own. >> >> Supporting vendor tools add something else we need to test and handle but it >> lets vendors own the tools they create and it is clear to us when a user >> raises >> a problem when using them. > > The vendor tools support works now as good or bad as in RTEMS 5. If someone > wants better support, then he/she should work on it. We can't make everything > perfect, there are other things left to do for the RTEMS 6 release. Should we document the extent of what we do support and what is missing? And yes I agree with your comments however users are often not aware of this and we end up fielding support related questions. I also do not think we need to do much to make it work but I am not sure. How do you build gcc with a different tools prefix? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/3] gitignore: Ignore clangd and clang-format files
You're correct. I'll remove this commit. Regards, Utkarsh On Tue, Aug 8, 2023 at 11:39 AM Chris Johns wrote: > On 8/8/2023 4:07 pm, Chris Johns wrote: > > On 8/8/2023 1:05 pm, Utkarsh Verma wrote: > >> --- > >> .gitignore | 4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/.gitignore b/.gitignore > >> index 8b28b186e1..d0144f6737 100644 > >> --- a/.gitignore > >> +++ b/.gitignore > >> @@ -12,3 +12,7 @@ Makefile.in > >> /testsuites/build/build > >> /testsuites/build/wscript > >> .waf* > >> +.clangd > >> +.clang-format > >> +compile_commands.json > >> +.cache/ > > > > What are these from? > > > > Why add them to your $HOME/.gitignore? > > Sorry ... that should be > > Why not add them to your $HOME/.gitignore? > > Chris > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 08.08.23 08:06, Chris Johns wrote: n 7/8/2023 4:06 pm, Sebastian Huber wrote: On 07.08.23 00:25, Chris Johns wrote: On 4/8/2023 4:39 pm, Sebastian Huber wrote: On 04.08.23 08:22, Chris Johns wrote: On 4/8/2023 3:16 pm, Sebastian Huber wrote: On 04.08.23 00:27, Chris Johns wrote: On 2/8/2023 6:49 pm, Chris Johns wrote:    > I am concerned about the compatibility to the ecosystem we have. Have you built all the tests in the testsuite with this value set to something that is not RTEMS default? I think a few things will break because of hard coding in them. I have asked for test results and I have not seen any yet the patch has been merged? The change was not approved my me and is still not approved. Sorry I thought it was fine after answering your questions. All good, I would like to finish the discusion. 🙂 Yes, I have tested this with the rtems7 tools. It was possible to build with the rtems7 tools before, however, the PROGRAM_PREFIX approach is better, since it allows also the build using vendor tools. We had some fixes for this recently: https://lists.rtems.org/pipermail/devel/2023-May/075321.html This is something the user need. What if a user adds or uses a prefix that does not conform to the standard format? I am assuming this is possible to do this, eg Gaisler's special prefix? Possible breakage is https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457  ? Do we need to document any constraints around this option? There will be always problems left to fix. I do not see this as a problem, I see an incomplete change pushed without the review being completed. Sometimes it is not 100% clear when a review is finished. Yes it is all a bit fragile and there is lots of guess work. A basic build and the normal tests work fine with non-standard tools. For the Gaisler tools, you would need: PROGRAM_PREFIX = sparc-gaisler-rtems5- I guess the rld-cc.cpp will also have issues with a clang build. Yes it would and libdl is a part of RTEMS and breaking it again is something I would like to avoid. I consider the change incomplete because one part says use PROGRAM_PREFIX to change the tools prefix however doing so may break other parts. There is nothing to warn the user PROGRAM_PREFIX may not work as expected. I don't use vendor tool chains, but it seems that some users would like to use them. They were supported by the old build system, so a lacking support in the new build system would be a regression. But if you don't like this change, then we can also revert the patch. I think the change is fine and I am not suggesting it is reverted. It is not clear to me if more work is needed to complete what this has started because I do not know where we stand with vendor tools. I think supporting vendor tools is something we should consider and either accept it and sort out what is needed or we clearly state vendors are on their own. Supporting vendor tools add something else we need to test and handle but it lets vendors own the tools they create and it is clear to us when a user raises a problem when using them. The vendor tools support works now as good or bad as in RTEMS 5. If someone wants better support, then he/she should work on it. We can't make everything perfect, there are other things left to do for the RTEMS 6 release. -- 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