Kernel image files extracted using dd commands shown above were added to the first post in this thread:

could you please check the non-touch one? I'm starting to think that this is not really correct. It doesn't look like a Linux-kernel image to me - more like a simple backup of mmcblk0 but cropped after 4.5 MB - so after the Linux-kernel starts but before it ends.
So it's neither a usable kernel for fastboot, nor a complete image of the unpartitioned mmc-space usable for dd. I guess you'd have to use the "skip"-option on dd to ensure you copy the kernel completely. Of course, once you have the unpartitioned 32MB somewhere, you can also use a simple hexeditor.

Unfortunately, I only checked for that after I tried to flash it. So at the moment, my Kindle seems "broken some more". MfgTool still can see it when magic-booting but sending it to fastboot doesn't seem to work.

I can confirm that 0xE41000 looks like a good guess for the diags-kernel in the non-touch, too. With 0x4E3000 (padded to 4K boundaries), it looks slightly larger than the non-diag (0x48A540).

I guess, I'll have to read into how to flash with MfgTool / how to create own profiles next..

@geekmaster:
The problem with the runme.sh-scripts is that I have to be able to copy them to the Kindle - which is next-to-impossible in the short timespan I can access it - and the system has to boot far enough to start accessing scripts - which I also strongly doubt.
Though I gotta admit that I didn't yet access the serial port to watch the boot messages. Looks like this might be a good idea, too.

Hello.
I tyred to flash main kernel tou provided using fastboot, tried dd if=/dev/mmcblk0 of=/mnt/us/kernel-5.0.4.img bs=1K count=4971, but my Kindle Touch still can't boot in main mode.
I don't know firmware version, I used mmcblk0p1.img from the first post.

If the command you used is "as posted" and not a typo here -
Then your source (InFile, if= ) and destination (OutFile, of= ) options are reversed.
The command "as posted" is reading from the mmc not writing to it.

It might also be that you left out some of what you did from this post.
Could you confirm the details of what you tried please?

If the command you used is "as posted" and not a typo here -
Then your source (InFile, if= ) and destination (OutFile, of= ) options are reversed.
The command "as posted" is reading from the mmc not writing to it.

It might also be that you left out some of what you did from this post.
Could you confirm the details of what you tried please?

I did right as I posted.
dd.. then fastboot flash..
But if I didn't write main kernel with dd, but copied it, fastboot should have been written it right back. So I guess it's ok that nothing good happened.

The problem was that the SKIP option was left off of the dd commands (now added in the post above). I am remaking and reposting the kernel images.

I have *way* too many urgent things going on right now (remember that "geekmaster vacation" thread?), and I did not take the time to examine the images before posting them. Due to my current lack of time, I am taking shortcuts and not testing things like I usually do... UPDATE: New kernel images were extracted using the dd "skip" option to begin at the correct offset in mmcblk0. The kernel image download links were updated in the first post.
Can somebody with more free time please take over these tasks so I do not have to rush so much that I skip steps and overlook mistakes? Thanks.

If the command you used is "as posted" and not a typo here -
Then your source (InFile, if= ) and destination (OutFile, of= ) options are reversed.
The command "as posted" is reading from the mmc not writing to it.
...

Wrong answer. No, it is not reversed. That command is used to make a backup copy of the kernel. You flash the kernels with fastboot. Your advice to reverse those options is actually DANGEROUS because it could actually damage data stored in the mmc, such as the device PCBSN, which would require ANOTHER custom uboot to debrick it...

Although it *might* be possible to use dd to write a kernel image into a portion of /dev/mmcblk0 (with the correct dd seek offset), that is not a *normal* way to do this, and it would require testing and verification. Because it is a device, it might not support the dd "seek" option needed to do that, and that area of mmc might be protected from writing by the kernel mode device drivers...

