Serial port connection

knc1 · 04-06-2016, 08:10 AM

Quote:

Originally Posted by knc1

- - - -
My B003 is going "into the shop" for a serial port connection . . .
- - - -

The K2 is just a small screen DX(G) - so I can confirm that the serial port connections are the same:
See pic #1 on:
https://www.mobileread.com/forums/sho...55&postcount=1

Those four pads are numbered:
1 - reference <- -> (optional, if required by adapter)
2 - Tx (from K2) <- -> adapter Rx
3 - Rx (to K2) <- -> adapter Tx
4 - Gnd <- -> adapter Gnd

The reference (and idle Tx) measure 2.7 volts - -
So a 3.3 volt, lv, ttl to usb converter should work.
And of course, any adapter that accepts an external reference (the jim.sh ftx board).

Note: You open a K2 the same as the DX(G) also.
The little tabs you have to push down are located 1-3/4 inch in from each side.

Edit:
The output levels are too high for 2.5v cmos convertor, so a 3.3v should work.
See attachments.

The jim.sh/ftx adapter can be set at a fixed 3V3 or to use an external reference.

I decided to go with using the external reference.
Even though it sometimes means a bit of a hassle to get it working -
I.E: The interface reference voltage (the Kindle) has to be 'on' at or before the USB connection is made.

If I had gone with the fixed 3v3 setting - then the interface level would have been generated from the USB bus power.
Ah, but the I/O levels would only be an approximation of what Lab126 set this thing up to use.

So far, using it in 'external reference' mode - I am getting good, solid, noise free serial communications with the device.

knc1 · 04-06-2016, 06:22 PM

The good: It didn't take me 7 months this time.

'pics RSN

= = = = =

Yup - no doubt about it - I am the one that bricked it:

Code:

system: I S60dbus:def:starting system message bus
Failed to start message bus: Invalid combination of attributes on element <allow>

Tomorrow - figure out how to make that bad file I put on there 'go away'

= = = =

The better late than never:
I have figured out how I should have tested changes to the dbus configuration.

Searching for the straw that will break this camel's back:
Tomorrow - jb the B002 and start digging into it, just to get ideas of what I can do to 'fix' the B003.

(The K2/DX(G) devices date to before I was a member here (or a Kindle owner). )

knc1 · 04-07-2016, 11:34 AM

On the B003-fm:2.5.2 I have these choices in u-boot:

Code:

uboot> ?
?       - alias for 'help'
autoscr - run script from memory
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootf - boots from either of the selected kernels. depending on mode and settings.
bootm   - boot application image from memory
bootp	- boot image via network using BootP/TFTP protocol
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
echo    - echo args to console
erase   - erase FLASH memory
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
flinfo  - print FLASH memory information
go      - start application at address 'addr'
help    - print online help
iminfo  - print header information for application image
imls    - list all images found in flash
itest	- return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nfs	- boot image via network using NFS protocol
nm      - memory modify (constant address)
ping	- send ICMP ECHO_REQUEST to network host
pmic    - PMIC utility commands
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sleep   - delay execution for some time
sspi    - SPI utility commands
tftpboot- boot image via network using TFTP protocol
version - print monitor version
uboot>

So if I can't find what I need in the "Recovery Menu" -
It doesn't have a "Recovery Menu", it has a "Developer Menu"

Code:

Developer Menu
====
3. Load MMC0 over USB storage
4. Erase MMC0
I. Initialize Partition Table (fdisk) and format FAT
O. Format and overwrite FAT partition
E. Export FAT partition
U. Update using update*.bin file on FAT partition
M. Update using update*.bin file on FAT partition of second MMC port
D. dmesg / kernel printk ring buffer.
Q. quit

And "Q" does not give the option to open a shell in the initrd system, it just, well, quits (reboots).

Maybe u-boot is the best choice -
I can still copy a system image from the B002, load and run it from a network connection (or so it seems).

Maybe the easiest to do from u-boot would to be forcing a: "rdinit=/bin/sh" into the kernel's command line. **maybe**

Hmm...
"Diagnostics Mode" does not seem to be much help either -

Code:

Turing-WW Diagnostic Services, version 3.27
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) Video
2) LED
3) Buttons
4) Keyboard
5) 5-Way
6) USB Device Mode
7) Power
8) Gas Gauge
9) Audio
0) WAN
M) MoviNand
N) Run Modes
S) Device Settings
F) FCT
G) Operator Test Suite
D) Disable auto-run of diagnostics
X) Exit Diagnostic Services

