Re: [PATCH] u-boot: Provide tasks to generate default U-Boot environment(s) images

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 4548 bytes --]

Hi Richard,

> On Tue, 2019-07-09 at 16:20 +0200, Lukasz Majewski wrote:
> > This change provides tasks to generate default U-Boot environment
> > images from built U-Boot (via. get_default_envs.sh script).
> > 
> > Those images then can be used to generate wic images (with e.g.
> > eMMC layout). With such approach the end user doesn't see the "CRC
> > environment" error after the first boot.
> > 
> > Moreover, those are built per MACHINE (as u-boot itself is) so then
> > could be used in SWUpdate scenarios with single tar'ed archive with
> > multiple MACHINE specific *.swu images.
> > 
> > It is also possible to adjust the *_ENVS_* variables in machine
> > specific conf file.
> > 
> > Test:
> > Newest master-next for poky repo - SHA1:
> > eb5b0a0b5e53a6e55a09e66489d3f24d0c6232ee MACHINE =
> > "beaglebone-yocto" in local.conf bitbake virtual/bootloader
> > 
> > 
> > As a result following links are available in deploy directory:
> > u-boot-env.img{_r}.
> > 
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > ---
> >  meta/recipes-bsp/u-boot/u-boot.inc | 41
> > ++++++++++++++++++++++++++++++++++++++ 1 file changed, 41
> > insertions(+)
> > 
> > diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> > b/meta/recipes-bsp/u-boot/u-boot.inc index 9a754fd09b..e0ccf1ce1f
> > 100644 --- a/meta/recipes-bsp/u-boot/u-boot.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> > @@ -331,3 +331,44 @@ do_deploy () {
> >  }
> >  
> >  addtask deploy before do_build after do_compile
> > +
> > +# Extract default envs from build U-Boot
> > +DEFAULT_UBOOT_ENVS_FILE ?= "u-boot-env"
> > +DEFAULT_ENVS ?= "${DEFAULT_UBOOT_ENVS_FILE}.txt"
> > +UBOOT_ENVS_DEFAULT ?=
> > "${DEFAULT_UBOOT_ENVS_FILE}-${MACHINE}-${PV}-${PR}.img"
> > +UBOOT_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 ${UBOOT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS} +
> > +    # Generate redundant env image
> > +    ${B}/tools/mkenvimage -r -s ${UBOOT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS} +
> > +    rm ${B}/${DEFAULT_ENVS}
> > +}
> > +
> > +addtask gen_default_envs before do_deploy 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 +
> > +     cd ${DEPLOYDIR}
> > +     ln -sf ${UBOOT_ENVS_DEFAULT} ${DEFAULT_UBOOT_ENVS_FILE}.img
> > +     ln -sf ${UBOOT_ENVS_DEFAULT}_r
> > ${DEFAULT_UBOOT_ENVS_FILE}.img_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'm not sure this second function/task is right.
> 
> DEPLOYDIR is really "owned" by the do_deploy function. As such, if you
> rerun the deploy task, it should be recreated with the right content.
> 
> By default I appreciate that deploy.bbclass doesn't wipe out the
> directory but it probably should to make it clear what the
> expectations are here.
> 
> I don't think it would cause a real problem right now, until files
> changed names or something in one of these tasks, then you'd end up
> with files you didn't expect since nothing ever cleans this directory.
> 
> Is there a reason we can't make this part of do_deploy and clean the
> directory at the start of do_deploy?

The only reason was to have more readable code - as it is easier to
read separate tasks.

Another issue is that this code shall probably be optional, so I would
need to make this feature somehow dependent on some flag ...

Any good suggestions? PACKAGECONFIG seems like a good starting point ?

> 
> Cheers,
> 
> Richard
> 
> 
> 
> 




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-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 499 bytes --]