[RFC PATCH v1 9/9] tools: Add tool to create Renesas SPKG images

Ralph Siemsen ralph.siemsen at linaro.org
Tue Aug 9 19:02:06 CEST 2022


On Tue, Aug 9, 2022 at 12:07 PM Pali Rohár <pali at kernel.org> wrote:
>
> This documentation is not probably up-to-date. List of all kwbimage
> config options can be visible in kwbimage_generate_config() function.

I will check the code as well.

> > 1) mkimage already has far too many options
>
> I know. But for nand there can be just --nand suboption1,suboption2,...
> format. For other non-nand vendor specific option it would be an issue.
> Maybe something like --vendor option or --image-options ... could be
> used?

In my case this would work, as there are only 3 parameters for NAND.
However in general, it could get pretty messy, I see at least ten
different NAND parameters described in the NAND DT binding.

> > 2) covering all possible vendor-specific values/encodings of NAND
> > parameters would be quite a task
>
> Yea, it is problematic. But... is not everything related to NAND just
> common to what can be specified in device tree properties for nand node?
> And de-facto already known and well-defined?

I did have the thought of using device tree. It does have the
advantage that it is a known format with defined parameters.

> Because I cannot imagine what else for what there is not already device
> tree binding, could be required for vendor bootrom. (But maybe I just do
> not see it...)

In quite a few cases, the DT parameters are incomplete, or just hints
(see "nand-ecc-maximize"), that trigger various run-time decisions
about the actual parameters.

Duplicating this logic in mkimage seems difficult, bordering on
impossible if it depends on run-time identification of the flash chip,
for example.

> Just one suggestion: It is a good idea to also implement "verify_header"
> mkimage callback. Build process then use it to verify that generated
> image is really correct.

I'll check it out, thanks!

Ralph


More information about the U-Boot mailing list