[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