Re: [PATCH 4/6] build: Add support to make bootloader images
On 29.02.24 00:05, Chris Johns wrote: It could help to export also EXEEXT and BOOT_IMAGE_EXTENSION in the package configuration file. For RTEMS 6, we should have a look how our package configuration support can be used to build applications on some commonly used build systems. We are currently not able to produce build images. Yes we should. I also wonder if base addresses and other values that get used should be prov Ok, this is a separate issue. We could add all the BSP options contained in bspopts.h also to the package config file. What about the CPU options? What about options in BSP-specific configuration files? -- embedded brains GmbH & Co. KG 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 4/6] build: Add support to make bootloader images
On 29.02.24 00:05, Chris Johns wrote:
If it is will the details be exported in the pkgconfig file and made available
for users building applications in a consistent and easy to use way?
Application build systems can query the tool using the RTEMS_MKIMAGE package
configuration varible, for example:
pkg-config --variable=RTEMS_MKIMAGE
${prefix}/lib/pkgconfig/${ARCH}-${BSP_NAME}.pc
Nice. This is my preferred way of handling this.
If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
"false".
So the process has to be a single command?
Yes, a single command which is written in Python. For the U-Boot image
it converts the ELF file to binary, then to a gz file, then to the
U-Boot image.
It could help to export also EXEEXT and BOOT_IMAGE_EXTENSION in the package
configuration file. For RTEMS 6, we should have a look how our package
configuration support can be used to build applications on some commonly used
build systems. We are currently not able to produce build images.
Yes we should. I also wonder if base addresses and other values that get used
should be prov
Is this output created along side the ELF file?
Yes.
+1
Does this approach handle all BSPs that need this?
The BSP can use Python, so I would say yes.
I am sorry I do not follow.
The script is written in Python, so this should be good enough to
generate boot images for all kinds of BSPs.
Will you be converting all BSPs that need this type of support?
I will add support for the BSPs using U-Boot.
Could you please provide the high level view of how this is to be handled? I
have not reviewed all the detail in the patches to understand this and even then
I may get things wrong.
The BSP provides an optional script to convert an ELF file into a boot
image. In a Makefile it could be used like this:
EXEEXT = $(shell pkg-config --variable=EXEEXT $(PKG_CONFIG))
RTEMS_MKIMAGE = $(shell pkg-config --variable=RTEMS_MKIMAGE $(PKG_CONFIG))
ifeq ($(RTEMS_MKIMAGE), false)
APP = $(BUILDDIR)/app$(EXEEXT)
else
BOOT_IMAGE_EXTENSION = $(shell pkg-config
--variable=BOOT_IMAGE_EXTENSION $(PKG_CONFIG))
APP = $(BUILDDIR)/app$(BOOT_IMAGE_EXTENSION)
%$(BOOT_IMAGE_EXTENSION): %$(EXEEXT)
$(RTEMS_MKIMAGE) $^ $@
endif
Should we create a GSoC project to review and support the other BSPs?
I would add the boot image support only if needed. There are probably
more important things to do.
--
embedded brains GmbH & Co. KG
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 2/2] testsuites/dhrystone: Initialize before use
A very similar change was made in 2017 to resolve the same warning for a different variable. The only real difference is that it is wrapped in __rtems__ ifdefs. I can move this change to the #ifdef'd section if that's preferable. Kinsey On Fri, Mar 1, 2024 at 1:02 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 28.02.24 19:15, Kinsey Moore wrote: > > This resovles a warning where a variable could be used before it is > > initialized in some code paths. > > I am not sure if we should modify benchmark code. > > -- > embedded brains GmbH & Co. KG > 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: [PATCH 2/2] testsuites/dhrystone: Initialize before use
On Fri, Mar 1, 2024 at 8:21 AM Kinsey Moore wrote: > A very similar change was made in 2017 to resolve the same warning for a > different variable. The only real difference is that it is wrapped in > __rtems__ ifdefs. I can move this change to the #ifdef'd section if that's > preferable. > Do not rearrange. Just add the __rtems__ conditional. The goal is to fix issues while minimizing differences. --joel > > Kinsey > > On Fri, Mar 1, 2024 at 1:02 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 28.02.24 19:15, Kinsey Moore wrote: >> > This resovles a warning where a variable could be used before it is >> > initialized in some code paths. >> >> I am not sure if we should modify benchmark code. >> >> -- >> embedded brains GmbH & Co. KG >> 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] testsuites/dhrystone: Initialize before use
This resovles a warning where a variable could be used before it is initialized in some code paths. --- testsuites/benchmarks/dhrystone/dhry_1.c | 1 + 1 file changed, 1 insertion(+) diff --git a/testsuites/benchmarks/dhrystone/dhry_1.c b/testsuites/benchmarks/dhrystone/dhry_1.c index 3ad2e7f204..ef6ecf9251 100644 --- a/testsuites/benchmarks/dhrystone/dhry_1.c +++ b/testsuites/benchmarks/dhrystone/dhry_1.c @@ -133,6 +133,7 @@ execution_start: #ifdef __rtems__ /* avoid used uninitialized warning */ + Int_1_Loc = 0; Int_2_Loc = 0; #endif -- 2.39.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] testsuites/dhrystone: Initialize before use
On Fri, Mar 1, 2024 at 8:40 AM Joel Sherrill wrote: > On Fri, Mar 1, 2024 at 8:21 AM Kinsey Moore > wrote: > >> A very similar change was made in 2017 to resolve the same warning for a >> different variable. The only real difference is that it is wrapped in >> __rtems__ ifdefs. I can move this change to the #ifdef'd section if that's >> preferable. >> > > Do not rearrange. Just add the __rtems__ conditional. The goal is to fix > issues while minimizing differences. > I have posted a v2 that hides the change behind a __rtems__ conditional. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
