[PATCH 4/6] build: Add support to make bootloader images

[Chris Johns]

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