scripts/dump.sh: Potentially typo address

[bishopdynamics]

At scripts/dump.sh:22 the address given is 0x889EA000 but when I try that I get an error:

ERR(../drivers/usb/gadget/v2_burning/v2_common/optimus_download.c)L694:imgSz 0x889ea000 out of cap 0x859ea000

I tried changing address to 0x859ea000, and the resulting file appears to be a valid ext4 filesystem, and is mountable without errors, so I think that might be the right address to use.

cheers

[frederic]

Thanks for sharing the info. This value is actually the data partition size. It seems it varies depending on device/firmware version. On a different device, I had to use the value you suggested to dump the data partition. Here are the version numbers :

• 0x889EA000 : App Version 0.24.107 - OS Version 6.3.29 - U-Boot 2015.01 (Jan 21 2022 - 08:55:34 - v1.0-57-gec3ec936c2)
• 0x859EA000 : App Version 0.44.43 - OS Version 6.1.16

I think this size might be cumbersome to obtain at runtime to make a generic script. Except if we find some bulkcmd to dump the partition table and get the actual data partition size.

[bishopdynamics]

It looks like the update binary does return a non-zero exit code when we have the wrong partition size, so this is how I handled it:

echo "Dumping partition: data"
# data partition size is either 0x889EA000 (4476752 sectors) or 0x859EA000 (4378448 sectors)
echo "Trying data partition size: 0x889EA000"
$UPDTOOL mread store data normal 0x889EA000 "${BACKUP_DIR}/data.ext4" || {
    echo "Trying other data partition size: 0x859EA000"
    $UPDTOOL mread store data normal 0x859EA000 "${BACKUP_DIR}/data.ext4" || {
        echo "Failed to backup data partition at either of known sizes: 0x889EA000, 0x859EA000"
        exit 1
    }
}

Of course, this assumes there are only two valid partition sizes.