Quote:
Originally Posted by twobob
...
Each write cycle is worth 2Mb. so 300 Mb = 150 loops...
each cycle takes about 30 seconds. so 4MB per minute.
681.6Mb = ~341 loops = 170.4 minutes = 2.84 hours 
keep waiting... when it's done - reboot.
... |
I was thinking we can speed this up in some cases, such as debricking by replacing a damaged partition with a clean copy of the SAME VERSION. All we have to do is modify k3_flasher to READ and compare blocks (perhaps 2MB blocks) and SKIP them unless there is a mismatch. Only write blocks that changed. Reads should be MUCH faster than block erase and write cycles.
Also, it might be worth verifying that the write blocks are aligned to erase block boundaries. If the start address causes an offset, it could be doing slow read/erase/write cycles across the boundaries. Better to align to erase block boundaries to skip the otherwise unneeded read (if they occur). This can be a huge problem for flash drives formatted on XP (the 53 sector/track size) not aligned to flash erase block boundaries. Not sure if a problem here, but worth investigating.
EDIT: What I did not make clear is that each block gets erased and rewritten TWICE when misaligned. Each erase block gets a read/erase/write for the tail end of an overlapped data block, plus ANOTHER read/erase/write for the beginning of the next overlapped data block. Alignment can eliminate not only ALL reads, but also a much slower extra erase and write. It can more than double the speed even when rewriting ALL blocks, compared to misaligned writes.
Whatever the case, more than two hours is too long (especially if it is draining the kindle battery). We should at least skip the write if the block does not need to change. Fast debricking using this would require reflashing an undamaged copy of your bricked firmware version, but that can be arranged.