Re: [PATCH 0/2 v3] Refactor the aarch64/raspberryp4b BSP

2023-08-08 Thread Utkarsh Verma
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

2023-08-08 Thread Utkarsh Verma
---
 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

2023-08-08 Thread Utkarsh Verma
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

2023-08-08 Thread Utkarsh Verma
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

2023-08-08 Thread Chris Johns
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

2023-08-08 Thread Utkarsh Verma
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

2023-08-08 Thread Sebastian Huber

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