[OE-core] [PATCH v2] image_types.bbclass: Added default argument for ubi and ubifs image creation

[Andrea Adami]

On Thu, Jun 15, 2017 at 9:52 AM, Choong, Yin Thong
<yin.thong.choong at intel.com> wrote:
> I get the information thru the official ubi and ubifs website. http://www.linux-mtd.infradead.org/faq/ubifs.html
> Besides I also tested with core-image-sato-sdk build which required more -c maximum size to create the image. If the configuration size is no sufficient error will highlight and build fail.
>
> Default -c is 2047. If build core-image-sato-sdk. -c parameter has to be increased to 8749 which will be highlight on the build error.
>
> Thanks and Regards
> Choong YinThong
>
> -----Original Message-----
> From: Andrea Adami [mailto:andrea.adami at gmail.com]
> Sent: Thursday, June 15, 2017 3:20 PM
> To: Choong, Yin Thong <yin.thong.choong at intel.com>
> Cc: OE-core <openembedded-core at lists.openembedded.org>; otc-pg-team at eclists.intel.com; Eggleton, Paul <paul.eggleton at intel.com>; Wold, Saul <saul.wold at intel.com>
> Subject: Re: [OE-core] [PATCH v2] image_types.bbclass: Added default argument for ubi and ubifs image creation
>
> On Thu, Jun 15, 2017 at 1:05 AM,  <yin.thong.choong at intel.com> wrote:
>> From: Choong YinThong <yin.thong.choong at intel.com>
>>
>> Added default argument for ubi and ubifs image creation.
>
> Hello,
>
> Is it better to error out *before* ot to create an *invalid* image?
> How can you guess such defaults?
>
> Cheers
> Andrea
>
>
>
>> MKUBIFS_ARGS and UBINIZE_ARGS both argument still able to edit in
>> local.conf
>>
>> [YOCTO #11589]
>>
>> Signed-off-by: Choong YinThong <yin.thong.choong at intel.com>
>> ---
>>  meta/classes/image_types.bbclass | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/meta/classes/image_types.bbclass
>> b/meta/classes/image_types.bbclass
>> index 7749b00..bbde08d 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -292,3 +292,12 @@ IMAGE_EXTENSION_live = "hddimg iso"
>>  # The IMAGE_TYPES_MASKED variable will be used to mask out from the
>> IMAGE_FSTYPES,  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
>>  IMAGE_TYPES_MASKED ?= ""
>> +
>> +# Default argument to create ubi and ubifs image with
>> +core-image-sato-sdk
>> +(http://www.linux-mtd.infradead.org/faq/ubifs.html)
>> +# -m 2048: tells mkfs.ubifs that the minimum input/output unit size
>> +of the flash this UBIFS image is created for is 2048 bytes (NAND page
>> +in this case); # -e 129024: logical eraseblock size of the UBI volume this image is created for; # -c 8749: specifies maximum file-system size in logical eraseblocks; this means that it will be possible to use the resulting file-system on volumes up to this size (less or equivalent); so in this particular case, the resulting FS may be put on volumes up to about 251MiB (129024 multiplied by 2047); See this section for more details.
>> +# -p 128KiB: tells ubinize that physical eraseblock size of the flash
>> +chip the UBI image is created for is 128KiB (128 * 1024 bytes); # -s 512: tells ubinize that the flash supports sub-pages and sub-page size is 512 bytes; ubinize will take this into account and put the VID header to the same NAND page as the EC header.
>> +MKUBIFS_ARGS ??= " -m 2048 -e 129024 -c 8749 "
>> +UBINIZE_ARGS ??= " -p 128KiB -m 2048 -s 512 "

Hello,

the linux-mtd faq starts with "The below example... " it's just this,
an example.

I am building ubi/ubifs images since some years and basically each
device needs to customize that in a config file:
My examples:

# UBI: max collie (14.125 = 113 PEBs)
# 14.125 x 1024 : 128 = 113 PEBs
MKUBIFS_ARGS = "-m 1 -e 130944 -c 113 -x zlib"
UBINIZE_ARGS = "-m 1 -p 131072"

# UBI: max akita (128-7 MiB = 968 PEBs)
# 121 x 1024 : 128 = 968 PEBs
MKUBIFS_ARGS = "-m 2048 -e 129024 -c 968 -x zlib"
UBINIZE_ARGS = "-m 2048 -p 131072 -s 512"

# UBI: max c7x0 (128-7 MiB = 7744 PEBs)
# 121 x 1024 : 16 = 7744 PEBs
MKUBIFS_ARGS = "-m 512 -e 15872 -c 7744 -x zlib"
UBINIZE_ARGS = "-m 512 -p 16384 -s 256"

# UBI: max poodle (64-7 MiB = 3648 PEBs)
# 57 x 1024 : 16 = 3648 PEBs
MKUBIFS_ARGS = "-m 512 -e 15872 -c 3648 -x zlib"
UBINIZE_ARGS = "-m 512 -p 16384 -s 256"

What I am saying is that with the 'defaults' you obtain almost surely
an unbootable image....
I'd prefer a prompt about the missing settings.

My 2 cents

Andrea

P.S.
There is one more issue since some time:
I use IMAGE_FSTYPES ?= "tar.gz jffs2 jffs2.sum ubi ubifs"

if the ubi image fails then bitbake aborts and the other valid rootfs
(tar.gx, jffs2,...) are not created
This happens with the first device above, having only 113 PEBs

Worth to check and maybe fire a bug.


>> --
>> 2.7.4
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core