Re: [PATCH 4/6] build: Add support to make bootloader images
On 11.03.24 00:40, Chris Johns wrote: On 7/3/2024 5:27 pm, Sebastian Huber wrote: On 07.03.24 02:09, Chris Johns wrote: On 6/3/2024 8:33 am, Gedare Bloom wrote: If script generation needs to be done, it should be implemented in Python with input from the yml spec item as necessary to fill out a templated script with variables to customize for the BSP, and with appropriate injection of comments etc to allow traceability backward to the original source data and source program that generated the script. We cannot import the YML data in external code without coping it as it all resides in the wscript file. I would prefer seeing the YML python support moved into `spec` as modules with unitests that can be imported. This would allow us to add eco-system tools to support, manage and use the YML data. The module to work with specification items is here: https://github.com/RTEMS/rtems-central/blob/master/rtemsspec/items.py This stuff has tests, code formatting, static analysis, and even a CI script. This does not help rtens.git ans that is the scope of this patch set. Yes, but you talked about "We cannot import the YML data in external code without coping it...". I assumed this referred to the RTEMS Tools. Independent of this, working with the build specification items would be the wrong approach. You need the input of a configured BSP. I do not understand what this means. What is the "input of a configured BSP"? Lets assume you have a BSP which has its RAM origin at A or B depending on the BSP configuration options. If you have a BSP installed configured to use A, then the bootloader image probably needs to be created using A. If it is configured to use B, it needs to use B. -- 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 7/3/2024 5:27 pm, Sebastian Huber wrote: > On 07.03.24 02:09, Chris Johns wrote: >> On 6/3/2024 8:33 am, Gedare Bloom wrote: >>> If script generation needs to be done, it should be implemented in >>> Python with input from the yml spec item as necessary to fill out a >>> templated script with variables to customize for the BSP, and with >>> appropriate injection of comments etc to allow traceability backward >>> to the original source data and source program that generated the >>> script. >> We cannot import the YML data in external code without coping it as it all >> resides in the wscript file. I would prefer seeing the YML python support >> moved >> into `spec` as modules with unitests that can be imported. This would allow >> us >> to add eco-system tools to support, manage and use the YML data. > > The module to work with specification items is here: > > https://github.com/RTEMS/rtems-central/blob/master/rtemsspec/items.py > > This stuff has tests, code formatting, static analysis, and even a CI script. This does not help rtens.git ans that is the scope of this patch set. > Independent of this, working with the build specification items would be the > wrong approach. You need the input of a configured BSP. I do not understand what this means. What is the "input of a configured BSP"? Chris ___ 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 07.03.24 02:09, Chris Johns wrote: On 6/3/2024 8:33 am, Gedare Bloom wrote: If script generation needs to be done, it should be implemented in Python with input from the yml spec item as necessary to fill out a templated script with variables to customize for the BSP, and with appropriate injection of comments etc to allow traceability backward to the original source data and source program that generated the script. We cannot import the YML data in external code without coping it as it all resides in the wscript file. I would prefer seeing the YML python support moved into `spec` as modules with unitests that can be imported. This would allow us to add eco-system tools to support, manage and use the YML data. The module to work with specification items is here: https://github.com/RTEMS/rtems-central/blob/master/rtemsspec/items.py This stuff has tests, code formatting, static analysis, and even a CI script. Independent of this, working with the build specification items would be the wrong approach. You need the input of a configured BSP. -- 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 05.03.24 22:33, Gedare Bloom wrote:
On Mon, Mar 4, 2024 at 12:19 AM Chris Johns wrote:
On 1/3/2024 9:57 pm, Sebastian Huber wrote:
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.
I see it is in a YAML spec file. Sorry that is a no from me. See below.
+1
We should not be in the habit of serializing source code inside a data
file without very good reasons to do so. This feels wrong.
I don't see the issue here. The variable substitution in the build
specification items is not as obscure as with m4.
If script generation needs to be done, it should be implemented in
Python with input from the yml spec item as necessary to fill out a
templated script with variables to customize for the BSP, and with
appropriate injection of comments etc to allow traceability backward
to the original source data and source program that generated the
script.
I think this is exactly the approach of the patch set. The Python script
which fills out the templated script with variables to customize for the
BSP is the wscript. You can of course also put comments into the
generated script. If you use the
if __name__ == "__main__":
approach, you could even provide an executable script and a module.
--
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 6/3/2024 8:33 am, Gedare Bloom wrote: > If script generation needs to be done, it should be implemented in > Python with input from the yml spec item as necessary to fill out a > templated script with variables to customize for the BSP, and with > appropriate injection of comments etc to allow traceability backward > to the original source data and source program that generated the > script. We cannot import the YML data in external code without coping it as it all resides in the wscript file. I would prefer seeing the YML python support moved into `spec` as modules with unitests that can be imported. This would allow us to add eco-system tools to support, manage and use the YML data. Chris ___ 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 Mon, Mar 4, 2024 at 12:19 AM Chris Johns wrote:
>
>
>
> On 1/3/2024 9:57 pm, Sebastian Huber wrote:
> > 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.
>
> I see it is in a YAML spec file. Sorry that is a no from me. See below.
>
+1
We should not be in the habit of serializing source code inside a data
file without very good reasons to do so. This feels wrong.
If script generation needs to be done, it should be implemented in
Python with input from the yml spec item as necessary to fill out a
templated script with variables to customize for the BSP, and with
appropriate injection of comments etc to allow traceability backward
to the original source data and source program that generated the
script.
___
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 1/3/2024 9:57 pm, Sebastian Huber wrote:
> 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.
I see it is in a YAML spec file. Sorry that is a no from me. See below.
I have learnt the hard way from the RSB and others we need to be precise with
these interfaces and it is best we consider and review them before we launch
them.
>>> 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.
Python is good but I am not convinced we should allow all the code (or any code)
to resides in the spec YML file as you have. For example the code you have
posted for this command uses uboot's mkimage command and I am not comfortable we
make a host OS specific dependency that has no configure check (I can see), ie
does this patch set build on an M class MacOS machine without brew or macports
help. [1]
I cautious of host code being included in spec files. It is too easy to sneak in
code we depend that creates untracked dependencies and then who cleans that up?
Reverting a patch like this because we find one later would be counter
productive to everyone.
I am happy if we add a command to the rtems-tool repo that can find and import a
python module installed by a BSP or resident in the build tree but it needs to
be python end to end and not reliant on a subprocess call unless the subprocess
call uses a tool installed by the RSB. The import interface would need to
specified so it can be supported long term.
And the problem with your code is a lack of error handling. We should avoid
python exceptions for user errors. They should be for program errors.
[1] https://git.rtems.org/rtems-tools/tree/misc/tools/mkimage.py
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.
The idea of the project would be investigating which other BSPs need this. An an
example
https://github.com/epics-base/epics-base/blob/7.0/configure/os/CONFIG.Common.RTEMS-mvme2700.
There are other example we need to clean up.
Chris
___
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 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 28/2/2024 6:44 pm, Sebastian Huber wrote:
> On 28.02.24 06:48, Chris Johns wrote:
>> Hi,
>>
>> Is this to allow BSP ready output to be created from the build system?
>
> Yes, this is the goal.
Nice and thanks for looking into this.
>> 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?
> 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.
>> 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.
Should we create a GSoC project to review and support the other BSPs?
Chris
___
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 28.02.24 06:48, Chris Johns wrote:
Hi,
Is this to allow BSP ready output to be created from the build system?
Yes, this is the goal.
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
If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is
set to "false".
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.
Is this output created along side the ELF file?
Yes.
Does this approach handle all BSPs that need this?
The BSP can use Python, so I would say yes.
Will you be converting all BSPs that need this type of support?
I will add support for the BSPs using U-Boot.
Thanks
Chris
On 28/2/2024 2:15 am, Sebastian Huber wrote:
Add a new build item type to provide optional BSP-specific tools to make
bootloader images. The tools are installed as Python scripts in:
${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
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
If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
"false".
Update #4272.
---
spec/build/bsps/bspopts.yml | 2 ++
spec/build/bsps/optpkgmkimage.yml| 19 ++
spec/build/bsps/pkgconfig.yml| 1 +
spec/build/cpukit/cpuopts.yml| 4 +++
spec/build/cpukit/optbootimageext.yml| 17 +
spec/build/cpukit/optbuildbootimages.yml | 16 +
wscript | 45 ++--
7 files changed, 102 insertions(+), 2 deletions(-)
create mode 100644 spec/build/bsps/optpkgmkimage.yml
create mode 100644 spec/build/cpukit/optbootimageext.yml
create mode 100644 spec/build/cpukit/optbuildbootimages.yml
diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml
index 734292f421..74fe6d17f9 100644
--- a/spec/build/bsps/bspopts.yml
+++ b/spec/build/bsps/bspopts.yml
@@ -33,6 +33,8 @@ links:
uid: optldflagsbsp
- role: build-dependency
uid: optmakelegacy
+- role: build-dependency
+ uid: optpkgmkimage
- role: build-dependency
uid: optprintexcpt
- role: build-dependency
diff --git a/spec/build/bsps/optpkgmkimage.yml
b/spec/build/bsps/optpkgmkimage.yml
new file mode 100644
index 00..00d9a0171f
--- /dev/null
+++ b/spec/build/bsps/optpkgmkimage.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- substitute: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by: HAVE_MKIMAGE
+ value: $${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
+- enabled-by: true
+ value: 'false'
+description: ''
+enabled-by: true
+format: '{}'
+links: []
+name: PKGCONFIG_MKIMAGE
+type: build
diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
index afaffbbf0f..e1cdc9a70e 100644
--- a/spec/build/bsps/pkgconfig.yml
+++ b/spec/build/bsps/pkgconfig.yml
@@ -20,6 +20,7 @@ content: |
RTEMS_MAJOR=${__RTEMS_MAJOR__}
RTEMS_MINOR=${__RTEMS_MINOR__}
RTEMS_REVISION=${__RTEMS_REVISION__}
+ RTEMS_MKIMAGE=${PKGCONFIG_MKIMAGE}
Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
Version: ${RTEMS_VERSION}
diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
index 1d28ace552..bdf8fc2f66 100644
--- a/spec/build/cpukit/cpuopts.yml
+++ b/spec/build/cpukit/cpuopts.yml
@@ -75,6 +75,10 @@ links:
uid: optcoverageldflags
- role: build-dependency
uid: optnocoverageldflags
+- role: build-dependency
+ uid: optbootimageext
+- role: build-dependency
+ uid: optbuildbootimages
- role: build-dependency
uid: optversion
target: cpukit/include/rtems/score/cpuopts.h
diff --git a/spec/build/cpukit/optbootimageext.yml
b/spec/build/cpukit/optbootimageext.yml
new file mode 100644
index 00..c9347ffba8
--- /dev/null
+++ b/spec/build/cpukit/optbootimageext.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by: true
+ value: .img
+description: |
+ Defines the file extension of boot images.
+enabled-by: true
+format: '{}'
+links: []
+name: BOOT_IMAGE_EXTENSION
+type: build
diff --git a/spec/build/cpukit/optbuildbootimages.yml
Re: [PATCH 4/6] build: Add support to make bootloader images
Hi,
Is this to allow BSP ready output to be created from the build system?
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?
Is this output created along side the ELF file?
Does this approach handle all BSPs that need this?
Will you be converting all BSPs that need this type of support?
Thanks
Chris
On 28/2/2024 2:15 am, Sebastian Huber wrote:
> Add a new build item type to provide optional BSP-specific tools to make
> bootloader images. The tools are installed as Python scripts in:
>
> ${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
>
> 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
>
> If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
> "false".
>
> Update #4272.
> ---
> spec/build/bsps/bspopts.yml | 2 ++
> spec/build/bsps/optpkgmkimage.yml| 19 ++
> spec/build/bsps/pkgconfig.yml| 1 +
> spec/build/cpukit/cpuopts.yml| 4 +++
> spec/build/cpukit/optbootimageext.yml| 17 +
> spec/build/cpukit/optbuildbootimages.yml | 16 +
> wscript | 45 ++--
> 7 files changed, 102 insertions(+), 2 deletions(-)
> create mode 100644 spec/build/bsps/optpkgmkimage.yml
> create mode 100644 spec/build/cpukit/optbootimageext.yml
> create mode 100644 spec/build/cpukit/optbuildbootimages.yml
>
> diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml
> index 734292f421..74fe6d17f9 100644
> --- a/spec/build/bsps/bspopts.yml
> +++ b/spec/build/bsps/bspopts.yml
> @@ -33,6 +33,8 @@ links:
>uid: optldflagsbsp
> - role: build-dependency
>uid: optmakelegacy
> +- role: build-dependency
> + uid: optpkgmkimage
> - role: build-dependency
>uid: optprintexcpt
> - role: build-dependency
> diff --git a/spec/build/bsps/optpkgmkimage.yml
> b/spec/build/bsps/optpkgmkimage.yml
> new file mode 100644
> index 00..00d9a0171f
> --- /dev/null
> +++ b/spec/build/bsps/optpkgmkimage.yml
> @@ -0,0 +1,19 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-string: null
> +- substitute: null
> +- env-assign: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: HAVE_MKIMAGE
> + value: $${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
> +- enabled-by: true
> + value: 'false'
> +description: ''
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: PKGCONFIG_MKIMAGE
> +type: build
> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> index afaffbbf0f..e1cdc9a70e 100644
> --- a/spec/build/bsps/pkgconfig.yml
> +++ b/spec/build/bsps/pkgconfig.yml
> @@ -20,6 +20,7 @@ content: |
>RTEMS_MAJOR=${__RTEMS_MAJOR__}
>RTEMS_MINOR=${__RTEMS_MINOR__}
>RTEMS_REVISION=${__RTEMS_REVISION__}
> + RTEMS_MKIMAGE=${PKGCONFIG_MKIMAGE}
>
>Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
>Version: ${RTEMS_VERSION}
> diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
> index 1d28ace552..bdf8fc2f66 100644
> --- a/spec/build/cpukit/cpuopts.yml
> +++ b/spec/build/cpukit/cpuopts.yml
> @@ -75,6 +75,10 @@ links:
>uid: optcoverageldflags
> - role: build-dependency
>uid: optnocoverageldflags
> +- role: build-dependency
> + uid: optbootimageext
> +- role: build-dependency
> + uid: optbuildbootimages
> - role: build-dependency
>uid: optversion
> target: cpukit/include/rtems/score/cpuopts.h
> diff --git a/spec/build/cpukit/optbootimageext.yml
> b/spec/build/cpukit/optbootimageext.yml
> new file mode 100644
> index 00..c9347ffba8
> --- /dev/null
> +++ b/spec/build/cpukit/optbootimageext.yml
> @@ -0,0 +1,17 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-string: null
> +- env-assign: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: true
> + value: .img
> +description: |
> + Defines the file extension of boot images.
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: BOOT_IMAGE_EXTENSION
> +type: build
> diff --git a/spec/build/cpukit/optbuildbootimages.yml
> b/spec/build/cpukit/optbuildbootimages.yml
> new file mode 100644
> index 00..12328b006d
> --- /dev/null
> +++ b/spec/build/cpukit/optbuildbootimages.yml
> @@ -0,0 +1,16 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- env-enable: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: true
> + value: false
> +description: |
> + If this option is enabled, then boot images for the test programs are
> built.
> +enabled-by: true
>
Re: [PATCH 4/6] build: Add support to make bootloader images
Hello Sebastian,
On 2/27/24 16:15, Sebastian Huber wrote:
Add a new build item type to provide optional BSP-specific tools to make
bootloader images. The tools are installed as Python scripts in:
${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
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
If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
"false".
Do I see this right? This will create automatically an
${PREFIX}/bin/rtems-mkimage-arm-xilinx-zynq.py
if RTEMS is build for ARM/xilinx-zynq and a mkimage shell command is
found on the host?
Where ${PREFIX} is the RTEMS install path and not necessarily the tools
path (i.e. it may not be in $PATH)?
Is it worth documenting that one can add this feature for further BSP by
creating an appropriate spec/build/bsps///mkimage.yml file?
Update #4272.
---
spec/build/bsps/bspopts.yml | 2 ++
spec/build/bsps/optpkgmkimage.yml| 19 ++
spec/build/bsps/pkgconfig.yml| 1 +
spec/build/cpukit/cpuopts.yml| 4 +++
spec/build/cpukit/optbootimageext.yml| 17 +
spec/build/cpukit/optbuildbootimages.yml | 16 +
wscript | 45 ++--
7 files changed, 102 insertions(+), 2 deletions(-)
create mode 100644 spec/build/bsps/optpkgmkimage.yml
create mode 100644 spec/build/cpukit/optbootimageext.yml
create mode 100644 spec/build/cpukit/optbuildbootimages.yml
diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml
index 734292f421..74fe6d17f9 100644
--- a/spec/build/bsps/bspopts.yml
+++ b/spec/build/bsps/bspopts.yml
@@ -33,6 +33,8 @@ links:
uid: optldflagsbsp
- role: build-dependency
uid: optmakelegacy
+- role: build-dependency
+ uid: optpkgmkimage
- role: build-dependency
uid: optprintexcpt
- role: build-dependency
diff --git a/spec/build/bsps/optpkgmkimage.yml
b/spec/build/bsps/optpkgmkimage.yml
new file mode 100644
index 00..00d9a0171f
--- /dev/null
+++ b/spec/build/bsps/optpkgmkimage.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- substitute: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by: HAVE_MKIMAGE
+ value: $${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
+- enabled-by: true
+ value: 'false'
+description: ''
+enabled-by: true
+format: '{}'
+links: []
+name: PKGCONFIG_MKIMAGE
+type: build
diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
index afaffbbf0f..e1cdc9a70e 100644
--- a/spec/build/bsps/pkgconfig.yml
+++ b/spec/build/bsps/pkgconfig.yml
@@ -20,6 +20,7 @@ content: |
RTEMS_MAJOR=${__RTEMS_MAJOR__}
RTEMS_MINOR=${__RTEMS_MINOR__}
RTEMS_REVISION=${__RTEMS_REVISION__}
+ RTEMS_MKIMAGE=${PKGCONFIG_MKIMAGE}
Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
Version: ${RTEMS_VERSION}
diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
index 1d28ace552..bdf8fc2f66 100644
--- a/spec/build/cpukit/cpuopts.yml
+++ b/spec/build/cpukit/cpuopts.yml
@@ -75,6 +75,10 @@ links:
uid: optcoverageldflags
- role: build-dependency
uid: optnocoverageldflags
+- role: build-dependency
+ uid: optbootimageext
+- role: build-dependency
+ uid: optbuildbootimages
- role: build-dependency
uid: optversion
target: cpukit/include/rtems/score/cpuopts.h
diff --git a/spec/build/cpukit/optbootimageext.yml
b/spec/build/cpukit/optbootimageext.yml
new file mode 100644
index 00..c9347ffba8
--- /dev/null
+++ b/spec/build/cpukit/optbootimageext.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by: true
+ value: .img
+description: |
+ Defines the file extension of boot images.
+enabled-by: true
+format: '{}'
+links: []
+name: BOOT_IMAGE_EXTENSION
+type: build
diff --git a/spec/build/cpukit/optbuildbootimages.yml
b/spec/build/cpukit/optbuildbootimages.yml
new file mode 100644
index 00..12328b006d
--- /dev/null
+++ b/spec/build/cpukit/optbuildbootimages.yml
@@ -0,0 +1,16 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- env-enable: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by: true
+ value: false
+description: |
+ If this option is enabled, then boot images for the test programs are built.
+enabled-by: true
+links: []
+name: BUILD_BOOT_IMAGES
+type: build
diff --git a/wscript b/wscript
index e43ae8ba3e..c6cfad147a 100755
--- a/wscript
+++ b/wscript
@@ -197,6 +197,15 @@ def
