11-12-2021, 11:08 AM
(11-12-2021, 08:48 AM)lot378 Wrote: and your goal here is data recovery rather than figuring out how it went wrong.
It's both. I want to know what happened. And I am still very skeptical that it was due to nand wear. There were none of the gradual slowdown & steadily worsening problems that Tesla & Raspberry Pi users have reported. And I have seen many reports of SD cards failing in the same way after little or no use. I think people just assume all failures are due to nand wear and don't realize that firmware bugs can axe all their data without warning.
Currently waiting on testbed hardware to arrive so I can start probing it.
BTW, emmc spec section 6.6.33 - Dynamic Capacity Management - The host+card combination are supposed to cooperate to gradually reduce the reported size of the medium as blocks wear out & need to be retired. I don't get any web search results about whether linux supports this yet, so maybe it doesn't. It should. If not, the DYNCAP_NEEDED field, showing the number of groups that need to be released (and easily readable with mmc-utils) will just keep incrementing, which is another sign of flash wear, or not.
Code:
sudo mmc extcsd read /dev/mmcblk2 | grep DYNCAP
Also, here is some interesting reading on JTAG.
https://blog.senr.io/blog/jtag-explained
The emmc itself should be open source. It is too important a component to be left secret & proprietary. We should be running open mmc firmware code with everything fully documented.