View Single Post
Old 07-07-2012, 10:43 AM   #51
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by kraqh3d View Post
It's not a copy as the extracted diag_kernel is huge. The main_kernel is 2.1MB while diag_kernel is 18.6MB. And file reports main_kernel as a uboot uImage file, but reports diag_kernel as data. I'm curious so I'm running binwalk against it, but that'll take a while.
An earlier version of the script searched for the kernels (for future possible changes).

For increased speed, the newest version just dumps what it finds at the two kernel offsets in the image, getting the image length from the "header". On the K3 the second header contains garbage, so that long image was the result of a "garbage" image length. Just delete the (false) diags kernel image on a K3. It is just residue that can be safely ignored. Changing the script to detect it is running on a K3 and skip dumping the diags kernel would add to its complexity. Remember, it started out as a "one-liner" linux command anyway...
geekmaster is offline   Reply With Quote