Hi emmc bricked folks,
this is a emmc partition scanner which is mainly usable for emmc bricked phones (only Samsung?).
It's a companion software for my xda thread: "PIT file method to revive your phone from a MMC_CAP_ERASE brick".
The tools are started via "install zip" from a recovery.
emmc_scan_all_partitions_once.zip
emmc_scan_all_partitions_infinitely.zip
these allow fast scanning of all blocks of all emmc partitions in 1MiB steps.
The main purpose is to access each emmc block to find any bricked block in the partitions after repartitioning.
The "infinitely" variant runs checks infinitely, which may help to find emmc brick effects which only occur sporadically (if such effect really exists). Run this as long as you want. Reboot to finish.
If this freezes the last partition shown may have a bricked block inside.
emmc_find_brick_start.zip
emmc_find_brick_end.zip
these scan the whole emmc device.
emmc_find_brick_start starts scanning from the beginning of the device upward.
emmc_find_brick_end searches the end of the device and then scans downward.
If this runs up to the end or down to zero (showing a message with "completed --> OK"), no bricked block was found.
If it freezes, the block shown last with "..." at end of line is the first bricked block in that direction.
The line before with "-> ok" is the first usable block before/after the brick.
The tools above only read bytes from the emmc block devices, so it generally shouldn't harm anything.
Don't worry about the term "flash", because it doesn't really flash, it's only using the update mechanism of the recovery (edify scripting).
This is called fake flashing.
emmc_scan_write.zip
this is a very experimental scanner.
It is for experiments on phones, which have no obvious bad blocks in the partitions (scanned by scan_all_partitions_infintely without freeze) but still freeze randomly (without having problems with apps etc.).
It continuously creates a file of 10MB and deletes it after that.
The theory behind that:
* the wear leveler will assign different blocks each time the file is created
* the wear leveler may get a problem when assigning blocks to the file
* then it will freeze
* hopefully, if the file isn't deleted it will claim the bricked block(s), so they are not assigned again
* this will allow to isolate the blocks
* to keep those files containing bricked blocks, they are placed on the internal sd
note: the running counter is the amount written yet. It is not related to the partition size.
important:
The internal sd is determined by an environment variable EXTERNAL_STORAGE.
Despite it's name it should be the *internal* sd, instead SECONDARY_STORAGE contains the external sd.
I hope, this applies to all android OSes...please report if not.
For now you shouldn't use the tool, until you checked this:
adb shell set
If EXTERNAL_STORAGE isn't your *internal* sd, the tool will not help, because it writes on the external sd.
Some users wonder why it works so fast.
That's because it doesn't read each and every byte (like dd command or the "emmc brickbug check" app) but instead jumps in reasonable steps and in each step reads only the first byte of the chunk.
I think, reading each byte is not needed, because the flash memory is always used blockwise and the wear leveler (which has the bug) is working on the block level not the byte level. So a bricked block should always affect each byte in this block, which means reading one byte should be enough.
I choose steps of 1MiB (1024x1024 bytes), mainly because it's like parted etc., but unfortunately 1MB (1000x1000) doesn't work well so I was forced to use the MiB steps and calculated the other (currently rounded). May be the internal wear leveler block size is smaller (e.g. 256kiB = 256x1024 bytes), but it seems that the affected block area is always bigger than 1MiB. But I may rethink this decision...
when it's running slow
The scan method is very fast, I think the complete scan of the internal emmc should be done in under a minute, add several minutes for the external sd if scanning all partitions.
That said, if you get much slower performance, you probably hit an emmc bricked block. It seems the emmc brick can show up in two ways, either completely freezing the device or returning an error after a timeout which slows down the scan process significantly.
The word "FREEZE" in the descriptions above should be replaced by "freeze or slowdown".
So if it slows down, note the numbers at this point, like if the emmc freezes.
It's possible to use the scanner manually in adb (also from a terminal in the gui).
Extract file emmc-scan from one of the zips, put somewhere (=PATHTOSCANNER).
Eventually use
to make it executable (depend on how you extract it).
usage for find-brick-start:
usage for find-brick-end:
with e.g. MMCBLOCKDEVICE = /dev/block/mmcblk0 for N7000, etc.
example session:
to scan all partitions of all flash memory devices automatically (using my algorithm to find the flash devices) simply use:
for usage description use:
which outputs something like this:
To use the scanner with a terminal app in the android gui,
you ommit "adb shell",
so the example session would look like this:
There were several problems to be solved, mainly:
* seek, setpos functions not working for big partitions (only 4 byte numbers)
* dd command with skip= also not working for big partitions
* finding the emmc device(s)
* finding all emmc partitions to be scanned
* finding the end of a partition without working seek/setpos and without touching a block
* showing live outputs from the program in recovery (unfortunately doesn't work with \r)
the zips are now signed (but see "known bugs" section below).
currently tested on:
* Samsung Galaxy Note N7000
please report if it works for your phone model (e.g. finds the correct partitions) if it's not on the compatibility list.
known bugs:
* the signed zips may not work with stock recovery (1 report but no reports after changing the signing method)
Disclaimer: of course I cannot give any guaranties.
Please don't copy or link directly to an attachment. Link to the whole thread instead.
I will probably update this first post and the attachments frequently, at least until all calms down.
this is a emmc partition scanner which is mainly usable for emmc bricked phones (only Samsung?).
It's a companion software for my xda thread: "PIT file method to revive your phone from a MMC_CAP_ERASE brick".
The tools are started via "install zip" from a recovery.
emmc_scan_all_partitions_once.zip
emmc_scan_all_partitions_infinitely.zip
these allow fast scanning of all blocks of all emmc partitions in 1MiB steps.
The main purpose is to access each emmc block to find any bricked block in the partitions after repartitioning.
The "infinitely" variant runs checks infinitely, which may help to find emmc brick effects which only occur sporadically (if such effect really exists). Run this as long as you want. Reboot to finish.
If this freezes the last partition shown may have a bricked block inside.
emmc_find_brick_start.zip
emmc_find_brick_end.zip
these scan the whole emmc device.
emmc_find_brick_start starts scanning from the beginning of the device upward.
emmc_find_brick_end searches the end of the device and then scans downward.
If this runs up to the end or down to zero (showing a message with "completed --> OK"), no bricked block was found.
If it freezes, the block shown last with "..." at end of line is the first bricked block in that direction.
The line before with "-> ok" is the first usable block before/after the brick.
The tools above only read bytes from the emmc block devices, so it generally shouldn't harm anything.
Don't worry about the term "flash", because it doesn't really flash, it's only using the update mechanism of the recovery (edify scripting).
This is called fake flashing.
emmc_scan_write.zip
this is a very experimental scanner.
It is for experiments on phones, which have no obvious bad blocks in the partitions (scanned by scan_all_partitions_infintely without freeze) but still freeze randomly (without having problems with apps etc.).
It continuously creates a file of 10MB and deletes it after that.
The theory behind that:
* the wear leveler will assign different blocks each time the file is created
* the wear leveler may get a problem when assigning blocks to the file
* then it will freeze
* hopefully, if the file isn't deleted it will claim the bricked block(s), so they are not assigned again
* this will allow to isolate the blocks
* to keep those files containing bricked blocks, they are placed on the internal sd
note: the running counter is the amount written yet. It is not related to the partition size.
important:
The internal sd is determined by an environment variable EXTERNAL_STORAGE.
Despite it's name it should be the *internal* sd, instead SECONDARY_STORAGE contains the external sd.
I hope, this applies to all android OSes...please report if not.
For now you shouldn't use the tool, until you checked this:
adb shell set
If EXTERNAL_STORAGE isn't your *internal* sd, the tool will not help, because it writes on the external sd.
Some users wonder why it works so fast.
That's because it doesn't read each and every byte (like dd command or the "emmc brickbug check" app) but instead jumps in reasonable steps and in each step reads only the first byte of the chunk.
I think, reading each byte is not needed, because the flash memory is always used blockwise and the wear leveler (which has the bug) is working on the block level not the byte level. So a bricked block should always affect each byte in this block, which means reading one byte should be enough.
I choose steps of 1MiB (1024x1024 bytes), mainly because it's like parted etc., but unfortunately 1MB (1000x1000) doesn't work well so I was forced to use the MiB steps and calculated the other (currently rounded). May be the internal wear leveler block size is smaller (e.g. 256kiB = 256x1024 bytes), but it seems that the affected block area is always bigger than 1MiB. But I may rethink this decision...
when it's running slow
The scan method is very fast, I think the complete scan of the internal emmc should be done in under a minute, add several minutes for the external sd if scanning all partitions.
That said, if you get much slower performance, you probably hit an emmc bricked block. It seems the emmc brick can show up in two ways, either completely freezing the device or returning an error after a timeout which slows down the scan process significantly.
The word "FREEZE" in the descriptions above should be replaced by "freeze or slowdown".
So if it slows down, note the numbers at this point, like if the emmc freezes.
It's possible to use the scanner manually in adb (also from a terminal in the gui).
Extract file emmc-scan from one of the zips, put somewhere (=PATHTOSCANNER).
Eventually use
Code:
chmod 555 PATHTOSCANNER/emmc-scanusage for find-brick-start:
Code:
PATHTOSCANNER/emmc-scan -p -f MMCBLOCKDEVICEusage for find-brick-end:
Code:
PATHTOSCANNER/emmc-scan -p -b MMCBLOCKDEVICEwith e.g. MMCBLOCKDEVICE = /dev/block/mmcblk0 for N7000, etc.
example session:
Code:
unzip 120824-221256-emmc_find_brick_end.zip emmc-scan
adb root
adb push emmc-scan /cache/
adb shell chmod 555 /cache/emmc-scan
adb shell /cache/emmc-scan -p -f /dev/block/mmcblk0to scan all partitions of all flash memory devices automatically (using my algorithm to find the flash devices) simply use:
Code:
adb shell /cache/emmc-scanfor usage description use:
Code:
adb shell /cache/emmc-scan -Hwhich outputs something like this:
Code:
usage:
emmc-scan [-f | -b] [-a] [-p] [DEVICE | PARTITION]
emmc-scan -w [-a] [-p] DIRECTORY
emmc-scan -H
operations:
-f forward, scan from begin to end of device
-b backward, scan from end to begin of device
-w write to writable partitions (fill with small files)
targets
-a scan all partitions
DEVICE device to be scanned (e.g. /dev/block/mmcblk0 )
PARTITION partition to be scanned (e.g. /dev/block/mmcblk0p10 )
DIRECTORY directory to be filled with files (e.g. /data, /sdcard )
other:
-p print position while scanning
-c print CR after position
-H output this help text
comments:
- scanning/writing is done in 0 byte steps (0 MiB)
- multiple devices/partitions/-a can be given with different options
- devices are scanned with all options given before
examples:
emmc-scan -b mmcblk0p10
scan /dev/block/mmcblk0p10 backward
emmc-scan -f -a -b /dev/block/mmcblk0
scan all partitions forward and mmcblk0 backwardTo use the scanner with a terminal app in the android gui,
you ommit "adb shell",
so the example session would look like this:
Code:
chmod 555 /cache/emmc-scan
/cache/emmc-scan -p -f /dev/block/mmcblk0There were several problems to be solved, mainly:
* seek, setpos functions not working for big partitions (only 4 byte numbers)
* dd command with skip= also not working for big partitions
* finding the emmc device(s)
* finding all emmc partitions to be scanned
* finding the end of a partition without working seek/setpos and without touching a block
* showing live outputs from the program in recovery (unfortunately doesn't work with \r)
the zips are now signed (but see "known bugs" section below).
currently tested on:
* Samsung Galaxy Note N7000
please report if it works for your phone model (e.g. finds the correct partitions) if it's not on the compatibility list.
known bugs:
* the signed zips may not work with stock recovery (1 report but no reports after changing the signing method)
Disclaimer: of course I cannot give any guaranties.
Please don't copy or link directly to an attachment. Link to the whole thread instead.
I will probably update this first post and the attachments frequently, at least until all calms down.
Last edited:
