From: Lukasz Majewski <lukma@denx.de>
To: Marek Vasut <marex@denx.de>, Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@konsulko.com>,
Stefan Agner <stefan.agner@toradex.com>,
OpenEmbedded Core Mailing List
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
Date: Thu, 3 May 2018 20:15:15 +0200 [thread overview]
Message-ID: <20180503201515.5d205adb@jawa> (raw)
In-Reply-To: <5835447d-e8fb-dd1a-5d13-1561e475758f@denx.de>
[-- Attachment #1: Type: text/plain, Size: 3347 bytes --]
Hi Marek, Stefano,
> On 05/03/2018 06:50 PM, Stefano Babic wrote:
> > On 03/05/2018 18:36, Marek Vasut wrote:
> >> On 05/03/2018 06:28 PM, Stefano Babic wrote:
> >>> On 27/04/2018 17:07, Marek Vasut wrote:
> >>>> On 04/27/2018 04:51 PM, Lukasz Majewski wrote:
> >>>>> This commit provides the ability to generate u-boot
> >>>>> environment(s) as images, which afterwards can be used to
> >>>>> produce image (with wic) for flashing (eMMC or SPI-NOR).
> >>>>>
> >>>>> This change removes the need to run "env default" during
> >>>>> production phase, as proper environment (including redundant
> >>>>> one) is already stored on persistent memory (the CRC is also
> >>>>> correct).
> >>>>>
> >>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> >>>>
> >>>> If your default env is correct, why do you need this ? I can see
> >>>> some use with non-default env, but then that can be wrapped into
> >>>> a separate recipe.
> >>>>
> >>>
> >>> A use case is when the environment must be changed from user
> >>> space. fw_setenv will report the CRC error and it needs the
> >>> default environment to add changes. The default environment is
> >>> linked together to fw_setenv, but this prohibites to use
> >>> fw_setenv for multiple boards and must be explicitely built for
> >>> that machine and with the same sources as u-boot (at least, they
> >>> must share the same CONFIG_EXTRA_ENV). If the default environment
> >>> is extracted, we could have a general (distro ?) fw_setenv.
> >>
> >> I think in that case, the real solution is to either build
> >> fw_setenv per machine
> >
> > This is how we try to do now, fw_setenv is built per machine but it
> > is enough that u-boot-fw-utils is built in a different version as
> > u-boot to get a mess.
>
> Well yes, if you mix and match packages, it becomes a mess. Isn't that
> to be expected ?
>
> >> OR fix fw_setenv to take env defaults from a file or somesuch ?
> >
> > Right, I interprete this patch as a step in this direction. This
> > patch generates a default that can be used as input for fw_setenv.
>
> It generates environment images which can be written -- on certain
> specific setups -- into the flash. It doesn't generate any sort of
> input for the fw_setenv to my knowledge ?
>
I think that it would be great if:
1. We would have this code as a separate recipe - as suggested by Marek
and Stefano already. This recipe would end up as a package to be
installed on the rootfs
2. As input I would use default_envs.txt (or any other name) - either
extracted from u-boot build or provided from external file
3. For now I do use mkenvimage -> and I do have env image [*] to be
flashed on the board.
However, I do wonder if for the default fw_setenv envs we could:
- modify fw_setenv to read (and store) [*] when no correct default env
is available
I must check if fw_setenv handles images generated by mkenvimage (or
boot.src [1] generated by mkimage).
[1] - <u-boot repo>/board/samsung/common/bootscripts/autoboot.cmd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 499 bytes --]
next prev parent reply other threads:[~2018-05-03 18:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 14:51 [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images Lukasz Majewski
2018-04-27 15:07 ` Marek Vasut
2018-04-27 16:15 ` Lukasz Majewski
2018-04-27 17:37 ` Marek Vasut
2018-04-29 13:53 ` Lukasz Majewski
2018-04-29 14:07 ` Marek Vasut
2018-04-30 14:03 ` Otavio Salvador
2018-04-30 17:32 ` Marek Vasut
2018-05-03 16:28 ` Stefano Babic
2018-05-03 16:36 ` Marek Vasut
2018-05-03 16:50 ` Stefano Babic
2018-05-03 16:59 ` Marek Vasut
2018-05-03 18:15 ` Lukasz Majewski [this message]
2018-05-03 19:02 ` Marek Vasut
2018-05-09 11:45 ` Lukasz Majewski
2018-05-09 11:57 ` Marek Vasut
2018-05-03 20:58 ` Stefano Babic
2018-05-03 23:04 ` Marek Vasut
2018-04-30 6:50 ` Martin Hundebøll
2018-04-30 8:18 ` Lukasz Majewski
2018-04-30 13:23 ` Martin Jansa
2018-04-30 13:26 ` Martin Jansa
2018-04-30 14:22 ` Lukasz Majewski
2018-05-03 16:24 ` Stefano Babic
2018-05-03 18:17 ` Lukasz Majewski
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=20180503201515.5d205adb@jawa \
--to=lukma@denx.de \
--cc=marex@denx.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=sbabic@denx.de \
--cc=stefan.agner@toradex.com \
--cc=trini@konsulko.com \
/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