diff options
| author | Sven Eckelmann <sven.eckelmann@openmesh.com> | 2018-09-03 09:58:42 +0200 |
|---|---|---|
| committer | John Crispin <john@phrozen.org> | 2018-09-10 10:01:58 +0200 |
| commit | 78a5d25dca5de9b00890e7a414a6e423c4ba6e19 (patch) | |
| tree | 31465f7f9d2bc9c14e6152a0ca17d73c54afb4fa /scripts/ubinize-image.sh | |
| parent | 3e734e822b5167110979d60d6cc7da8ca01cdf09 (diff) | |
| download | upstream-78a5d25dca5de9b00890e7a414a6e423c4ba6e19.tar.gz upstream-78a5d25dca5de9b00890e7a414a6e423c4ba6e19.tar.bz2 upstream-78a5d25dca5de9b00890e7a414a6e423c4ba6e19.zip | |
ar71xx: Skip more hashed blocks for OM2P(-HS) 64k variant
The OM2P(-HS)v4 got a variant which uses a slightly different flash. The
standard versions used a flash with 256KB blocks which is no longer
available. The replacement flash uses a flash with 64K blocks.
The padding for the image rootfs is already for 64K and 256K and thus can
be flashed on the device without any problems. Unfortunately, the
bootloader will check $rootfs_size (rounded down to the nearest 64k block)
minus 1x 64k. But it is now possible that the new JFFS2 rootfs_data starts
even earlier and modifies the checked region. The check will then fail and
the backup image (when available) will be booted.
Just setting it to the same number of skipped blocks as other 64K models
avoids this problem.
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Diffstat (limited to 'scripts/ubinize-image.sh')
0 files changed, 0 insertions, 0 deletions