knc1 · 04-07-2016, 08:47 PM

Now this comment is interesting:
http://blogkindle.com/2009/03/kindle.../#comment-8072

Maybe I'll give it a try tomorrow.
Oh, the horrors of: "Factory Reset" - after I have spent the last two months tell people to never use it.

knc1 · 04-08-2016, 11:38 AM

The K2 (fw-2.5.4) storage layout, the DX(G) should be the same:

Code:

[root@kindle root]# cat /proc/partitions
major minor  #blocks  name

   7     0    1560656 loop0
  31     0        128 mtdblock0
  31     1       3584 mtdblock1
  31     2         32 mtdblock2
  31     3        128 mtdblock3
  31     4       3584 mtdblock4
  31     5         64 mtdblock5
  31     6        128 mtdblock6
  31     7         24 mtdblock7
  31     8         64 mtdblock8
 179     0    2007040 mmcblk0
 179     1     411277 mmcblk0p1
 179     2      34596 mmcblk0p2
 179     4    1560664 mmcblk0p4

Where:

Code:

mxc_nor_flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

erase region 0: offset=0x0,size=0x2000,blocks=8
erase region 1: offset=0x10000,size=0x10000,blocks=127
mxc_nor_flash.0: 1 set(s) of 1 interleaved chips --> 16 partitions of 512 KiB

Creating 9 MTD partitions on "mxc_nor_flash.0":
0x00020000-0x00040000 : "Bootloader1"
0x00060000-0x003e0000 : "Kernel1"
0x00008000-0x00010000 : "BoardId"
0x00040000-0x00060000 : "Bootloader2"
0x00400000-0x00780000 : "Kernel2"
0x00010000-0x00020000 : "BootEnv"
0x003e0000-0x00400000 : "Diags"
0x00000000-0x00006000 : "Vectors"
0x00010000-0x00020000 : "unused0"

That NOR flash memory layout:

Code:

0x00000000-0x00006000 : "Vectors"       ( 24*1024)  mtdblock7

# Unassigned:
0x00006000-0x00008000 :   ????          (   8*1924)

0x00008000-0x00010000 : "BoardId"       (  32*1024) mtdblock2

# A small case of double assignment here (may be fixed in later fw versions)
0x00010000-0x00020000 : "unused0"       (  64*1024) mtdblock8
0x00010000-0x00020000 : "BootEnv"       (  64*1924) mtdblock5 

0x00020000-0x00040000 : "Bootloader1"   ( 128*1024) mtdblock0
0x00040000-0x00060000 : "Bootloader2"   ( 128*1024) mtdblock3
0x00060000-0x003e0000 : "Kernel1"       (3584*1024) mtdblock1
0x003e0000-0x00400000 : "Diags"         ( 128*1024) mtdblock6
0x00400000-0x00780000 : "Kernel2"       (3584*1024) mtdblock4

# Unassigned:
0x00780000-0x007FFFFF :   ????          ( 512*1024)

The NAND flash layout:

Code:

Units = cylinders of 7688 * 512 = 3936256 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1   *           1         107      411277  83 Linux
/dev/mmcblk0p2             108         116       34596  83 Linux
/dev/mmcblk0p4             117         522     1560664   b Win95 FAT32

Where:

Code:

/dev/root on / type ext3 (ro,noatime,nodiratime,data=ordered) a.k.a: /dev/mmcblk0p1
/dev/mmcblk0p2 on /var/local type ext3 (rw,sync,data=ordered)

fsp on /mnt/us type fuse.fsp (rw,nosuid,nodev,user_id=0,group_id=0) a.k.a: USB mass storage

/dev/loop/0 on /mnt/base-us type vfat (rw,noexec,noatime,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8)
## (Which is /dev/mmcblk0p4 - 8192 byte DOS disk label)

# What the user sees of /dev/mmcblk0p4:
Units = cylinders of 64 * 512 = 32768 bytes

          Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p4p1               1       48770     1560632   b Win95 FAT32

Now - off to start copying out this stuff in an organized manner as a step towards de-bricking my K2i.

Edit:
The kernel image is using 1844 of the 3584, 1024byte blocks allowed.
Plenty of room for some additions.

knc1 · 04-08-2016, 12:46 PM

