unbrik kindle3

[knc1]

Originally Posted by hawhill

They clearly complain about the eMMC, not the USB connection. And from all the things that work via USB, I find it hard to believe that the culprit should be there.

Agreed.

Perhaps my posts where not clear, I did not suspect the USB communications.

I wanted to be certain that the USB connection was positively identified before continuing with things to be done over it.
A point in the procedure that I thought was important to include in the thread for the benefit of future readers.

The alternate (displayed by the output of blkid) was to identify those device names to avoid because they named the devices holding another operating system.

For this specific LiveCD and host machine, the devices /dev/sda and /dev/sdb

[hawhill]

Oh, that part was more directed at ed007, since he mentioned above that he still suspects the USB controller. It just doesn't match my experiences with broken USB controllers.

As an aside note: I agree that USB controllers are quite notorious for breaking due to bad electrical design. A hacker friend of mine goes as far as saying "USB simply does not work". However, I think hardware designers have learned and now have some diodes in place that care for the worst electrostatical surges. This is somewhat mandatory as nowadays, USB controllers tend to be part of the SoC (and they are for Kindles). Note that the MMC is not - however, I wouldn't go as far as recommending to desolder the eMMC chip and replace it by another. At least if you never did SMD soldering before.

[knc1]

Originally Posted by hawhill

Note that the MMC is not - however, I wouldn't go as far as recommending to desolder the eMMC chip and replace it by another. At least if you never did SMD soldering before.

That would be a challange, to re-work the board.

I do have a Kindle-3, it is open, it is lying next to the photo stand...

But I haven't had the time (yet) to photograph the MMC part and locate its datasheet. I expect it will turn out to be a Hynix part, and Hynix is real good about publishing their datasheets.

In the datasheet we should be able to learn where (if) they put the erase-block(s) that serve as the bad block table, the details for unlocking it and updating it.

The erase-blocks used for the internal bad block table are usually on their own dedicated lock chain.
And sometimes the read/erase/re-program commands are different.

Since it appears that we only have to deal with one or two blocks, it should be practical to do this "by hand" (well, with general purpose commands).

Once that bad block which the driver keeps running into is gone, the driver might just return to 'operation as normal'.

Although I also agree that the driver could probably benefit from a touch of re-writing.

At the moment, I have lost interest in this subject.
Maybe when my own K3 starts to wear-out...

[geekmaster]

Originally Posted by knc1

Although geekmaster seems to imply in his last post here that he thinks the device is not repairable; what he actually points out is not proof to the contrary, just interesting observations.

I did not say that, nor did I intend to "imply" what you are "inferring" about my comments. In fact, in a previous post I already mentioned that vfat supports bad-block mapping (if you do NOT select "quick" format) so the bad areas can be mapped out during a high-level format command. Running windows CHKDSK on the mounted USB drive can also map out bad sectors. There is no limit to how many bad blocks can be mapped out this way (unlike the 64MB device-driver spare blocks limit).

But even with bad block mapping, as I mentioned previously, there may be OTHER blocks that are near "end of life" that will not be mapped out and can reduce data retention and reliability. Just make sure you backup anything you want to keep to a reliable storage device and keep only COPIES on this mmc, and you should be fine.

Originally Posted by knc1

In the datasheet we should be able to learn where (if) they put the erase-block(s) that serve as the bad block table, the details for unlocking it and updating it.

The erase-blocks used for the internal bad block table are usually on their own dedicated lock chain. And sometimes the read/erase/re-program commands are different.

As I mentioned previously, this information is all in the GPL source code, which is more accurate than any "datasheet". It is actually what the kindle USES to access the device.

Originally Posted by knc1

At the moment, I have lost interest in this subject.

So this was a "disinterested" reply?

[ed007]

I thank all the participants for their help, I'll look for a donor.

[knc1]

Originally Posted by ed007

I thank all the participants for their help, I'll look for a donor.

It may not be time to give up on this question just yet since these things may eventually wear out.

The machine in question here is the K3, which uses a Samsung KLM4G1EEHM, eMMC chip.

Paraphrasing Samsung here:
The embedded flash management software of the chip's on-board controller manages Wear Leveling, Bad Block Management and ECC.

Ref:
http://drpbox.knetconnect.com/k3/KLMxGxxEHx.pdf
Page 4, Paragraph 4, First Sentence.

[geekmaster]

Originally Posted by knc1

It may not be time to give up on this question just yet since these things may eventually wear out.

The machine in question here is the K3, which uses a Samsung KLM4G1EEHM, eMMC chip.

Paraphrasing Samsung here:
The embedded flash management software of the chip's on-board controller manages Wear Leveling, Bad Block Management and ECC.

Ref:
http://drpbox.knetconnect.com/k3/KLMxGxxEHx.pdf
Page 4, Paragraph 4, First Sentence.
__________________
Notice: This post has not been pre-approved by GeekMaster.

Please keep your snide and snarky remarks to yourself.

Spoiler:

I clearly mentioned that I obtained my information from the GPL software for the K4 and Touch, and the Freescale Reference Manual for the iMX50 SoC. The GPL software is rather generic so that it can handle a variety of different hardware. It may be doing functions in software that COULD be done by some specific hardware, and it certainly DOES have code to support software bad block mapping and error correction, but as I mentioned previously, the SOFTWARE lacks support for write wear levelling. I did NOT say that the HARDWARE has no write wear levelling, and I am glad to see that it does at least have rudimentary STATIC write wear leveling.

