* [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
@ 2018-04-27 14:51 Lukasz Majewski
2018-04-27 15:07 ` Marek Vasut
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Lukasz Majewski @ 2018-04-27 14:51 UTC (permalink / raw)
To: OpenEmbedded Core Mailing List, Marek Vasut; +Cc: Tom Rini, Stefan Agner
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>
---
This patch depends on "u-boot: Upgrade to 2018.03 release"
https://patchwork.openembedded.org/patch/149998/
---
meta/recipes-bsp/u-boot/u-boot.inc | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
index c2bcf99840..2796e503cf 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -305,3 +305,38 @@ do_deploy () {
}
addtask deploy before do_build after do_compile
+
+# Create new rules to extract default envs
+UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
+DEFAULT_ENVS ?= "u-boot-env-default.txt"
+DEFAULT_ENVS_SIZE ?= "65536"
+
+# Generate default environment
+do_gen_default_envs[doc] = "Generate image with default U-Boot environment(s)"
+do_gen_default_envs () {
+ ${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
+
+ # Generate env image
+ ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
+
+ # Generate redundant env image
+ ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
+
+ rm ${B}/${DEFAULT_ENVS}
+}
+
+addtask gen_default_envs before do_deploy_default_envs after do_compile
+
+# Deploy default environment
+do_deploy_default_envs[doc] = "Copy images with default U-Boot environment to deployment directory"
+do_deploy_default_envs () {
+ install -d ${DEPLOYDIR}
+
+ install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
+ install ${B}/${UBOOT_ENVS_DEFAULT}_r ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
+
+ rm ${B}/${UBOOT_ENVS_DEFAULT}
+ rm ${B}/${UBOOT_ENVS_DEFAULT}_r
+}
+
+addtask deploy_default_envs before do_deploy after do_gen_default_envs
--
2.11.0
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
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-05-03 16:28 ` Stefano Babic
2018-04-30 6:50 ` Martin Hundebøll
2018-05-03 16:24 ` Stefano Babic
2 siblings, 2 replies; 25+ messages in thread
From: Marek Vasut @ 2018-04-27 15:07 UTC (permalink / raw)
To: Lukasz Majewski, OpenEmbedded Core Mailing List; +Cc: Tom Rini, Stefan Agner
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.
> ---
> This patch depends on "u-boot: Upgrade to 2018.03 release"
> https://patchwork.openembedded.org/patch/149998/
> ---
> meta/recipes-bsp/u-boot/u-boot.inc | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
> index c2bcf99840..2796e503cf 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -305,3 +305,38 @@ do_deploy () {
> }
>
> addtask deploy before do_build after do_compile
> +
> +# Create new rules to extract default envs
> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> +DEFAULT_ENVS_SIZE ?= "65536"
> +
> +# Generate default environment
> +do_gen_default_envs[doc] = "Generate image with default U-Boot environment(s)"
> +do_gen_default_envs () {
> + ${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
> +
> + # Generate env image
> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
Does this actually work during cross build , when mkenvimage
architecture is different than host architecture ?
> + # Generate redundant env image
> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
Is redundant env always needed on all systems ?
> + rm ${B}/${DEFAULT_ENVS}
> +}
> +
> +addtask gen_default_envs before do_deploy_default_envs after do_compile
> +
> +# Deploy default environment
> +do_deploy_default_envs[doc] = "Copy images with default U-Boot environment to deployment directory"
> +do_deploy_default_envs () {
> + install -d ${DEPLOYDIR}
> +
> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> + install ${B}/${UBOOT_ENVS_DEFAULT}_r ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
Does this work with multiple machines or will it overwrite the deployed
image ?
> + rm ${B}/${UBOOT_ENVS_DEFAULT}
> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> +}
> +
> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
>
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-27 15:07 ` Marek Vasut
@ 2018-04-27 16:15 ` Lukasz Majewski
2018-04-27 17:37 ` Marek Vasut
2018-05-03 16:28 ` Stefano Babic
1 sibling, 1 reply; 25+ messages in thread
From: Lukasz Majewski @ 2018-04-27 16:15 UTC (permalink / raw)
To: Marek Vasut; +Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]
Hi Marek,
Thanks for prompt feedback.
> 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 ?
Some users wants to have the working board (i.e. without any warnings
that CRC for envs is bad) after flashing the SPI-NOR/eMMC
> I can see some
> use with non-default env, but then that can be wrapped into a separate
> recipe.
I can add this functionality as a separate recipe. This is v1, so ideas
are welcome.
>
> > ---
> > This patch depends on "u-boot: Upgrade to 2018.03 release"
> > https://patchwork.openembedded.org/patch/149998/
> > ---
> > meta/recipes-bsp/u-boot/u-boot.inc | 35
> > +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> > b/meta/recipes-bsp/u-boot/u-boot.inc index c2bcf99840..2796e503cf
> > 100644 --- a/meta/recipes-bsp/u-boot/u-boot.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> > @@ -305,3 +305,38 @@ do_deploy () {
> > }
> >
> > addtask deploy before do_build after do_compile
> > +
> > +# Create new rules to extract default envs
> > +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> > +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> > +DEFAULT_ENVS_SIZE ?= "65536"
> > +
> > +# Generate default environment
> > +do_gen_default_envs[doc] = "Generate image with default U-Boot
> > environment(s)" +do_gen_default_envs () {
> > + ${B}/source/scripts/get_default_envs.sh ${B} >
> > ${B}/${DEFAULT_ENVS} +
> > + # Generate env image
> > + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
>
> Does this actually work during cross build , when mkenvimage
> architecture is different than host architecture ?
Yes. This was tested.
>
> > + # Generate redundant env image
> > + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
>
> Is redundant env always needed on all systems ?
No, they are not. However, it shall not be a problem if it is build
anyway - user can adjust wic to only put primary env image.
>
> > + rm ${B}/${DEFAULT_ENVS}
> > +}
> > +
> > +addtask gen_default_envs before do_deploy_default_envs after
> > do_compile +
> > +# Deploy default environment
> > +do_deploy_default_envs[doc] = "Copy images with default U-Boot
> > environment to deployment directory" +do_deploy_default_envs () {
> > + install -d ${DEPLOYDIR}
> > +
> > + install ${B}/${UBOOT_ENVS_DEFAULT}
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> > + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
>
> Does this work with multiple machines
Unfortunately not.
For multiple machines one needs to add ${target}, which would add
machine name into path:
target=${MACHINE}_defconfig
and change ${B} -> ${B}/${target}
I suppose, that I would need to adjust this script to be similar to
do_install() and do_compile() in this matter.
> or will it overwrite the
> deployed image ?
As it is now - it will overwrite the image.
>
>
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> > +}
> > +
> > +addtask deploy_default_envs before do_deploy after
> > do_gen_default_envs
>
>
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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-27 16:15 ` Lukasz Majewski
@ 2018-04-27 17:37 ` Marek Vasut
2018-04-29 13:53 ` Lukasz Majewski
2018-04-30 14:03 ` Otavio Salvador
0 siblings, 2 replies; 25+ messages in thread
From: Marek Vasut @ 2018-04-27 17:37 UTC (permalink / raw)
To: Lukasz Majewski; +Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
On 04/27/2018 06:15 PM, Lukasz Majewski wrote:
> Hi Marek,
>
> Thanks for prompt feedback.
>
>> 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 ?
>
> Some users wants to have the working board (i.e. without any warnings
> that CRC for envs is bad) after flashing the SPI-NOR/eMMC
And the board is not working when it tells you your env is not
populated? Then maybe the board port is broken.
>> I can see some
>> use with non-default env, but then that can be wrapped into a separate
>> recipe.
>
> I can add this functionality as a separate recipe. This is v1, so ideas
> are welcome.
I think that only makes sense.
>>> ---
>>> This patch depends on "u-boot: Upgrade to 2018.03 release"
>>> https://patchwork.openembedded.org/patch/149998/
>>> ---
>>> meta/recipes-bsp/u-boot/u-boot.inc | 35
>>> +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
>>>
>>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
>>> b/meta/recipes-bsp/u-boot/u-boot.inc index c2bcf99840..2796e503cf
>>> 100644 --- a/meta/recipes-bsp/u-boot/u-boot.inc
>>> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
>>> @@ -305,3 +305,38 @@ do_deploy () {
>>> }
>>>
>>> addtask deploy before do_build after do_compile
>>> +
>>> +# Create new rules to extract default envs
>>> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
>>> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
>>> +DEFAULT_ENVS_SIZE ?= "65536"
>>> +
>>> +# Generate default environment
>>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
>>> environment(s)" +do_gen_default_envs () {
>>> + ${B}/source/scripts/get_default_envs.sh ${B} >
>>> ${B}/${DEFAULT_ENVS} +
>>> + # Generate env image
>>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
>>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
>>
>> Does this actually work during cross build , when mkenvimage
>> architecture is different than host architecture ?
>
> Yes. This was tested.
How can it work if this binary cannot be executed ? :)
>>> + # Generate redundant env image
>>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
>>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
>>
>> Is redundant env always needed on all systems ?
>
> No, they are not. However, it shall not be a problem if it is build
> anyway - user can adjust wic to only put primary env image.
So many wasted CPU cycles for a feature barely anyone needs. Nope :)
>>> + rm ${B}/${DEFAULT_ENVS}
>>> +}
>>> +
>>> +addtask gen_default_envs before do_deploy_default_envs after
>>> do_compile +
>>> +# Deploy default environment
>>> +do_deploy_default_envs[doc] = "Copy images with default U-Boot
>>> environment to deployment directory" +do_deploy_default_envs () {
>>> + install -d ${DEPLOYDIR}
>>> +
>>> + install ${B}/${UBOOT_ENVS_DEFAULT}
>>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
>>> + install ${B}/${UBOOT_ENVS_DEFAULT}_r
>>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
>>
>> Does this work with multiple machines
>
> Unfortunately not.
>
> For multiple machines one needs to add ${target}, which would add
> machine name into path:
>
> target=${MACHINE}_defconfig
>
> and change ${B} -> ${B}/${target}
>
>
> I suppose, that I would need to adjust this script to be similar to
> do_install() and do_compile() in this matter.
Yep
>> or will it overwrite the
>> deployed image ?
>
> As it is now - it will overwrite the image.
Yep
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
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
1 sibling, 1 reply; 25+ messages in thread
From: Lukasz Majewski @ 2018-04-29 13:53 UTC (permalink / raw)
To: Marek Vasut; +Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 5238 bytes --]
Hi Marek,
> On 04/27/2018 06:15 PM, Lukasz Majewski wrote:
> > Hi Marek,
> >
> > Thanks for prompt feedback.
> >
> >> 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 ?
> >
> > Some users wants to have the working board (i.e. without any
> > warnings that CRC for envs is bad) after flashing the SPI-NOR/eMMC
>
> And the board is not working when it tells you your env is not
> populated?
It complains that CRC is wrong, which is true as without this patch
(and some wic adjustments) we don't have proper envs in expected
non-volatile area.
> Then maybe the board port is broken.
Then it proceeds with default envs - and boots.
>
> >> I can see some
> >> use with non-default env, but then that can be wrapped into a
> >> separate recipe.
> >
> > I can add this functionality as a separate recipe. This is v1, so
> > ideas are welcome.
>
> I think that only makes sense.
Ok.
>
> >>> ---
> >>> This patch depends on "u-boot: Upgrade to 2018.03 release"
> >>> https://patchwork.openembedded.org/patch/149998/
> >>> ---
> >>> meta/recipes-bsp/u-boot/u-boot.inc | 35
> >>> +++++++++++++++++++++++++++++++++++ 1 file changed, 35
> >>> insertions(+)
> >>>
> >>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> >>> b/meta/recipes-bsp/u-boot/u-boot.inc index
> >>> c2bcf99840.cdd7703db9ea580308d4ebcd6d0ae3209b761daa.2796e503cf
> >>> 100644 --- a/meta/recipes-bsp/u-boot/u-boot.inc +++
> >>> b/meta/recipes-bsp/u-boot/u-boot.inc @@ -305,3 +305,38 @@
> >>> do_deploy () { }
> >>>
> >>> addtask deploy before do_build after do_compile
> >>> +
> >>> +# Create new rules to extract default envs
> >>> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> >>> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> >>> +DEFAULT_ENVS_SIZE ?= "65536"
> >>> +
> >>> +# Generate default environment
> >>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
> >>> environment(s)" +do_gen_default_envs () {
> >>> + ${B}/source/scripts/get_default_envs.sh ${B} >
> >>> ${B}/${DEFAULT_ENVS} +
> >>> + # Generate env image
> >>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
> >>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
> >>
> >> Does this actually work during cross build , when mkenvimage
> >> architecture is different than host architecture ?
> >
> > Yes. This was tested.
>
> How can it work if this binary cannot be executed ? :)
Could you be more specific here?
I do follow normal u-boot recipe build. If mkenvimage is build in a
wrong way (as other tools) - then I suppose that the whole u-boot recipe
is broken.
The get_default_envs.sh script is prepared to use either native or
cross-compiled set of binutils (that thought I had in mind when I said
that it was tested).
>
> >>> + # Generate redundant env image
> >>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
> >>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
> >>
> >> Is redundant env always needed on all systems ?
> >
> > No, they are not. However, it shall not be a problem if it is build
> > anyway - user can adjust wic to only put primary env image.
>
> So many wasted CPU cycles for a feature barely anyone needs. Nope :)
I will try to craft some OE magic to make it not build when not
needed... :-)
>
> >>> + rm ${B}/${DEFAULT_ENVS}
> >>> +}
> >>> +
> >>> +addtask gen_default_envs before do_deploy_default_envs after
> >>> do_compile +
> >>> +# Deploy default environment
> >>> +do_deploy_default_envs[doc] = "Copy images with default U-Boot
> >>> environment to deployment directory" +do_deploy_default_envs () {
> >>> + install -d ${DEPLOYDIR}
> >>> +
> >>> + install ${B}/${UBOOT_ENVS_DEFAULT}
> >>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> >>> + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> >>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
> >>
> >> Does this work with multiple machines
> >
> > Unfortunately not.
> >
> > For multiple machines one needs to add ${target}, which would add
> > machine name into path:
> >
> > target=${MACHINE}_defconfig
> >
> > and change ${B} -> ${B}/${target}
> >
> >
> > I suppose, that I would need to adjust this script to be similar to
> > do_install() and do_compile() in this matter.
>
> Yep
Ok.
>
> >> or will it overwrite the
> >> deployed image ?
> >
> > As it is now - it will overwrite the image.
> Yep
>
Ok.
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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-29 13:53 ` Lukasz Majewski
@ 2018-04-29 14:07 ` Marek Vasut
0 siblings, 0 replies; 25+ messages in thread
From: Marek Vasut @ 2018-04-29 14:07 UTC (permalink / raw)
To: Lukasz Majewski; +Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
On 04/29/2018 03:53 PM, Lukasz Majewski wrote:
> Hi Marek,
Hello Lukasz,
>> On 04/27/2018 06:15 PM, Lukasz Majewski wrote:
>>> Hi Marek,
>>>
>>> Thanks for prompt feedback.
>>>
>>>> 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 ?
>>>
>>> Some users wants to have the working board (i.e. without any
>>> warnings that CRC for envs is bad) after flashing the SPI-NOR/eMMC
>>
>> And the board is not working when it tells you your env is not
>> populated?
>
> It complains that CRC is wrong, which is true as without this patch
> (and some wic adjustments) we don't have proper envs in expected
> non-volatile area.
This is NOT an error, this is warning and a correct behavior. If your
default U-Boot environment is not correct, that is a bug in your U-Boot
port.
If you need to adjust that environment later in the product life cycle,
that's a different topic.
>> Then maybe the board port is broken.
>
> Then it proceeds with default envs - and boots.
I think I might not quite understand the problem anymore. Is the issue
here that U-Boot informs you that it's using default environment which
you do not like ?
[...]
>>>>> +# Generate default environment
>>>>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
>>>>> environment(s)" +do_gen_default_envs () {
>>>>> + ${B}/source/scripts/get_default_envs.sh ${B} >
>>>>> ${B}/${DEFAULT_ENVS} +
>>>>> + # Generate env image
>>>>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
>>>>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
>>>>
>>>> Does this actually work during cross build , when mkenvimage
>>>> architecture is different than host architecture ?
>>>
>>> Yes. This was tested.
>>
>> How can it work if this binary cannot be executed ? :)
>
> Could you be more specific here?
>
> I do follow normal u-boot recipe build. If mkenvimage is build in a
> wrong way (as other tools) - then I suppose that the whole u-boot recipe
> is broken.
>
> The get_default_envs.sh script is prepared to use either native or
> cross-compiled set of binutils (that thought I had in mind when I said
> that it was tested).
Consider you crosscompile mkenvimage for ARM and try to run it on x86 host.
>>>>> + # Generate redundant env image
>>>>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
>>>>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
>>>>
>>>> Is redundant env always needed on all systems ?
>>>
>>> No, they are not. However, it shall not be a problem if it is build
>>> anyway - user can adjust wic to only put primary env image.
>>
>> So many wasted CPU cycles for a feature barely anyone needs. Nope :)
>
> I will try to craft some OE magic to make it not build when not
> needed... :-)
Can't you just patch a correct default env into the U-Boot port ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
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-30 6:50 ` Martin Hundebøll
2018-04-30 8:18 ` Lukasz Majewski
2018-04-30 13:23 ` Martin Jansa
2018-05-03 16:24 ` Stefano Babic
2 siblings, 2 replies; 25+ messages in thread
From: Martin Hundebøll @ 2018-04-30 6:50 UTC (permalink / raw)
To: Lukasz Majewski, OpenEmbedded Core Mailing List, Marek Vasut
Cc: Tom Rini, Stefan Agner
Hi Lukasz,
On 2018-04-27 16:51, 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).
I think we should create a separate recipe to install the native
mkenvimage binary (e.g. u-boot-mkenvimage_%.bb) or update
u-boot-mkimage_%.bb install it.
Then a new recipe to create the environment images can depend on
u-boot-mkenvimage-native.
Also note the recently added upstream support for external environment
definitions:
http://git.denx.de/?p=u-boot.git;a=commit;h=f3d8f7dd73ac5dde258eb786d4a01869395b56d7
For our usecase we need the ability to generate environment images in
yocto from such external definitions.
// Martin
>
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>
> ---
> This patch depends on "u-boot: Upgrade to 2018.03 release"
> https://patchwork.openembedded.org/patch/149998/
> ---
> meta/recipes-bsp/u-boot/u-boot.inc | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
> index c2bcf99840..2796e503cf 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -305,3 +305,38 @@ do_deploy () {
> }
>
> addtask deploy before do_build after do_compile
> +
> +# Create new rules to extract default envs
> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> +DEFAULT_ENVS_SIZE ?= "65536"
> +
> +# Generate default environment
> +do_gen_default_envs[doc] = "Generate image with default U-Boot environment(s)"
> +do_gen_default_envs () {
> + ${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
> +
> + # Generate env image
> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
> +
> + # Generate redundant env image
> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
> +
> + rm ${B}/${DEFAULT_ENVS}
> +}
> +
> +addtask gen_default_envs before do_deploy_default_envs after do_compile
> +
> +# Deploy default environment
> +do_deploy_default_envs[doc] = "Copy images with default U-Boot environment to deployment directory"
> +do_deploy_default_envs () {
> + install -d ${DEPLOYDIR}
> +
> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> + install ${B}/${UBOOT_ENVS_DEFAULT}_r ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
> +
> + rm ${B}/${UBOOT_ENVS_DEFAULT}
> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> +}
> +
> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-30 6:50 ` Martin Hundebøll
@ 2018-04-30 8:18 ` Lukasz Majewski
2018-04-30 13:23 ` Martin Jansa
1 sibling, 0 replies; 25+ messages in thread
From: Lukasz Majewski @ 2018-04-30 8:18 UTC (permalink / raw)
To: Martin Hundebøll
Cc: Marek Vasut, Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]
Hi Martin,
> Hi Lukasz,
>
> On 2018-04-27 16:51, 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).
>
> I think we should create a separate recipe to install the native
> mkenvimage binary (e.g. u-boot-mkenvimage_%.bb) or update
> u-boot-mkimage_%.bb install it.
I see your point.
I suppose that the above idea is more OE style than:
${B}/tools/mkenvimage
and DEPENDS = "u-boot:compile"
>
> Then a new recipe to create the environment images can depend on
> u-boot-mkenvimage-native.
Ok.
>
> Also note the recently added upstream support for external
> environment definitions:
> http://git.denx.de/?p=u-boot.git;a=commit;h=f3d8f7dd73ac5dde258eb786d4a01869395b56d7
Those features are complementary.
1. Envs definition from CONFIG_EXTRA_ENV_SETTINGS are provided
externally,
2. The one generated by source/scripts/get_default_envs.sh are simply
the ones from u-boot's "default environment" (extracted from the
binary).
They both produce *.txt file which is the input for mkenvimage.
>
> For our usecase we need the ability to generate environment images in
> yocto from such external definitions.
Ok. I see.
>
> // Martin
>
> >
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> >
> > ---
> > This patch depends on "u-boot: Upgrade to 2018.03 release"
> > https://patchwork.openembedded.org/patch/149998/
> > ---
> > meta/recipes-bsp/u-boot/u-boot.inc | 35
> > +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> > b/meta/recipes-bsp/u-boot/u-boot.inc index c2bcf99840..2796e503cf
> > 100644 --- a/meta/recipes-bsp/u-boot/u-boot.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> > @@ -305,3 +305,38 @@ do_deploy () {
> > }
> >
> > addtask deploy before do_build after do_compile
> > +
> > +# Create new rules to extract default envs
> > +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> > +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> > +DEFAULT_ENVS_SIZE ?= "65536"
> > +
> > +# Generate default environment
> > +do_gen_default_envs[doc] = "Generate image with default U-Boot
> > environment(s)" +do_gen_default_envs () {
> > + ${B}/source/scripts/get_default_envs.sh ${B} >
> > ${B}/${DEFAULT_ENVS} +
> > + # Generate env image
> > + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS} +
> > + # Generate redundant env image
> > + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS} +
> > + rm ${B}/${DEFAULT_ENVS}
> > +}
> > +
> > +addtask gen_default_envs before do_deploy_default_envs after
> > do_compile +
> > +# Deploy default environment
> > +do_deploy_default_envs[doc] = "Copy images with default U-Boot
> > environment to deployment directory" +do_deploy_default_envs () {
> > + install -d ${DEPLOYDIR}
> > +
> > + install ${B}/${UBOOT_ENVS_DEFAULT}
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> > + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r +
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> > +}
> > +
> > +addtask deploy_default_envs before do_deploy after
> > do_gen_default_envs
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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
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
1 sibling, 1 reply; 25+ messages in thread
From: Martin Jansa @ 2018-04-30 13:23 UTC (permalink / raw)
To: Martin Hundebøll
Cc: Marek Vasut, Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 3744 bytes --]
u-boot-mkimage already builds mkenvimage, you just need to install it in
do_install:
install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
This is what we have in recipes-bsp/u-boot/u-boot-mkimage_%.bbappend and it
works fine.
On Mon, Apr 30, 2018 at 8:50 AM, Martin Hundebøll <mnhu@prevas.dk> wrote:
> Hi Lukasz,
>
> On 2018-04-27 16:51, 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).
>>
>
> I think we should create a separate recipe to install the native
> mkenvimage binary (e.g. u-boot-mkenvimage_%.bb) or update
> u-boot-mkimage_%.bb install it.
>
> Then a new recipe to create the environment images can depend on
> u-boot-mkenvimage-native.
>
> Also note the recently added upstream support for external environment
> definitions:
> http://git.denx.de/?p=u-boot.git;a=commit;h=f3d8f7dd73ac5dde
> 258eb786d4a01869395b56d7
>
> For our usecase we need the ability to generate environment images in
> yocto from such external definitions.
>
> // Martin
>
>
>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>
>> ---
>> This patch depends on "u-boot: Upgrade to 2018.03 release"
>> https://patchwork.openembedded.org/patch/149998/
>> ---
>> meta/recipes-bsp/u-boot/u-boot.inc | 35 ++++++++++++++++++++++++++++++
>> +++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
>> b/meta/recipes-bsp/u-boot/u-boot.inc
>> index c2bcf99840..2796e503cf 100644
>> --- a/meta/recipes-bsp/u-boot/u-boot.inc
>> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
>> @@ -305,3 +305,38 @@ do_deploy () {
>> }
>> addtask deploy before do_build after do_compile
>> +
>> +# Create new rules to extract default envs
>> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
>> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
>> +DEFAULT_ENVS_SIZE ?= "65536"
>> +
>> +# Generate default environment
>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
>> environment(s)"
>> +do_gen_default_envs () {
>> + ${B}/source/scripts/get_default_envs.sh ${B} >
>> ${B}/${DEFAULT_ENVS}
>> +
>> + # Generate env image
>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
>> +
>> + # Generate redundant env image
>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
>> +
>> + rm ${B}/${DEFAULT_ENVS}
>> +}
>> +
>> +addtask gen_default_envs before do_deploy_default_envs after do_compile
>> +
>> +# Deploy default environment
>> +do_deploy_default_envs[doc] = "Copy images with default U-Boot
>> environment to deployment directory"
>> +do_deploy_default_envs () {
>> + install -d ${DEPLOYDIR}
>> +
>> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFA
>> ULT}
>> + install ${B}/${UBOOT_ENVS_DEFAULT}_r
>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
>> +
>> + rm ${B}/${UBOOT_ENVS_DEFAULT}
>> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
>> +}
>> +
>> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
>>
>> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 5238 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-30 13:23 ` Martin Jansa
@ 2018-04-30 13:26 ` Martin Jansa
2018-04-30 14:22 ` Lukasz Majewski
0 siblings, 1 reply; 25+ messages in thread
From: Martin Jansa @ 2018-04-30 13:26 UTC (permalink / raw)
To: Martin Hundebøll
Cc: Marek Vasut, Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 4538 bytes --]
And here is example how we're using it:
https://github.com/webosose/meta-webosose/blob/master/meta-webos-raspberrypi/recipes-bsp/u-boot/u-boot-env.bb
To make it compatible with raspberrypi3 and raspberrypi3-64, I've updated
it a bit to select correct IMAGETYPE and BOOTCMD based on the environment:
do_compile() {
sed -e 's/@@KERNEL_IMAGETYPE@@/${KERNEL_IMAGETYPE}/' \
-e 's/@@KERNEL_BOOTCMD@@/${KERNEL_BOOTCMD}/' \
"${WORKDIR}/uboot-env.txt.in" > "${WORKDIR}/uboot-env.txt"
uboot-mkenvimage -s 16384 -o uboot.env ${WORKDIR}/uboot-env.txt
}
On Mon, Apr 30, 2018 at 3:23 PM, Martin Jansa <martin.jansa@gmail.com>
wrote:
> u-boot-mkimage already builds mkenvimage, you just need to install it in
> do_install:
>
> install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
> ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
>
> This is what we have in recipes-bsp/u-boot/u-boot-mkimage_%.bbappend and
> it works fine.
>
> On Mon, Apr 30, 2018 at 8:50 AM, Martin Hundebøll <mnhu@prevas.dk> wrote:
>
>> Hi Lukasz,
>>
>> On 2018-04-27 16:51, 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).
>>>
>>
>> I think we should create a separate recipe to install the native
>> mkenvimage binary (e.g. u-boot-mkenvimage_%.bb) or update
>> u-boot-mkimage_%.bb install it.
>>
>> Then a new recipe to create the environment images can depend on
>> u-boot-mkenvimage-native.
>>
>> Also note the recently added upstream support for external environment
>> definitions:
>> http://git.denx.de/?p=u-boot.git;a=commit;h=f3d8f7dd73ac5dde
>> 258eb786d4a01869395b56d7
>>
>> For our usecase we need the ability to generate environment images in
>> yocto from such external definitions.
>>
>> // Martin
>>
>>
>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>
>>> ---
>>> This patch depends on "u-boot: Upgrade to 2018.03 release"
>>> https://patchwork.openembedded.org/patch/149998/
>>> ---
>>> meta/recipes-bsp/u-boot/u-boot.inc | 35 ++++++++++++++++++++++++++++++
>>> +++++
>>> 1 file changed, 35 insertions(+)
>>>
>>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
>>> b/meta/recipes-bsp/u-boot/u-boot.inc
>>> index c2bcf99840..2796e503cf 100644
>>> --- a/meta/recipes-bsp/u-boot/u-boot.inc
>>> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
>>> @@ -305,3 +305,38 @@ do_deploy () {
>>> }
>>> addtask deploy before do_build after do_compile
>>> +
>>> +# Create new rules to extract default envs
>>> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
>>> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
>>> +DEFAULT_ENVS_SIZE ?= "65536"
>>> +
>>> +# Generate default environment
>>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
>>> environment(s)"
>>> +do_gen_default_envs () {
>>> + ${B}/source/scripts/get_default_envs.sh ${B} >
>>> ${B}/${DEFAULT_ENVS}
>>> +
>>> + # Generate env image
>>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
>>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
>>> +
>>> + # Generate redundant env image
>>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
>>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
>>> +
>>> + rm ${B}/${DEFAULT_ENVS}
>>> +}
>>> +
>>> +addtask gen_default_envs before do_deploy_default_envs after do_compile
>>> +
>>> +# Deploy default environment
>>> +do_deploy_default_envs[doc] = "Copy images with default U-Boot
>>> environment to deployment directory"
>>> +do_deploy_default_envs () {
>>> + install -d ${DEPLOYDIR}
>>> +
>>> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFA
>>> ULT}
>>> + install ${B}/${UBOOT_ENVS_DEFAULT}_r
>>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
>>> +
>>> + rm ${B}/${UBOOT_ENVS_DEFAULT}
>>> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
>>> +}
>>> +
>>> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
>>>
>>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
[-- Attachment #2: Type: text/html, Size: 6599 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-27 17:37 ` Marek Vasut
2018-04-29 13:53 ` Lukasz Majewski
@ 2018-04-30 14:03 ` Otavio Salvador
2018-04-30 17:32 ` Marek Vasut
1 sibling, 1 reply; 25+ messages in thread
From: Otavio Salvador @ 2018-04-30 14:03 UTC (permalink / raw)
To: Marek Vasut
Cc: Tom Rini, Stefan Agner, Patches and discussions about the oe-core layer
On Fri, Apr 27, 2018 at 2:37 PM Marek Vasut <marex@denx.de> wrote:
> On 04/27/2018 06:15 PM, Lukasz Majewski wrote:
> > I can add this functionality as a separate recipe. This is v1, so ideas
> > are welcome.
> I think that only makes sense.
Also, we likely need to make use of the mkimage recipe so we use the tools
and not build it all again.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-30 13:26 ` Martin Jansa
@ 2018-04-30 14:22 ` Lukasz Majewski
0 siblings, 0 replies; 25+ messages in thread
From: Lukasz Majewski @ 2018-04-30 14:22 UTC (permalink / raw)
To: Martin Jansa
Cc: Marek Vasut, Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 5159 bytes --]
Hi Martin,
> And here is example how we're using it:
>
> https://github.com/webosose/meta-webosose/blob/master/meta-webos-raspberrypi/recipes-bsp/u-boot/u-boot-env.bb
>
> To make it compatible with raspberrypi3 and raspberrypi3-64, I've
> updated it a bit to select correct IMAGETYPE and BOOTCMD based on the
> environment:
>
> do_compile() {
> sed -e 's/@@KERNEL_IMAGETYPE@@/${KERNEL_IMAGETYPE}/' \
> -e 's/@@KERNEL_BOOTCMD@@/${KERNEL_BOOTCMD}/' \
> "${WORKDIR}/uboot-env.txt.in" > "${WORKDIR}/uboot-env.txt"
> uboot-mkenvimage -s 16384 -o uboot.env ${WORKDIR}/uboot-env.txt
> }
>
Thanks for sharing the code (and detailed explanation).
>
> On Mon, Apr 30, 2018 at 3:23 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
>
> > u-boot-mkimage already builds mkenvimage, you just need to install
> > it in do_install:
> >
> > install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
> > ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
> >
> > This is what we have in
> > recipes-bsp/u-boot/u-boot-mkimage_%.bbappend and it works fine.
> >
> > On Mon, Apr 30, 2018 at 8:50 AM, Martin Hundebøll <mnhu@prevas.dk>
> > wrote:
> >> Hi Lukasz,
> >>
> >> On 2018-04-27 16:51, 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).
> >>>
> >>
> >> I think we should create a separate recipe to install the native
> >> mkenvimage binary (e.g. u-boot-mkenvimage_%.bb) or update
> >> u-boot-mkimage_%.bb install it.
> >>
> >> Then a new recipe to create the environment images can depend on
> >> u-boot-mkenvimage-native.
> >>
> >> Also note the recently added upstream support for external
> >> environment definitions:
> >> http://git.denx.de/?p=u-boot.git;a=commit;h=f3d8f7dd73ac5dde
> >> 258eb786d4a01869395b56d7
> >>
> >> For our usecase we need the ability to generate environment images
> >> in yocto from such external definitions.
> >>
> >> // Martin
> >>
> >>
> >>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> >>>
> >>> ---
> >>> This patch depends on "u-boot: Upgrade to 2018.03 release"
> >>> https://patchwork.openembedded.org/patch/149998/
> >>> ---
> >>> meta/recipes-bsp/u-boot/u-boot.inc | 35
> >>> ++++++++++++++++++++++++++++++ +++++
> >>> 1 file changed, 35 insertions(+)
> >>>
> >>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> >>> b/meta/recipes-bsp/u-boot/u-boot.inc
> >>> index c2bcf99840..2796e503cf 100644
> >>> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> >>> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> >>> @@ -305,3 +305,38 @@ do_deploy () {
> >>> }
> >>> addtask deploy before do_build after do_compile
> >>> +
> >>> +# Create new rules to extract default envs
> >>> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> >>> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> >>> +DEFAULT_ENVS_SIZE ?= "65536"
> >>> +
> >>> +# Generate default environment
> >>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
> >>> environment(s)"
> >>> +do_gen_default_envs () {
> >>> + ${B}/source/scripts/get_default_envs.sh ${B} >
> >>> ${B}/${DEFAULT_ENVS}
> >>> +
> >>> + # Generate env image
> >>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
> >>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
> >>> +
> >>> + # Generate redundant env image
> >>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
> >>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
> >>> +
> >>> + rm ${B}/${DEFAULT_ENVS}
> >>> +}
> >>> +
> >>> +addtask gen_default_envs before do_deploy_default_envs after
> >>> do_compile +
> >>> +# Deploy default environment
> >>> +do_deploy_default_envs[doc] = "Copy images with default U-Boot
> >>> environment to deployment directory"
> >>> +do_deploy_default_envs () {
> >>> + install -d ${DEPLOYDIR}
> >>> +
> >>> + install ${B}/${UBOOT_ENVS_DEFAULT}
> >>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFA ULT}
> >>> + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> >>> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
> >>> +
> >>> + rm ${B}/${UBOOT_ENVS_DEFAULT}
> >>> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> >>> +}
> >>> +
> >>> +addtask deploy_default_envs before do_deploy after
> >>> do_gen_default_envs
> >>>
> >>> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
> >
> >
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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-30 14:03 ` Otavio Salvador
@ 2018-04-30 17:32 ` Marek Vasut
0 siblings, 0 replies; 25+ messages in thread
From: Marek Vasut @ 2018-04-30 17:32 UTC (permalink / raw)
To: Otavio Salvador
Cc: Tom Rini, Stefan Agner, Patches and discussions about the oe-core layer
On 04/30/2018 04:03 PM, Otavio Salvador wrote:
> On Fri, Apr 27, 2018 at 2:37 PM Marek Vasut <marex@denx.de> wrote:
>
>> On 04/27/2018 06:15 PM, Lukasz Majewski wrote:
>>> I can add this functionality as a separate recipe. This is v1, so ideas
>>> are welcome.
>
>> I think that only makes sense.
>
> Also, we likely need to make use of the mkimage recipe so we use the tools
> and not build it all again.
And -- based on the offlist discussion -- I realized that env tools are
machine specific, they bundle default env with them.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
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-30 6:50 ` Martin Hundebøll
@ 2018-05-03 16:24 ` Stefano Babic
2018-05-03 18:17 ` Lukasz Majewski
2 siblings, 1 reply; 25+ messages in thread
From: Stefano Babic @ 2018-05-03 16:24 UTC (permalink / raw)
To: Lukasz Majewski, OpenEmbedded Core Mailing List, Marek Vasut
Cc: Tom Rini, Stefan Agner
Hi Lukasz,
On 27/04/2018 16:51, 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>
>
> ---
> This patch depends on "u-boot: Upgrade to 2018.03 release"
> https://patchwork.openembedded.org/patch/149998/
> ---
> meta/recipes-bsp/u-boot/u-boot.inc | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
> index c2bcf99840..2796e503cf 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -305,3 +305,38 @@ do_deploy () {
> }
>
> addtask deploy before do_build after do_compile
> +
> +# Create new rules to extract default envs
> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> +DEFAULT_ENVS_SIZE ?= "65536"
> +
> +# Generate default environment
> +do_gen_default_envs[doc] = "Generate image with default U-Boot environment(s)"
> +do_gen_default_envs () {
> + ${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
> +
> + # Generate env image
> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
> +
> + # Generate redundant env image
> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
> +
> + rm ${B}/${DEFAULT_ENVS}
> +}
> +
Why do we need a separate task ? Is it not part of do_compile ?
> +addtask gen_default_envs before do_deploy_default_envs after do_compile
> +
> +# Deploy default environment
> +do_deploy_default_envs[doc] = "Copy images with default U-Boot environment to deployment directory"
> +do_deploy_default_envs () {
> + install -d ${DEPLOYDIR}
> +
> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> + install ${B}/${UBOOT_ENVS_DEFAULT}_r ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
> +
> + rm ${B}/${UBOOT_ENVS_DEFAULT}
> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> +}
> +
> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
>
I would like to see that the default environment is installed and
delivered as (additional) package. I could then add it to my rootfs and
use it to set up the environment in user space in case a CRC error is
reported by the env tools.
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-04-27 15:07 ` Marek Vasut
2018-04-27 16:15 ` Lukasz Majewski
@ 2018-05-03 16:28 ` Stefano Babic
2018-05-03 16:36 ` Marek Vasut
1 sibling, 1 reply; 25+ messages in thread
From: Stefano Babic @ 2018-05-03 16:28 UTC (permalink / raw)
To: Marek Vasut, Lukasz Majewski, OpenEmbedded Core Mailing List
Cc: Tom Rini, Stefan Agner
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.
>> ---
>> This patch depends on "u-boot: Upgrade to 2018.03 release"
>> https://patchwork.openembedded.org/patch/149998/
>> ---
>> meta/recipes-bsp/u-boot/u-boot.inc | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
>> index c2bcf99840..2796e503cf 100644
>> --- a/meta/recipes-bsp/u-boot/u-boot.inc
>> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
>> @@ -305,3 +305,38 @@ do_deploy () {
>> }
>>
>> addtask deploy before do_build after do_compile
>> +
>> +# Create new rules to extract default envs
>> +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
>> +DEFAULT_ENVS ?= "u-boot-env-default.txt"
>> +DEFAULT_ENVS_SIZE ?= "65536"
>> +
>> +# Generate default environment
>> +do_gen_default_envs[doc] = "Generate image with default U-Boot environment(s)"
>> +do_gen_default_envs () {
>> + ${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
>> +
>> + # Generate env image
>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
>
> Does this actually work during cross build , when mkenvimage
> architecture is different than host architecture ?
>
>> + # Generate redundant env image
>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
>
> Is redundant env always needed on all systems ?
>
>> + rm ${B}/${DEFAULT_ENVS}
>> +}
>> +
>> +addtask gen_default_envs before do_deploy_default_envs after do_compile
>> +
>> +# Deploy default environment
>> +do_deploy_default_envs[doc] = "Copy images with default U-Boot environment to deployment directory"
>> +do_deploy_default_envs () {
>> + install -d ${DEPLOYDIR}
>> +
>> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
>> + install ${B}/${UBOOT_ENVS_DEFAULT}_r ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
>
> Does this work with multiple machines or will it overwrite the deployed
> image ?
>
>
>> + rm ${B}/${UBOOT_ENVS_DEFAULT}
>> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
>> +}
>> +
>> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
>>
>
>
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 16:28 ` Stefano Babic
@ 2018-05-03 16:36 ` Marek Vasut
2018-05-03 16:50 ` Stefano Babic
0 siblings, 1 reply; 25+ messages in thread
From: Marek Vasut @ 2018-05-03 16:36 UTC (permalink / raw)
To: Stefano Babic, Lukasz Majewski, OpenEmbedded Core Mailing List
Cc: Tom Rini, Stefan Agner
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 OR fix fw_setenv to take env defaults from a file or somesuch ?
[...]
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 16:36 ` Marek Vasut
@ 2018-05-03 16:50 ` Stefano Babic
2018-05-03 16:59 ` Marek Vasut
0 siblings, 1 reply; 25+ messages in thread
From: Stefano Babic @ 2018-05-03 16:50 UTC (permalink / raw)
To: Marek Vasut, Stefano Babic, Lukasz Majewski,
OpenEmbedded Core Mailing List
Cc: Tom Rini, Stefan Agner
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.
> 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.
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 16:50 ` Stefano Babic
@ 2018-05-03 16:59 ` Marek Vasut
2018-05-03 18:15 ` Lukasz Majewski
2018-05-03 20:58 ` Stefano Babic
0 siblings, 2 replies; 25+ messages in thread
From: Marek Vasut @ 2018-05-03 16:59 UTC (permalink / raw)
To: Stefano Babic, Lukasz Majewski, OpenEmbedded Core Mailing List
Cc: Tom Rini, Stefan Agner
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 ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 16:59 ` Marek Vasut
@ 2018-05-03 18:15 ` Lukasz Majewski
2018-05-03 19:02 ` Marek Vasut
2018-05-03 20:58 ` Stefano Babic
1 sibling, 1 reply; 25+ messages in thread
From: Lukasz Majewski @ 2018-05-03 18:15 UTC (permalink / raw)
To: Marek Vasut, Stefano Babic
Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 16:24 ` Stefano Babic
@ 2018-05-03 18:17 ` Lukasz Majewski
0 siblings, 0 replies; 25+ messages in thread
From: Lukasz Majewski @ 2018-05-03 18:17 UTC (permalink / raw)
To: Stefano Babic
Cc: Marek Vasut, Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]
On Thu, 3 May 2018 18:24:32 +0200
Stefano Babic <sbabic@denx.de> wrote:
> Hi Lukasz,
>
> On 27/04/2018 16:51, 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>
> >
> > ---
> > This patch depends on "u-boot: Upgrade to 2018.03 release"
> > https://patchwork.openembedded.org/patch/149998/
> > ---
> > meta/recipes-bsp/u-boot/u-boot.inc | 35
> > +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> > b/meta/recipes-bsp/u-boot/u-boot.inc index c2bcf99840..2796e503cf
> > 100644 --- a/meta/recipes-bsp/u-boot/u-boot.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> > @@ -305,3 +305,38 @@ do_deploy () {
> > }
> >
> > addtask deploy before do_build after do_compile
> > +
> > +# Create new rules to extract default envs
> > +UBOOT_ENVS_DEFAULT ?= "uboot-envs-default"
> > +DEFAULT_ENVS ?= "u-boot-env-default.txt"
> > +DEFAULT_ENVS_SIZE ?= "65536"
> > +
> > +# Generate default environment
> > +do_gen_default_envs[doc] = "Generate image with default U-Boot
> > environment(s)" +do_gen_default_envs () {
> > + ${B}/source/scripts/get_default_envs.sh ${B} >
> > ${B}/${DEFAULT_ENVS} +
> > + # Generate env image
> > + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS} +
> > + # Generate redundant env image
> > + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS} +
> > + rm ${B}/${DEFAULT_ENVS}
> > +}
> > +
>
> Why do we need a separate task ? Is it not part of do_compile ?
The get_default_envs.sh script requires the build-in.o to be already
build. For that reason I've added a separate task, which goes just after
the do_compile for u-boot.
>
> > +addtask gen_default_envs before do_deploy_default_envs after
> > do_compile +
> > +# Deploy default environment
> > +do_deploy_default_envs[doc] = "Copy images with default U-Boot
> > environment to deployment directory" +do_deploy_default_envs () {
> > + install -d ${DEPLOYDIR}
> > +
> > + install ${B}/${UBOOT_ENVS_DEFAULT}
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> > + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r +
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> > +}
> > +
> > +addtask deploy_default_envs before do_deploy after
> > do_gen_default_envs
>
> I would like to see that the default environment is installed and
> delivered as (additional) package. I could then add it to my rootfs
> and use it to set up the environment in user space in case a CRC
> error is reported by the env tools.
>
> Regards,
> Stefano
>
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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 18:15 ` Lukasz Majewski
@ 2018-05-03 19:02 ` Marek Vasut
2018-05-09 11:45 ` Lukasz Majewski
0 siblings, 1 reply; 25+ messages in thread
From: Marek Vasut @ 2018-05-03 19:02 UTC (permalink / raw)
To: Lukasz Majewski, Stefano Babic
Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
On 05/03/2018 08:15 PM, Lukasz Majewski wrote:
> 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.
Sounds about good. I think this approach fails with NAND, so be careful
there.
> 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
Or add some build-time option to build it with blank default env. Then
you can apply your file-based approach, the setenv would be
board-agnostic and it should do I guess ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 16:59 ` Marek Vasut
2018-05-03 18:15 ` Lukasz Majewski
@ 2018-05-03 20:58 ` Stefano Babic
2018-05-03 23:04 ` Marek Vasut
1 sibling, 1 reply; 25+ messages in thread
From: Stefano Babic @ 2018-05-03 20:58 UTC (permalink / raw)
To: Marek Vasut, Stefano Babic, Lukasz Majewski,
OpenEmbedded Core Mailing List
Cc: Tom Rini, Stefan Agner
Hi Marek,
On 03/05/2018 18:59, Marek Vasut wrote:
> 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 ?
>
Well, quite. But in the specific case, it is weird that the environment
tools are built by a separate recipe. u-boot-fw-utils generates binaries
from the same sources as u-boot (or it should), and building the tool
per machine means for me to have a single recipe for it, that generates
as additional package the env tools. This guarantees that they are
always in sync.
>>> OR fix fw_setenv to take env defaults from a file or somesuch ?
>>
Having a separate recipe as now means for me to try to have the tools
not per machine, and then makes sense to pass as input the default
environment to the tools.
>> 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 ?
Not the current patch - we are discussing how it could evolve ;-)
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 20:58 ` Stefano Babic
@ 2018-05-03 23:04 ` Marek Vasut
0 siblings, 0 replies; 25+ messages in thread
From: Marek Vasut @ 2018-05-03 23:04 UTC (permalink / raw)
To: Stefano Babic, Lukasz Majewski, OpenEmbedded Core Mailing List
Cc: Tom Rini, Stefan Agner
On 05/03/2018 10:58 PM, Stefano Babic wrote:
> Hi Marek,
>
> On 03/05/2018 18:59, Marek Vasut wrote:
>> 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 ?
>>
>
> Well, quite. But in the specific case, it is weird that the environment
> tools are built by a separate recipe. u-boot-fw-utils generates binaries
> from the same sources as u-boot (or it should), and building the tool
> per machine means for me to have a single recipe for it, that generates
> as additional package the env tools. This guarantees that they are
> always in sync.
Patches welcome ? :)
>>>> OR fix fw_setenv to take env defaults from a file or somesuch ?
>>>
>
> Having a separate recipe as now means for me to try to have the tools
> not per machine, and then makes sense to pass as input the default
> environment to the tools.
Cfr the conclusion (?) we reached with Lukasz I think ?
>>> 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 ?
>
> Not the current patch - we are discussing how it could evolve ;-)
Ah, I wonder if we shouldn't start a new thread for this and crosspost
it to the U-Boot ML too then ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-03 19:02 ` Marek Vasut
@ 2018-05-09 11:45 ` Lukasz Majewski
2018-05-09 11:57 ` Marek Vasut
0 siblings, 1 reply; 25+ messages in thread
From: Lukasz Majewski @ 2018-05-09 11:45 UTC (permalink / raw)
To: Marek Vasut, Stefano Babic
Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 5080 bytes --]
Hi Marek, Stefano,
> On 05/03/2018 08:15 PM, Lukasz Majewski wrote:
> > 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
I've looked a bit more on the topic, and I do have some further
questions:
1. It seems like u-boot is compiled at least twice - once when
do_comiple() is invoked in u-boot.inc (here we support multiple
configs, and targets) and in u-boot-fw-utils (also u-boot-mkimage
compiles u-boot for sandbox_defconfig).
It seems like the synchronization of the built package (and envs) is
ensured with u-boot-common_2018.03.inc package.
2. It seems like it would be feasible to have a separate recipe -
u-boot-envs_2018.03.bb [*] which would:
- Use u-boot-env.txt provided as an external file (from e.g.
SRC += "./file/u-boot-env.txt"). This is the approach similar
to
https://github.com/webosose/meta-webosose/blob/master/meta-webos-raspberrypi/recipes-bsp/u-boot/u-boot-env.bb
- If above input *.txt file is not present then get the envs
extracted from built u-boot.
The main question for above item - how and where to extract this file?
- The most feasible would be to extend do_compile of u-boot.inc
to run get_default_envs.sh script there (as it builds all
the kind of u-boot variants/binaries).
- Then "export" those generated *.txt files to [*] recipe.
What would be the best way?
Via ${DEPLOYDIR} ? Install it on /boot directory (exported by
u-boot) ?
> >
> > 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.
>
> Sounds about good. I think this approach fails with NAND, so be
> careful there.
>
> > 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
> Or add some build-time option to build it with blank default env. Then
> you can apply your file-based approach, the setenv would be
> board-agnostic and it should do I guess ?
>
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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images
2018-05-09 11:45 ` Lukasz Majewski
@ 2018-05-09 11:57 ` Marek Vasut
0 siblings, 0 replies; 25+ messages in thread
From: Marek Vasut @ 2018-05-09 11:57 UTC (permalink / raw)
To: Lukasz Majewski, Stefano Babic
Cc: Tom Rini, Stefan Agner, OpenEmbedded Core Mailing List
On 05/09/2018 01:45 PM, Lukasz Majewski wrote:
> Hi Marek, Stefano,
>
>> On 05/03/2018 08:15 PM, Lukasz Majewski wrote:
>>> 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
>
> I've looked a bit more on the topic, and I do have some further
> questions:
>
> 1. It seems like u-boot is compiled at least twice - once when
> do_comiple() is invoked in u-boot.inc (here we support multiple
> configs, and targets) and in u-boot-fw-utils (also u-boot-mkimage
> compiles u-boot for sandbox_defconfig).
>
> It seems like the synchronization of the built package (and envs) is
> ensured with u-boot-common_2018.03.inc package.
>
> 2. It seems like it would be feasible to have a separate recipe -
> u-boot-envs_2018.03.bb [*] which would:
>
> - Use u-boot-env.txt provided as an external file (from e.g.
> SRC += "./file/u-boot-env.txt"). This is the approach similar
> to
> https://github.com/webosose/meta-webosose/blob/master/meta-webos-raspberrypi/recipes-bsp/u-boot/u-boot-env.bb
>
> - If above input *.txt file is not present then get the envs
> extracted from built u-boot.
>
> The main question for above item - how and where to extract this file?
>
> - The most feasible would be to extend do_compile of u-boot.inc
> to run get_default_envs.sh script there (as it builds all
> the kind of u-boot variants/binaries).
>
> - Then "export" those generated *.txt files to [*] recipe.
> What would be the best way?
>
> Via ${DEPLOYDIR} ? Install it on /boot directory (exported by
> u-boot) ?
Compile the fw env utils per-machine for now and in parallel add option
to compile it with blank env and use env from file into upstream u-boot
fwutils ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2018-05-09 12:09 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.