u-boot network pre-sets:

Code:

ipaddr=192.168.15.244
serverip=192.168.15.200
netmask=255.255.255.0
nfsrootfs=/nfsboot
bootargs_base=console=ttymxc0,115200 mem=128M panic=10
bootcmd_root_nfs=setenv bootargs $(bootargs_base) root=/dev/nfs rw nfsroot=$(nfsrootfs),v3,tcp rw ip=$(ipaddr):$(serverip):$(serverip):$(netmask):mario1 rootdelay=3

knc1 · 04-08-2016, 03:32 PM

Notice above, that 'load binary file from a dos filesystem' thingy?

What better 'binary file' to load than the Kindle's kernel?
Most likely, with a modified initial ram fs filesystem, one that will give us an interactive shell.

When the mtdblock1 storage was copied out - the copy was of the entire storage area and the kernel uImage only uses part of that area.

So where does that image file in that storage area end?

One way:

Code:

NOR $ file mtdblock1
mtdblock1: u-boot legacy uImage, s050110-1006221747-TN2.0.4~2.6., Linux/ARM, OS Kernel Image (Not compressed), 1887240 bytes, Tue Jun 22 20:03:02 2010, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0xE212A2C3, Data CRC: 0xFA767E08

An (old school) one image uImage - 1887240 + the 64 byte uImage header == 1887304 bytes

Another way:

Code:

NOR $ od -A d mtdblock1
- - - - -
1887280 146024 000034 046030 000035 046054 000035 000000 000000
1887296 000000 000000 000000 000000 177777 177777 177777 177777
1887312 177777 177777 177777 177777 177777 177777 177777 177777
*
3670016

Note: File padding is usually 0's and erased flash is always 1's.
So count 'em: 1887296 + 8 == 1887304 bytes

Yeah! I can still do simple math!

So only grab the first 1,887,304 bytes from the storage image file:

Code:

NOR $ dd  if=mtdblock1 of=uImage-1 bs=1887304 count=1
1+0 records in
1+0 records out
1887304 bytes (1.9 MB) copied, 0.00524526 s, 360 MB/s

That file is checksum'd - if we got it wrong, mkimage -l will refuse to tell us anything about it:

Code:

NOR $ mkimage -l uImage-1
Image Name:   s050110-1006221747-TN2.0.4~2.6.2
Created:      Tue Jun 22 20:03:02 2010
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1887240 Bytes = 1843.01 kB = 1.80 MB
Load Address: 80008000
Entry Point:  80008000

The u-boot, mkimage tool likes it, we must have gotten it copied correctly, otherwise it would only tell us: "corrupted file" if the checksums didn't pass.

Now that uImage-1 file has the Linux kernel with the initial filesystem appended to it.
**all** that needs to be done is to take it apart, then take apart the initramfs part, modify the initramfs section as desired, put everything back together, then use mkimage to wrap it back up in a u-boot friendly header.
**ALL** (as in: 'the only thing(s) to do')
Right!

knc1 · 04-09-2016, 03:32 PM

My notes on how I got the file attachments out of the 2.5.4 uImage file.
Only for the truely bored, with nothing else to read.

Spoiler:

Copy all after the uImage header:

Code:

NOR $ dd if=uImage-1 of=kImage-1 bs=64 skip=1
29488+1 records in
29488+1 records out
1887240 bytes (1.9 MB) copied, 0.114397 s, 16.5 MB/s

At the time this kernel+initramfs binary was built, the most commonly used compression was gzip.
So check for gzip signature:

Code:

NOR $ od -A d -t x1 kImage-1 | grep '1f 8b 08 00'
0012896 1f 8b 08 00 45 5d 21 4c 02 03 9c bd 0d 78 54 c5

That 12,896 bytes is too small to be the expected kernel, so we have a different than expected composite file here.

From the console port messages, this system uses a self-extracting, compressed kernel, so the first part is the decompressor.
Copy out the compressor part of the image:

Code:

NOR $ dd if=kImage-1 of=compressor-1 bs=32 count=403
403+0 records in
403+0 records out
12896 bytes (13 kB) copied, 0.00157493 s, 8.2 MB/s

Copy out everything after the de-compressor:

Code:

NOR $ dd if=kImage-1 of=payload-1 bs=32 skip=403
58573+1 records in
58573+1 records out
1874344 bytes (1.9 MB) copied, 0.225707 s, 8.3 MB/s

