flash ubi image instead of ubi volume

[viper viper]

i need to update entire ubi container instead of single volume on top of mtd device.

so my config is

images: (
        {
            filename = "rootfs.ubi";
            device = "/dev/mtd5";
            type = "flash";
        }

i ran swupdate from ramfs, with detached mtd5 device. but after flashing i cannot attach it due errors:

~ # ubiattach -p /dev/mtd5
[ 1285.795805] ubi0: attaching mtd5
[ 1285.828056]  NAND bbt detect factory Bad block at 4e60000
[ 1285.924676] ubi0 error: ubi_attach: bad image sequence number 1584228876 in PEB 362, expected 138540538
[ 1285.928417] Erase counter header dump:
[ 1285.932116] magic          0x55424923
[ 1285.935825] version        1
[ 1285.938758] ec             2
[ 1285.941689] vid_hdr_offset 2048
[ 1285.944873] data_offset    4096
[ 1285.948072] image_seq      1584228876
[ 1285.951785] hdr_crc        0x1844c26
[ 1285.955403] erase counter header hexdump:
[ 1285.959463] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd5, error -22
ubiattach: error!: cannot attach "/dev/mtd5"
           error 22 (Invalid argument)


what did i missing?

[Stefano Babic]

Hi "Viper",

If you update a full UBI container, you must be take care about all
options to create volumes and to "ubinize" the result. They must match
your NAND result. You cannot rely anymore that the target does this for
you, this is done when single UBI volumes are updated. SWUpdate just
take your ubinized image and write it into the flash, as mtd-utils can do.

The issue above seems due to a mismatch between the NAND and the build
of the image.

Best regards,
Stefano Babic

[viper viper]

>The issue above seems due to a mismatch between the NAND and the build
>of the image.

impossible. this rootfs.ubi is build for this board, for this nand.

in addition, i can flash this image successfuly via vendor bootrom

&& vendor uboot (fastboot command). this exactly image runs device in the first place.

[Stefano Babic]

On 03.08.24 13:10, viper viper wrote:
> >The issue above seems due to a mismatch between the NAND and the build
> >of the image.
>
> impossible.

Nothing is impossible.

> this rootfs.ubi is build for this board, for this nand.
> in addition, i can flash this image successfuly via vendor bootrom

You should test with mtd utils, like with nandwrite and check if it
works. SWUpdate / mtd-utils just write an image to the flash without any
processing. Or you analyze what vendor bootrom to check if something
different is done, it cannot be excluded.

> && vendor uboot (fastboot command).

fastboot is not to write to flash, it is a protocol (mainly) over USB.

Best regards,
Stefano Babic

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/07b26642-e7bd-4c86-ace1-fefbce66ca46n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/07b26642-e7bd-4c86-ace1-fefbce66ca46n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[viper viper]

> You should test with mtd utils, like with nandwrite and check if it
works

thanks, i will

> fastboot is not to write to flash, it is a protocol (mainly) over USB.

i mean, i can successfuly flash this very rootfs.ubi via vendor implemented "fastboot flash" command.

[viper viper]

>You should test with mtd utils, like with nandwrite and check if it
>works. SWUpdate / mtd-utils just write an image to the flash without any
>processing. Or you analyze what vendor bootrom to check if something
>different is done, it cannot be excluded.

so,  flash_erase + nandwrite works like a charm, ubi image attached, volumes mounted.

flashing via swupdate still leads to broken ubi. maybe there is a bug in flash_handler.

trying to figure it out.

[viper viper]

so, the problem is: flash_handler erases only that part of nand, which will be oqqupied by flashing image (img->size)

        if(flash_erase_sector(mtdnum, img->seek, img->size)) {
                ERROR("I cannot erasing %s",
                        img->device);
                return -1;
        }

this would be enough if image contains only "static" data, like bootloaders, squashfs, etc. BUT! my image contains ubifs part with autoresize option, which cannot be appied on dirty nand.

i assume we need some kind of "full erase" option with patch like this
-         if(flash_erase_sector(mtdnum, img->seek, img->size)) {

+        if(flash_erase_sector(mtdnum, img->seek, mtd->size)) {

Stefano, what do u think?

[viper viper]

sry, typo:

with  "full erase" flag the patch will be look like this

+        if(flash_erase_sector(mtdnum, 0, mtd->size)) {

obviously, this will conflict with "offset" option

[Stefano Babic]

Hi Viper,

On 17.08.24 11:48, viper viper wrote:
> so, the problem is: flash_handler erases only that part of nand, which
> will be oqqupied by flashing image (img->size)
>
>         if(flash_erase_sector(mtdnum, img->seek, img->size)) {
>                 ERROR("I cannot erasing %s",
>                         img->device);
>                 return -1;
>         }
>
> this would be enough if image contains only "static" data, like
> bootloaders, squashfs, etc. BUT! my image contains ubifs part with
> autoresize option, which cannot be appied on dirty nand.

Then this use case is unsupported.

> i assume we need some kind of "full erase" option with patch like this
> -         if(flash_erase_sector(mtdnum, img->seek, img->size)) {
> +        if(flash_erase_sector(mtdnum, img->seek, mtd->size)) {
>
> Stefano, what do u think?
>

You have already answered that this breaks in case of offset. One way is
to add a new property to the handler to pass the flag to force the erase
of the whole MTD. In case "offset" is passed, and this is not sector
aligned, the correct behavior is a read-erase-modify-write, restoring
data before img->seek.

Best regards,
Stefano Babic

> https://groups.google.com/d/msgid/swupdate/07b26642-e7bd-4c86-ace1-fefbce66ca46n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/07b26642-e7bd-4c86-ace1-fefbce66ca46n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/07b26642-e7bd-4c86-ace1-fefbce66ca46n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/07b26642-e7bd-4c86-ace1-fefbce66ca46n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/617238a0-8c95-4bac-bb30-641183fcfec2n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/617238a0-8c95-4bac-bb30-641183fcfec2n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================