Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY
On 29.07.23 08:30, Chris Johns wrote: I think this is not really related to the new RTEMS_VERSION_VC_KEY/RTEMS_VERSION_CONTROL_KEY option. The purpose of this option is to give users the ability to define their own version control key. I think we are broadly aligned however there are different labels for some the pieces [1]. I have reviewed the existing code and then this change and it seems the default is an empty string a user can altered via a config.ini file. Is this correct? In v2 of the patch, the default is "git" indicating that the version control key should be obtained using Git. Is this per BSP or global? This is per BSP. All the configuration options are per BSP. In your config.ini you can set options for all BSPs via the [DEFAULT] section. For me the sources are the controlled item the calls rtems_version() and rtems_version_control_key() should report and not what a user can configure. We don't control the version control system of the user, so it should be user configurable. Why not just look for a file called VERSION and then a key=value pair that is: RTEMS_VERSION_VC_KEY=foo-bar Why not just use what is normally used by the build system? Supporting the VERSION file needs extra code for only one purpose. I think naming this option RTEMS_VERSION_CONTROL_KEY makes more sense, since the corresponding RTEMS API directive is rtems_version_control_key(). Is VC a well known abbreviation? And document deployment users add this file and then configuration control the released sources and this file? The config.ini are not included in the sources shipped with RTEMS and they can be version controlled by the user. [1] Informational only .. https://git.rtems.org/rtems-tools/tree/rtemstoolkit/version.py#n31 -- 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] Revert "bsps/arm/beagle/dcan: Added DCAN support"
Folks, this patch revert was missing in Gedare's series of reverting CAN-based patches in preparation for RTEMS 6 release. Due to this all beagleboard based BSPs fail to build due to error like: Failures: 1 debug arm/beagleboardorig build: configure: /export/home/rtems/git/rtems/ACTIVE_ZONE/stm32h7-new-\ hal/waf configure --prefix=/tmp/rtems-test.1033228\ --top=/export/home/rtems/git/rtems/ACTIVE_ZONE/stm32h7-new-hal\ --rtems-config=config-arm-beagleboardorig-debug.ini error: export/home/rtems/git/bsps/arm/beagle/dcan/am335x- dcan.c:37:10: fatal error: dev/can/can.h: No such file or directory Thanks, Karel On 7/31/23 20:07, Karel Gardas wrote: This reverts commit 26d50bdfb601b9ef71ec2b30d2d9467c2437f443. --- bsps/arm/beagle/dcan/am335x-dcan.c| 104 - bsps/arm/beagle/dcan/dcan.c | 646 -- bsps/arm/beagle/dcan/hw_cm_per.h | 1407 --- bsps/arm/beagle/dcan/hw_dcan.h| 1289 --- bsps/arm/beagle/include/bsp/am335x_dcan.h | 106 - .../beagle/include/bsp/hw_control_AM335x.h| 7794 - bsps/arm/beagle/include/bsp/soc_AM335x.h | 206 - spec/build/bsps/arm/beagle/obj.yml|2 - 8 files changed, 11554 deletions(-) delete mode 100644 bsps/arm/beagle/dcan/am335x-dcan.c delete mode 100644 bsps/arm/beagle/dcan/dcan.c delete mode 100755 bsps/arm/beagle/dcan/hw_cm_per.h delete mode 100755 bsps/arm/beagle/dcan/hw_dcan.h delete mode 100644 bsps/arm/beagle/include/bsp/am335x_dcan.h delete mode 100755 bsps/arm/beagle/include/bsp/hw_control_AM335x.h delete mode 100755 bsps/arm/beagle/include/bsp/soc_AM335x.h ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY
On 31/7/2023 5:14 pm, Sebastian Huber wrote: > On 29.07.23 08:30, Chris Johns wrote: >>> I think this is not really related to the new >>> RTEMS_VERSION_VC_KEY/RTEMS_VERSION_CONTROL_KEY option. The purpose of this >>> option is to give users the ability to define their own version control key. >> >> I think we are broadly aligned however there are different labels for some >> the >> pieces [1]. I have reviewed the existing code and then this change and it >> seems the default is an empty string a user can altered via a config.ini >> file. >> Is this correct? > > In v2 of the patch, the default is "git" indicating that the version control > key > should be obtained using Git. What version control keys are supported? >> >> Is this per BSP or global? > > This is per BSP. All the configuration options are per BSP. In your config.ini > you can set options for all BSPs via the [DEFAULT] section. Per BSP does not make sense. Having a means for a user to inject anything at build time is confusing to me because it can be different for the same set of sources. >> For me the sources are the controlled item the calls rtems_version() and >> rtems_version_control_key() should report and not what a user can configure. > > We don't control the version control system of the user, so it should be user > configurable. The configuration file controls a build and this setting changes the meaning of the configuration data being built. It does not align. >> Why not just look for a file called VERSION and then a key=value pair that >> is: >> >> RTEMS_VERSION_VC_KEY=foo-bar > > Why not just use what is normally used by the build system? Supporting the > VERSION file needs extra code for only one purpose. Yes releasing RTEMS. At the moment a get clone of a release tag will show a file does not match. In a formal sense that would require a special consideration that would need to be documented and applied. > I think naming this option RTEMS_VERSION_CONTROL_KEY makes more sense, since > the > corresponding RTEMS API directive is rtems_version_control_key(). Is VC a well > known abbreviation? The name in the API is what it is and I am not suggesting it be changed. Maybe it could have been more general to serve a wider purpose than just the VC but it is there now so that time has passed. >> >> And document deployment users add this file and then configuration control >> the >> released sources and this file? > > The config.ini are not included in the sources shipped with RTEMS and they can > be version controlled by the user. That is the central point I am attempting to make. Version data should be the version of the sources shipped and not the build. A build label is different and would clearly state the purpose and if I see a bug report I can ignore it and concentrate on the version data. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
MicroBlaze Dynamic Loader Test Failures
Hi, I am currently working on RTEMS dynamic loader support for MicroBlaze. I got most of the dynamic loader tests working, but for a few of them, I had to modify the test. I believe the failures are because the MicroBlaze RTEMS port uses soft floating point emulation. Tests dl07, dl08, and dl09 fail because the objects being loaded include floating point code that requires an extra routine from GCC, `__extendsfdf2`, that is not included in the base application. According to GCC documentation (https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html), `__extendsfdf2` is used to extend a float to a double. This is needed in test dl07, for example, to print `dl01_bss2[0]` on line 66: printf (DL_NAME ": dl01_bss2: %4zu: %p: %f\n", PAINT_VAR (dl01_bss2[0])); The modification that I made to get this working was to add the following to init.c in each of the three failing tests: #ifdef __microblaze__ extern double __extendsfdf2 (float a); /* This ensures that __extendsfdf2 is included in the compiled output. */ double (*extendsfdf2_fp)(float) = &__extendsfdf2; #endif /* __microblaze__ */ I'm not sure of any way to check whether or not this code should be included other than `#ifdef __microblaze__`. This doesn't seem like a great solution, though. I searched for a predefined macro that would allow this to be generic across different architectures, maybe something indicating software floating point, but I couldn't find anything suitable. Does anyone have a suggestion for a better way to solve this? Thanks, Alex ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: MicroBlaze Dynamic Loader Test Failures
On 1/8/2023 1:46 pm, Alex White wrote: > Hi, > > I am currently working on RTEMS dynamic loader support for MicroBlaze. I got > most of the dynamic loader tests working, but for a few of them, I had to > modify the test. I believe the failures are because the MicroBlaze RTEMS port > uses soft floating point emulation. Tests dl07, dl08, and dl09 fail because > the objects being loaded include floating point code that requires an extra > routine from GCC, `__extendsfdf2`, that is not included in the base > application. > > According to GCC documentation > (https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html), > `__extendsfdf2` is used to extend a float to a double. This is needed in test > dl07, for example, to print `dl01_bss2[0]` on line 66: > > printf (DL_NAME ": dl01_bss2: %4zu: %p: %f\n", PAINT_VAR (dl01_bss2[0])); > > The modification that I made to get this working was to add the following to > init.c in each of the three failing tests: > > #ifdef __microblaze__ > extern double __extendsfdf2 (float a); > /* This ensures that __extendsfdf2 is included in the compiled output. */ > double (*extendsfdf2_fp)(float) = &__extendsfdf2; > #endif /* __microblaze__ */ > > I'm not sure of any way to check whether or not this code should be included > other than `#ifdef __microblaze__`. This doesn't seem like a great solution, > though. I searched for a predefined macro that would allow this to be generic > across different architectures, maybe something indicating software floating > point, but I couldn't find anything suitable. > > Does anyone have a suggestion for a better way to solve this? There is no clean way to solve this. It is the classic embedded dynamic loading trade off normally solved at a system level. A solution that may work is to add `libgcc.a` to the tar file in the test exe then configure a `/etc/ld.conf` (I think that is the file name) to search the archive for symbols. The RTL should resolve the missing symbols on the target at run time and load the needed object files. If this support is made conditional on some sort of soft-float build system conditional it should work for any other targets with the same issue. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