Check that second part:

Code:

NOR $ file payload-1
ramfs-1: gzip compressed data, from Unix, last modified: Tue Jun 22 20:03:01 2010, max compression

A rename and a bit of zcat so we have a copy of both the compressed and non-compressed ramfs binary.

Code:

NOR $ mv payload-1 payload-1.gz
NOR $ zcat payload-1.gz payload-1

gzip: payload-1.gz: decompression OK, trailing garbage ignored

That 'trailing garbage' may be something that we need.
But to continue on blindly - -

Check the output file:

Code:

NOR $ file payload-1
payload-1: data

Data? Well, strings shows that we have finally reached the kernel.
See if there are any more attachments:

Code:

NOR $ od -A d -t x1 payload-1 | grep '1f 8b 08 00'
0084448 1f 8b 08 00 3f 5d 21 4c 02 03 bc 5b 0d 4c 5c 57
2639344 00 00 00 00 49 4b 43 46 47 5f 53 54 1f 8b 08 00

Two of them:

First part:

Code:

NOR $ dd if=payload-1 of=payload-1a bs=4 count=21112
21112+0 records in
21112+0 records out
84448 bytes (84 kB) copied, 0.0801735 s, 1.1 MB/s

Middle part:

Code:

NOR $ dd if=payload-1 of=payload-1b bs=4 skip=21112 count=638724
638724+0 records in
638724+0 records out
2554896 bytes (2.6 MB) copied, 2.4713 s, 1.0 MB/s

Check it:

Code:

NOR $ file payload-1b
payload-1b: gzip compressed data, from Unix, last modified: Tue Jun 22 20:02:55 2010, max compression

Give it the proper extension:

Code:

NOR $ mv payload-1b payload-1b.gz

Last part:

Code:

NOR $ dd if=payload-1 of=payload-1c bs=4 skip=659839
171309+0 records in
171309+0 records out
685236 bytes (685 kB) copied, 0.646588 s, 1.1 MB/s

Check it:

Code:

NOR $ file payload-1c
payload-1c: gzip compressed data, from Unix, last modified: Tue Jun 22 19:49:33 2010, max compression

Fix the extension:

Code:

NOR $ mv payload-1c payload-1c.gz

Which should have split "payload-1" into a kernel and its two attachments:
Where/What/Why/How those extra 12 bytes got into the mess ...
Will deal with that later, if it becomes a problem.

Un-compress and check:

Code:

NOR $ zcat payload-1b.gz >payload-1b
gzip: payload-1b.gz: decompression OK, trailing garbage ignored

NOR $ file payload-1b
payload-1b: ASCII cpio archive (SVR4 with no CRC)

That is the initial file system we are looking for.

Code:

NOR $ zcat payload-1c.gz >payload-1c
gzip: payload-1c.gz: decompression OK, trailing garbage ignored

NOR $ file payload-1c
payload-1c: ASCII text
NOR $ less payload-1c

And that is the configuration file the kernel was built with.

Turn that archive back into a file system:

Code:

