unbrik kindle3

[ed007]

Try this:

delete

Do you work in agriculture? (joke)

[knc1]

Originally Posted by geekmaster

You forgot to warn him to avoid typing "rm -rf /" while running as root.

Intentional.
That was to become step 3 of the directions I was planning to post for him.
Right after describing how to mount his Windows partition in that LiveCD. (Which may have auto-mounted it already and he wants to run as 'root'. ;-) )

[knc1]

Originally Posted by ed007

This is not a team, this is a comment for you - shows that now I plug my usb connector.
You do not look a video? Views counter = 0
I understood the meaning of the command "sudo dmesg-c", but it is not clear to me what gives? Errors with the name of the device there.
root no problem - LiveCD.
add:
10 minutes to spend watching video is not necessary: the time of the important points mentioned in the comments.

Yes, it could be a problem, even with a LiveCD.

Since your running a LiveCD, most likely you have some other Operating System installed on your internal hard drive.

Some LiveCDs will auto-mount that Other Operating System, some will not.

All LiveCD kernels will recognize the internal drive.

Depending on the LiveCD, its own use will probably use one to three device names (from the /dev/sd* device pool).

Which means that if sda and sdb names are used by the LiveCD, then the sdc name might very well be your internal hard drive.

And since you are using direct device operations (dd) as 'root' - then you might just as well kiss your other Operating System installation good bye.

I really, really, want to see the output of dmesg that ONLY corresponds to your plugging in the Kindle's USB cable.

No extra lines, no fewer lines, no videos, no editing to what you think is related.

It is only from that information that we can be certain what the cable's device name assignment was at the time you plugged it in.

- - - -

Here is another direction for you to ignore in your request for help:

sudo blkid

Cut & paste the resulting output in your next post.

[PoP]

[QUOTE=ed007;2018098]Try this:

obfuscated  system"rm -rf /" nasty command

Don't. Only try what you understand! malicious perl code

[geekmaster]

[QUOTE=PoP;2018238]

Originally Posted by ed007

Try this:

obfuscated  system"rm -rf /" nasty command

Don't. Only try what you understand! malicious perl code

I do not think it was responsible for that dangerous perl program to be posted with a recommendation to actually TRY it.

We all know quite well that SOMEBODY will do it. That post should be editted and its perl contents removed.

This is not good.

Thanks for the warning PoP! I was actually *tempted* to try it (thinking it would be something humorous due to recent context, but certainly not outright maliciously dangerous), but I tend toward the side of caution. I am glad that I waited, but I am very disappointed. The obfuscation and the "Try this" recommendation are what make that post so downright despicable. There are beginners here, and people who do not understand. I sure hope others do not get bitten by that less-than-responsible post.

@ed007: Please edit your post and remove the dangerously malicious obfuscated perl program from it. (I see that you did this now.) Thanks.

[hawhill]

From looking at the info in the OP, it looks like the eMMC degraded and the sectors on the end are not working anymore. This is probably the internal controller in the eMMC, in fact the damaged flash sectors might be in another physical position.

It looks like a case of "send it to amazon and hope for exchange device".

Note that I don't think it's the USB connection. The errors on the Kindle itself indicate otherwise.

I have one question left: How did it break? Out of thin air or after doing something? It wasn't mentioned in the OP...

[geekmaster]

Originally Posted by hawhill

From looking at the info in the OP, it looks like the eMMC degraded and the sectors on the end are not working anymore. This is probably the internal controller in the eMMC, in fact the damaged flash sectors might be in another physical position.

It looks like a case of "send it to amazon and hope for exchange device".

Note that I don't think it's the USB connection. The errors on the Kindle itself indicate otherwise.

I have one question left: How did it break? Out of thin air or after doing something? It wasn't mentioned in the OP...

From what I have seen in the mmc read and write functions in the u-boot source code, they do not do effective write wear-leveling. It is possible that the mmc was worn out by too many repeated writes to a limited area. One way this can occur is by mounting a swap file on the MMC. It should be possible to map out the bad areas, but some blocks may still be near end-of-life. FAT partitions support bad block mapping, so you can map out defective areas that way.

[ed007]

knc1
sudo blkid

Spoiler:

root@ubuntu:~# blkid
/dev/loop0: TYPE="squashfs"
/dev/sda1: UUID="7A9C24E99C24A19D" TYPE="ntfs"
/dev/sda2: UUID="BA8CE9E98CE99FDD" TYPE="ntfs"
/dev/sdb: SEC_TYPE="msdos" LABEL="UDISK" UUID="9B3D-A89F" TYPE="vfat"
root@ubuntu:~# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x3f931899

Device Boot Start End Blocks Id System
/dev/sda1 * 63 147460634 73730286 7 HPFS/NTFS/exFAT
/dev/sda2 147460635 156296384 4417875 7 HPFS/NTFS/exFAT

Disk /dev/sdb: 2021 MB, 2021654016 bytes
63 heads, 62 sectors/track, 1010 cylinders, total 3948543 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009e87d

This doesn't look like a partition table
Probably you selected the wrong device.

Device Boot Start End Blocks Id System
/dev/sdb1 ? 3223366752 3470046675 123339962 f4 SpeedStor
/dev/sdb2 ? 378192737 710426324 166116794 10 OPUS
/dev/sdb3 ? 225603442 225603451 5 74 Unknown

