Oh sh*t - just trashed mmcblk0
 

Yepp... That's the device, not just a partition. Don't ask why. And of course, I didn't have a backup, because I was sure it would never happen. :D

Anyway, could somebody please send me the first 65 4k-blocks of a Kindle Touch (the version shouldn't matter), i.e.

dd if=/dev/mmcblk0 of=rescue.bin bs=4096 count=65

Thanks a ton!

Oh my, this is embarassing... :eek:

Am I allowed to ask how?

--No K5 here.

I think I would have signed up under a different user name before I would admit I had to ask for that. ;)
Sorry, I can't help, no K5 here.

please wait, I prepared it.
here it is: https://www.dropbox.com/s/4xxp6a9gdtyulte/rescue.bin
taken from the KT.

Or in the PM I sent ixtab. :D

Now he has a choice. :)

Ok, thanks to varnie and geekmaster! Everything is fine again now.

What happened:
I was about to try and create an update package which would allow to install an SSH-enabled diags partition without going through all the Windows -> USB downloader -> fastboot mode misery.

We already know that the main kernel is at offset 0x41000, the diags kernel at offset 0xe41000 on the device. So all it takes is a bit of dd'ing around.

Being the wise guy that I am, I didn't just pack the update.bin, but tried the script using an interactive session first (which allowed me to repair the system even while it was horribly broken, without rebooting first).

Being the stupid guy that I am, I forgot to append the "seek" parameter to dd - so instead of writing the diags kernel to where it should be, I wrote it right to the beginning of the "disk", overwriting the MBR, and parts of the main kernel.

In fact, having two different versions of first blocks now also gives us a bit more information about the disk layout: the first 65 4k-blocks seem to be mostly irrelevant, with the obvious exception of the partition table within the MBR. And, an interesting observation: the files sent by varnie and geekmaster were actually different. The differences are limited to the Master boot record though, and seem to be irrelevant, but interesting: the entire 446 bytes of bootstrap code were "00" in varnies file, but "FF" in geekmasters. Since the code is obviously not used, this doesn't matter, but I'm curious as to were it comes from. And, the "number of sectors" entry for the 4th partition (userstore) differs, even though the rest is identical for that partition (and the others).

Funny stuff :)

I would have used a different approach, and just populate the diags /usr/local folder by extracting a data.tar.gz file. But I suppose that could be a problem if new firmware erases that folder. It would be worth a try just to see if it works.

Flashing a partition is easier from fastboot, which is why we do it for simple debricking, but from an update package it seems a bit extreme (and then you need to flash a matching diags kernel too, just to be safe). IMHO.

Of course, your way is guaranteed to work (even if future firmware DOES delete the /usr/local folder), so may be the best option in the end.

looks like a handy bit of space for a splash image IMHO :P

The "FF" are an erased, erase block that has never been written to.
(Flash erases to "FF" not to "00").
The iROM code (used to initally load or re-load an external flash device) only works in 512 byte increments so those "00" may be 512 byte block padding.
Check the boundaries of 512 byte increments for differences, including differences in padding.

Ah, yes, the first blocks of the flash are "in use", they are "in use" by the SoC on-chip firmware. The SoC reference manual includes the "memory map" of what is what there.

Just for completeness: the update package that I was mentioning has now been published.

Hmm..., why should I? Despite my nickname :) , I'm only human, and I can make mistakes - why shouldn't I admit that?

BTW: as this thread's original topic is essentially resolved, let's just see where it goes. It is now open to "fire at will" :)

A comment on your:

Everyone makes mistakes.

Intelligence allows people to learn from them.

Wisdom guides people to do them less than twice.

Sharing them sometimes helps others.

Hiding them rarely helps anyone.

I once read a very illuminating article at 30 thousand feet from some of the worlds most successful people who talked about their biggest mistake.

The one that stuck out was the quote that (para-phrasing) said "I make mistakes everyday, my biggest mistake is when I stop pushing hard enough to cause them"

Yeah. So that. Thanks for sharing : )