DO NOT try to update your kindle after debricking your kindle

[wsxhwyy]

simple kindle touch (and k4nt) debricking method
https://www.mobileread.com/forums/sho...d.php?t=170929

Before my kindle bricked I used firmware 5.0.3. I used this method to debrick my kindle and it succeeded. But my firmware version is 5.0.0 now. Now I tried to update it to 5.0.3. But when it finished my kindle bricked again. I analyzed the update package and found these.


logmsg "I" "fl_kl1" "partition=/dev/mmcblk0" "flashing kernel"
BLOCK_SIZE=1024
KERNEL_OFFSET=266240
KERNEL_SEEK=$(( ${KERNEL_OFFSET} / ${BLOCK_SIZE} ))
KERNEL_COUNT=$(( 5111808 / ${BLOCK_SIZE} ))
mkdir -p imx50_yoshi
echo "dd out kernel via \"dd if=/dev/mmcblk0 of=imx50_yoshi/uImage-current skip=${KERNEL_SEEK} bs=${BLOCK_SIZE} count=${KERNEL_COUNT}\""
dd if=/dev/mmcblk0 of=imx50_yoshi/uImage-current skip=${KERNEL_SEEK} bs=${BLOCK_SIZE} count=${KERNEL_COUNT}
bspatch imx50_yoshi/uImage-current imx50_yoshi/uImage uImage.patch
dd if=imx50_yoshi/uImage of=/dev/mmcblk0 seek=${KERNEL_SEEK} bs=${BLOCK_SIZE}

I think it means that your kernel WILL BE PATCHED TWICE. Now my touch is bricked because of the wrong kernel. And I need a kernel dump. I hope that somebody could provide me a copy. And those who want to try this debricking method, please do not try to update your kindle after debricking.

[geekmaster]

You should have updated to 5.0.4, which does not patch stuff.

You can reflash a 5.0.0 kernel with fastboot, to match the 5.0.0 partition.

Or you can flash a newer kernel to match a newer partition.


Again... update to 5.0.4 and not 5.0.3 ( a lot of kindles bricked during a 5.0.3 update ).

[wsxhwyy]

Originally Posted by geekmaster

You should have updated to 5.0.4, which does not patch stuff.

Now I need a kernel dump. Maybe flash kernel with dd is better than flash kernel with fastboot. I've checked my kernel's MD5 and it is wrong.

And maybe provide different images from 5.0.0/5.0.1/5.0.3/5.0.4 for those who needs debrick is a better choice.

Call "dd if=/dev/mmcblk0 of=/mnt/us/uImage skip=260 bs=1024 count=4992" to dump kernel.

Now I cannot boot. So I cannot update my device using OTA package.

[geekmaster]

Originally Posted by wsxhwyy

Now I need a kernel dump. Maybe flash kernel with dd is better than flash kernel with fastboot. I've checked my kernel's MD5 and it is wrong.

And maybe provide different images from 5.0.0/5.0.1/5.0.3/5.0.4 for those who needs debrick is a better choice.

Call "dd if=/dev/mmcblk0 of=/mnt/us/uImage skip=260 bs=1024 count=4992" to dump kernel.

Now I cannot boot. So I cannot update my device using OTA package.

Flashing with dd is potentially dangerous, because it can overwrite "write-only" locations in /dev/mmbblk0, if you do not get the offsets and sizes exactly correct. MUCH safer to use fastboot.

