[PATCH 5/6] build: Add mkimage support for powerpc/qoriq

[Chris Johns]

On 4/3/2024 6:35 pm, Sebastian Huber wrote:
> On 04.03.24 08:22, Chris Johns wrote:
>>> diff --git a/spec/build/bsps/powerpc/qoriq/mkimage.yml
>>> b/spec/build/bsps/powerpc/qoriq/mkimage.yml
>>> new file mode 100644
>>> index 0000000000..712fd237b1
>>> --- /dev/null
>>> +++ b/spec/build/bsps/powerpc/qoriq/mkimage.yml
>>> @@ -0,0 +1,39 @@
>>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>> +build-type: mkimage
>>> +content: |
>>> +  #!${PYTHON}
>>> +
>>> +  import gzip
>>> +  import os
>>> +  import shutil
>>> +  import subprocess
>>> +  import sys
>>> +  import tempfile
>>> +
>>> +  with tempfile.TemporaryDirectory() as tmp_dir:
>>> +      bin_path = os.path.join(tmp_dir, "bin")
>>> +      gz_path = os.path.join(tmp_dir, "gz")
>>> +      subprocess.run([
>>> +          "${OBJCOPY}",
>>> +          "-O", "binary", sys.argv[1], bin_path
>>> +      ],
>>> +                     check=True)
>>> +      with open(bin_path, "rb") as f_bin:
>>> +          with gzip.open(gz_path, "wb") as f_gz:
>>> +              shutil.copyfileobj(f_bin, f_gz)
>>> +      subprocess.run([
>>> +          "${U_BOOT_MKIMAGE}",
>>> +          "-A", "ppc", "-O", "linux", "-T", "kernel", "-a", "0x4000", "-e",
>>> +          "0x4000", "-n", "RTEMS", "-d", gz_path, sys.argv[2]
>>> +      ],
>>> +                     check=True)
>> Sorry this patch is a no from me and adding python like this with such limited
>> error checking is something I am not comfortable with.
>>
>> I am OK wih a python module that something robust can import and validate giving
>> the user consistent and meaningful error messages but as I have just said whole
>> programs in spec files like this, sorry thet is no from me.
> 
> Python exceptions usually give a lot of context, but sure you always can improve
> things. 

Lets define and implement what we want from the start. I do not think I am
asking for a major piece of work to be written but this task has some ground
work that needs to be established with an architecture that scales. It is an
important feature we need so I am happy to find a suitable initial starting point.

> If someone doesn't like the error handling in a mkimage script he can
> improve it through patches.
> 
> The script may have to know details of the BSP configuration, so what would be
> your approach to address this?

As a said a loadable module of code that confirms to an API to export the "BSP
configuration" as an option. That module would be wrapped in a generic command
that validates the module and handles the error checking presenting the user
with errors messages that are not language based or implementation specific.

A key point is defining what is exported.

The command line tool can be in rtems-tools and based on the framework there if
that helps. The imported module could contain variables, a class or a series of
calls. For example:

 m.py

 USES_TEMPFILE = True

Then you can:

 import m
 if hasattr(m, 'USES_TEMPFILE') and m.USES_TEMPFILE:
   # get a temp file
   try:
     m.something()
   finally:
     # clean up temp file

The tool can be focused on your use case with a stable command line interface
yet extendible.

> With the script in the build specification item
> you can simply use the variable substitution. I don't think these scripts will
> be super complex, just a sequence of commands.

May be it is simpler if we just say no host code fragments like this in spec
files? I fine and relieved if that is the case. It would forced formalisation of
the exporting of these parameters, something I think we need long term.

Chris