This is a worked example of using the copycmp.sh script and the dc3dd utility attached to post:
https://www.mobileread.com/forums/sho...6&postcount=27
In this example, I am doing device-to-file copy/compare and in the problem situation presented in this thread, the use will be file-to-device.
This example is run on a PW-1 with USBnetworking access (ssh terminal) to the command line as user: 'root'.
My ssh setup includes a hosts file entry for: 'ken1' and an ssh config file address short-cut: 'kpw' using pubkey authentication (no manual login).
(All of which I described in one of my threads on using kindle/ssh.)
Copy the tar-ball from the PC to the root of the Kindle's USB storage:
Code:
$ scp copycmp.tar.gz kpw:/mnt/us
copycmp.tar.gz 100% 264KB 264.1KB/s 00:00
Open an ssh terminal to the 'remote' (about 2 feet) Kindle PW-1:
Code:
$ ssh kpw
Welcome to Kindle!
#################################################
# N O T I C E * N O T I C E * N O T I C E #
#################################################
Rootfs is mounted read-only. Invoke mntroot rw to
switch back to a writable rootfs.
#################################################
[root@kindle root]#
Unpack the release archive in the USB storage root:
Code:
[root@kindle root]# cd /mnt/us
[root@kindle us]# tar -xzf copycmp.tar.gz
The script requires the full featured dd utility from (Debian) CoreUtils package.
Check that it is going to run on this particular Kindle:
Code:
[root@kindle us]# cd copycmp
[root@kindle copycmp]# arm/dd --help
Usage: arm/dd [OPERAND]...
or: arm/dd OPTION
Copy a file, converting and formatting according to the operands.
- - - - -
Looks like that will work.
Return to root's home directory.
Check its real full pathname:
Code:
[root@kindle copycmp]# cd
[root@kindle root]# pwd
/tmp/root
[root@kindle root]# df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 32768 268 32500 1% /var
The 'tmpfs' filesystem type is implemented in ram and everything in it will 'go away' when the Kindle is rebooted.
The script uses space in the /tmp tree for its block sized working files.
Shown above is that tree portion has about 32Mbytes free - more than enough.
We will run the script (and it will run dd) from the current directory in ram.
Just copy the two things we need to our current location (the period at the end of the line is part of the command).
Code:
[root@kindle root]# cp /mnt/us/copycmp/copycmp.sh /mnt/us/copycmp/arm/dd .
[root@kindle root]# ls
copycmp.sh dd
For this example, the contents of the 'diags' partition will be copied to a file of all zeros.
The file needs to be the same size as the 'diags' partition.
Linux makes that information available in the /proc tree and a bit of command line math converts from 1K blocks to bytes.
Code:
[root@kindle root]# cat /proc/partitions
major minor #blocks name
7 0 1398776 loop0
7 2 72 loop2
7 3 564 loop3
7 4 67788 loop4
7 5 32 loop5
7 6 1884 loop6
7 7 5352 loop7
179 0 1921024 mmcblk0
179 1 358400 mmcblk0p1
179 2 65536 mmcblk0p2
179 3 65536 mmcblk0p3
179 4 1398784 mmcblk0p4
We are only interested in the byte-size of p2, so:
Code:
[root@kindle root]# set $(cat /proc/partitions | grep mmcblk0p2) ; echo $(($3*1024))
67108864
Make sure we have enough free space on USB storage for our output files:
Code:
[root@kindle root]# df -h /mnt/us
Filesystem Size Used Available Use% Mounted on
fsp 1.3G 166.7M 1.2G 12% /mnt/us
Since the copycmp script will neither truncate not extend the destination, we need to have a pre-existing destination file for the partition's contents:
Code:
[root@kindle root]# dd if=/dev/zero of=/mnt/us/blk0p2.img bs=67108864 count=1
1+0 records in
1+0 records out
67108864 bytes (64.0MB) copied, 96.629396 seconds, 678.2KB/s
Time to run the copycmp script:
Code:
[root@kindle root]# time ./copycmp.sh /dev/mmcblk0p2 /mnt/us/blk0p2.img
Termination on block boundary. (0+0.0+0)
Blocks: 16384, plus Bytes: 0, Total skips: 10660, Total bytes: 67108864
real 8m 51.76s
user 3m 27.99s
sys 4m 7.89s
Normally, you would not use the 'time' function, you would just run the script.
Note that we also learn that the partition has 10,660; 4096 byte blocks of zeros in it.
While the script was executing, I logged into the Kindle with another ssh terminal session to check on cpu usage:
Code:
[root@kindle us]# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
- - - - -
root 17943 6.9 0.2 2332 644 pts/0 RN+ 00:46 0:22 /bin/sh ./copycmp.sh /dev/mmcblk0p2 /mnt/us/blk0p2.img
- - - - -
The eMMC flash is so slow to program that we are using less than 10% of the cpu time to run the script.
The copycmp script has already done a write-readback-compare of each block it wrote.
But just for test purposes, we will run the command again.
Since the file should be a bit-wise exact copy of the partition, the script will just read and compare.
A handy feature that can save a lot of writing to the flash when just updating an image.
Again, you would probably not run the script under the timing utility:
Code:
[root@kindle root]# time ./copycmp.sh /dev/mmcblk0p2 /mnt/us/blk0p2.img
Termination on block boundary. (0+0.0+0)
Blocks: 16384, plus Bytes: 0, Total skips: 16384, Total bytes: 67108864
real 6m 36.85s
user 2m 52.15s
sys 2m 45.36s
That is the expected output.
The netBSD dc3dd utility can also do write with read-back verification (by any of several hash functions).
For comparison with the above, get a copy of it from the (opened) release tar-ball and give it a try (with a different output filename).
Code:
[root@kindle root]# cp -a /mnt/us/copycmp/arm/dc3dd .
[root@kindle root]# time ./dc3dd if=/dev/mmcblk0p2 hof=/mnt/us/blk0p2-dc3dd.img hash=sha1 ssz=4096 nwspc=on verb=on
dc3dd 7.1.614 started at 2012-10-04 01:24:05 +0717
compiled options:
command line: ./dc3dd if=/dev/mmcblk0p2 hof=/mnt/us/blk0p2-dc3dd.img hash=sha1 ssz=4096 nwspc=on verb=on
device size: 131072 sectors (probed)
sector size: 4096 bytes (set)
67108864 bytes (64 M) copied (100%), 35.4048 s, 1.8 M/s
output hashing (100%)
input results for device `/dev/mmcblk0p2':
16384 sectors in
0 bad sectors replaced by zeros
f40172decf43e08bf93724c55eb4a9c2a24a8825 (sha1)
output results for file `/mnt/us/blk0p2-dc3dd.img':
16384 sectors out
[ok] f40172decf43e08bf93724c55eb4a9c2a24a8825 (sha1)
dc3dd completed at 2012-10-04 01:24:40 +0717
real 0m 35.42s
user 0m 5.90s
sys 0m 2.31s
Hmm...
About 9 minutes for the script and about 35 seconds for the compiled dc3dd utility.
With the dc3dd utility we only get a pass/fail indication on the over-all file (or partition - it can write to devices also).
With the much slower script we (can) get block-by-block status messages on failure(s).
So it would seem that a reasonalbe approach would be to run the needed copy with dc3dd first.
If that passes its hash-sum testing, your done.
If not, then run the same update with the copycmp script and find out more details of where/what is failing.