Commit Graph

2 Commits

Author SHA1 Message Date
Sven Eckelmann
3599ea5263 images: Fix sysupgrade.tar for devices with NOR flash
The NOR flash rootfs images stored in a sysupgrade.tar must end with the
JFFS2 marker. Otherwise, devices like OpenMesh A42/A62 are not able to
calculate the md5sum of the fixed squashfs part and store it inside the
u-boot-env.

But the commit ee76bd11bb ("images: fix boot failures on NAND with small
sub pages") adds up to 1020 0x00 bytes after the 0xdead0de EOF marker. The
calculated md5sum will be wrong due do this change and u-boot will fail to
boot the newly flashed device with a message like:

  Validating MD5Sum of 'vmlinux'...
  Passed!
  Validating MD5Sum of 'rootfs'...
  Failed!
      583a1b7b54b8601efa64ade42742459b != 8850ee812dfd7638e94083329d5d2781

  Data validation failed!

and boot the old image again.

Since the original change should not change the behavior of NOR images,
just check for the deadc0de marker at the end of the squashfs-jffs2 image
do avoid the problematic behavior for these images.

Fixes: ee76bd11bb ("images: fix boot failures on NAND with small sub pages")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
2020-12-22 19:11:50 +01:00
Jonas Gorski
ee76bd11bb images: fix boot failures on NAND with small sub pages
SquashFS has a minimum block size of at least 1k, so we need to make
sure the last data block is also at least that big.

This is not an issue on NOR or SD CARD devices, since their rootfs
partitions go all the way to the end of the usable space.

But on NAND with ubiblock, the rootfs partition will be the exact space,
rounded up to LEB size. Unfortunately, some NAND chips with small sub
pages have a LEB size of x.5 kiB. This can cause the the last data block
to be less than 1k, which will cause the last block to be inaccessible,
causing boot failures as seen on MR24:

[    1.532960] block ubiblock0_3: created from ubi0:3(rootfs)
[    1.538457] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem
[    1.552847] SQUASHFS error: squashfs_read_data failed to read block 0x621472
[    1.559896] squashfs: SQUASHFS error: unable to read id index table
[    1.566474] VFS: Cannot open root device "(null)" or unknown-block(254,0): error -5

Since on most NOR devices, the start of the squashfs partition is not
aligned. Since the start of the rootfs_data partition there is dependend
on the SquashFS size, we cannot just always pad it, as the padding could
creep into the rootfs_data partition, breaking jffs2.

So fix this by ensuring a squashfs rootfs is always a multiple of 1k
only for UBI and NAND sysupgrade images.

Fixes  without affecting NOR devices.

Tested-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
2019-09-14 11:43:19 +02:00