Hello.
I tyred to flash main kernel tou provided using fastboot, tried dd if=/dev/mmcblk0 of=/mnt/us/kernel-5.0.4.img bs=1K count=4971, but my Kindle Touch still can't boot in main mode.
I don't know firmware version, I used mmcblk0p1.img from the first post.

Thank you VERY much!
I flashed it and FINALLY my Kindle Touch DID SOMETHING after trying to boot it in main mode!

But now it is stuck on "Kindle tree screen".
What should I do to make it work?

I used mmcblk0p1 from the first post, is there 5.0.4 version like kernel I've just flashed?

USBnetwork is still not working..

USBnet for diags requires flashing the mmcblk0p2_ssh.img file you can download at the first post. Diags menu N) U) Z) X) to start SSH, wait 20 seconds, then SSH in (root password mario). Then you can flash mmcblk0p1 with dd. You CANNOT flash mmcblk0p1 with fastboot because it is too big...

If you damaged your diags kernel, you can boot diags with the kernel in the kexec thread (booting from USB drive), or you can flash that kernel to your mmc with fastboot.

You might also need to reset the boot counter (search the posts). Erasing mmcblk0p3 would also reset the counter, but you would lose your collections database if you do that.

A 5.0.4 mmcblk0p1 has not been posted as far as I know. You could always run the 5.0.4 update from amazon to upgrade from 5.0.0, after you get it running.

USBnet for diags requires flashing the mmcblk0p2_ssh.img file you can download at the first post. Diags menu N) U) Z) X) to start SSH, wait 20 seconds, then SSH in (root password mario). Then you can flash mmcblk0p1 with dd. You CANNOT flash mmcblk0p1 with fastboot because it is too big...

If you damaged your diags kernel, you can boot diags with the kernel in the kexec thread (booting from USB drive), or you can flash that kernel to your mmc with fastboot.

You might also need to reset the boot counter (search the posts). Erasing mmcblk0p3 would also reset the counter, but you would lose your collections database if you do that.

I flashed right mmcblk0p2 twice, then flashed diags_kernel - no effect.
I'll try to erase mmcblk0p3, but I doubt there is anything..

Wrong answer. No, it is not reversed. That command is used to make a backup copy of the kernel. You flash the kernels with fastboot. Your advice to reverse those options is actually DANGEROUS because it could actually damage data stored in the mmc, such as the device PCBSN, which would require ANOTHER custom uboot to debrick it...

Although it *might* be possible to use dd to write a kernel image into a portion of /dev/mmcblk0 (with the correct dd seek offset), that is not a *normal* way to do this, and it would require testing and verification. Because it is a device, it might not support the dd "seek" option needed to do that, and that area of mmc might be protected from writing by the kernel mode device drivers...

No advice in the post, just a discription of the direction options.

Also a request for clarification from the O.P. (which you cut from the quote to make your point).

To which the O.P. made a clarifying post and we are understanding each other just fine, without any outside help, thank you.

when I do:dd if=/dev/zero of=/dev/mmcblk0p3 bs=4K
it shows:dd:writing '/dev/mmcblk0p3':No space left on device
How should I deal with it?
And how to use fastboot to flash kernel-5.0.4.img?

It should have wiped the entire partition before the error message. If you do not want the error message, the quick and dirty way is to add 2>/dev/null to the end of the command.

The "right" way is more complicated (which I try to avoid whenever possible), and requires that you find out how many blocks your destination has. There are a number of ways to do that. Using "fdisk -l" is one of them (but those are 512-byte blocks, so you have to divide by 8 to get 4K blocks), or you can use "df" (but that gives 1K blocks so you need to divide by 4). Then you need to add the computed block count to the "count=" parameter of "dd".

As you can see, it is a lot more complicated than my one-line answer, which just ignores the "normal" error when the device gets full.

Another way would be just to write enough to "kill" the partition format, such as "count=1000" or something...

The point is to make the partition no longer mountable, so that the startup scripts will reformat that partition during the next reboot.