I need some sleep before I strip out any images. I tried one for the k4 but messed up. It is almost 5am here and I have work in the "morning". ;-(

These things take time and I already burned several hours making firmware images for people.

EDIT: 5.0.4 is mostly just a kernel update, and it provides a full kernel image (not patches). Very little change to the main partition. So if you install a 5.0.0 kernel and 5.0.0 main partition, it should upgrade to 5.0.4 fine.

In fact, 5.0.4 should upgrade fine even if the main partition and kernel are not matching versions (unless 5.0.1, 5.0.2, or 5.0.3, which contained patches and could potentially cause problems during an update). They *should* have done a CRC check though to prevent double patching, but perhaps that code was not well-tested (or according to your analysis, may not even have EXISTED)...

Just be patient and you will get your 5.0.0 kernel image (and perhaps a 5.0.4 kernel image too).

[wsxhwyy]

Originally Posted by geekmaster

Flashing with dd is potentially dangerous, because it can overwrite "write-only" locations in /dev/mmbblk0, if you do not get the offsets and sizes exactly correct. MUCH safer to use fastboot.

I need some sleep before I strip out any images. I tried one for the k4 but messed up. It is almost 5am here and I have work in the "morning". ;-(

These things take time and I already burned several hours making firmware images for people.

EDIT: 5.0.4 is mostly just a kernel update, and it provides a full kernel image (not patches). Very little change to the main partition. So if you install a 5.0.0 kernel and 5.0.0 main partition, it should upgrade to 5.0.4 fine.

In fact, 5.0.4 should upgrade fine even if the main partition and kernel are not matching versions (unless 5.0.1, 5.0.2, or 5.0.3, which contained patches and could potentially cause problems during an update). They *should* have done a CRC check though to prevent double patching, but perhaps that code was not well-tested (or according to your analysis, may not even have EXISTED)...

Just be patient and you will get your 5.0.0 kernel image (and perhaps a 5.0.4 kernel image too).

I flashed a 5.0.4 kernel into my device using dd but it cannot boot.

[knc1]

Originally Posted by wsxhwyy

I flashed a 5.0.4 kernel into my device using dd but it cannot boot.

The u-boot bootable kernels are one of several formats that the kernel build system can turn out plus a "u-boot header".

You should be able to report on the various header values of interest with 'od' (man: od) if there isn't already a tool for the purpose ('file' might 'just do it').

Of course you'll need to look-up the proper offsets to report in the u-boot *.h files.

This should allow you to make checks on any u-boot wrapped, kernel image, before you try to 'copy device' it to storage media.
Interesting things, like: Will it fit?

*nix trivia:
"copy device" goes by the name 'dd' because the name 'cd' was already in use for a recognized purpose when "copy device" was written. So author just bump'd the first letter of the name one character.

[geekmaster]

Originally Posted by knc1

The u-boot bootable kernels are one of several formats that the kernel build system can turn out plus a "u-boot header".

The u-boot flash header is built from the "flash_header.S" source module, and it is a USB Downloader plug-in flash header that includes code to initialize DRAM and conditionally find and excecute the payload that was relocated to DRAM, as I recall. The procedure is documented in the i.MX50 Reference Manual.

The Linux Kernel (and other) flash partitions each contain a flash header that is very different from the "plug-in" flash header, and these flash headers serve a different purpose. They include the length of the kernel, and although I have not studied their layout, it appears that they may also contain a CRC32 of the partition.

This explains why fastboot CRC partition checks fail after the partition contents have changed. Writing to a mounted mmc filesystem does not update the flash header CRC. Likewise, after a firmware update, the kernel image can also change, invalidating its flash header CRC.

The point of my reply is that there are two different things here that are called "flash headers" in the code and documentation, and they are not the same and must not be confused with each other.

[mbovenka]

Originally Posted by knc1

*nix trivia:
"copy device" goes by the name 'dd' because the name 'cd' was already in use for a recognized purpose when "copy device" was written. So author just bump'd the first letter of the name one character.

I always heard it came from the IBM JCL 'DD' (Data Description) statement; that's why dd's syntax is so odd, compared to other Unix/Linux commands.

Having worked with JCL in my sordid past, I think it's rather likely; the syntax is certainly similar.

[geekmaster]

Originally Posted by mbovenka

I always heard it came from the IBM JCL 'DD' (Data Description) statement; that's why dd's syntax is so odd, compared to other Unix/Linux commands.

Having worked with JCL in my sordid past, I think it's rather likely; the syntax is certainly similar.

Yeah, I used both of the common JCLs... I could punch a custom JCL deck with no reference card or cheat sheet, when most of the other programmers just did "cut and paste" without even understanding what they were doing or why. I even had a punch card machine in my basement and an ASR-33 teletype with paper tape punch in my living room, and a second telephone line that spent much of its time plugged into an acoustic coupler. For that matter, just how long *would* it take to download a 10GB 1080p SBS-Half 3D Stereoscopic feature length movie using bit-torrent protocol over a 300bps acoustic-coupled modem, anyway? We never even imagined such a thing "back in the day".

Does that make me an old-timer?

[mbovenka]

Originally Posted by geekmaster

Does that make me an old-timer?

Yes

[geekmaster]

ddplot

UPDATE: Changed "virtual_xres" to "line_length" to for Kindle 3 compatibility.

Now that this thread has devolved into a discussion on the dd command, we might say that the "great and powerful" dd can also be used for "unusual" things like this (try it on a k4 or touch):

ddplot script code:

PHP Code:

#/bin/sh

set $(eips -i|grep line_length)
VX=$4 # fb0:line_length

n=0
while [[ $n -lt 600 ]]; do
  n=$((n+1))
  C0="$C0$(echo -ne '\xff')" # white
  C1="$C1$(echo -ne '\x01')" # black (no '\x00' in string)
done

plot() {
  local X=$1; local Y=$2; local C=$3
  echo $C|dd of=/dev/fb0 bs=1 count=1 seek=$((Y*VX+X)) 2>/dev/null
}  

hline() {
  local X=$1; local Y=$2; local L=$3; local C=$4
  echo $C|dd of=/dev/fb0 bs=1 count=$L seek=$((Y*VX+X)) 2>/dev/null
}

vline() {
  local X=$1; local Y=$2; local L=$3; local C=$4
  while [[ $L -gt 0 ]]; do
    L=$((L-1))
    plot $X $Y $C
    Y=$((Y+1))
  done 
}

fline() { # forward-slash
  local X=$1; local Y=$2; local L=$3; local C=$4 
  while [[ $L -gt 0 ]]; do
    L=$((L-1))
    plot $((X+L)) $Y $C
    Y=$((Y+1))
  done
}

bline() { # back-slash
  local X=$1; local Y=$2; local L=$3; local C=$4
  while [[ $L -gt 0 ]]; do
    L=$((L-1))
    plot $((X+L)) $((Y+L)) $C
  done
}

eips -c -f # flash clear

vline 233 100 400 $C1
hline 100 233 400 $C1; eips ''
vline 367 100 400 $C1
hline 100 367 400 $C1; eips ''
n=3
while [[ $n -gt 0 ]]; do
  n=$((n-1))
  bline 160 160 280 $C1; eips ''
  fline 160 160 280 $C1; eips ''
  bline 160 160 280 $C0; eips ''
  fline 160 160 280 $C0; eips ''
done
bline 160 160 280 $C1; eips ''
fline 160 160 280 $C1; eips ''

vline 300 100 400 $C1
hline 100 300 400 $C1; eips ''

vline 233 100 400 $C0
hline 100 233 400 $C0; eips ''                  
vline 367 100 400 $C0                           
hline 100 367 400 $C0; eips '' 


I have also implemented Bresenham's line and circle algorithms (for round-cornered vector buttons) and the Hershey vector fonts and a bitmap blitter for raster fonts, all using dd in an sh shell. Binary data processing in a shell script is said to be "impossible" if you trust what Google finds on this subject. For me, "impossible" is just another challenge.

And as you may have already seen in the "touchscreen ascii fingerpaint" thread, the hexdump command can similarly be "abused" to read binary touchscreen event device data. But hexdump also supports offsets like dd, so it can read raw binary pixel data, to complement writing pixels with dd above. Who would have thought you could implement GetPixel() and SetPixel() functions in a shell script using only hexdump and dd to process individual bytes of binary data? And yet, it is MUCH faster than plotting graphics with BASIC in the "olden days".

Sadistic hobby, eh?

UPDATE: This script calls eips to refresh the eInk display, and dd to write binary pixel data to the framebuffer, and it would need a third external program hexdump to read binary framebuffer pixels and binary touchscreen event data and/or keypress events, if you wish to add such features. See my touchpaint script for an example.

CHALLENGE: Who will be the first to implement a C compiler using only sh built-in shell features and the dd external program to output the binary compiled executable program?

UPDATE: This post spawned a separate "eink algorithmic art shell scripting" thread here:

https://www.mobileread.com/forums/sho...d.php?t=172182

[knc1]

Originally Posted by geekmaster

Now that this thread has devolved into a discussion on the dd command
- - -
Sadistic hobby, eh?
- - -
It would need a third external program, hexdump to read binary framebuffer pixels and binary touchscreen event data and/or keypress events.

Try od rather than hexdump - it may even be enabled in the Busybox images (or can be if not).


Never trust anyone over 30 or command names over three characters.

[geekmaster]

Originally Posted by knc1

Try od rather than hexdump - it may even be enabled in the Busybox images (or can be if not).


Never trust anyone over 30 or command names over three characters.

Of course I tried all my options to see which was fastest. od is not in that busybox, as was mentioned in other posts in reply to that same suggestion. You wouldn't happen to be over 30 now, would you?

[knc1]

Originally Posted by geekmaster

Of course I tried all my options to see which was fastest. od is not in that busybox, as was mentioned in other posts in reply to that same suggestion. You wouldn't happen to be over 30 now, would you?

my grandkids are.

[geekmaster]

Originally Posted by knc1

my grandkids are.

Ah... so you started your adventure in computing with a slide-rule and a hand-cranked adding machine then... I see...