[Barnes & Noble Nook Tablet] hkvc:
SUCCESS SUCCESS SUCCESS with Modified Ramdisk

Hi All,

SHORT form for impatient people

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

OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.recovery.img;

OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1

OMAP44XX SDP # booti 0x81000000

LONG form for people who want bit more details

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

I have been able to boot into a modified recovery image using my NOP based BYPASS logic for secure boot chain.

What I learnt in the process are

a) Secure boot chain logic doesn't bother if we change the UBoot / XYZ code space :-) :-) :-) Key to any logic using/manipulating the memory of the NookTab from uboot.

b) The Android img images for BN NookTab contain

b.1) The standard 2K Android header (nothing special from BN in this).

However NOTE that pagesize is 4096 and a good base address (picked from recovery.img of factory.zip) is 0x80080000

b.2) The Kernel and the Ramdisk images with in the android img file in turn contain 0x120 Byte headers individually

b.3) The Secure Boot chain seems to be particular about these 0x120 byte headers

Even for my modified ramdisk, I had to use the original ramdisks' BN Header. Otherwise the security check seemed to take a hell lot of time most of the time and the end results were touchy (Have to debug this further ..., ALSO THERE IS THE OPTION OF AVOIDING THE SEC_ENTRY call in the FIRST PLACE ITSELF TO TRY AND BYPASS THIS, IF REQUIRED, I have to experiment this later).

So if one is using a tool which searchs for the GZIP MAGIC to decide where to split the img file into strictly two parts consisting of

dump_1) Android_Image_Header+Kernel_BNHeader+Kernel+Ramdisk_BNHeader and

dump_2) Ramdisk file

are fine.

However if one is using a program which uses the Android image header structure to dump the contents need to be careful to extract the BN header from the corresponding ramdisk file and then after manipulating/modifying the ramdisk file, RE PREPEND the BN header back to the ramdisk. Before clubing/joining all the files together.

Or tools which assume wrong pagesize (some I found used 2K page size instead of picking from android header) or which split the constituents into individual parts intelligently (which by the way will discard the BN Header potentially) will have to be MODIFIED before using.

I ended up writing my own c code to dump using Android header and inturn use shell script to extract the BN Header for safe keeping before merging everything back later. I will post the code and simple shell scripts in a day or two.

BELOW is the OUTPUT OF MY SUCESSFUL RUN with MODIFIED RAMDISK

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

OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;

3207168 bytes read

OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1

80e84808: 1a00000a ....

80e847a0: 1a000004 ....

80e84808: e1a00000 ....

80e847a0: 1a000004 ....

OMAP44XX SDP # booti 0x81000000

kernel @ 80088000 (2682952)

[ERROR] [SEC_ENTRY] Call to Secure HAL failed!

ramdisk @ 81080000 (513707)

Initrd start : 81080000 , Initrd end : 810fd58bAcclaim Board.

Starting kernel ...

Linux version 2.6.35.7 (build@dhabuildimage17) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Fri Nov 11 12:35:42 PST 1

CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c53c7f

CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

Machine: OMAP4430 ACCLAIM

Memory policy: ECC disabled, Data cache writealloc

...........