mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Bruno Thomsen <bruno.thomsen@gmail.com>
To: Alexander Dahl <ada@thorsis.com>
Cc: Denis OSTERLAND <denis.osterland@diehl.com>,
	ptxdist@pengutronix.de, bth@kamstrup.com
Subject: Re: [ptxdist] [PATCH v3] u-boot: generate environment image
Date: Fri, 22 Nov 2019 14:31:30 +0100	[thread overview]
Message-ID: <CAH+2xPBD++xCdjXjMc2oRYQftXjtPQ=x4UzLg+qB5=xRNB+7vw@mail.gmail.com> (raw)
In-Reply-To: <9844490.fM4Dk9IfLu@ada>

Hi Alexander,

> thanks for your effort. I guess some folks have custom rules for generating
> env images, so do we. It's good to have a common approach for ordinary use
> cases to prevent reinventing the wheel. I have some remarks however, see
> below. ;-)

Thanks for review.

We just realized that around 75% of our rules was custom but not
project specific
in any way. So we might as well upstream them if possible :)

> > +config U_BOOT_ENV_IMAGE_SIZE
> > +     prompt "Environment image size"
> > +     string
> > +     default "0x2000"
> > +     help
> > +       Enter the U-Boot environment size for generation of image.
> > +       Size can be prefixed with 0x for hexadecimal values.
> > +       Must match size defined in target config and "/etc/fw_env.config".
>
> Kconfig knows the type "hex" which you could use here. It would prevent
> invalid user input.

Ok, will fix in next version.

> > +ifdef PTXCONF_U_BOOT_DEFAULT_ENV_IMAGE
> > +     $(U_BOOT_MAKE_ENV) $(U_BOOT_DIR)/scripts/get_default_envs.sh
> > $(U_BOOT_BUILD_DIR) | \ +             $(U_BOOT_BUILD_DIR)/tools/mkenvimage -p 0x0 \
> > +             $(call ptx/ifdef,PTXCONF_U_BOOT_ENV_IMAGE_REDUNDANT,-r,) \
> > +             -s $(PTXCONF_U_BOOT_ENV_IMAGE_SIZE) \
> > +             -o $(U_BOOT_BUILD_DIR)/u-boot-env.img -
>
> This way of calling scripts/get_default_envs.sh is possible since U-Boot
> v2018.03-rc3, it will probably fail with older U-Boot. We allow arbitrary U-
> Boot versions with this package and can not easily test on that. Nevertheless
> I would keep it in, but add a hint in the menu on this requirement. Users with
> older U-Boot can just deactivate it.
>
> With U-Boot v2018.01 this gives:
>
>   File 'env_common.o' not found!
>
> The resulting platform-v7a/images/u-boot-env.img is just the checksum and all
> zeros then.
>
> The script itself exists since U-Boot v2016.11-rc2, but without support for
> separate build dir, and it might be broken somewhere in between. Before
> v2016.11 we would get such an error:
>
>   /bin/bash: /home/adahl/Work/bsp/tt-generic/platform-v7a/build-target/u-
> boot-2016.09.01/scripts/get_default_envs.sh: No such file or directory
>
> The resulting platform-v7a/images/u-boot-env.img is also just the checksum and
> all zeros then.
>
> I'm not sure if we can bail out here or just add something to the help text?
> Maybe add it to the prompt?

I will update help to reflect this limitation using final version as shipping
with release candidates is just bad practice(tm) ;)

Running an old version of U-Boot has many limitation like poor support of new
gcc versions and boards not using Kconfig. So don't enable this option if you
use an ancient U-Boot version. Evolution has to continue.

>
> > +endif
> > +ifdef PTXCONF_U_BOOT_CUSTOM_ENV_IMAGE
> > +     $(U_BOOT_BUILD_DIR)/tools/mkenvimage -p 0x0 \
>
> Why -p 0x0? What's the benefit over stuffing with 0xFF by default?

U-boot run-time will by default pad with 0x00 and mkenvimage pad with
0xFF by default. U-boot does not care what pad is used.
So it was just to mimic what normal U-boot run-time does, but we can use
default.

>
> > +             $(call ptx/ifdef,PTXCONF_U_BOOT_ENV_IMAGE_REDUNDANT,-r,) \
> > +             -s $(PTXCONF_U_BOOT_ENV_IMAGE_SIZE) \
> > +             -o $(U_BOOT_BUILD_DIR)/u-boot-custom-env.img \
> > +             $(PTXDIST_WORKSPACE)/$(PTXCONF_U_BOOT_CUSTOM_ENV_IMAGE_SOURCE)
>
> I'm not sure about that path. I would put my input file to e.g. [workspace]/
> configs/platform-v7a/env_source.config and use of PTXDIST_PLATFORMCONFIGDIR is
> not possible this way. I would have to set
> PTXCONF_U_BOOT_CUSTOM_ENV_IMAGE_SOURCE it like this:
>
>   configs/platform-${PTXCONF_PLATFORM}/my-env-source.config
>
> besides: I had a similar problem with dts files and layers. You can not use
> the macros from the make files in those config variables for automatically
> locating that in lower layers. :-/
>
> Anyways, if I set it to a working path, it works.
>
> You might add a make dependency on the input file however, so the stage gets
> rebuild automatically if the custom env input changes?
>

Okay, rebuild in case of source file changes and move it to platformconfigdir,
so it's stored next to the kernel configuration.

Have not tested the below section with ptxdist layers, but seems to work
in my setup without layers. According to docs[1] it should search from top
layer and down.

ifdef PTXCONF_U_BOOT_CUSTOM_ENV_IMAGE
U_BOOT_CUSTOM_ENV_SRC := $(call ptx/in-platformconfigdir, \
    $(PTXCONF_U_BOOT_CUSTOM_ENV_IMAGE_SOURCE))
$(STATEDIR)/u-boot.compile: $(call remove_quotes, $(U_BOOT_CUSTOM_ENV_SRC))
endif

> > +ifdef PTXCONF_U_BOOT_DEFAULT_ENV_IMAGE
> > +     @install -v -D -m644 $(U_BOOT_BUILD_DIR)/u-boot-env.img \
> > +             $(IMAGEDIR)/u-boot-env.img
> > +endif
> > +ifdef PTXCONF_U_BOOT_CUSTOM_ENV_IMAGE
> > +     @install -v -D -m644 $(U_BOOT_BUILD_DIR)/u-boot-custom-env.img \
> > +             $(IMAGEDIR)/u-boot-custom-env.img
> > +endif
> >
> >  ifdef PTXCONF_U_BOOT_BOOT_SCRIPT
> >       @$(call install_init, u-boot)
>
> Removing those images in clean stage is missing.

Yes, I will add them to cleanup including a missing cleanup of imx dtb image.

/Bruno

[1] https://www.ptxdist.org/doc/dev_manual.html#writing-layer-aware-rules

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2019-11-22 13:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 16:40 Bruno Thomsen
2019-11-20  8:10 ` Alexander Dahl
2019-11-22 13:31   ` Bruno Thomsen [this message]
2019-11-22 14:14     ` Michael Olbrich
2019-11-22 15:49       ` Bruno Thomsen

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='CAH+2xPBD++xCdjXjMc2oRYQftXjtPQ=x4UzLg+qB5=xRNB+7vw@mail.gmail.com' \
    --to=bruno.thomsen@gmail.com \
    --cc=ada@thorsis.com \
    --cc=bth@kamstrup.com \
    --cc=denis.osterland@diehl.com \
    --cc=ptxdist@pengutronix.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