But once again you seem to be missing the point, and concentrating on finding fault with what I say.

What is IMPORTANT here (as I mentioned before) is that whether or not the kindle has or uses write wear levelling DOES NOT MATTER because the FORMAT of the USB drive is vfat, which has ITS OWN bad block handling that does not have the severe limitations of hardware bad block mapping and write wear-leveling. If you format WITHOUT the "quick format" option OR you run CHKDSK on it, you can detect and map out bad blocks.

I have written DEVICE DRIVERS for mmc (and MANY other devices, which your wimpy internet research will not find), and I have studied the specs for many devices. I understand this stuff and I use my knowledge professionally. Spec sheets and reference manuals CANNOT BE TRUSTED. You MUST refer to the reference SOURCE code to know for sure how devices are being used. Many documented features are not effective and require software assistance or workarounds (in MANY devices). These details are buried in the kernel drivers and thankfully can be ignored by most applications programmers. But because you SEEM to think it is important and relevant to this discussion (at least for your apparently destructive purposes), I will go a little deeper into how this stuff actually works.

Hardware write wear leveling is ONLY effective when most of the drive is EMPTY from a SECURE ERASE operation on the ENTIRE DEVICE. Controllers do not generally understand the high level format. After a block has been written, it is a USED block, and deleting files from a PARTITION does not free those blocks at the controller level. Write wear levelling can only move data to blocks that have NEVER been written to since the last secure erase operation. Only advanced SSD devices and advanced operating systems (like Windows 7) have TRIM support that allows the device controller to know when a high-level erase block can be reclaimed as free at the low level (so that it can AGAIN be used for write wear leveling), and that is obviously lacking in both the MMC devices and the firmware in the kindles.

With no TRIM support at both hardware and software levels, a software format (either quick or slow) DOES NOT FREE ERASE BLOCKS AT THE HARDWARE LEVEL! The downside of this discontinuity between low-level and high-level erased blocks is that after all blocks of an mmc device have been written (even after reformatting), those blocks cannot be used for write wear leveling, which effectively DISABLES write wear leveling rather quickly if you ever put a lot of content on your device. This is why bad block support in the vfat format is so important for mmc devices, but you must actually do a thorough scan for bad blocks during your format for that to be effective, and that is not being done by the kindle startup routines that format the mmc USB drive. You *could* do it from Windows on a mounted USB drive though (and perhaps should do that, especially when experiencing problems as described in this thread).

[knc1]

Originally Posted by knc1

Paraphrasing Samsung here:
The embedded flash management software of the chip's on-board controller manages Wear Leveling, Bad Block Management and ECC.

Ref:
http://drpbox.knetconnect.com/k3/KLMxGxxEHx.pdf
Page 4, Paragraph 4, First Sentence.

The Samsung documentation on the part makes multiple references to the MMC-4.3 standard.

The standard document is a "controlled distribution" document, you can get your own copy here:
http://www.jedec.org/standards-docum...cs/jesd-84-a43
For free after registration, also free.

Samsung Electronics has also published an application note concerning the optimal trim size. Document is mirrored here:
http://drpbox.knetconnect.com/k3/app...rim_size-0.pdf

Another Samsung Electronics publication gives a pictorial description of the considerations to be made for direct writes to the device. Document is mirrored here:
http://drpbox.knetconnect.com/k3/app...on_guide-0.pdf

[knc1]

Originally Posted by hawhill

This is somewhat mandatory as nowadays, USB controllers tend to be part of the SoC (and they are for Kindles). Note that the MMC is not - however, I wouldn't go as far as recommending to desolder the eMMC chip and replace it by another. At least if you never did SMD soldering before.

The Samsung part on the K3 is the smallest capacity of a family of parts that share the same package and pin-out (ball-out?).

For someone with access to the special tools required for SMD re-work, replacing the eMMC chip would be an interesting challenge.

But who keeds a K3 with a 64Gbyte eMMC chip?

And not to forget the software changes that might be required to ensure the Samsung recommended write alignment behavior.
(App. note referenced in post above.)

If the O.P. is still around, this might be a good chance to actually do a significant hardware modification to the K3.

[ed007]

I have the tools to replace the chip mmc, but I'm sure the problem is not in it. And between him and the usb.

[knc1]

Originally Posted by ed007

I have the tools to replace the chip mmc, but I'm sure the problem is not in it. And between him and the usb.

Agreed that it is unlikely to be a problem with the eMMC, but...

At this point in the thread we are only guessing that the problem is in the eMMC.
That would need to be confirmed or denied first.

One thing that might lead to a decision about the eMMC part would be to output the "Smart Report" the chip has available internally.

See:
http://drpbox.knetconnect.com/k3/KLMxGxxEHx.pdf
Page 11, Section 4.2 and following.

There is a relatively new tool for reporting the registers of MMC devices:
http://git.kernel.org/?p=linux/kerne....git;a=summary

I have "git clone'd" that repository and started reading the source to see if it covers the Samsung "Smart Report" function.
But have not (yet) finished the reading and the comparing with the Samsung documentation.

The tool is new, and from the small bit of source I have read, the author is working first on supporting the 4.3 MMC standard features and registers.