[OE-core] [oe-core][PATCHv4] image_types.bbclass: add optional size to ubi vols

Andre McCurdy armccurdy at gmail.com
Wed Jun 20 19:07:54 UTC 2018


On Wed, Jun 20, 2018 at 8:29 AM, Tobias Olausson <TOl at hms.se> wrote:
> Hey,
>
> Sorry for top posting. I have done some testing of this during the day, and it seems that this only works if you run "export MKUBIFS_ARGS_foo" and similar in whichever config file contains those settings (such as a machine conf).
>
> I would have preferred a combined shell/python solution, but that seems to be trickier than I thought, since there is code in place that looks for IMAGE_CMD_multiubi specifically (in image.bbclass), and I have not been able to override that. Any ideas of making this work without the export hack are welcome.

The general approach would probably be to use a single bitbake
variable with delimiters and then have the shell script split it. It's
not trivial though (especially since MKUBIFS_ARGS would need to
continue to be defined without delimiters in the non-multiubi case).

But anyway, the original multiubi code was merged without questioning
this so questioning it now is really just nitpicking. Either multiubi
doesn't actually have any users or they are all smart enough to
realise that these variables need to be exported to make them work.

(RP, note that you currently have the buggy v3 version of this patch
in master-next rather than the v4).

>
> Cheers,
>
>  Tobias Olausson
>  Development Engineer
>  HMS Industrial Networks AB
>
>
> From: Andre McCurdy <armccurdy at gmail.com>
> Sent: Tuesday, June 19, 2018 8:33 PM
> To: Tobias Olausson
> Cc: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][PATCHv4] image_types.bbclass: add optional size to ubi vols
>
>
> On Tue, Jun 19, 2018 at 8:09 AM, Tobias Olausson <TOl at hms.se> wrote:
>> From 1d15f0d3c516351e6540a912367bcb22f9c25bbf Mon Sep 17 00:00:00 2001
>> From: Tobias Olausson <tol at hms.se>
>> Date: Mon, 18 Jun 2018 15:01:53 +0200
>> Subject: [oe-core][PATCHv4] image_types.bbclass: add optional size to ubi vols
>>
>> Instead of hard coding the ubi volume to be just large enough to fit the
>> root file system, one can use a variable to set a preferred size.
>>
>> Signed-off-by: Tobias Olausson <tol at hms.se>
>> ---
>>  meta/classes/image_types.bbclass | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
>> index 00a00d318f..2a0a7994c9 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -164,10 +164,22 @@ multiubi_mkfs() {
>>                 local vname="_$3"
>>         fi
>>
>> +       # Set UBI_VOL_SIZE (for regular ubi) or UBI_VOL_SIZE_vname for multiubi
>> +       if [ -z "${vname}" ]; then
>> +               local ubi_vol_size=${UBI_VOL_SIZE}
>> +       else
>> +               eval local ubi_vol_size=\"\$UBI_VOL_SIZE${vname}\"
>
> This looks odd. Presumably it (and the multiubi code from which it's
> derived) relies on the _<VOLUMENAME> suffix variables
> (MKUBIFS_ARGS_foo, UBI_VOL_SIZE_foo, etc) being exported from bitbake
> to the shell?
>
> I didn't find any discussion about that from when the original
> multiubi code was merged though. Are there any multiubi users who can
> clarify?
>
>> +       fi
>> +
>>         echo \[ubifs\] > ubinize${vname}-${IMAGE_NAME}.cfg
>>         echo mode=ubi >> ubinize${vname}-${IMAGE_NAME}.cfg
>>         echo image=${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}${IMAGE_NAME_SUFFIX}.ubifs >> ubinize${vname}-${IMAGE_NAME}.cfg
>>         echo vol_id=0 >> ubinize${vname}-${IMAGE_NAME}.cfg
>> +
>> +       if [ -n "${ubi_vol_size}" ]; then
>> +               echo "vol_size=${ubi_vol_size}" >> ubinize${vname}-${IMAGE_NAME}.cfg
>> +       fi
>> +
>>         echo vol_type=dynamic >> ubinize${vname}-${IMAGE_NAME}.cfg
>>         echo vol_name=${UBI_VOLNAME} >> ubinize${vname}-${IMAGE_NAME}.cfg
>>         echo vol_flags=autoresize >> ubinize${vname}-${IMAGE_NAME}.cfg
>> --
>> 2.17.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



More information about the Openembedded-core mailing list