[DONE] NOP based Boot security chain FULL BYPASS with UART access - Barnes & Noble Nook Tablet
>>> With UART access NookTab Secure BOOT Chain as been FULLY BROKEN, Custom Kernel and Custom Ramdisk have been succesfully run on NookTab, Look towards 2nd page or so for full info <<<
Hi,
Few days back I had got an idea to try and see if we can BYPASS the boot security chain by replacing the bootloader in memory, because NOOKTAB allows UART ACCESS to UBOOT.
My initial thought was to use a replacement UBOOT without Security checks. However on further thought, as UBOOT has memory access commands, I realised the simpler solution is to edit the UBOOT code directly in memory from UBOOT prompt itself.
In turn I had posted the concept and the commands to try and do the same on the below two threads, for people to try. However as no one seems to have tried it yet, I myself opened up the my NookTab and connected the UART signals and am continuing my experiments and the initial results are promising.
FINDING1: The MShield security logic doesn't mind if one modifies the UBOOT CODE. I was able to NOP the security check result logic check and the code continued to boot.
Next I have to try a modified RAMDisk and see it works fully.
My earlier posts on this can be got from these two threads
http://forum.xda-developers.com/showthread.php?t=1378886
http://forum.xda-developers.com/showthread.php?t=1418172
For someone interested in experimenting with this below are the commands to try on UART of NOOKTAB.
uboot Command summary
---------------------------------------
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.
Command sequence for Ramdisk check bypassing
-----------------------------------------------------------------------------
UBOOTPROMT> md.l 80e84808 ----- This should show 1a00000a
NOTE: I have verified that the 2nd possibility mentioned in my earlier post i.e 0x80e8.0000-0x120 is the load address to use to calculate the offsets.
next run
UBOOTPROMPT> mw.l 80e84808 e1a00000 ------------- This modify with NOP
Next run
UBOOTPROMPT> md.l 80e84808 ------ should show e1a00000
Next if you have updated the recovery.img with new ramdisk into /recovery partition RUN
UBOOTPROMPT> mmcinit 1; booti mmc1 recovery
HOWEVER instead if you have updated the flashing_boot.img file with new ramdisk in microSD then RUN
UBOOTPROMPT> mmcinit 0; fatload mmc 0:1 0x81000000 flashing_boot.img; booti 0x81000000
Now it should boot with out giving a signature error.
NOTE1: I have verified that changing the contents of UBOOT (i.e NOPing) in itself doesn't lock the ARM, next I have to try a updated ramdisk and see what happens. If you ask me It should work, fingers crossed, I will try and update.
NOTE2: In any android img file at offset 0x10 (i.e 16) the ramdisk size is stored as a 4 byte (long) value. Cross verify first that the original img and the ramdisk size at offset 0x10 in it matches the original ramdisk. Then update the 0x10 offset of new img file with new ramdisk's size.
NOTE3: kernel security check bypass address = '0x80e847a0'
[REPOSTING OLD, CONCEPT] BYPASS Kernel and Ramdisk check for People with UART ACCESS
**************************
>>> This was my original post to the other two threads on this concept, I have put this here for completeness. The load address confusion which I had is already resolved <<<
****************************
Hi,
NOTE: THis is based on a initial look at the source code and then the objdump of u-boot.bin. I haven't cross checked this yet, because for now I haven't opened up the nooktab for uart access yet. Also this assumes by default booti command is used for booting in BN uboot. If some one wants to use bootm, then a different location requires to be patched wrt the image loading security check.
If you are a lucky ;-) person working with opened up NookTab with UART access, then basically replacing the memory contents of these two offsets with NOP will 90% BYPASS the security check successfully and allow you to boot a MODIFIED KERNEL or RAMDISK as required.
All offsets specified Assuming u-boot is loaded at 0 (adjust for the actual address where u-boot.bin is loaded, haven't looked into that yet).
Check for Security check of Kernel image is at
[ORIG] 0x48c0 => bne 0x48d8 (0x1a00.0004)
Make this a NOP by overwriting using uboot memory write command to
[MODI] 0x48c0 => mov r0, r0 (0xe1a0.0000)
Check for Security check of RAMDisk image is at
[ORIG] 0x4928 => bne 0x4958 (1a00.000a)
Make this a NOP by overwriting with
[MODI] 0x4928 => mov r0, r0 (0xe1a0.0000)
Someone (Hi Adamoutler, maybe you) with opened up NookTab can try this and tell me if it worked or not.
NOTE: you have to add up the actual u-boot load address to the offsets specified.
UPDATE1: It appears the load address is either
Possibility 1) 0x80e8.0000 OR
Possibility 2) 0x80e8.0000-0x120 (More likely).
Have to dig thro bit more, but one of these two will potentially work.
So that means to NOP RAMDisk security check the offset is
Possibility 1 ==> 0x80e8.0000+0x4928
Possibility 2 ==> 0x80e8.0000-0x120+0x4928 (More likely)
Best is to cross check if the resultant address contains the BNE instruction bytes specified above.
Same concept applies for the Kernel security check Nopping offset.
NOTE: It appears there is a 0x120 size header before the actual u-boot.bin code starts and in turn, when I did the objdump, it included the 0x120 bytes of header also assumed as code. And inturn the full (including the header) u-boot.bin or for that matter the u-boot from emmc seems to load into 0x80e8.0000-0x120.
UPDATE 2:
Code around the locations to be noped to help identify the same in memory, in case my offset calculations are wrong
48b4: eb0030f1 bl 0x10c80
48b8: e59d3010 ldr r3, [sp, #16]
48bc: e3530000 cmp r3, #0
48c0: 1a000004 bne 0x48d8
48c4: e59f0104 ldr r0, [pc, #260] ; 0x49d0
48c8: e594100c ldr r1, [r4, #12]
48cc: e5942008 ldr r2, [r4, #8]
48d0: eb0015db bl 0xa044
............
491c: eb0030d7 bl 0x10c80
4920: e59d3010 ldr r3, [sp, #16]
4924: e3530000 cmp r3, #0
4928: 1a00000a bne 0x4958
492c: e59f00a4 ldr r0, [pc, #164] ; 0x49d8
4930: e5941014 ldr r1, [r4, #20]
4934: e5942010 ldr r2, [r4, #16]
4938: eb0015c1 bl 0xa044
UPDATE 3: ... for a rainy day in future ;-)
UPDATE 4: For maximum success, first try a changed RAMDisk rather than Changed Kernel. If Changed Ramdisk works then try Changed Kernel (THere is one more thing in Code, which I am not sure if it will impact a modified kernel or not yet, only way is to experiment).
UPDATE 5: I have cross verified on the target with UART access and the 2nd possibility mentioned above wrt load address is what is correct.
android img header structure for reference
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 */
};
PARTIAL SUCCESS BYPASSING SEC CHECK using NOP
Hi
By BYPASSING both the Kernel and Ramdisk checks using NOPs, I am able to run the kernel (not modified, but repackaged, so bypassed Kernel sec check) and modified ramdisk.
However either
a) I seem to have done something wrong OR
b) Secure boot chain is doing something internally before passing control to uboot during kernel sec check, which is different between a successful call and a bad call.
Because the kernel crashes after control passes to it, almost immidiately.
NOTE: Have to try with only ramdisk change ...
The UART Dump of my run is given below.
OMAP44XX SDP # booti 0x81000000
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
kernel @ 80088000 (2689312)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513429)
Initrd start : 81080000 , Initrd end : 810fd475Acclaim Board.
Starting kernel ...
undefined instruction
pc : [<800886e4>] lr : [<80e930c0>]
sp : 80e3fac4 ip : 00028f05 fp : 80eabe44
r10: 810fd475 r9 : 80eb1fb8 r8 : 80e3ffdc
r7 : 80088000 r6 : 00000000 r5 : 80e3ffb4 r4 : 80eb1fb8
r3 : 00000000 r2 : 80000100 r1 : 00000e18 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
NOTE: This requires UART access to NookTab.
UPDATE 1: I found one mistake in that the unpack tool was always using a fixed size 2048 for page size rather than 4096 in the BN recovery.img, I fixed it and repackaged the new set of files and now even thou success eludes me, I find that this time it didn't give a SEC ERROR for my modified ramdisk !?!?!? But it was slower with the checks this time.
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2687264)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513416)
Initrd start : 81080000 , Initrd end : 810fd468Acclaim Board.
Starting kernel ...
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 ([email protected]) (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
...........
That all looks very good and sounds extremely promising
So in the realms of being able to boot modified roms where does this put us?
Uses of this method and its merits/demerits or needs/no needs
Hi Celtic/All,
*** The only places I see a meaningful use for this is mentioned towards the end, otherwise, I am working on this mainly for the fun of exploration. In most other cases where one thinks one needs this, I can tell you It can be achieved with out this, except for some exotic things which don't affect majority of users ***
My thoughts on ROMs with different complexities
------------------------------------------------------------------------
If a modified ROM is not using (doesn't need) custom Kernel or custom Ramdisk, then my 2ndihkvc or any other working 2nd-init method is the simple and straight forward way of doing a custom rom.
If it however requires a custom Ramdisk, then this NOP based BYPASS method will allow one to achieve the same. However I don't see any need for anyone to use a custom ramdisk. If someone is using a custom ramdisk, It can be 98% modified to use the generic 2nd-init method and in case of NookTab my simple 2ndihkvc method (As documented in my other thread, the default 2nd-init logic fails on NookTab as it uses ONE too many PTRACE calls).
If it requires a custom Kernel then with bit more work on this I don't see why a Custom kernel cann't be booted.
However if you ask me, we don't gain much with a custom kernel or ramdisk, which cann't be achieved using root access and or module loading support in default kernel, and inturn REMEMBER that both of these can be done on NookTab today (i.e 1. Root access and 2. Module loading).
Also NOTE that this requires UART access.
*** ONE PLACE WHERE THIS CAN HELP *** is, with BN 1.4.1 firmware, which has blocked the current rooting method If I am not wrong (Unless someone has found a way to break it recently, which I have missed). For 1.4.1, with this, we can boot into a specific custom recovery image and modify the /system partition, such that we put su and SuperUser back into it under /system/bin (with proper chmod settings) and /system/app, so that we can gain Root access again, on rebooting into the NookTAB normally after this change.
*** Another place *** is when the device is very old and the new kernel can bring in some feature missing badly in a very old device. Again in many of these cases, if one puts sufficient effort the feature may be back portable and or injectable into a older kernel using the module route.
REMEMBER IN LINUX - KERNEL MODULE IS SAME AS KERNEL as far as PRIVILAGES are concerned, as it stands TODAY, all LIMITS IF ANY are ARTIFICIAL.
HOPE THAT HELPS
I love reading these threads even though I don't fully understand everything going on in the code parts.
I'm interested in custom kernels because as far as I know there's no way to get ICS running on the Tab without one.
Nexus S 4G 4.0.3
I honestly dont know much about creating custom ROM's but I have been wondering why every thinks that we have to have the bootloader unlocked before we can get any type of custom ROM. I have a Moto X2. The bootloader is not and never will be unlocked but I am running a really sweet custom ROM on it. I know from other android phones that a ROM is possible with a locked bootloader.
My point is...I am glad to see someone working around this and taking the next step. I was wondering if DEV's have almost given up on the NT. Thank you for your work!
Rooting 1.4.1
hkvc said:
... BN 1.4.1 firmware, which has blocked the current rooting method If I am not wrong (Unless someone has found a way to break it recently, which I have missed).
Click to expand...
Click to collapse
See my method at http://forum.xda-developers.com/showthread.php?t=1413734 (since Dec 27)
Note that my method starts with either a rooted or (preferably) unrooted copy of 1.4.0, roots it if necessary, modifies it slightly, updates to 1.4.1, and then regains root. Requires ADB/USB access.
POTENTIAL SUCCESS with CUSTOM KERNEL (INDIRECT METHOD)
Hi All,
In SHORT for impatient
---------------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
OMAP44XX SDP # booti 0x81000000
(c) HKVC, GPL ;-)
The sufficient minimal Details
-------------------------------------
I have verified that NOT CALLING SEC_ENTRY calls, with in uboot, related to kernel and ramdisk check keeps things smooth. That should mean the FLOOD GATES are POTENTIALLY OPEN for CUSTOM KERNELs with UART ACCESS.
This requires few additional NOPs compared to what I had originally specified (My original set of NOPs had some issue with Kernel booting, which I have to debug later, however this work around seems to resolve it - I don't want to delve more into this than what I have already specified here, unless Secure Bootloader people get any ideas ;-).
UART Boot Dump/log
-------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;
3207168 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
80e84794: eb0030f1 .0..
80e847fc: eb0030d7 .0..
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2682952)
ramdisk @ 81080000 (513707)
Initrd start : 81080000 , Initrd end : 810fd58bAcclaim Board.
Starting kernel ...
Linux version 2.6.35.7 ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Fri Nov 11 12:35:42 PST 2011
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
On node 0 totalpages: 245760
And if the merge bootloader of the nook color and from nook tablet, compare it and try to create one substitution?
DeanGibson said:
See my method at http://forum.xda-developers.com/showthread.php?t=1413734 (since Dec 27)
Note that my method starts with either a rooted or (preferably) unrooted copy of 1.4.0, roots it if necessary, modifies it slightly, updates to 1.4.1, and then regains root. Requires ADB/USB access.
Click to expand...
Click to collapse
Hi DeanGibson,
Thanks for your efforts on that. It should help people who get bumped into 1.41 by BN.
HOWEVER Do note that if the uSD based MLO and u-boot.bin gets loaded first before the ones in eMMC by the internal boot rom of the Omap (Should be the case based on what Pokey had mentioned sometime back, I haven't cross checked myself yet, as I have been busy with these stuff which I am looking into). Then what ever (except for one cavet - which I wont mention here) BN may do in a future update, with the UART based u-boot method which I have mentioned in this thread, one will always be able to get root access to the device.
OMG hkvc, between you, DG, and AO how can the NT win?
You guys are monsters! (in a good way)
Ok, little explaining before questioning is I'm not a tech guy. But from the all post of hkvc in this thread, the understanding that we can access more space in 16GB internal storage and custom ROM/kernel is on the way is correct?
camapghe said:
Ok, little explaining before questioning is I'm not a tech guy. But from the all post of hkvc in this thread, the understanding that we can access more space in 16GB internal storage and custom ROM/kernel is on the way is correct?
Click to expand...
Click to collapse
This requires repartitioning the drive, which we are not at this time confident, that it will not brick your nook by doing so. (This double negative actually is making a positive: Repartitioning might brick your nook.)
This hardware modification has nothing to do with accessing more of the space as that is entirely a software remedy. We're just not confident about how hard the Nook looks at the primary partition table.
SUCCESS SUCCESS SUCCESS with CUSTOM Kernel+ CUSTOM Ramdisk, UART NOP BYPASS
Hi All,
As I had mentioned yesterday/today early morning, By bypassing the SEC_ENTRY check I was able to run stock kernel with out any problem. And as I had mentioned then even thou it is a indirect way of verifying possibility of custom kernels, it should still open the flood gate for custom kernels (with UART access for NoW ;-).
Now I have actually verified by RUNNING a CUSTOM Kernel which I compiled along with a CUSTOM Ramdisk (with adb enabled - look at last few lines), which you can know from
a) the kernel version line while booting, which contains the machine used for compiling (Obviously I have redacted part of my name ;-),
b) as well as the size of the kernel and ramdisk images which is different from the stock img files, because this contains both a custom kernel as well as custom ramdisk from me.
SO IT IS SUCCESS with CUSTOM KERNELS+ CUSTOM RAMDISKS, using the uboot commands which I had mentioned in my older post.
UART DUMP including UBoot commands
--------------------------------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.kr.img;
4157440 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
80e84794: eb0030f1 .0..
80e847fc: eb0030d7 .0..
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2693828)
ramdisk @ 81080000 (1455055)
Initrd start : 81080000 , Initrd end : 811e32afAcclaim Board.
Starting kernel ...
Linux version 2.6.35.7 ([email protected]) (gcc version 4.5.4 (Ubuntu/Linaro 4.5.3-9ubuntu1) ) #1 SMP PREEMPT Wed Jan 4 02:43:18 IST 2012
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
On node 0 totalpages: 245760
..... Chopped ...............
omapfb omapfb: Unknown ioctl 0x40044620
init: Unable to open persistent property directory /data/property errno: 2
enabling adb
adb_open
android_usb gadget: high speed config #1: android
SO ALL OF YOU out there ITHCING to experiment with Custom Kernels and What not, Go ahead and enjoy the freedom to do so on NOOK TABLET (with UART access for NoW ;-)
My Android Img file manipulation scripts including few older ones by others.
Hi,
I am attaching the simple C program and the scripts which I use for extracting BN Android Imgs consisting of
a) Dumping the individual sections of Android img
b) Allow seperating the header from the actual Kernel or Ramdisk
c) Allow concatenating (This is kind of dummy, but required to take care of u-boot logic of loading) the old header with new Kernel or Ramdisk
d) Pass proper arguments to recreate the Android IMG file.
Also I have attached some of the other open source tools which I started with originally, but due to few things here and there and also to get maximum flexibility I moved to my own set of scripts and program.
recovery img with simple ramdisk with ADB and Root shell on Adb and console
Hi,
Attached is a recovery.img file with the standard Kernel from NookTab and a modified Ramdisk which has support for
a) ADB shell
b) Root shell access (Both ADB and Console)
c) Console is enabled in UART.
Note that the sh on the ramdisk is renamed busybox with a symbolic link called busybox pointing to this sh.
go into /system/bin and run
busybox --install /system/bin
So that you have the standard commands available on the recovery shell.
Also remember to run
export PATH=/system/bin:$PATH
I am following this thread, Congrats on your findings and thanks for your time you spent on it.
Related
[Q] unable to install android on topaz someone help me do not know where this error
Gentlemen, with these settings below I can not succeed in installing android on my HTC topaz where I'm wrong because the settings of the Haret defaul.txt enters the boot to put it on display with this information Haret boot Shutting down hardware Turning off MMU ... PSR = 600000 AND LATCH. I'LL SHOW THEM HOW THIS SET THE SD CARD AND THE FILES THEREIN. THE ROOT OF THE FOLLOWING FILES ARE SDCARD: / CONF / MEDIA CALIBRATION.TXT DEFAULT.TXT EncFiltLog.menc HARET.EXE Initrd.gz modules-2.6.27-00706-g4da65fd-dirty.tar.gz ROOTFS.IMG system.sqsh zImage REMEMBERING THAT THIS CARD SD formatted in FAT32. SETUP FILE IS THIS DEFAULT.TXT. MTYPE September 2293 September KERNEL zImage # Set FBDURINGBOOT 0 September initrd initrd.gz September ramsize 0x10000000 September ramaddr 0x10000000 PWF # dm.txt 0x8e0000 0x20000 PWF # smem.txt 0x01f00000 0x100000 # = Msmts_calib 0x376.0x3c1.0x6a.0x8a September cmdline "= msmts_calib 0x395.0x3d5.0x79.0xa0 msmvkeyb_toggle = off lcd.density mddi.width = 240 = 320 = 480 mddi.height no_console_suspend pmem.extra gsensor_axis = 1 =- 1, -2.3 sensor topaz force_cdma = = htc_battery_smem.fake 0 = 1 " # Mddi.width mddi.height = 320 = 480 boot WHAT IS WRONG OR BETTER WHERE I'M wrong? GRATEFUL FOR THE HELP
pauloedusp said: Gentlemen, with these settings below I can not succeed in installing android on my HTC topaz where I'm wrong because the settings of the Haret defaul.txt enters the boot to put it on display with this information Haret boot Shutting down hardware Turning off MMU ... PSR = 600000 AND LATCH. I'LL SHOW THEM HOW THIS SET THE SD CARD AND THE FILES THEREIN. THE ROOT OF THE FOLLOWING FILES ARE SDCARD: / CONF / MEDIA CALIBRATION.TXT DEFAULT.TXT EncFiltLog.menc HARET.EXE Initrd.gz modules-2.6.27-00706-g4da65fd-dirty.tar.gz ROOTFS.IMG system.sqsh zImage REMEMBERING THAT THIS CARD SD formatted in FAT32. SETUP FILE IS THIS DEFAULT.TXT. MTYPE September 2293 September KERNEL zImage # Set FBDURINGBOOT 0 September initrd initrd.gz September ramsize 0x10000000 September ramaddr 0x10000000 PWF # dm.txt 0x8e0000 0x20000 PWF # smem.txt 0x01f00000 0x100000 # = Msmts_calib 0x376.0x3c1.0x6a.0x8a September cmdline "= msmts_calib 0x395.0x3d5.0x79.0xa0 msmvkeyb_toggle = off lcd.density mddi.width = 240 = 320 = 480 mddi.height no_console_suspend pmem.extra gsensor_axis = 1 =- 1, -2.3 sensor topaz force_cdma = = htc_battery_smem.fake 0 = 1 " # Mddi.width mddi.height = 320 = 480 boot WHAT IS WRONG OR BETTER WHERE I'M wrong? GRATEFUL FOR THE HELP Click to expand... Click to collapse 1st off.. post in the correct forum: http://forum.xda-developers.com/forumdisplay.php?f=623 2nd try change the name of the startup file from "default" to "startup.txt" 3rd: you should have this layout in your sd card: /AndroidApps/ /conf/ /media/ /STARTUP CONFIG/ /STARTUP.TXT /haret.exe /initrd.gz /rootfs.img /system.ex2 /zImage 4th: try using latest bundle package (XDAndroid is working for me). find some more info here: http://forum.xda-developers.com/showthread.php?t=509493 hope this helps, good luck!
I'm sorry for this post I will put it in the forum thanks for the warning stated. I did just download the knack that you told me. only one question should be how startup.ext settings? AND A QUESTION FILE modules-2.6.27.46-01165-gfc1639f.tar.gz Unzip WHERE DO I HAVE? the system that I downloaded was XDANDROID.2.2.AOSP.FRX01.17.09.10.UPDATE_PACKAGE grateful
pauloedusp said: I'm sorry for this post I will put it in the forum thanks for the warning stated. I did just download the knack that you told me. only one question should be how startup.ext settings? AND A QUESTION FILE modules-2.6.27.46-01165-gfc1639f.tar.gz Unzip WHERE DO I HAVE? the system that I downloaded was XDANDROID.2.2.AOSP.FRX01.17.09.10.UPDATE_PACKAGE grateful Click to expand... Click to collapse if you just extract the package and copy the whole 'Andboot' folder to the root of your SD, then go into the STARTUP CONFIG\TOPAZ and copy the startup.txt file to into the Andboot folder and launch haret it should work. keep in mind that you should have at least 250mb-300mb free in your storage card. the modules can stay gzipped, no problem. I'm afraid that for advanced setting i cannot be of any help. If you have question, try posting them in the XDAndroid thread... good luck
thanks for the help but I have not had success ... I tried all forms with multiple files at last unable to exit the screen when having to boot the Haret. Haret boot Shutting down hardware Turning off MMU ... In preloader PSR = 600000df I'm forgetting to do something so I do not know what it is yet but thanks for the help. nobody answered me in the post. good keep searching and counting on your help I'm already almost one month trying and nothing ... but thanks
External module: insmod load error
Hi, I am trying to load a kernel module into my Android phone (HTC Ion, GDP2). The phone has a cyanogenmod rom with the kernel version 2.6.34.5-cyanogenmod .. shade at oxygene #2. I am able to successfully cross-compile the LKM (a simple helloworld module) on my Ubuntu machine for the supersonic-2.6.34 kernel obtained from the cyanogen git repository. During make ARCH=arm and CROSSCOMPILE=<my-toolchain-path>/arm-eabi-4.2.1/bin/arm-eabi- menuconfig I have enabled the loading of external modules and made sure than the version string of the kernel looks exactly the same as that of the phone-kernel (to avoid version match problem during insmod). However, after I copy my helloworld.ko to /sdcard and try to insmod from there (i do have root privileges of course) I get the following error: insmod: init_module 'helloworld.ko' failed (No such file or directory) After dmesg: <4>[54107.816314] select 1060 (ndroid.settings), adj 7, size 3942, to kill <4>[54107.816741] send sigkill to 1060 (ndroid.settings), adj 7, size 3942 <4>[54112.699005] select 970 (android.browser), adj 8, size 7407, to kill <4>[54112.699279] send sigkill to 970 (android.browser), adj 8, size 7407 <7>[54116.056854] tiwlan0: no IPv6 routers present <6>[54181.677948] request_suspend_state: sleep (0->3) at 54123617131664 (2010-11-21 18:46:53.796054520 UTC) <7>[54181.692169] deinit sharp panel <7>[54182.325012] save exit: isCheckpointed 1 <4>[54657.268341] helloworld: Unknown symbol mcount I am not able to understand the reason behind this. Can somebody help me out? Thanks in advance! Hrushi For your reference following is the LKM code: #include <linux/init.h> #include <linux/module.h> MODULE_LICENSE("Dual DSD/GPL"); static int hello_init(void){ printk(KERN_ALERT "Hello, world\n"); return 0; } static void hello_exit(void){ printk(KERN_ALERT "Goodbye, cruel world\n"); } module_init(hello_init); module_exit(hello_exit);
[Q] pmid10c boot image help
I am looking to compile a new kernel for this device. I have pulled off the boot.img file from /dev/block/nandc and used split_bootimg.pl to pull apart the kernel and the boot ramdisk. I have used extract-ikconfig to get the kernel config and built my new 3.4 kernel (with modules). So far so good... I have tried to build the new boot.img file with no avail. My concern is with the original kernel as the new one should be build the same (I think). It looks like it is not compressed as I run the command file boot.img-kernel It returns boot.img-kernel: data So it is not a Linux kernel ARM boot executable zImage Is this correct? Can Android boot with this or is the split_bootimg.pl tool not creating the file correctly (it does pull the ramdisk as I have uncompressed it fine! and the file does contain the kernel config) Ok So assuming I can create a proper boot.img with my built zImage and the old ramdisk, what do I need to do with the modules? Do I update the boot.img on the tablet and copy the modules over to the existing /system/lib/modules? (this appears to not work) I did not find an exact guide on android kernel and the modules.... Domenic link to the old (working) boot.img hxxps://docs.google.com/file/d/0B0c1jpaziDZ-NU5Sd18wbUVjN1E/edit?usp=sharing
some progress domenictroilo said: I am looking to compile a new kernel for this device. I have pulled off the boot.img file from /dev/block/nandc and used split_bootimg.pl to pull apart the kernel and the boot ramdisk. I have used extract-ikconfig to get the kernel config and built my new 3.4 kernel (with modules). So far so good... I have tried to build the new boot.img file with no avail. My concern is with the original kernel as the new one should be build the same (I think). It looks like it is not compressed as I run the command file boot.img-kernel It returns boot.img-kernel: data So it is not a Linux kernel ARM boot executable zImage Is this correct? Can Android boot with this or is the split_bootimg.pl tool not creating the file correctly (it does pull the ramdisk as I have uncompressed it fine! and the file does contain the kernel config) Ok So assuming I can create a proper boot.img with my built zImage and the old ramdisk, what do I need to do with the modules? Do I update the boot.img on the tablet and copy the modules over to the existing /system/lib/modules? (this appears to not work) I did not find an exact guide on android kernel and the modules.... Domenic link to the old (working) boot.img hxxps://docs.google.com/file/d/0B0c1jpaziDZ-NU5Sd18wbUVjN1E/edit?usp=sharing Click to expand... Click to collapse Ok so the mkimage command can be used to pull the uImage out of the Kernel Part of the file like this: mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Linux 3.0.8" -d uImage boot.img-kernel2 The only question is where in the boot process can I find the "Load Address" and "Entry Point" values that are required to create my uImage. I would think that these are going to be needed as options when I build my new kernel, and I will need to change the boot process or add a boot.scr file with my options. I have mounted the /dev/block/nanda partition (uBoot partition) but am not certain on where I would find the current environment values. I did find this little snippet on the net that referes to the base address for this device xxx.tabletroms.com/forums/all-other-android-tablets-general-discussion/5791-full-specs-whatever-else-polaroid-pmid10c-tablet-2.htmlx mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' --board sun4i --base 0x40000000 -o boot.img But he never discusses where he found the -base address. Is this the same as the Load Address and Entry Point? Domenic
domenictroilo said: Ok so the mkimage command can be used to pull the uImage out of the Kernel Part of the file like this: mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Linux 3.0.8" -d uImage boot.img-kernel2 The only question is where in the boot process can I find the "Load Address" and "Entry Point" values that are required to create my uImage. I would think that these are going to be needed as options when I build my new kernel, and I will need to change the boot process or add a boot.scr file with my options. I have mounted the /dev/block/nanda partition (uBoot partition) but am not certain on where I would find the current environment values. I did find this little snippet on the net that referes to the base address for this device xxx.tabletroms.com/forums/all-other-android-tablets-general-discussion/5791-full-specs-whatever-else-polaroid-pmid10c-tablet-2.htmlx mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' --board sun4i --base 0x40000000 -o boot.img But he never discusses where he found the -base address. Is this the same as the Load Address and Entry Point? Domenic Click to expand... Click to collapse So the base address is found in script.bin (converted to text file with bin2fex tool). This is the information found in it: [dram_para] dram_baseaddr = 0x40000000 Still how do I find the "Load Address" and "Entry Point" for the current kernel...
unmkbootimg domenictroilo said: So the base address is found in script.bin (converted to text file with bin2fex tool). This is the information found in it: [dram_para] dram_baseaddr = 0x40000000 Still how do I find the "Load Address" and "Entry Point" for the current kernel... Click to expand... Click to collapse Well more reading leads me to use unmkbootimg but on my linux 32bit system all I get is: # strace ./unmkbootimg execve("./unmkbootimg", ["./unmkbootimg"], [/* 20 vars */]) = 0 --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL +++ Illegal instruction Too bad I can see the souce code to find out what this program is doing or compile it for myself.....
split_bootimg.pl should give you the parameters i listed on tabletroms. What source are you using? Polaroid never coughed any up and i last harassed them in February.
bigsupersquid said: split_bootimg.pl should give you the parameters i listed on tabletroms. What source are you using? Polaroid never coughed any up and i last harassed them in February. Click to expand... Click to collapse Here is the split: letourneau:~/tmp# ../split_bootimg.pl /root/boot.img Page size: 2048 (0x00000800) Kernel size: 8112836 (0x007bcac4) Ramdisk size: 210343 (0x000335a7) Second size: 0 (0x00000000) Board name: Command line: console=ttyS0,115200 rw init=/init loglevel=8 Writing boot.img-kernel ... complete. Writing boot.img-ramdisk.gz ... complete. I am using the linux--sunxi kernel for now with an additional patch for dmard06.ko (which I do not expect to work!) I emailed them for the kernel source but just received a form email saying they will get back to me..... oh well I will as again. Just playing around for now to see if a newer kernel will tweek up the speed on this device as it is very laggy. Domenic I may be using an older version of split_bootimg.pl?
On another note, I was able to execute unmkbootimg on a different linux server. I was attempting to run it on a PIII 800 so it needs something > a pentium (I guess). ./unmkbootimg boot.img unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]> Kernel size 8112836 Kernel address 0x40008000 Ramdisk size 210343 Ramdisk address 0x41000000 Secondary size 0 Secondary address 0x40f00000 Kernel tags address 0x40000100 Flash page size 2048 Board name is "" Command line "console=ttyS0,115200 rw init=/init loglevel=8" This image is built using standard mkbootimg Extracting kernel to file zImage ... Extracting root filesystem to file initramfs.cpio.gz ... All done. --------------- To recompile this image, use: mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x40000000 --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' -o new_boot.img --------------- Domenic
think the parameters you're searching for are specific for building the new kernel without proper source code to extract them from? maybe you could get them from dmesg while the tablet is running? else think there might be a way to grep the variable names in the existing kernel binary or headers? i also would like a fresh kernel. maybe useful stuff here: https://vilimpoc.org/research/sh3dev/kernel-hacking.html
http://forum.xda-developers.com/showpost.php?p=46668556&postcount=31 thanks jjchico i haven't checked this out yet, but may be useful.
Well I have build a new kernel and copied the modules over, but I does not boot. It appears that it never mounts the ramdisk as it never gets to the second splash screen, but I am flying blind as there is no serial port to debug with. I suspect that I do not quite understand the boot process for this tablet.... here is what is on the nanda vfat partition: (good information here http://rhombus-tech.net/allwinner_a10/a10_boot_process/) since this is in my linux.ini cat linux.ini [segment] img_name = c:\linux\u-boot.bin img_size = 0x80000 img_base = 0x4A000000 [script_info] script_base = 0x43000000 script_size = 0x10000 [logo_info] logo_name = c:\linux\linux.bmp logo_show = 1 Not quite certain how to setup img_base on my compile I guess. I have tried the linix.ini from the link above but the tablet booted to livesuite image... that is a fail.
Not being a kernel developer.... I am wondering if the option to setup SUNXI_NAND_COMPAT_DEV is creating /dev/block/nandX or /dev/nandX as this will definatly impact the init.sun4i.rc file as it is mounting /dev/block/nandX This could be my first issue.... but then does /init first display the initlogo.rle or start processing init.sun4i.rc. Well if the first thing it does in load initlogo.rle then I am not even getting this far....below is the description of SUNXI_NAND_COMPAT_DEV Symbol: SUNXI_NAND_COMPAT_DEV [=y] │ │ Type : boolean │ │ Prompt: Create old nand device names (nanda-nandz) │ │ Defined at drivers/block/Kconfig:564 │ │ Depends on: BLK_DEV [=y] && SUNXI_NAND [=y] │ │ Location: │ │ -> Device Drivers │ │ -> Block devices (BLK_DEV [=y]) │ │ -> SUNXI Nandflash Driver (SUNXI_NAND [=y]) │
well a little more reading leads me to this page on the CarbonRom http://www.slatedroid.com/topic/64378-rom-carbonrom-422/ turns out that if you want to run a 3.4 kernel you MUST update u-boot (http://www.mediafire...4ro667xcfkd2dv7).... so I have flashed the CarbonRom and it does boot with the u-boot update. Not to worry the new u-boot will still boot the old kernel. The only issue I have with the CarbonRom kernel is the missing dmard06 driver so no touch screen..... I may get a new kernel working yet!
domenictroilo said: well a little more reading leads me to this page on the CarbonRom http://www.slatedroid.com/topic/64378-rom-carbonrom-422/ turns out that if you want to run a 3.4 kernel you MUST update u-boot (http://www.mediafire...4ro667xcfkd2dv7).... so I have flashed the CarbonRom and it does boot with the u-boot update. Not to worry the new u-boot will still boot the old kernel. The only issue I have with the CarbonRom kernel is the missing dmard06 driver so no touch screen..... I may get a new kernel working yet! Click to expand... Click to collapse https://github.com/fsebentley/linux_allwinner_drivers_input_touchscreen_mods https://groups.google.com/forum/#!topic/linux-sunxi/D0n8dyaVA34 ?
bigsupersquid said: https://github.com/fsebentley/linux_allwinner_drivers_input_touchscreen_mods https://groups.google.com/forum/#!topic/linux-sunxi/D0n8dyaVA34 ? Click to expand... Click to collapse the patch compiles,you need to comment out #include <linux/earlysuspend.h> as it is not supported on the newer kernel and not required by the driver anyway. I just need to get the kernel to actually load lol..... I have at least gotten past the boot screen now, but it hangs.... I will try a different arm tool chain and see what happens next.....
So close but yet so far..... well I have the new kernel installed and booted with adb shell available but it turns out the new mma7660.ko is not compatable with my device I get this error from dmesg over and over and over.... <4>[ 3254.934675] incomplete xfer (0x20) <3>[ 3254.938093] Assertion failed! drivers/hwmon/mma7660.c,196,mma7660_read_xyz,result>=0 Will rename the driver and see if I can get past init further in the boot.... Edit Well more issues with drivers the dmard06 is not compatible either, I had more success with the Carbon Kernel I will see if I can find the source git, should be around.... dmesg | busybox grep dmard <4>[ 5.408528] dmard06: init <3>[ 5.447835] dmard06gsensor_fetch_sysconfig_para: after: gsensor_twi_addr is 0x4c, dirty_addr_buf: 0x4c. dirty_addr_buf[1]: 0xfffe <4>[ 5.488546] dmard06_init: after fetch_sysconfig_para: normal_i2c: 0x4c. normal_i2c[1]: 0xfffe <6>[ 5.508612] gsensor_detect: Detected chip dmard06 at adapter 1, address 0x4c <4>[ 5.601533] dmard06 gsensor I2C err = 0! <4>[ 5.613430] dmard06 probe failed <4>[ 5.624926] dmard06: probe of 1-004c failed with error -1 This all makes some sense as Polaroid has not get gotten me the kernel and the drivers they load (their kernel have very unique names: Module Size Used by Not tainted 8192cu 575431 0 rtl8150 8910 0 mcs7830 6557 0 qf9700 8513 0 asix 22500 0 usbnet 23745 3 mcs7830,qf9700,asix dmard06_gl 8202 2 mma7660 6541 0 mali 130177 14 ump 42178 19 mali gt811_ts_828 19947 0 sun4i_csi0 27946 0 nt99250 14254 1 gc0308 12848 1 videobuf_dma_contig 5659 1 sun4i_csi0 videobuf_core 18067 2 sun4i_csi0,videobuf_dma_contig
Well more issues with drivers the dmard06 is not compatible either, I had more success with the Carbon Kernel I will see if I can find the kernel source git, should be around.... dmesg | busybox grep dmard <4>[ 5.408528] dmard06: init <3>[ 5.447835] dmard06gsensor_fetch_sysconfig_para: after: gsensor_twi_addr is 0x4c, dirty_addr_buf: 0x4c. dirty_addr_buf[1]: 0xfffe <4>[ 5.488546] dmard06_init: after fetch_sysconfig_para: normal_i2c: 0x4c. normal_i2c[1]: 0xfffe <6>[ 5.508612] gsensor_detect: Detected chip dmard06 at adapter 1, address 0x4c <4>[ 5.601533] dmard06 gsensor I2C err = 0! <4>[ 5.613430] dmard06 probe failed <4>[ 5.624926] dmard06: probe of 1-004c failed with error -1 This all makes some sense as Polaroid has not provided me the kernel they used and the drivers they load have unique names see below from the original stock rom: Module Size Used by Not tainted 8192cu 575431 0 rtl8150 8910 0 mcs7830 6557 0 qf9700 8513 0 asix 22500 0 usbnet 23745 3 mcs7830,qf9700,asix dmard06_gl 8202 2 mma7660 6541 0 mali 130177 14 ump 42178 19 mali gt811_ts_828 19947 0 sun4i_csi0 27946 0 nt99250 14254 1 gc0308 12848 1 videobuf_dma_contig 5659 1 sun4i_csi0 videobuf_core 18067 2 sun4i_csi0,videobuf_dma_contig
I suspect after all the trouble I had with LG source that there are device-specific bits in the drivers. Polaroid will most likely have to cough up source to get it all working. Have you considered trying punchmod to use the old drivers? I dunno if that'd work considering the stock kernel is a lower version... but it might be worth a try.
bigsupersquid said: I suspect after all the trouble I had with LG source that there are device-specific bits in the drivers. Polaroid will most likely have to cough up source to get it all working. Have you considered trying punchmod to use the old drivers? I dunno if that'd work considering the stock kernel is a lower version... but it might be worth a try. Click to expand... Click to collapse I have changed the vermagic on the old modules and tried with the newer kernel but no go.... the latest 3.0 sunxi kernel is at 3.0.96 so I will build this one and see if I can get the special 3.0.8 polaroid modules to load. I have a ticket open with Polaroid lol I guess we will see if the cough up a kernel or not.... I would not put money on it...
domenictroilo said: I have changed the vermagic on the old modules and tried with the newer kernel but no go.... the latest 3.0 sunxi kernel is at 3.0.96 so I will build this one and see if I can get the special 3.0.8 polaroid modules to load. I have a ticket open with Polaroid lol I guess we will see if the cough up a kernel or not.... I would not put money on it... Click to expand... Click to collapse I've had an open ticket since November from talking on the phone after email did nothing. nothing but autoresponder.
bigsupersquid said: I've had an open ticket since November from talking on the phone after email did nothing. nothing but autoresponder. Click to expand... Click to collapse Do you believe that something like this http://gpl-violations.org/faq/violation-faq.html could force them to provide the source code? I could try to get the group at "FreakTab" to make the same requests for the kernel sources. Maybe with enough requests the gpl-violations group could take it on? (K I am getting off topic here sorry anyone out there......) I have attempted to build the 3.0.96 kernel but it did not boot.... back to hacking at the .config to see what I have missed (I need to move my build environment off this old p3 800 lol)
Bricked Huawei HiSilicon phones - Honor P6, Mate, 4C etc... way to unbrick???
Hi people. I have new bricked Huawei Honor 4c with HiSilicon Kirin 620 octacore (Hi6620) Hardly bricked. I`ve unlocked bootloader and custom recovery used to flash it with my own update.zip from other phone (with LTE support). At the end of flashing - it turned off and bricked. BUT! After connecting to PC via USB it flashes GREEN and RED leds a few times and after windows determines it as a device with USB\VID_12D1&PID_3609&REV_0000 and named as 䕇䕎䥎 ㌲㔴㜶㤸 . It is Huawei`s VID. And after a lot of search I found a driver for it - and device became HUAWEI USB-COM 1.0. But nothing else. No flash utility, nothing. HiSilicon-IDT for K3 processor doesn`t work. After another searches I found very similar device - it`s named HiKey board. Based on Hisilicon Kirin processor too https://www.96boards.org/. This board is base around the HiSilicon Kirin 6220 eight-core ARM Cortex-A53 64-bit SoC running at 1.2GHz and delivering over 10,000 Dhrystone VAX MIPS total performance. The SoC also delivers high performance 3D graphics support with its ARM Mali 450-MP4 GPU. 1GB 800MHz LPDDR3 DRAM, 4GB eMMC Flash Storage and the standard 96Boards microSD v3.0 socket provide high performance. Flexible storage options and connectivity are available through 802.11a/b/g/n WiFi, Bluetooth 4.0 LE, three high speed USB 2.0 ports (1 OTG), an HDMI 1.3 1080p video output with audio, and Maker, DSI display and CSI camera interfaces. The board is the standard 96Boards credit-card form factor powered by an 8-18V DC 2A power supply. Click to expand... Click to collapse As we can see - it is very close to ours phone. It is fully documented and has a lot of spec about proc and other. And in it`s manual written about recovery procedure after damage of ROM - when device is powered on - it is in "download mode" for 90 seconds - abslolutly like mine phone - after 90 second it turns off from windows. In short - it is ability to write 2 fastboot images (fastboot1.img and fastboot2.img) in RAM, launch them and using fastboot command flash images to eMMC. They use SERIAL COM PORT to manipulate with device. It uses utility called "hisi-idt.py" - it is a python script for Linux based machines. I`ve Installed Linux Mint and try it. And I`ve some result - first image is going fine and I receive "Done" But second image is always "Failed". And fastboot command "fastboot devices" do not list any devices. Viewing binaries from my ROM (Fastboot.img and Fastboot1.img) in HEX - I can see load addresses to ROM are the same as in python script. It is 0xf9800800 and 0x0700000 for both images. But.... have no success. It looks like I`m close to the goal. Any ideas?
Noone intersted in? I`ve found UART Rx Tx points on the motherboard and now I can get some debug info. I see I can load images into RAM but... Code: debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... OnChipRom: fastboot1 Verif sucess ! [BDID]boardid: 745 <7.4.5> battery ocv is 4141 mv �����������������������������������������������������壂�{��?O H�����������w!!I㡡�v�J�ơ�����硾�B����9�F�F�$�/"�0D�c���������f��B���B�f��B�rreset device done. start enum. enum done intr Enum is starting. usb reset intr enum done intr NULL package NULL package USB ENUM OK. init ser device done.... USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package uFileAddress=ss=f9800800 start armboot download mode [BDID]boardid: 745 <7.4.5> battery 펟v���W�����ʝcn�g������ H�����������w!!I㡡�v�J�ơ�����硾�B����9�F�F�$�/"�0D�c���������f��B���B�f���gc姾����fB�ʔ thats all for a while
i have same problem pleas tell me if you fix it
michfood said: Noone intersted in? I`ve found UART Rx Tx points on the motherboard and now I can get some debug info. I see I can load images into RAM but... Code: debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... OnChipRom: fastboot1 Verif sucess ! [BDID]boardid: 745 <7.4.5> battery ocv is 4141 mv �����������������������������������������������������壂�{��?O H�����������w!!I㡡�v�J�ơ�����硾�B����9�F�F�$�/"�0D�c���������f��B���B�f��B�rreset device done. start enum. enum done intr Enum is starting. usb reset intr enum done intr NULL package NULL package USB ENUM OK. init ser device done.... USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package uFileAddress=ss=f9800800 start armboot download mode [BDID]boardid: 745 <7.4.5> battery 펟v���W�����ʝcn�g������ H�����������w!!I㡡�v�J�ơ�����硾�B����9�F�F�$�/"�0D�c���������f��B���B�f���gc姾����fB�ʔ thats all for a while Click to expand... Click to collapse Hello, can you uload somewere the python file to have a look at it? Also the log you have provided to us it's the whole log?
no the log is not full. it changes UART speed while booting. script: Code: #!/usr/bin/python #-*- coding: utf-8 -*- import os import os.path import serial, time import array import sys, getopt class bootdownload(object): ''' Hisilicon boot downloader >>> downloader = bootdownload() >>> downloader.download(filename) ''' # crctab calculated by Mark G. Mendel, Network Systems Corporation crctable = [ 0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7, 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef, 0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6, 0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de, 0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485, 0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d, 0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4, 0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc, 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823, 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b, 0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12, 0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a, 0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41, 0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49, 0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70, 0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78, 0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f, 0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067, 0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e, 0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256, 0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d, 0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405, 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c, 0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634, 0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab, 0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3, 0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a, 0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92, 0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9, 0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0x0cc1, 0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8, 0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0, ] startframe = { 'hi3716cv200':[0xFE,0x00,0xFF,0x01,0x00,0x00,0x00,0x04,0x00,0x00,0x02,0x01] } headframe = { 'hi3716cv200':[0xFE,0x00,0xFF,0x01,0x00,0x00,0x00,0x04,0x00,0x00,0x02,0x01] } bootheadaddress = { 'hi3716cv200':0xF9800800 } bootdownloadaddress = { 'hi3716cv200':0x07000000 } BOOT_HEAD_LEN = 0x4F00 MAX_DATA_LEN = 0x400 def __init__(self,chiptype,serialport): try: self.s = serial.Serial(port=serialport, baudrate=115200, timeout=1) except serial.serialutil.SerialException: #no serial connection self.s = None print "\nFailed to open serial!", serialport sys.exit(2) self.chip = chiptype def __del__(self): if self.s != None: self.s.close() def calc_crc(self, data, crc=0): for char in data: crc = ((crc << 8) | ord(char)) ^ self.crctable[(crc >> 8) & 0xff] for i in range(0,2): crc = ((crc << 8) | 0) ^ self.crctable[(crc >> 8) & 0xff] return crc & 0xffff def getsize(self, filename): st = os.stat(filename) return st.st_size def sendframe(self, data, loop): for i in range(1, loop): self.s.flushOutput() self.s.write(data) self.s.flushInput() try: ack = self.s.read() if len(ack) == 1: if ack == chr(0xaa): return None except: return None print 'failed' def sendstartframe(self): self.s.setTimeout(0.01) data = array.array('B', self.startframe[self.chip]).tostring() crc = self.calc_crc(data) data += chr((crc >> 8)&0xff) data += chr(crc&0xff) self.sendframe(data,10000) def sendheadframe(self,length,address): self.s.setTimeout(0.03) self.headframe[self.chip][4] = (length>>24)&0xff self.headframe[self.chip][5] = (length>>16)&0xff self.headframe[self.chip][6] = (length>>8)&0xff self.headframe[self.chip][7] = (length)&0xff self.headframe[self.chip][8] = (address>>24)&0xff self.headframe[self.chip][9] = (address>>16)&0xff self.headframe[self.chip][10] = (address>>8)&0xff self.headframe[self.chip][11] = (address)&0xff data = array.array('B', self.headframe[self.chip]).tostring() crc = self.calc_crc(data) data += chr((crc >> 8)&0xff) data += chr(crc&0xff) self.sendframe(data,16) def senddataframe(self,seq,data): self.s.setTimeout(0.15) head = chr(0xDA) head += chr(seq&0xFF) head += chr((~seq)&0xFF) data = head + data crc = self.calc_crc(data) data += chr((crc >> 8)&0xff) data += chr(crc&0xff) self.sendframe(data,32) def sendtailframe(self,seq): data = chr(0xED) data += chr(seq&0xFF) data += chr((~seq)&0xFF) crc = self.calc_crc(data) data += chr((crc >> 8)&0xff) data += chr(crc&0xff) self.sendframe(data,16) def senddata(self, data, address): length=len(data) self.sendheadframe(length,address) seq=1 while length > self.MAX_DATA_LEN: self.senddataframe(seq,data[(seq-1)*self.MAX_DATA_LEN:seq*self.MAX_DATA_LEN]) seq = seq+1 length = length-self.MAX_DATA_LEN self.senddataframe(seq,data[(seq-1)*self.MAX_DATA_LEN:]) self.sendtailframe(seq+1) def download(self, filename1, filename2): f=open(filename1,"rb") data = f.read() f.close() print 'Sending', filename1, '...' self.senddata(data,self.bootheadaddress[self.chip]) print 'Done\n' if filename2: f=open(filename2,"rb") data = f.read() f.close() print 'Sending', filename2, '...' self.senddata(data,self.bootdownloadaddress[self.chip]) print 'Done\n' def burnboot(chiptype, serialport, filename1, filename2=''): downloader = bootdownload(chiptype, serialport) downloader.download(filename1, filename2) def startterm(serialport=0): try: miniterm = Miniterm( serialport, 115200, 'N', rtscts=False, xonxoff=False, echo=False, convert_outgoing=2, repr_mode=0, ) except serial.SerialException, e: sys.stderr.write("could not open port %r: %s\n" % (port, e)) sys.exit(1) miniterm.start() miniterm.join(True) miniterm.join() def main(argv): ''' img2 = 'fastboot2.img' ''' img1 = 'fastboot1.img' img2 = '' dev = '/dev/serial/by-id/usb-䕇䕎䥎_㌲㔴㜶㤸-if00-port0' try: opts, args = getopt.getopt(argv,"hd:",["img1=","img2="]) except getopt.GetoptError: print 'hisi-idt.py -d device --img1 <fastboot1> --img2 <fastboot2>' sys.exit(2) for opt, arg in opts: if opt == '-h': print 'hisi-idt.py -d device --img1 <fastboot1> --img2 <fastboot2>' sys.exit() elif opt in ("-d"): dev = arg elif opt in ("--img1"): img1 = arg elif opt in ("--img2"): img2 = arg print '+----------------------+' print ' Serial: ', dev print ' Image1: ', img1 print ' Image2: ', img2 print '+----------------------+\n' if not os.path.isfile(img1): print "Image don't exists:", img1 sys.exit(1) if (img2): if not os.path.isfile(img2): print "Image don't exists:", img2 sys.exit(1) burnboot('hi3716cv200', dev, img1, img2) if __name__ == "__main__": main(sys.argv[1:]) logs: Code: ��������������������������������������������������������������������������������������������������������������������������0 ===>vbus_is_high! fastboot1 charger_type:CHARGER_TYPE_PC get_hw_config_int,hw_afreq:1200000. get_efuse_value,efuse ATE_flag temp:0x0af00000. ATE PASS,ate flag value:0x00000001. get_efuse_value,efuse acpu_freq change level:0x8e186100. get_efuse_value,efuse afreq change level val:0x00000000. get_efuse_value,efuse acpu_freq level:0x8e186100. get_efuse_value,efuse acpu freq sys level:0x00000000. ###INFO###,soc_freq = hw_afreq, efuse_afreq:1200000,hw_afreq:1200000. efuse ACPU 1.4G HPM:0. efuse ACPU 1.2G HPM:0. efuse ACPU 960M HPM:0. fastboot: acpu_dvfs_init successful! begin get voltage by hpm... prof[729000]: hpm_dly_exp = 0x00000cb0, hpm_dly_exit = 0x00000cf6! prof[960000]: hpm_dly_exp = 0x00000cb6, hpm_dly_exit = 0x00000cfc! prof[1200000]: hpm_dly_exp = 0x00000e94, hpm_dly_exit = 0x00000eda! acpu support freq num:5 volt:0x0000004a 0x0000004a 0x0000004a 0x0000004a 0x00000057 acpu_get_dvfs_volt,g_afreq_max_pro is :5��acpu max freq:1200000. #### success !!!!! set_acpu_freq: acpu support freq num is 5 and start is 4 . get_ddr_type 1; (lpddr2: 0; lpddr3: 1) pass the func addr: [0xfff81b10]: 0xf980d044ddr_init(): get_ddr_type: 1 ddr freq: 800000 in lpddr3_init: mode: 0; freq_config: 800 switch ddr voltage: 1.25V -> 1.2V lpddr3_init 150 lpddr3_150_rank0_init_pass lpddr3_150_rank1_init_pass lpddr3_init 266 lpddr3_266_rank0_init_pass lpddr3_266_rank1_init_pass lpddr3_init 400 lpddr3_400_rank0_init_pass lpddr3_400_rank1_init_pass switch ddr voltage: 1.2V -> 1.25V lpddr3_init 533 lpddr3_rank0_phydraminit_pass lpddr3_cat_pass lpddr3_533_rank0_init_pass rdet_lbs_passrdet_ds_passrdet_rbs_av_passwdet_lbs_passwdet_ds_passwdet_rbs_av_passlpddr3_533_rank1_init_pass lpddr3_init 800 lpddr3_rank0_phydraminit_pass lpddr3_cat_pass lpddr3_800_rank0_init_pass rdet_lbs_passrdet_ds_passrdet_rbs_av_passwdet_lbs_passwdet_ds_passwdet_rbs_av_passlpddr3_800_rank1_init_pass ERROR: tmp_freq: 0 tmp_freq: 400000 MR8 value=:0x0000005b MR5 value=:0x00000001 Samsung DDR MR6 value=:0x00000004 MR5 value=:0x00000000 [MR7,MR6,MR5]=:0x00000401 ddr init pll1 0x00007800!ddrc_qos_init done bootloader_logger got buffer at 0x07300000, size 0x00040000 bootloader_logger: no valid data in buffer , (sig = 0x43474244) [emmc_set_card_ready]emmc id:0xb64432c9 0x520644c1 0x474e4433 0x15010038 [emmc_set_card_ready]manufid: 0x00000015 DDR mode emmc --error: gps/ldo16 [SEC]check_oem_hw: carrier_id = 0x00000000 DX_BIV_SwImageVerification image id is 0x00000011, return is 0xf1000002 ! execute_load_fastboot2: In secure mode and fastboot2 verify failed! Load fastboot2 failed! hw_error_print : led = 12. func = 0. err = 0. [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on enter fatal_exception! Unrecovery Error, go to onchiprom usbloader! USB Soft Disconnect ��������������������������������������������������������������������������������������������������������������������������0 ===>vbus_is_high! fastboot1 charger_type:CHARGER_TYPE_PC get_hw_config_int,hw_afreq:1200000. get_efuse_value,efuse ATE_flag temp:0x0af00000. ATE PASS,ate flag value:0x00000001. get_efuse_value,efuse acpu_freq change level:0x8e186100. get_efuse_value,efuse afreq change level val:0x00000000. get_efuse_value,efuse acpu_freq level:0x8e186100. get_efuse_value,efuse acpu freq sys level:0x00000000. ###INFO###,soc_freq = hw_afreq, efuse_afreq:1200000,hw_afreq:1200000. efuse ACPU 1.4G HPM:0. efuse ACPU 1.2G HPM:0. efuse ACPU 960M HPM:0. fastboot: acpu_dvfs_init successful! begin get voltage by hpm... prof[729000]: hpm_dly_exp = 0x00000caf, hpm_dly_exit = 0x00000cf5! prof[960000]: hpm_dly_exp = 0x00000cb5, hpm_dly_exit = 0x00000cfb! prof[1200000]: hpm_dly_exp = 0x00000e90, hpm_dly_exit = 0x00000ed6! acpu support freq num:5 volt:0x0000004a 0x0000004a 0x0000004a 0x0000004a 0x00000057 acpu_get_dvfs_volt,g_afreq_max_pro is :5��acpu max freq:1200000. #### success !!!!! set_acpu_freq: acpu support freq num is 5 and start is 4 . get_ddr_type 1; (lpddr2: 0; lpddr3: 1) pass the func addr: [0xfff81b10]: 0xf980d044ddr_init(): get_ddr_type: 1 ddr freq: 800000 in lpddr3_init: mode: 0; freq_config: 800 switch ddr voltage: 1.25V -> 1.2V lpddr3_init 150 lpddr3_150_rank0_init_pass lpddr3_150_rank1_init_pass lpddr3_init 266 lpddr3_266_rank0_init_pass lpddr3_266_rank1_init_pass lpddr3_init 400 lpddr3_400_rank0_init_pass lpddr3_400_rank1_init_pass switch ddr voltage: 1.2V -> 1.25V lpddr3_init 533 lpddr3_rank0_phydraminit_pass lpddr3_cat_pass lpddr3_533_rank0_init_pass rdet_lbs_passrdet_ds_passrdet_rbs_av_passwdet_lbs_passwdet_ds_passwdet_rbs_av_passlpddr3_533_rank1_init_pass lpddr3_init 800 lpddr3_rank0_phydraminit_pass lpddr3_cat_pass lpddr3_800_rank0_init_pass rdet_lbs_passrdet_ds_passrdet_rbs_av_passwdet_lbs_passwdet_ds_passwdet_rbs_av_passlpddr3_800_rank1_init_pass ERROR: tmp_freq: 0 tmp_freq: 400000 MR8 value=:0x0000005b MR5 value=:0x00000001 Samsung DDR MR6 value=:0x00000004 MR5 value=:0x00000000 [MR7,MR6,MR5]=:0x00000401 ddr init pll1 0x00007800!ddrc_qos_init done bootloader_logger got buffer at 0x07300000, size 0x00040000 bootloader_logger: no valid data in buffer , (sig = 0x43474244) [emmc_set_card_ready]emmc id:0xb64432c9 0x520644c1 0x474e4433 0x15010038 [emmc_set_card_ready]manufid: 0x00000015 DDR mode emmc --error: gps/ldo16 [SEC]check_oem_hw: carrier_id = 0x00000000 DX_BIV_SwImageVerification image id is 0x00000011, return is 0xf1000002 ! execute_load_fastboot2: In secure mode and fastboot2 verify failed! Load fastboot2 failed! hw_error_print : led = 12. func = 0. err = 0. [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on [fastboot]:k3_led_green_on enter fatal_exception! Unrecovery Error, go to onchiprom usbloader! USB Soft Disconnect ��������������������������������������������������������������������������������������������������������������������������́v nUpdate debug uart baudRate to :921600 ===>vbus_is_high! fastboot1 download_mode:1 fastboot1 charger_type:CHARGER_TYPE_PC get_hw_config_int,hw_afreq:1200000. get_efuse_value,efuse ATE_flag temp:0x0af00000. ATE PASS,ate flag value:0x00000001. get_efuse_value,efuse acpu_freq change level:0x8e186100. get_efuse_value,efuse afreq change level val:0x00000000. get_efuse_value,efuse acpu_freq level:0x8e186100. get_efuse_value,efuse acpu freq sys level:0x00000000. ###INFO###,soc_freq = hw_afreq, efuse_afreq:1200000,hw_afreq:1200000. efuse ACPU 1.4G HPM:0. efuse ACPU 1.2G HPM:0. efuse ACPU 960M HPM:0. fastboot: acpu_dvfs_init successful! begin get voltage by hpm... prof[729000]: hpm_dly_exp = 0x00000cad, hpm_dly_exit = 0x00000cf3! prof[960000]: hpm_dly_exp = 0x00000cad, hpm_dly_exit = 0x00000cf3! prof[1200000]: hpm_dly_exp = 0x00000e88, hpm_dly_exit = 0x00000ece! acpu support freq num:5 volt:0x0000004a 0x0000004a 0x0000004a 0x0000004a 0x00000057 acpu_get_dvfs_volt,g_afreq_max_pro is :5��acpu max freq:1200000. #### success !!!!! set_acpu_freq: acpu support freq num is 5 and start is 4 . get_ddr_type 1; (lpddr2: 0; lpddr3: 1) pass the func addr: [0xfff81b10]: 0xf980d044ddr_init(): get_ddr_type: 1 ddr freq: 800000 in lpddr3_init: mode: 0; freq_config: 800 switch ddr voltage: 1.25V -> 1.2V lpddr3_init 150 lpddr3_150_rank0_init_pass lpddr3_150_rank1_init_pass lpddr3_init 266 lpddr3_266_rank0_init_pass lpddr3_266_rank1_init_pass lpddr3_init 400 lpddr3_400_rank0_init_pass lpddr3_400_rank1_init_pass switch ddr voltage: 1.2V -> 1.25V lpddr3_init 533 lpddr3_rank0_phydraminit_pass lpddr3_cat_pass lpddr3_533_rank0_init_pass rdet_lbs_passrdet_ds_passrdet_rbs_av_passwdet_lbs_passwdet_ds_passwdet_rbs_av_passlpddr3_533_rank1_init_pass lpddr3_init 800 lpddr3_rank0_phydraminit_pass lpddr3_cat_pass lpddr3_800_rank0_init_pass rdet_lbs_passrdet_ds_passrdet_rbs_av_passwdet_lbs_passwdet_ds_passwdet_rbs_av_passlpddr3_800_rank1_init_pass ERROR: tmp_freq: 0 tmp_freq: 400000 MR8 value=:0x0000005b MR5 value=:0x00000001 Samsung DDR MR6 value=:0x00000004 MR5 value=:0x00000000 [MR7,MR6,MR5]=:0x00000401 ddr init pll1 0x00007800!ddrc_qos_init done bootloader_logger got buffer at 0x07300000, size 0x00040000 bootloader_logger: found existing buffer, size 1044, addr 24 USB_DOWNLOAD_MODE timestamp: 0xfff2c982 return from fastboot1! uFileAddress=ss=07000000 uFileAddress=ss=07000000 uFileAddress=ss=07000000 image verify failed!
@michfood hmm okay i had a look. As i can understand your phone doesn't accept the second fastboot.img. I don't think that the problem is the crctable. Maybe you have a wrong fastboot.img?? Try to get a new dump from an another phone. If your image it's an original dump then there is no reason why it fails to pass the check. The reason why i think the crc signature it's correct it is because you are able to download both images(i saw more details in 96boards forum).
the second image do not start. after loading first - it says: "timestamp: 0xfff2c982 return from fastboot1! uFileAddress=ss=07000000 image verify failed!" so it is returned from fastboot1 to onchip loader and tries to load second image - but fails. have no possibility to look normal boot as all phones are under guaranty - nobody want to solder uart pins
Actually i didn't said to you to look at a normal boot uart log. In a normal boot you'll just see the kernel booting. Maybe you second fastboot.img is faulty...
the second boot is correct - from the update.app, as the first one there is a thought that message "image verify failed" is an onchip loader message after fastboot2 loads, runs, made some checks of other partitions (broken) (with no UART messages) and exits with some error code.
here we can see difference between boot from eMMC (left) and boot from RAM (right) http://clip2net.com/s/3mFVeRi
No, i think fastboot2 doesn't boot at all. Look at ths: Code: execute_load_fastboot2: In secure mode and fastboot2 verify failed! If you try to load only one fastboot.img? what happens?
you just look at log booting from emmc. while booting from ram - no such message. and once more - after loading first fastboot to RAM it exits with message "return from fastboot1" and tries to load second file to RAM. read carefully
I've got a honor 4x which uses the same chipset. Mine is also bricked but loads into Fastboot&rescue mode, which does not allow me to update the fastboot image due to a signature verify problem (BL31 image). This is related to ARM Trusted Firmware. Also, it does not load a new update.app from the SDCARD - Simply hangs on the logo screen. Therefore, I need to force it to flash a new fastboot.img. I read the HiKey user guide, and noticed there's a J15 SEL jumper, where, when closed, will attempt to program the flash from USB OTG source. Before a pull my phone apart, I would like to know whether anybody has tried flashing a new fastboot.img via USB OTG via closing the J15 SEL jumper and whether it worked. Or if there's any other way to boot my own fastboot.img
some info. i`m looking for motherboard on ali.. have no success
Same problem michfood said: Hi people. I have new bricked Huawei Honor 4c with HiSilicon Kirin 620 octacore (Hi6620) Hardly bricked. I`ve unlocked bootloader and custom recovery used to flash it with my own update.zip from other phone (with LTE support). At the end of flashing - it turned off and bricked. BUT! After connecting to PC via USB it flashes GREEN and RED leds a few times and after windows determines it as a device with USB\VID_12D1&PID_3609&REV_0000 and named as 䕇䕎䥎 ㌲㔴㜶㤸 . It is Huawei`s VID. And after a lot of search I found a driver for it - and device became HUAWEI USB-COM 1.0. But nothing else. No flash utility, nothing. HiSilicon-IDT for K3 processor doesn`t work. After another searches I found very similar device - it`s named HiKey board. Based on Hisilicon Kirin processor too https://www.96boards.org/. As we can see - it is very close to ours phone. It is fully documented and has a lot of spec about proc and other. And in it`s manual written about recovery procedure after damage of ROM - when device is powered on - it is in "download mode" for 90 seconds - abslolutly like mine phone - after 90 second it turns off from windows. In short - it is ability to write 2 fastboot images (fastboot1.img and fastboot2.img) in RAM, launch them and using fastboot command flash images to eMMC. They use SERIAL COM PORT to manipulate with device. It uses utility called "hisi-idt.py" - it is a python script for Linux based machines. I`ve Installed Linux Mint and try it. And I`ve some result - first image is going fine and I receive "Done" But second image is always "Failed". And fastboot command "fastboot devices" do not list any devices. Viewing binaries from my ROM (Fastboot.img and Fastboot1.img) in HEX - I can see load addresses to ROM are the same as in python script. It is 0xf9800800 and 0x0700000 for both images. But.... have no success. It looks like I`m close to the goal. Any ideas? Click to expand... Click to collapse Hi, I'm stucked in the same hard brick. Could you provide a download link for the driver you found? Are there news about progresses with this issue? Thank you very much, I'll try to help if you want
In China,Hisilicon Kirin 620 is hi6210,not 6620.You can get the source code of HUAWEI Honor 4C from:http://emuirom123.dbankcloud.com/Cherrymini_kernel_[Android 5.1 EMUI3.1].tar.gz?rid=1520 It is for the China Mobile version(CHM-TL00H) with Kirin 620. Chinese version Kirin 620 runs 8×A53 1.2GHz cores and ARM Mali-450 MP4 Gpu.The baseband of hisilicon kirin 620 is Balong V8R1SFT. Sorry for my bad English. 来自搭载Android 2.3 GingerBread的华为Y220-T10
JackLenz said: Hi, I'm stucked in the same hard brick. Could you provide a download link for the driver you found? Are there news about progresses with this issue? Thank you very much, I'll try to help if you want Click to expand... Click to collapse still nothing
zhaozihanzzh said: In China,Hisilicon Kirin 620 is hi6210,not 6620.You can get the source code of HUAWEI Honor 4C from:http://emuirom123.dbankcloud.com/Cherrymini_kernel_[Android 5.1 EMUI3.1].tar.gz?rid=1520 It is for the China Mobile version(CHM-TL00H) with Kirin 620. Chinese version Kirin 620 runs 8×A53 1.2GHz cores and ARM Mali-450 MP4 Gpu.The baseband of hisilicon kirin 620 is Balong V8R1SFT. Sorry for my bad English. 来自搭载Android 2.3 GingerBread的华为Y220-T10 Click to expand... Click to collapse thanks for info - but how it helps?
michfood said: still nothing Click to expand... Click to collapse And what about the driver link?
I found some source code on github, maybe it could be useful https://github.com/muhammadfahadbaig/android_vendor_huawei_hi6210sft
Porting kexec hardboot to LG L1 II
Hi, I've read the porting kexec hardboot wiki: https://github.com/Tasssadar/multirom/wiki/Porting-kexec-hardboot and, in particular, the following step: Hard-reboot in arch/arm/kernel/relocate_kernel.S Can be found here in the patch for mako. This can often be the hardest thing to find out. Try to look for restart.c or reboot.c or something like that in your device's arch/arm/mach-xxx folder and port the restart sequence from that file to assembler. If you are using Tegra 2/3 or MSM SoC, chances are reboot methods currently (or very similar to them) in the patch will work. Click to expand... Click to collapse So, the porting guide says the restart sequence should be ported from restart.c to relocate_kernel.S. Exactly, what function I've to port from restart.c? Any ideas?
Ok, I've ported the restart sequence into relocate_kernel.S. The patch just needs the following changes: Code: #elif defined(CONFIG_ARCH_MSM7X27) #include <mach/msm_iomap.h> Code: #elif defined(CONFIG_ARCH_MSM7X27) /* Restart using the PMIC chip, see mach-msm/restart.c */ mov r0, #3 ldr r1, =0x00100000 str r0, [r1] ldr r0, =0x77665501 str r0, [r1, #0x08] mov r0, #0 str r0, [r1, #0x0C] mov r0, #1 ldr r1, =0xc0100418 str r0, [r1] loop: b loop Many thanks to a msm dev guy for the help and explanations, which I've translated into assembly code shown above :good: Now, the next part of the porting kexec hardboot wiki says: Reserving memory for kexec-hardboot page Can be found here in the patch for mako. You need to find a place where reserving memory is safe, typicaly somewhere around where memory for ram_console is reserved. It probably will be in the board's file. I usually register the page just before the ram_console, which is before the end of the first memory bank. Click to expand... Click to collapse So, my question is: what board's file is the porting guide pointing to? Any ideas?
Ok, I've reserved memory for kexec-hardboot page. This part can be done if board-msm7x27a_v1.c board's file (located into arch/arm/mach-msm/lge/v1 directory) is changed as follows: Code: static void __init msm7x27a_reserve(void) { reserve_info = &msm7x27a_reserve_info; msm_reserve(); #ifdef CONFIG_KEXEC_HARDBOOT // Reserve space for hardboot page, just before the ram_console struct membank* bank = &meminfo.bank[0]; phys_addr_t start = bank->start + bank->size - SZ_1M - SZ_1M; int ret = memblock_remove(start, SZ_1M); if(!ret) pr_info("Hardboot page reserved at 0x%X\n", start); else pr_err("Failed to reserve space for hardboot page at 0x%X!\n", start); #endif } Now, the next part of the porting kexec hardboot wiki says: Setting KEXEC_HB_PAGE_ADDR Can be found here in the patch for mako. This is highly device-specific. Either apply the patch without this value (-> set it to beggining of the System RAM) and grep dmesg for the value you printk in memory reservation ("Hardboot page reserved at 0x%X") or look into /proc/iomem to see where the first bank of System RAM ends, substract size of ram_console ram and size of the hardboot page from that and you should get the right address. Click to expand... Click to collapse This is my /proc/iomem: Code: 00200000-0fefffff : System RAM 00208000-0098207b : Kernel code 009b2000-00c03f87 : Kernel data 0ff3e000-0ff3efff : crash_log 20000000-2b4fffff : System RAM 98000000-9807ffff : lcd01 9c000000-9c07ffff : lcd02 a0000000-a001ffff : kgsl_3d0_reg_memory a0000000-a001ffff : kgsl-3d0 a0200000-a0200fff : msm_serial_hs.0 a0300000-a0300fff : uartdm_resource a0400000-a0400fff : msm_sdcc.1 a0500000-a0500fff : msm_sdcc.2 a0600000-a0600fff : msm_sdcc.3 a0800000-a08003ff : msm_hsusb_host.0 a0800000-a08003ff : msm_hsusb a0800000-a08003ff : msm_otg a0d00000-a0d00fff : base a0e00000-a0e00fff : pbus_phys_addr a0f00000-a0ffffff : csic a0f00000-a0ffffff : msm_csic a1000000-a10fffff : csic a1000000-a10fffff : msm_csic a1200000-a1200fff : gsbi_qup_i2c_addr a1200000-a1200fff : qup_i2c a1280000-a1280fff : qup_phys_addr a1280000-a1280fff : qup_i2c a1300000-a1300fff : gsbi_qup_i2c_addr a1300000-a1300fff : qup_i2c a1380000-a1380fff : qup_phys_addr a1380000-a1380fff : qup_i2c a8600000-a8600fff : clk_ctl a9700000-a9700fff : msm_dmov a9a00000-a9a00fff : msm_serial.0 a9a00000-a9a00fff : msm_serial aa200000-aa2f1007 : mdp c0400000-c0400fff : pl310_erp In particular, line related to the first bank of System RAM says: Code: 00200000-0fefffff : System RAM So, should I subtract size of ram_console ram and size of the hardboot page from 0fefffff in order to get the right value for KEXEC_HB_PAGE_ADDR? And, should I use SZ_1M for the size of hardboot page? Any ideas?
Ok, I've set KEXEC_HB_PAGE_ADDR. Briefly, I've subtracted size of the hardboot page (SZ_1M) and size of ram_console (LGE_RAM_CONSOLE_SIZE) from the end address of the System RAM first bank (0ff00000 = 0fefffff + 1). This part can be done if memory.h (located into arch/arm/mach-msm/include/mach directory) is changed as follows: Code: #if defined(CONFIG_KEXEC_HARDBOOT) #if defined(CONFIG_MACH_MSM7X25A_V1) #define KEXEC_HB_PAGE_ADDR UL(0x0FDC2000) #else #error "Adress for kexec hardboot page not defined" #endif #endif Now, the next part of the porting kexec hardboot wiki says: Setting kexec_hardboot_hook Can be found here in the patch for mako. This method should contain some device-specific code which needs to be executed during the reboot sequence. Again, can be found in restart.c or reboot.c or something like that in your device's arch/arm/mach-xxx. Chances are you don't need to set anything in here. Click to expand... Click to collapse So, what device-specific code (which needs to be executed during the reboot sequence) should this method contain, in my particular case? Can I just use only pm8xxx_reset_pwr_off function, as in the patch for mako? Any ideas?