[Barnes & Noble Nook Tablet] hkvc:
android img header and uboot mem commands and possible example

Hi Adamoutler,

Wrt Recreating the android img file

---------------------------------------

In the dd above zImage contains the 2K Header and the Kernel while ramdisk.img contains the ramdisk, but while you recreated the newflashingboot.img, you have changed the order.

First pass the zimage and then the newramdisk.img to cat. That should fix that badmagic issue.

However the header also contains the ramdisk size, check that the new ramdisk is same size potentially. Otherwise even header requires to be updated. The header structure is

from tools/mkbootimg/bootimg.h

#define BOOT_MAGIC "ANDROID!"

#define BOOT_MAGIC_SIZE 8

#define BOOT_NAME_SIZE 16

#define BOOT_ARGS_SIZE 512

struct boot_img_hdr

{

unsigned char magic[BOOT_MAGIC_SIZE];

unsigned kernel_size; /* size in bytes */

unsigned kernel_addr; /* physical load addr */

unsigned ramdisk_size; /* size in bytes */

unsigned ramdisk_addr; /* physical load addr */

unsigned second_size; /* size in bytes */

unsigned second_addr; /* physical load addr */

unsigned tags_addr; /* physical addr for kernel tags */

unsigned page_size; /* flash page size we assume */

unsigned unused[2]; /* future expansion: should be 0 */

unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */

unsigned char cmdline[BOOT_ARGS_SIZE];

unsigned id[8]; /* timestamp / checksum / sha1 / etc */

};

Rather androids mkbootimg should also be able to recreate the image. However the way you have extracted the zImage using dd, it is not just zImage but zImage with Header, so mkbootimg may fail or will generate the wrong image, so you will to edit the ramdisk_size if required directly.

If the ramdisk size is smaller than specified, I dont' think it matters, because the kernel searches for the gzip signature to decide the gzip ramdisk file, if I remember correctly.

Wrt uboot memory commands

-------------------------------------

As for changing the uboot code in memory from uboot, try the mw (if I am not wrong, based on reading the code) command.

md.l address_in_Hex ---------- To cross check the memory content before overwriting (should match what I have mentioned as ORIG)

mw.l address_in_Hex 4ByteValueInHex -------------- To modify the given address location with new value

md.l address_in_Hex -------------- To cross check that the new value you have written has come properly.

For Ramdisk check bypassing

-----------------------------------

md.l 0x80e84808 OR md.l 80e84808

should show 1a00000a

If it does then my offset calculation is correct (I have used the 2nd possibility in my BYPASS logic explanation i.e one with -0x120)

NOTE: If the contents of the md.l 80e84808 is not 1a00000a, then do provide me values starting from 0x80e84800 to 0x80e84900. I will try and search the same in binary and then try and find the proper offsets.

next run

mw.l 80e84808 e1a00000 ------------- This modify with NOP

Next run

md.l 80e84808 ------ should show e1a00000

Next run (if recovery.img with new ramdisk updated to /recovery partition)

mmcinit 1; booti mmc1 recovery

Next run (if the new ramdisk is placed in uSD card as flashing_boot.img)

mmcinit 0; fatload mmc 0:1 0x81000000 flashing_boot.img; booti 0x81000000

Now it should boot with out giving a signature error, if the bypass worked.