NOR $ mkdir initramfs-2.5.4
NOR $ cd initramfs-2.5.4
initramfs-2.5.4 $ sudo cpio -i -d -m --no-absolute-filenames -I ../payload-1b
cpio: Removing leading `/' from member names
2012 blocks

initramfs-2.5.4 $ ls -l
total 28
drwxr-xr-x 2 61967  502 4096 2016-04-09 13:59 bin
drwxr-xr-x 7 root  root 4096 2016-04-09 13:59 dev
lrwxrwxrwx 1 root  root   18 2016-04-09 13:59 init -> /bin/recovery-util
drwxr-xr-x 3 61967  502 4096 2016-04-09 13:59 lib
drwxr-xr-x 2 root  root 4096 2010-06-22 20:02 proc
drwx------ 2 root  root 4096 2010-06-22 20:02 root
drwxr-xr-x 2 61967  502 4096 2010-06-22 20:02 sbin
drwxr-xr-x 2 root  root 4096 2010-06-22 20:02 sys

initramfs-2.5.4 $ ls -l bin/recovery-util
-rwxr-xr-x 1 61967 502 189651 2010-06-22 20:02 bin/recovery-util

initramfs-2.5.4 $ file bin/recovery-util
bin/recovery-util: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked (uses shared libs), not stripped

They (lab126) went to all of that trouble to compress everything multiple times (which only makes things bigger than the first compression) and yet they included the configuration file and failed to strip the compiled binaries of the unneeded symbol tables.

The interesting parts are attached below (they are GPLv2, just like the kernel because they where statically linked with the kernel).

knc1 · 04-09-2016, 09:05 PM

Since Amazon/Lab126 uses all compiled, custom code in their initramfs - -
It is back to the 'old school' of doing a rescue image.
A static built busybox + a bit of scripting + the Amazon kernel with matching modules (which I just extracted and attached above).

= = = =

donB006 · 04-09-2016, 09:49 PM

Hi knc1-

I wonder if you could use the rescue kernel made by Yifan Lu for the DXG in your K2. He explains all the mods made to the kernel for easy unbricking here:
https://www.mobileread.com/forums/sho...d.php?t=127969

Edit: Do you still have 2 minute connections? I think stopping the powerd and netwatchd services in /etc/init.d might be the way.

knc1 · 04-09-2016, 10:43 PM

Quote:

Originally Posted by donB006

Hi knc1-

I wonder if you could use the rescue kernel made by Yifan Lu for the DXG in your K2. He explains all the mods made to the kernel for easy unbricking here:
https://www.mobileread.com/forums/sho...d.php?t=127969

Edit: Do you still have 2 minute connections? I think stopping the powerd and netwatchd services in /etc/init.d might be the way.

It only monitors telnetd, not sshd nor serial port.

I intend to use the Amazon kernel and modules.
I will not be building a kernel unless it turns out to be needed.

knc1 · 04-10-2016, 11:04 AM

After sleeping on this situation over-night . . .
I decided I would native build (under emulation) the things I want in this new image.

The set-up process:

Ref: https://wiki.debian.org/ArmHardFloatChroot (using: armel / jessie instead of examples)
Requires to build: https://packages.debian.org/jessie/qemu-user-static
Requires to run: binfmt-misc support in host kernel

Spoiler:

There, that should be a good starting set of 'stuff' .

meanwhile - see just how far I can get building the things I want in my K2-Rescue image.

donB006 · 04-10-2016, 11:34 AM

Quote:

Originally Posted by knc1

After sleeping on this situation over-night . . .
I decided I would native build (under emulation) the things I want in this new image.

meanwhile - see just how far I can get building the things I want in my K2-Rescue image.

Here are some better links to Yifan Lu's work. Maybe improving on Yifan Lu's kernel would be better than improving on Amazon's kernel. Good Luck.

http://yifan.lu/2011/04/02/recoverin...rupt-kindle-2/

http://yifan.lu/2011/06/25/one-more-...-for-kindle-3/

knc1 · 04-10-2016, 11:52 AM

Quote:

Originally Posted by donB006

Here are some better links to Yifan Lu's work. Maybe improving on Yifan Lu's kernel would be better than improving on Amazon's kernel. Good Luck.

http://yifan.lu/2011/04/02/recoverin...rupt-kindle-2/

http://yifan.lu/2011/06/25/one-more-...-for-kindle-3/

I am not improving on Amazon's kernel
Repeat: not impoving on Amazon's kernel
I am building a ram-resident 'rescue disk' for the K2 as a uImage file with custom contents.

donB006 · 04-10-2016, 12:21 PM

Quote:

Originally Posted by knc1

I am not improving on Amazon's kernel
Repeat: not impoving on Amazon's kernel
I am building a ram-resident 'rescue disk' for the K2 as a uImage file with custom contents.

Wow. Is there a choice whether to boot the custom initial ram rescue file system instead of the kindle firmware file system?

Anyway, I finally found this page:
http://yifan.lu/2010/07/26/compiling...amazon-kindle/

Nevermind.

04-06-2016, 06:22 PM	#2
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	The good: It didn't take me 7 months this time. 'pics RSN = = = = = Yup - no doubt about it - I am the one that bricked it: Code: system: I S60dbus:def:starting system message bus Failed to start message bus: Invalid combination of attributes on element <allow> Tomorrow - figure out how to make that bad file I put on there 'go away' = = = = The better late than never: I have figured out how I should have tested changes to the dbus configuration. Searching for the straw that will break this camel's back: Tomorrow - jb the B002 and start digging into it, just to get ideas of what I can do to 'fix' the B003. (The K2/DX(G) devices date to before I was a member here (or a Kindle owner). ) Last edited by knc1; 04-06-2016 at 10:53 PM.

04-08-2016, 03:32 PM	#7
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Notice above, that 'load binary file from a dos filesystem' thingy? What better 'binary file' to load than the Kindle's kernel? Most likely, with a modified initial ram fs filesystem, one that will give us an interactive shell. When the mtdblock1 storage was copied out - the copy was of the entire storage area and the kernel uImage only uses part of that area. So where does that image file in that storage area end? One way: Code: NOR $ file mtdblock1 mtdblock1: u-boot legacy uImage, s050110-1006221747-TN2.0.4~2.6., Linux/ARM, OS Kernel Image (Not compressed), 1887240 bytes, Tue Jun 22 20:03:02 2010, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0xE212A2C3, Data CRC: 0xFA767E08 An (old school) one image uImage - 1887240 + the 64 byte uImage header == 1887304 bytes Another way: Code: NOR $ od -A d mtdblock1 - - - - - 1887280 146024 000034 046030 000035 046054 000035 000000 000000 1887296 000000 000000 000000 000000 177777 177777 177777 177777 1887312 177777 177777 177777 177777 177777 177777 177777 177777 * 3670016 Note: File padding is usually 0's and erased flash is always 1's. So count 'em: 1887296 + 8 == 1887304 bytes Yeah! I can still do simple math! So only grab the first 1,887,304 bytes from the storage image file: Code: NOR $ dd if=mtdblock1 of=uImage-1 bs=1887304 count=1 1+0 records in 1+0 records out 1887304 bytes (1.9 MB) copied, 0.00524526 s, 360 MB/s That file is checksum'd - if we got it wrong, mkimage -l will refuse to tell us anything about it: Code: NOR $ mkimage -l uImage-1 Image Name: s050110-1006221747-TN2.0.4~2.6.2 Created: Tue Jun 22 20:03:02 2010 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1887240 Bytes = 1843.01 kB = 1.80 MB Load Address: 80008000 Entry Point: 80008000 The u-boot, mkimage tool likes it, we must have gotten it copied correctly, otherwise it would only tell us: "corrupted file" if the checksums didn't pass. Now that uImage-1 file has the Linux kernel with the initial filesystem appended to it. all that needs to be done is to take it apart, then take apart the initramfs part, modify the initramfs section as desired, put everything back together, then use mkimage to wrap it back up in a u-boot friendly header. ALL (as in: 'the only thing(s) to do') Right! Last edited by knc1; 04-09-2016 at 04:08 AM.

04-09-2016, 09:49 PM	#10
donB006 Connoisseur Posts: 86 Karma: 186294 Join Date: Jun 2011 Device: Kindle k3G 3.4.2; DXG 2.5.8; DXG 3.1; Iriver Story HD	Hi knc1- I wonder if you could use the rescue kernel made by Yifan Lu for the DXG in your K2. He explains all the mods made to the kernel for easy unbricking here: https://www.mobileread.com/forums/sho...d.php?t=127969 Edit: Do you still have 2 minute connections? I think stopping the powerd and netwatchd services in /etc/init.d might be the way. Last edited by donB006; 04-09-2016 at 10:00 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Mod]External Serial Port	zhangsiyan12134	Kindle Developer's Corner	1	08-28-2015 12:09 PM
Serial port debrick	Fridolf	Kindle Developer's Corner	9	05-19-2015 05:14 AM
PW1 lost PADs for serial port, but found signals near USB port	uniqdom	Kindle Developer's Corner	1	04-29-2015 08:45 AM
How To Jailbreak By Serial Port	P_Chang	Kindle Developer's Corner	10	01-03-2015 04:17 PM
K3 using serial port problem	BusterBrown	Kindle Developer's Corner	42	06-05-2012 06:11 PM

04-07-2016, 08:47 PM	#4
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Now this comment is interesting: http://blogkindle.com/2009/03/kindle.../#comment-8072 Maybe I'll give it a try tomorrow. Oh, the horrors of: "Factory Reset" - after I have spent the last two months tell people to never use it.

04-09-2016, 09:05 PM	#9
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Since Amazon/Lab126 uses all compiled, custom code in their initramfs - - It is back to the 'old school' of doing a rescue image. A static built busybox + a bit of scripting + the Amazon kernel with matching modules (which I just extracted and attached above). = = = =

Advert

Advert