Related
Originally posted by blagus.
Important: AS SUGGESTED BY DEVELOPERS, PLEASE USE STOCK 2.1.1.A.0.6. FLASH IT WITH FlashTool, GET FILES FROM MY Mediafire FOLDER.
All files (splboot, miniloader, boot.img, etc.) will be uploaded to this Mediafire folder.
If you compiled something and want to share it, attach it here and I'll upload it to Mediafire to have everything in one place.
cat /proc/iomem with addresses needed to modify splboot and miniloader - X8:
Code:
$ cat /proc/iomem
00200000-0d8fffff : System RAM
0022b000-006e3fff : Kernel text
006e4000-00813733 : Kernel data
02900000-02afffff : kgsl_phys_memory
0d200000-0d8fffff : Crash kernel
0d9e0000-0d9fffff : ram_console
a0000000-a001ffff : kgsl_reg_memory
a0000000-a001ffff : kgsl
a0200000-a0200fff : msm_serial_hs.0
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : TIWLAN_SDIO.2
a0800000-a08003ff : msm_hsusb
a0800000-a08003ff : msm_hsusb_periphera
a0800000-a08003ff : msm_hsusb_host.0
a0800000-a08003ff : msm_hsusb_otg
a0800000-a08003ff : msm_otg
a0a00000-a0a007ff : msm_nand_phys
a9900000-a9900fff : msm_i2c.0
a9900000-a9900fff : msm_i2c
a9c00000-a9c00fff : msm_serial.2
a9c00000-a9c00fff : msm_serial
aa200000-aa2effff : mdp
aa300000-aa300fff : tssc
aa600000-aa600fff : pmdh
Run cat /proc/mtd to find addresses needed to make boot.img. Different for X10, X8, X10 Mini (Pro).
How to make boot.img:
Download build_bootimg.zip, extract. If you're on Linux, run makeit.sh, if on Windows, run makeit.bat
Don't forget that mkbootimg's cmdline needs tweaking. Read README.txt included to find out more.
Also, to make ramdisk, place files in ramdisk-folder and execute following:
Code:
mkbootfs ./ramdisk-folder > ramdisk
This will give you cpio ramdisk archive. gzip it and you're done. Name it ramdisk.gz.
If you like my post, thank me!
Originally posted by blagus.
Important: AS SUGGESTED BY DEVELOPERS, PLEASE USE STOCK 2.1.1.A.0.6. FLASH IT WITH FlashTool, GET FILES FROM MY Mediafire FOLDER.
All files (splboot, miniloader, boot.img, etc.) will be uploaded to this Mediafire folder.
If you compiled something and want to share it, attach it here and I'll upload it to Mediafire to have everything in one place.
cat /proc/iomem with addresses needed to modify splboot and miniloader - X8:
Code:
$ cat /proc/iomem
00200000-0d8fffff : System RAM
0022b000-006e3fff : Kernel text
006e4000-00813733 : Kernel data
02900000-02afffff : kgsl_phys_memory
0d200000-0d8fffff : Crash kernel
0d9e0000-0d9fffff : ram_console
a0000000-a001ffff : kgsl_reg_memory
a0000000-a001ffff : kgsl
a0200000-a0200fff : msm_serial_hs.0
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : TIWLAN_SDIO.2
a0800000-a08003ff : msm_hsusb
a0800000-a08003ff : msm_hsusb_periphera
a0800000-a08003ff : msm_hsusb_host.0
a0800000-a08003ff : msm_hsusb_otg
a0800000-a08003ff : msm_otg
a0a00000-a0a007ff : msm_nand_phys
a9900000-a9900fff : msm_i2c.0
a9900000-a9900fff : msm_i2c
a9c00000-a9c00fff : msm_serial.2
a9c00000-a9c00fff : msm_serial
aa200000-aa2effff : mdp
aa300000-aa300fff : tssc
aa600000-aa600fff : pmdh
Run cat /proc/mtd to find addresses needed to make boot.img. Different for X10, X8, X10 Mini (Pro).
How to make boot.img:
Download build_bootimg.zip, extract. If you're on Linux, run makeit.sh, if on Windows, run makeit.bat
Don't forget that mkbootimg's cmdline needs tweaking. Read README.txt included to find out more.
Also, to make ramdisk, place files in ramdisk-folder and execute following:
Code:
mkbootfs ./ramdisk-folder > ramdisk
This will give you cpio ramdisk archive. gzip it and you're done. Name it ramdisk.gz.
>>> 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.
Hello,
I'm trying to properly invoke a proprietary syscall on ARM architecture.
Target is an ELF recovery executable (ARM Big Endian) whose sources are not available, and which has been modded from AOSP (device is Meizu MX 4-core).
I have attached my progress in a rar archive : View attachment MX4_recovery.rar.
It includes the target executable along with a .IDC script that defines a few names for IDA (works for demo version as well).
- private SWI number is 0xF0066
- the sub invoking syscall is @00009350 getRcvKeyFrmKrnSYSCALL
recovery_printkey is my lame attempt at invoking the SVC 0 in C+ASM.
Code:
.global _myasmfunc
_myasmfunc:
.func _myasmfunc
@ RcvKeyFrmKrn syscall
ldr r7, =0xF0066
ldr r2, =_g_ptrfd
ldr r0, [r2]
ldr r1, =_g_buf
ldr r2, =_g_mode
swi #0
bx lr
.endfunc
After compiling (utility script in homedir), transferring and running on the device, RC=0 but all buffers are unchanged. I tried various combinations.
I wish I could breakpoint right before the SVC 0 instruction, but sadly cannot.
I am not too well-versed and probably made a mistake in analysing how parameters are set.
What I need to know:
[Q] What goes into the ARM registers, based on sub_CAB0 execution?
Can you please help?
Situation solved.
Only R0 register is used for 0xF0066 in the swi call site (0x400 buffer).
I thought I'd post an update since some progress has been made, though there are still some things missing.
The current plan is to make a unified kernel for all Universal 5420-based devices, including our Note, the 12.2, and Tab S. I've managed to forward-port a lot of the necessary drivers to Linux 3.14. Most come from Samsung's Universal 5422, 5430, 5433 and 7420 kernels (Linux 3.10), while other stuff such as the Mali GPU drivers were taken from one of Linaro's 3.14 kernel trees along with Mali platform support for the Exynos5420-based Arndale Octa board. Currently I have only been focusing on SM-P600 support since that's the tablet I will be testing it on, but once I make sure it runs I'll be adding in support for other devices as well.
What's done so far:
* Maxim max77802 drivers (PMIC, regulator)
* Maxim max77888 drivers (PMIC, MUIC, LED, regulator, haptic)
- These will be used as a base for max77803 support since it's essentially the same driver
* Samsung's TN extension features
* Samsung's USB notify layer
* Samsung's battery/charger/fuelgauge drivers
Also:
* The sii8240 driver has been pulled in, though it doesn't compile yet
* The sensors are all supported in mainline so their drivers can easily be cherry-picked
Todo:
* Port over the LCD driver (LSL101DL01 / LSL122DL01)
- It needs to be adapted to the new display port driver (exynos-dp) instead of the old s5p-dp driver.
- It also requires device tree support, which is absent in 3.4, whereas board files are not supported in 3.14.
- This is beyond my skill and knowledge so if there's anyone reading this who can- and is willing to help please contact me.
* Write a board-specific DT blob.
* Probably a few more things that I'm forgetting.
Source/changelog: here
Feel free to fork this if you wish to help with development, just make sure to notify me if you do.
Original post:
Hi guys,
As some of you may know, the Linux kernel for ARM has long migrated from the use of board files to the use of device tree blobs for providing hardware descriptions to the kernel. Still, Samsung seems to insist on relying on all this unnecessary junk code instead of migrating to the use of device trees for their Exynos devices. Currently, the only Exynos5420-based device trees in existance are for development boards such as the Arndale Octa and the SMDK5420. No device tree exists for the UNIVERSAL5420 board and its variants which are found in the Galaxy Note and Tab series. So, I decided to write one.
I am no programming expert but seeing as the device tree syntax is not that complex, I thought, how hard can it be? The hardest part is basically combing through all the board files and searching for whatever stands up as being relevant in the device tree format as well as figuring out the correct unit-addresses, most of which seem to be listed in /arch/arm/mach-exynos/include/mach/map.h.
I'm using the SMDK5420 device tree as a base since it seems to be a watered-down development version of the UNIVERSAL5420 board. Still, there's a lot of stuff that needs to be added in and certain bits also need replacing. So far I have added in the nodes for the Maxim MAX77802 PMIC and its regulators as well as the nodes for the charger and a few 'skeletons' for the screen, the ARM Mali GPU and the Wolfson WM5102 codec. Some of these may still have incorrect unit addresses and other bits may still be incorrect or unnecessary.
If this project becomes successful it might:
Allow us to run higher kernel versions (i.e. above Linux 3.4) on our devices.
Make it easier to create ports of open source bootloaders such as u-boot or kexecboot for our devices.
Open up new doors in getting Global Task Scheduling (big.LITTLE MP) to work on the universal5420, as has been achieved on exynos5420-based development boards.
The project is located in my git repository here along with the SM-P600 board files and other references.
This is obviously still in early development but if anyone here who is familiar with the device tree syntax is willing to review my code and provide some constructive criticism it would be much appreciated.
For further information on the device tree and its syntax, here are some helpful links:
http://www.devicetree.org/Device_Tree_Usage
https://www.power.org/documentation/epapr-version-1-1/
https://www.kernel.org/doc/Documentation/devicetree/
http://lwn.net/Articles/572692/ (Device trees I: Are we having fun yet?)
http://lwn.net/Articles/573409/ (Device trees II: The harder parts)
Click to expand...
Click to collapse
XDA:DevDB Information
Unified Exynos 5420 Kernel, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain
Source Code: https://github.com/sigma-1/universal5420-device-tree
Kernel Special Features:
Version Information
Status: Testing
Created 2014-10-31
Last Updated 2015-08-27
Well ... Wish you luck with the Development ...
Andmoreagain said:
Hi guys,
As some of you may know, the Linux kernel for ARM has long migrated from the use of board files to the use of device tree blobs for providing hardware descriptions to the kernel. Still, Samsung seems to insist on relying on all this unnecessary junk code instead of migrating to the use of device trees for their Exynos devices. Currently, the only Exynos5420-based device trees in existance are for development boards such as the Arndale Octa and the SMDK5420. No device tree exists for the UNIVERSAL5420 board and its variants which are found in the Galaxy Note and Tab series. So, I decided to write one.
I am no programming expert but seeing as the device tree syntax is not that complex, I thought, how hard can it be? The hardest part is basically combing through all the board files and searching for whatever stands up as being relevant in the device tree format as well as figuring out the correct unit-addresses, most of which seem to be listed in /arch/arm/mach-exynos/include/mach/map.h.
I'm using the SMDK5420 device tree as a base since it seems to be a watered-down development version of the UNIVERSAL5420 board. Still, there's a lot of stuff that needs to be added in and certain bits also need replacing. So far I have added in the nodes for the Maxim MAX77802 PMIC and its regulators as well as the nodes for the charger and a few 'skeletons' for the screen, the ARM Mali GPU and the Wolfson WM5102 codec. Some of these may still have incorrect unit addresses and other bits may still be incorrect or unnecessary.
If this project becomes successful it might:
Allow us to run higher kernel versions (i.e. above Linux 3.4) on our devices.
Make it easier to create ports of open source bootloaders such as u-boot or kexecboot for our devices.
Open up new doors in getting Global Task Scheduling (big.LITTLE MP) to work on the universal5420, as has been achieved on exynos5420-based development boards.
The project is located in my git repository here along with the SM-P600 board files and other references.
This is obviously still in early development but if anyone here who is familiar with the device tree syntax is willing to review my code and provide some constructive criticism it would be much appreciated.
For further information on the device tree and its syntax, here are some helpful links:
http://www.devicetree.org/Device_Tree_Usage
https://www.power.org/documentation/epapr-version-1-1/
https://www.kernel.org/doc/Documentation/devicetree/
http://lwn.net/Articles/572692/ (Device trees I: Are we having fun yet?)
http://lwn.net/Articles/573409/ (Device trees II: The harder parts)
XDA:DevDB Information
UNIVERSAL5420 Device Tree, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain
Kernel Special Features:
Version Information
Status: Testing
Created 2014-10-31
Last Updated 2014-11-01
Click to expand...
Click to collapse
Dear friend , maybe @xluco can help us get the device tree so that we can clear a way for AOSP and such ROMs to our SM-P600/1 ... Good Luck
With Best Wishes
Hitman1376
hitman1376 said:
Dear friend , maybe @xluco can help us get the device tree so that we can clear a way for AOSP and such ROMs to our SM-P600/1 ... Good Luck
With Best Wishes
Hitman1376
Click to expand...
Click to collapse
Thanks, unfortunately I'm not that familiar with the android source code. At least it will probably be easier to gather all the device information once we get everything into a single file.
But anyway, I did an adb pull of the /dev, /proc and /sys directories from my p600. Found lots of useful info, especially for calculating some of the interrupt values. The gpu node is also complete, although I have yet to update my repo.
I'm also going to grab myself a development board tomorrow in hopes of getting a better picture of what I'm doing. I need to be able to visualize things as I work on this stuff.
Well ... Finally Good news ...
Andmoreagain said:
Thanks, unfortunately I'm not that familiar with the android source code. At least it will probably be easier to gather all the device information once we get everything into a single file.
But anyway, I did an adb pull of the /dev, /proc and /sys directories from my p600. Found lots of useful info, especially for calculating some of the interrupt values. The gpu node is also complete, although I have yet to update my repo.
I'm also going to grab myself a development board tomorrow in hopes of getting a better picture of what I'm doing. I need to be able to visualize things as I work on this stuff.
Click to expand...
Click to collapse
Well ... seems like you know what to do ( And managed it out well :good: ... I took a look into the GitHub ... Good work :good: ) ... but , if there were any problems , I would be glad to help ( I own a P601 but it doesn't matter ... their almost the same ... ) ...
Wish you luck with the Development
Hitman1376
Excellent project mate, good luck! I'd offer some support but I don't know a single thing about device trees
Some updates!
Hey guys!
I had to take a long break from this project due to school and other stuff, but I'm at it again. I have done some homework along the way, and since there now exists a flattened device tree for the universal5422 board and several newer Exynos devices, it makes this work much easier since the universal5420 and 5422 are identical in many aspects, though not completely.
Now, to better explain what this project is all about and to clear up some confusion, a flattened device tree or a device tree blob is not the same thing as the android "device tree", required for compiling android for a specific device. The so-called flattened device tree is compiled as a separate binary along the kernel and describes the hardware of the device to the kernel in order to load the correct device drivers. In the past, ARM devices had to rely on so-called board files, such as all the board-*.c and dev-*.c files found in the arch/arm/mach-exynos directory of the stock kernel's source code for our device. This was a problematic solution, mostly because:
A) It meant that each vendor had to throw together a special branch of linux for every single device, containing a huge amount of device-specific code in order to load the necessary drivers.
B) There is an ongoing project, called the Android Mainlining Project, and I quote:
The goal of this project is to ultimately mainline all patches required to run the current released version of Android. The purpose of mainlining these patches is 3-fold:
to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers
To "mainline" a patch means to have it included in Linus Torvalds' kernel.org kernel, in a released (non-rc) version.
Click to expand...
Click to collapse
For some basic info regarding the Board File to Device Tree Migration, this document would be a good start.
"The Device Tree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspects of the hardware can be described in a data structure that is passed to the operating system at boot time."
Click to expand...
Click to collapse
Now, some updates:
I finally have a decent picture of each and every device available on our board, their addresses, and configurations. I have also documented which device is connected to which I2C (inter-integrated circuit) bus, but there are still several things that need to be figured out regarding this whole I2C labyrinth.
To begin with, the aliases listed in the generic exynos5420.dtsi device tree are as follows:
aliases {
mshc0 = &mmc_0;
mshc1 = &mmc_1;
mshc2 = &mmc_2;
pinctrl0 = &pinctrl_0;
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
pinctrl4 = &pinctrl_4;
i2c0 = &i2c_0;
i2c1 = &i2c_1;
i2c2 = &i2c_2;
i2c3 = &i2c_3;
i2c4 = &hsi2c_4;
i2c5 = &hsi2c_5;
i2c6 = &hsi2c_6;
i2c7 = &hsi2c_7;
i2c8 = &hsi2c_8;
i2c9 = &hsi2c_9;
i2c10 = &hsi2c_10;
gsc0 = &gsc_0;
gsc1 = &gsc_1;
spi0 = &spi_0;
spi1 = &spi_1;
spi2 = &spi_2;
usbdrdphy0 = &usbdrd_phy0;
usbdrdphy1 = &usbdrd_phy1;
};
Click to expand...
Click to collapse
As you can see, the I2C's are numbered from 0 to 10, making them 11 in total, where i2c's 4 - 10 apparently have the "high speed" or hs setting enabled.
This is a bit confusing to me, because the I2C buses that are actually in use, as seen in rootfs/sys/bus/i2c/devices, gives a different set of numbers:
i2c-0
i2c-1
i2c-3
i2c-7
i2c-8
i2c-10
i2c-17
i2c-18
i2c-22
i2c-24
Click to expand...
Click to collapse
And here are the devices assigned to them:
i2c-0
[email protected]
[email protected] (screen)
i2c-1
[email protected]
i2c-3
[email protected]
[email protected]
[email protected]
[email protected]
i2c-7
[email protected]
i2c-8
[email protected] (the digitizer or epen)
(?)@9 // device name not listed, but the address is the same as that of the maxim pmic on i2c-7 //
i2c-10
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
i2c-17
(?)@25
(?)@48
[email protected]
i2c-18
[email protected]
i2c-22
[email protected]
i2c-24
[email protected]
[email protected]
In the "drivers" folder I also found the following, but they were not assigned to a bus or an address:
exynos_edid
exynos_hdcp
ir-kbd-i2c
Click to expand...
Click to collapse
Anyway, if the i2c buses only go from 0 - 10 in the generic Exynos5420 device tree, then why do we also have 17, 18, 22 and 24 appearing here?
Furthermore, here is how their addresses are listed in the stock source code (arch/arm/mach-exynos/include/map.h)
#define EXYNOS5_PA_IIC(x) (0x12C60000 + ((x) * 0x10000))
#define EXYNOS5420_PA_HSIIC0 0x12CA0000
#define EXYNOS5420_PA_HSIIC1 0x12CB0000
#define EXYNOS5420_PA_HSIIC2 0x12CC0000
#define EXYNOS5420_PA_HSIIC3 0x12CD0000
#define EXYNOS5420_PA_HSIIC4 0x12E00000
#define EXYNOS5420_PA_HSIIC5 0x12E10000
#define EXYNOS5420_PA_HSIIC6 0x12E20000
Click to expand...
Click to collapse
Aaaand if we look into rootfs/proc/iomem, we find this:
12c60000-12c60fff : s3c2440-i2c
12c70000-12c70fff : s3c2440-i2c.1
12c70000-12c70fff : s3c2440-i2c
12c90000-12c90fff : s3c2440-i2c.3
12c90000-12c90fff : s3c2440-i2c
12cd0000-12cd0fff : exynos5-hs-i2c
12e00000-12e00fff : exynos5-hs-i2c
12e20000-12e20fff : exynos5-hs-i2c.6
12e20000-12e20fff : exynos5-hs-i2c
12c60000-12c60fff : s3c2440-i2c.0
12cd0000-12cd0fff : exynos5-hs-i2c.3
12e00000-12e00fff : exynos5-hs-i2c.4
Click to expand...
Click to collapse
I'm currently working on building CM12 with some additional packages such as i2c-tools and some extra kernel debugging features. But in the meantime, if anyone here can help solve this entire I2C puzzle then it would be of great help. We have the devices, their addresses, etc., but which bus is which compared to the generic Exynos5420 device tree "header" (for lack of a better term) is my biggest question at the moment.
If the final outcome of this project actually works, then there won't be anything standing in the way of compiling, say, linux-linaro-lsk-v3.10-android with full HMP support. Sure, some proprietary kernel drivers may have to be integrated such as the Mali drivers but I have already tried to bake them into linux 3.14 and it compiled without any errors whatsoever. Hell, we might even be able to finally upgrade them by grabbing the latest sources from ARM! In any case it's worth a try because f*ck the sammy police!
So as far as I can tell, Samsung have decided that despite having five free I2C ports, they're going to move four of their I2Cs to be bit-banged on GPIOs. I think this should be sufficient for those four (11, 17, 22 and 24) in a device tree:
Code:
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpd1 4 0 /* sda */
&gpd1 5 0 /* scl */
>;
i2c-gpio,delay-us = <1>;
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpb3 6 0 /* sda */
&gpb3 7 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa1 5 0 /* sda */
&gpa1 4 0 /* scl */
>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa2 2 0 /* sda */
&gpa2 3 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
};
The addresses of the other ports appear to agree with the existing code in exynos5420-pinctrl.dtsi:
Code:
s3c2440-i2c.0 = [email protected]
s3c2440-i2c.1 = [email protected]
s3c2440-i2c.2 = [email protected]
s3c2440-i2c.3 = [email protected]
exynos5-hs-i2c.0 = [email protected]
exynos5-hs-i2c.1 = [email protected]
exynos5-hs-i2c.2 = [email protected]
exynos5-hs-i2c.3 = [email protected]
exynos5-hs-i2c.4 = [email protected]
exynos5-hs-i2c.5 = [email protected]
exynos5-hs-i2c.6 = [email protected]
-d
Well, HMP is trully what's left missing from this tab. I mean we've got good roms, AOSP support, having its hardware completely unlocked would be the last piece of the puzzle at it were ... Personally it would give me smooth Linux via framebuffer, at it stands it's CPU (core) limited, often maxing all 4 cores, having 8 cores to stretch its legs even with throttling in place (it) would be a blessing. Smooth desktop OS on a Note tablet would be a first.
Hmmm, having no (significant) kernel experience my support would be confined to that of encouragement ... oh well. Good luck to you sir!
I'm out of town and left my laptop at home, but here's a new draft for the iic nodes I made on my phone:
Code:
[email protected] {
[email protected] {
};
[email protected] {
};
};
[email protected] {
[email protected] {
};
};
[email protected] {
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
};
[email protected] {
clock-frequency = <400000>;
status = "okay";
[email protected] {
compatible = "maxim,max77802";
interrupt-parent = <&gpx0>;
interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&max77802_irq>;
wakeup-source;
reg = <0x9>;
voltage-regulators {
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck2_reg: BUCK2 {
regulator-name = "vdd_arm";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1500000>;
regulator-apply-uV;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck3_reg: BUCK3 {
regulator-name = "vdd_int";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck4_reg: BUCK4 {
regulator-name = "vdd_g3d";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck6_reg: BUCK6 {
regulator-name = "vdd_kfc";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
ldo2_reg: LDO2 {
regulator-name ="VMEM2_1.2V_AP";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo3_reg: LDO3 {
regulator-name = "VCC_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo4_reg: LDO4 {
regulator-name = "VMMC2_2.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo5_reg: LDO5 {
regulator-name = "VHSIC_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo6_reg: LDO6 {
regulator-name = "VXPLL_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo8_reg: LDO8 {
regulator-name = "VMIPI_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo9_reg: LDO9 {
regulator-name = "VADC_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo10_reg: LDO10 {
regulator-name = "VMIPI_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo11_reg: LDO11 {
regulator-name = "VDDQ_PRE_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo12_reg: LDO12 {
regulator-name = "VUOTG_3.0V_AP";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo14_reg: LDO14 {
regulator-name = "VABB1_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo15_reg: LDO15 {
regulator-name = "VHSIC_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo17_reg: LDO17 {
regulator-name = "VG3DS_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo18_reg: LDO18 {
regulator-name = "CAM_ISP_SENSOR_IO_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo19_reg: LDO19 {
regulator-name = "VT_CAM_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo23_reg: LDO23 {
regulator-name = "KEY_LED_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo24_reg: LDO24 {
regulator-name = "CAM_AF_2.8_PM";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo25_reg: LDO25 {
regulator-name = "VCC_3.3V_MHL";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo26_reg: LDO26 {
regulator-name = "VCC_3.0V_MOTOR";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo27_reg: LDO27 {
regulator-name = "VSIL_1.2A";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo28_reg: LDO28 {
regulator-name = "VCC_1.8V_MHL";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo29_reg: LDO29 {
regulator-name = "TSP_VDD_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo30_reg: LDO30 {
regulator-name = "VMIFS_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo32_reg: LDO32 {
regulator-name = "IRLED_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo33_reg: LDO33 {
regulator-name = "VCC_2.8V_AP";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo35_reg: LDO35 {
regulator-name = "CAM_SENSOR_CORE_1.2V";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
};
};
};
[email protected] {
[email protected] {
};
};
[email protected] {
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpd1 4 0 /* sda */
&gpd1 5 0 /* scl */
>;
i2c-gpio,delay-us = <1>;
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpb3 6 0 /* sda */
&gpb3 7 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa1 5 0 /* sda */
&gpa1 4 0 /* scl */
>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa2 2 0 /* sda */
&gpa2 3 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
[email protected] {
};
};
EDIT:
Oh and some great news! I just had a long and interesting conversation with a local who noticed me while I was writing this earlier and asked me about it. Surprisingly, after I told him about my project he said he knew exactly what I was talking about. Turned out he's a developer who specializes in embedded linux systems and has actual experience with writing flattened device trees. What's even better is that he's willing to help me with this!
This has just taken an interesting turn so stay tuned...
Hi mate!
I really want to help you but I don't know how to programming in Linux(for the moment) and I know little bit in Android. My hoght school profile is based on IT and programming but unfortunately i don't make on these langage, I'm making only C++ and C#.The point is: I want to help you and the CM devs to resolve the bugs. I'm waiting response form Sand Pox.
If u find me useful pm to me and I will try to help u. Good luck !
Good luck!
Kryptocid said:
Hi mate!
I really want to help you but I don't know how to programming in Linux(for the moment) and I know little bit in Android. My hoght school profile is based on IT and programming but unfortunately i don't make on these langage, I'm making only C++ and C#.The point is: I want to help you and the CM devs to resolve the bugs. I'm waiting response form Sand Pox.
If u find me useful pm to me and I will try to help u. Good luck !
Click to expand...
Click to collapse
Hey! I just sent you a PM
I just put up a new repo with the current progress. I'll add more reference stuff later on, but here's the link to the repo: https://bitbucket.org/sigma-1/exynos5420_lt03wifi_dts
Hallo?
So, I think it's time to declare my research on the flattened device tree officially over. What I have thrown together so far gives me a good idea of how the fdt should eventually look like, although it's not completely accurate.
What should happen now is basically device driver development. Since I'm aiming for Linux 3.18.y there are some things that need to be considered. The SM-P600 relies on certain drivers that are exclusively present in the stock kernel, but some of them can also be found in other Samsung kernels which range from v3.4 to 3.10.
Some of these drivers can be swapped out for generic drivers, while others need to be ported over. My current plan is to start by compiling a system with only just the minimal hardware support to make it boot.
Android's branch of the 3.18 kernel has much of the required support already, but there are at least two major drivers that must be implemented, namely the LCD driver and drivers for the max77803 pmic from Maxim Integrated. The latter does not play that much of an essential part as the max77802 pmic which is already supported in the kernel, but one of the things it controls is the charging mechanism which I believe is pretty much essential.
Also, there is no support for the proprietary battery/charger/fuelgauge drivers from Samsung. Hopefully the generic driver works just as well even though I literally have no idea how it will work out.
Our max17050 fuel gauge is already supported, it's just the max77803 "charger" part that needs to be figured out.
Once the device boots, the rest of the drivers can be implemented one by one as kernel modules once they have been adapted to linux 3.18. That's also where device tree overlays come in, which is one of the cool features of the device tree implementation.
So, I guess I'm off to learn how to write linux device drivers. Guess I'll just write the LCD driver from scratch. The Maxim drivers all look very similar so the 3.4 verson can probably just be upgraded in accordance with the ones already present in Linus' tree.
Another thing to note here is that the ARM Mali GPU drivers are not present in the upstream linux kernel. On the other hand, they have been reverse-engineered and implemented into the Direct Rendering Manager (DRM). What that means though is that the proprietary libs will no longer work. Instead, libdrm would have to be implemented into the android source along with its exynos-specific support libs.
The Mali/Midgard drivers could be implemented into the kernel source, but I personally like the open source alternative better as long as it works.
Andmoreagain said:
So, I think it's time to declare my research on the flattened device tree officially over. What I have thrown together so far gives me a good idea of how the fdt should eventually look like, although it's not completely accurate.
What should happen now is basically device driver development. Since I'm aiming for Linux 3.18.y there are some things that need to be considered. The SM-P600 relies on certain drivers that are exclusively present in the stock kernel, but some of them can also be found in other Samsung kernels which range from v3.4 to 3.10.
Some of these drivers can be swapped out for generic drivers, while others need to be ported over. My current plan is to start by compiling a system with only just the minimal hardware support to make it boot.
Android's branch of the 3.18 kernel has much of the required support already, but there are at least two major drivers that must be implemented, namely the LCD driver and drivers for the max77803 pmic from Maxim Integrated. The latter does not play that much of an essential part as the max77802 pmic which is already supported in the kernel, but one of the things it controls is the charging mechanism which I believe is pretty much essential.
Also, there is no support for the proprietary battery/charger/fuelgauge drivers from Samsung. Hopefully the generic driver works just as well even though I literally have no idea how it will work out.
Our max17050 fuel gauge is already supported, it's just the max77803 "charger" part that needs to be figured out.
Once the device boots, the rest of the drivers can be implemented one by one as kernel modules once they have been adapted to linux 3.18. That's also where device tree overlays come in, which is one of the cool features of the device tree implementation.
So, I guess I'm off to learn how to write linux device drivers. Guess I'll just write the LCD driver from scratch. The Maxim drivers all look very similar so the 3.4 verson can probably just be upgraded in accordance with the ones already present in Linus' tree.
Another thing to note here is that the ARM Mali GPU drivers are not present in the upstream linux kernel. On the other hand, they have been reverse-engineered and implemented into the Direct Rendering Manager (DRM). What that means though is that the proprietary libs will no longer work. Instead, libdrm would have to be implemented into the android source along with its exynos-specific support libs.
The Mali/Midgard drivers could be implemented into the kernel source, but I personally like the open source alternative better as long as it works.
Click to expand...
Click to collapse
Keep it up! Good work
Is it worth considering a possible arm port of Ubuntu? How about Ubuntu Touch to make use of SPEN?
So far it looks as though your effort has the depth and scope ... is it something you would consider worth exploring?
xda_nikita said:
Is it worth considering a possible arm port of Ubuntu? How about Ubuntu Touch to make use of SPEN?
So far it looks as though your effort has the depth and scope ... is it something you would consider worth exploring?
Click to expand...
Click to collapse
I actually intend on starting with building a regular Linux rootfs with a desktop distro such as Ubuntu before jumping on to a full android build. In regards to s-pen functionality, I won't be focusing on that until everything else is working as it should. I hope it can be supported eventually though. I myself would love to be able to draw directly in GIMP or InkScape with the s-pen.
My first aim is to get the u-boot bootloader up and running. That alone would open up a lot of possibilities for future development as well as true multi boot.
So I've been tinkering with this a bit, and I'm currently pulling in some Samsung drivers to a linux-linaro v3.13 tree. I decided to go with this particular kernel base since it's not too different from linux 3.10 and because it has native support for exynos5420 which upstream android/linux-3.10 doesn't. My original thought was to use linux 3.18, but it just presented me with too much incompatibility with the 3.10 drivers.
I've also found a suitable driver for the max77803 PMIC. It's actually for max77888, but our stock driver is based on the max77888 driver and they're almost identical for that matter. Pulled it in from a 3.10 tree along with the battery+motor drivers and a driver for the sii8240 chip. I'm still fixing up some missing includes before I start diffing it against the stock drivers. I'll post an update once it all compiles without an issue.
Edit:
Fixed up some build errors with the sec_battery driver, now running into some "field has incomplete type" error with max17050 fuelgauge driver. Not sure what to make of this so if anyone has any ideas it would be greatly appreciated.
Code:
LD drivers/base/built-in.o
CC drivers/battery/sec_battery.o
CC drivers/battery/sec_adc.o
CC drivers/battery/max17050_fuelgauge.o
In file included from drivers/battery/max17050_fuelgauge.c:15:0:
include/linux/battery/sec_fuelgauge.h:60:19: error: field 'fuel_alert_wake_lock' has incomplete type
struct wake_lock fuel_alert_wake_lock;
^
scripts/Makefile.build:308: recipe for target 'drivers/battery/max17050_fuelgauge.o' failed
make[2]: *** [drivers/battery/max17050_fuelgauge.o] Error 1
scripts/Makefile.build:455: recipe for target 'drivers/battery' failed
make[1]: *** [drivers/battery] Error 2
Makefile:816: recipe for target 'drivers' failed
make: *** [drivers] Error 2
Source code: https://bitbucket.org/sigma-1/linux-linaro-3.13-2014.01
I also find Samsung's 3.10 kernels a bit odd looking in some aspects. They still use deprecated macros such as __devinit and __devexit that shouldn't be present in 3.10 at all. Anyway, I'm gonna continue to try and sort this out.
Hi not a developer (so far) but did someone read about this device here?
There is a Linux running on an Samsung Exynos5422 Cortex™-A15
Its maybe helpfull to get some stuff thats not supported from Samsung opensource
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
peterpan07 said:
Hi not a developer (so far) but did someone read about this device here?
There is a Linux running on an Samsung Exynos5422 Cortex™-A15
Its maybe helpfull to get some stuff thats not supported from Samsung opensource
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
Click to expand...
Click to collapse
Yeah, the Exynos series of SoC's are all supported upstream, including Exynos 5420. The current kernel base I'm using comes from Linaro and not Samsung OSRC and it has most of the required support already. The upstream kernel actually has much better and advanced support for the Exynos series than any of Samsung's stock kernels. They just seem to be more interested in actually providing upstream support for the development boards while end-user devices such as phones and tablets get no such support. It's understandable and in most cases this doesn't really make much difference to the end-user. Exynos 5420 is a special case though IMO because our stock kernel still doesn't properly support all the capabilities it has to offer.
The issue we're facing is basically that Samsung's phones and tablets rely on hardware that isn't entirely supported upstream. Like I've mentioned before, an example would be the PMICs that are commonly used in Samsung's products. Usually these are chips manufactured by Maxim Integrated and while a handful of these chips have upstream kernel support, most of them don't and their drivers are exclusively found in Samsung OSRC kernel trees. Thankfully the PMICs are the least of my worries in this context because these drivers are all based on one another and all look pretty similar for that matter. Basically the only thing that truly needs to be worked upon in this early phase is the driver for our LCD (LSL101DL01). If simply adding OF/Device Tree support to the driver doesn't work then it may have to be rewritten in order for it to work properly with linux v3.10 and higher. I simply haven't started looking into it enough to be able to say anything about it at this point.
The PMICs are my current priority, since support for max77802/803 will also be needed for the u-boot bootloader as far as my understanding goes. Otherwise it doesn't seem like u-boot requires much driver support compared to the kernel.
Current todo list:
- Apply upstream patches for max77802 support
- Get max77803 (muic, motor, leds, charger), max17050 (fuel gauge) and Samsung's battery drivers working
- Forward-port the LCD driver to play nicely with Linux v3.10 or higher
- Add device tree bindings for all of the above
Again, any help would be appreciated. I'm personally just learning things as I go along so if there's anyone here who has experience with C/kernel programming and might be willing to contribute to this project or even just provide some insight or ideas, then please let me know! The more, the merrier!
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