Partition table entries are not in disk order

Disk /dev/sdc: 4001 MB, 4001366016 bytes
4 heads, 16 sectors/track, 122112 cylinders, total 7815168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x489339d6

Device Boot Start End Blocks Id System
/dev/sdc1 * 7688 1338943 665628 83 Linux
/dev/sdc2 1338944 1388095 24576 83 Linux
/dev/sdc3 1388096 1404479 8192 83 Linux
/dev/sdc4 1404480 7815167 3205344 b W95 FAT32
root@ubuntu:~#

sudo dmesg-c - 120kb file, 2000 lines of errors is attached.
p.s.
Do not swear that I am as root: start with ms dos and always admin.


hawhill,

How did it break?

I bought it at auction for 25eur. No information.
The problem is that the errors are coming from all partition. It is unlikely that all partitions of the bits. I bow to the defect controller usb.This is the weakest point in any technique - static electricity!

[knc1]

sudo dmesg-c - 120kb file, 2000 lines of errors is attached.

Put a blank space between the command and the command option.

Then follow the exact steps I post above.
Expect approximately 6 to 12 lines, more and you need to re-read the steps I gave you.

The video directions for un-bricking this device was made for a device to which a specific set of conditions apply.

The video directions do not work for you.

QED: Something is different about the conditions of your device.

If you could just follow along, we can work out together what is different and what is to be done.
But only you can press the keyboard and all I can do is tell you what to press.

My requests for specific information has a specific reason in the path of working out what your machine's problem is.

[knc1]

Originally Posted by hawhill

From looking at the info in the OP, it looks like the eMMC degraded and the sectors on the end are not working anymore. This is probably the internal controller in the eMMC, in fact the damaged flash sectors might be in another physical position.

It looks like a case of "send it to amazon and hope for exchange device".

Note that I don't think it's the USB connection. The errors on the Kindle itself indicate otherwise.

I have one question left: How did it break? Out of thin air or after doing something? It wasn't mentioned in the OP...

There is another factor that is perhaps masking a clear view of what is wrong.

The dd command the O.P. has posted uses the default block size of 512 bytes, but flash devices (including mmc) can only erase/write in erase block sizes.

The internal controller 'hides' this for sizes not equal to the erase block size.
So the problem may be that the internal controller just does not have enough (good, working) resources to handle all the pending writes.

For instance =
If the erase block size is 4,096 bytes, then the controller has to store and pend the first 7, 512 byte writes.

If you notice the time stamp of the error message vs. the previous time stamp'd message - you can see this 1/2 second of silence (silence in reported errors).

[knc1]

Originally Posted by geekmaster

From what I have seen in the mmc read and write functions in the u-boot source code, they do not do effective write wear-leveling. It is possible that the mmc was worn out by too many repeated writes to a limited area. One way this can occur is by mounting a swap file on the MMC. It should be possible to map out the bad areas, but some blocks may still be near end-of-life. FAT partitions support bad block mapping, so you can map out defective areas that way.

We __should__ be able to re-map the bad erase block(s) for good erase block(s) at the device level.

These high capacity flash-cell base devices are "over built" with spares just because flash-cell building is sort of 'iffy' technology.

The internal device controller often can do the mapping transparent to the user, but this device looks like it will need a bit of manual help with the chore.

__AND__ I don't (yet) know if the mmc tools required are installed on this model kindle - we may have to compile them for the O.P.

[geekmaster]

Originally Posted by knc1

...
These high capacity flash-cell base devices are "over built" with spares just because flash-cell building is sort of 'iffy' technology.

The internal device controller often can do the mapping transparent to the user, but this device looks like it will need a bit of manual help with the chore.

The mmc devices in the newer kindles do all this mapping in software (kernel mode device drivers *and* in the u-boot code). They also do all the error detection and error correction in software. You can examine it in the GPL source code.

As I recall, on the touch, there is 64MB of spare blocks scattered across the device, and when these all get used up you will start seeing errors "leak through"...

[ed007]

Is there a way to get to MMC through the uboot or jtag?

[knc1]

Originally Posted by ed007

Is there a way to get to MMC through the uboot or jtag?

Yes to both.

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 think it can be restored to operation.
It would be an interesting technical exercise but the time and effort is not worth the 20euro you have in the device.

The Kindle3 has not been on the market long enough for mmc chips to begin to degrade in any significant numbers.
So fixing only yours, now, would not be of any general benefit.
Maybe in five years the topic would be of enough interest to work through the process.

Just discard this device or keep it for spare parts.

[hawhill]

Well, I mentioned above that I considered this device "bricked". However, knc1 is probably right - the underlying problem might not be fixable, but could in theory be bypassed (one of my favorite quotes from Gilliams "Brazil": "can you fix it?" - "no I can't. But I can bypass it").

In order to do that, one would have to modify the in-kernel mmc driver (given that it really does bad block management in there, which I still find hard to believe that the eMMC does nothing in that regard) to alter its bad block management. Plus, the kernel would need to be exchanged.

That would be some major work that probably noone will tackle who doesn't feel really pressed to solve a similar problem.

I'd really like to emphasize that I can't think of any other thing that would produce those errors on the Kindle itself. 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.