public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Ralph Siemsen <ralph.siemsen@linaro.org>
Cc: u-boot@lists.denx.de,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Andre Przywara <andre.przywara@arm.com>,
	Heiko Thiery <heiko.thiery@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Simon Glass <sjg@chromium.org>, Stefan Roese <sr@denx.de>
Subject: Re: [RFC PATCH v1 9/9] tools: Add tool to create Renesas SPKG images
Date: Tue, 9 Aug 2022 18:06:59 +0200	[thread overview]
Message-ID: <20220809160659.a4t4hyvbhj2f52o7@pali> (raw)
In-Reply-To: <CANp-EDayFk851-=RKYxXKcfBwvgn6ApoWt3QZg20UwF4bAktbQ@mail.gmail.com>

Hello!

On Tuesday 09 August 2022 11:54:30 Ralph Siemsen wrote:
> Hi Pali,
> 
> On Tuesday 09 August 2022 15:03:48 Pali Rohár wrote:
> >
> > Hello! You can use for example config file, like it has kwbimage.c which
> > is integrated into mkimage and has support for NAND ECC settings.
> 
> Thank you, I was unaware of this config file approach. From a quick
> look at doc/README.kwbimage it seems quite reasonable for
> device-specific parameters.

This documentation is not probably up-to-date. List of all kwbimage
config options can be visible in kwbimage_generate_config() function.

> On Tue, Aug 9, 2022 at 9:07 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > Or another option could be to extend mkimage tool to accept new argument
> > for specifying NAND settings. As we can see more image formats have
> > support for it, so some abstraction in mkimage makes sense here.
> 
> In principle I agree. But practically speaking I see two problems:
> 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?

> 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?

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...)

> So I am inclined to keep it simple for now, and try using a config file.
> 
> Ralph

Keep it simple is the best option!

In the worst case, in the future, some of the options introduced by your
config file format, would be possible to specify also via command line
arguments. So I do not see any issue with this config file approach.


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.

  reply	other threads:[~2022-08-09 16:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 12:59 [RFC PATCH v1 0/9] Renesas RZ/N1 SoC initial support Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 1/9] ARM: armv7: add non-SPL enable for Cortex SMPEN Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 2/9] clk: renesas: prepare for non-RCAR clock drivers Ralph Siemsen
2022-08-13  4:37   ` Sean Anderson
2022-08-09 12:59 ` [RFC PATCH v1 3/9] clk: renesas: add R906G032 driver Ralph Siemsen
2022-08-13  5:30   ` Sean Anderson
2022-08-15  2:48     ` Ralph Siemsen
2022-08-23  4:14       ` Sean Anderson
2022-08-26 15:47         ` Ralph Siemsen
2023-02-22 17:39           ` Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 4/9] pinctrl: " Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 5/9] ram: cadence: add driver for Cadence EDAC Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 6/9] dts: basic devicetree for Renesas RZ/N1 SoC Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 7/9] ARM: rzn1: basic support " Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 8/9] board: schneider: add LCES board support Ralph Siemsen
2022-08-09 12:59 ` [RFC PATCH v1 9/9] tools: Add tool to create Renesas SPKG images Ralph Siemsen
2022-08-09 13:03   ` Pali Rohár
2022-08-09 13:07     ` Pali Rohár
2022-08-09 15:54       ` Ralph Siemsen
2022-08-09 16:06         ` Pali Rohár [this message]
2022-08-09 17:02           ` Ralph Siemsen
2022-08-09 17:15         ` Sean Anderson
2022-08-12 17:00           ` Ralph Siemsen
2022-08-12 17:03   ` [RFC PATCH v2 9/9] tools: spkgimage: add Renesas SPKG format Ralph Siemsen
2022-08-13 14:47     ` Sean Anderson
2022-08-14  1:45       ` Ralph Siemsen
2022-08-16 14:33         ` Ralph Siemsen
2022-08-23  3:42           ` Sean Anderson
2022-08-26 15:01             ` Ralph Siemsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220809160659.a4t4hyvbhj2f52o7@pali \
    --to=pali@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=heiko.thiery@gmail.com \
    --cc=ralph.siemsen@linaro.org \
    --cc=samuel@sholland.org \
    --cc=sjg@chromium.org \
    --cc=sr@denx.de \
    --cc=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox