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 | |
| parent | 3e734e822b5167110979d60d6cc7da8ca01cdf09 (diff) | |
| download | mtk-20170518-78a5d25dca5de9b00890e7a414a6e423c4ba6e19.zip mtk-20170518-78a5d25dca5de9b00890e7a414a6e423c4ba6e19.tar.gz mtk-20170518-78a5d25dca5de9b00890e7a414a6e423c4ba6e19.tar.bz2 | |
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>
| -rwxr-xr-x | scripts/om-fwupgradecfg-gen.sh | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/scripts/om-fwupgradecfg-gen.sh b/scripts/om-fwupgradecfg-gen.sh index dad70b2..4a70940 100755 --- a/scripts/om-fwupgradecfg-gen.sh +++ b/scripts/om-fwupgradecfg-gen.sh @@ -24,7 +24,7 @@ case $CE_TYPE in MAX_PART_SIZE=7168 KERNEL_FLASH_ADDR=0x1c0000 FLASH_BS=262144 - MD5_SKIP_BLOCKS=1 + MD5_SKIP_BLOCKS=4 SIZE_FACTOR=1 SIZE_FORMAT="%d" ;; |