Related
>>> 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.
I am looking to compile a new kernel for this device. I have pulled off the boot.img file from /dev/block/nandc and used split_bootimg.pl to pull apart the kernel and the boot ramdisk. I have used extract-ikconfig to get the kernel config and built my new 3.4 kernel (with modules). So far so good...
I have tried to build the new boot.img file with no avail. My concern is with the original kernel as the new one should be build the same (I think). It looks like it is not compressed as I run the command
file boot.img-kernel
It returns
boot.img-kernel: data
So it is not a Linux kernel ARM boot executable zImage
Is this correct? Can Android boot with this or is the split_bootimg.pl tool not creating the file correctly (it does pull the ramdisk as I have uncompressed it fine! and the file does contain the kernel config)
Ok So assuming I can create a proper boot.img with my built zImage and the old ramdisk, what do I need to do with the modules? Do I update the boot.img on the tablet and copy the modules over to the existing /system/lib/modules? (this appears to not work)
I did not find an exact guide on android kernel and the modules....
Domenic
link to the old (working) boot.img hxxps://docs.google.com/file/d/0B0c1jpaziDZ-NU5Sd18wbUVjN1E/edit?usp=sharing
some progress
domenictroilo said:
I am looking to compile a new kernel for this device. I have pulled off the boot.img file from /dev/block/nandc and used split_bootimg.pl to pull apart the kernel and the boot ramdisk. I have used extract-ikconfig to get the kernel config and built my new 3.4 kernel (with modules). So far so good...
I have tried to build the new boot.img file with no avail. My concern is with the original kernel as the new one should be build the same (I think). It looks like it is not compressed as I run the command
file boot.img-kernel
It returns
boot.img-kernel: data
So it is not a Linux kernel ARM boot executable zImage
Is this correct? Can Android boot with this or is the split_bootimg.pl tool not creating the file correctly (it does pull the ramdisk as I have uncompressed it fine! and the file does contain the kernel config)
Ok So assuming I can create a proper boot.img with my built zImage and the old ramdisk, what do I need to do with the modules? Do I update the boot.img on the tablet and copy the modules over to the existing /system/lib/modules? (this appears to not work)
I did not find an exact guide on android kernel and the modules....
Domenic
link to the old (working) boot.img hxxps://docs.google.com/file/d/0B0c1jpaziDZ-NU5Sd18wbUVjN1E/edit?usp=sharing
Click to expand...
Click to collapse
Ok so the mkimage command can be used to pull the uImage out of the Kernel Part of the file like this:
mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Linux 3.0.8" -d uImage boot.img-kernel2
The only question is where in the boot process can I find the "Load Address" and "Entry Point" values that are required to create my uImage. I would think that these are going to be needed as options when I build my new kernel, and I will need to change the boot process or add a boot.scr file with my options. I have mounted the /dev/block/nanda partition (uBoot partition) but am not certain on where I would find the current environment values.
I did find this little snippet on the net that referes to the base address for this device xxx.tabletroms.com/forums/all-other-android-tablets-general-discussion/5791-full-specs-whatever-else-polaroid-pmid10c-tablet-2.htmlx
mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' --board sun4i --base 0x40000000 -o boot.img
But he never discusses where he found the -base address. Is this the same as the Load Address and Entry Point?
Domenic
domenictroilo said:
Ok so the mkimage command can be used to pull the uImage out of the Kernel Part of the file like this:
mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Linux 3.0.8" -d uImage boot.img-kernel2
The only question is where in the boot process can I find the "Load Address" and "Entry Point" values that are required to create my uImage. I would think that these are going to be needed as options when I build my new kernel, and I will need to change the boot process or add a boot.scr file with my options. I have mounted the /dev/block/nanda partition (uBoot partition) but am not certain on where I would find the current environment values.
I did find this little snippet on the net that referes to the base address for this device xxx.tabletroms.com/forums/all-other-android-tablets-general-discussion/5791-full-specs-whatever-else-polaroid-pmid10c-tablet-2.htmlx
mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' --board sun4i --base 0x40000000 -o boot.img
But he never discusses where he found the -base address. Is this the same as the Load Address and Entry Point?
Domenic
Click to expand...
Click to collapse
So the base address is found in script.bin (converted to text file with bin2fex tool). This is the information found in it:
[dram_para]
dram_baseaddr = 0x40000000
Still how do I find the "Load Address" and "Entry Point" for the current kernel...
unmkbootimg
domenictroilo said:
So the base address is found in script.bin (converted to text file with bin2fex tool). This is the information found in it:
[dram_para]
dram_baseaddr = 0x40000000
Still how do I find the "Load Address" and "Entry Point" for the current kernel...
Click to expand...
Click to collapse
Well more reading leads me to use unmkbootimg but on my linux 32bit system all I get is:
# strace ./unmkbootimg
execve("./unmkbootimg", ["./unmkbootimg"], [/* 20 vars */]) = 0
--- SIGILL (Illegal instruction) @ 0 (0) ---
+++ killed by SIGILL +++
Illegal instruction
Too bad I can see the souce code to find out what this program is doing or compile it for myself.....
split_bootimg.pl should give you the parameters i listed on tabletroms.
What source are you using? Polaroid never coughed any up and i last harassed them in February.
bigsupersquid said:
split_bootimg.pl should give you the parameters i listed on tabletroms.
What source are you using? Polaroid never coughed any up and i last harassed them in February.
Click to expand...
Click to collapse
Here is the split:
letourneau:~/tmp# ../split_bootimg.pl /root/boot.img
Page size: 2048 (0x00000800)
Kernel size: 8112836 (0x007bcac4)
Ramdisk size: 210343 (0x000335a7)
Second size: 0 (0x00000000)
Board name:
Command line: console=ttyS0,115200 rw init=/init loglevel=8
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.
I am using the linux--sunxi kernel for now with an additional patch for dmard06.ko (which I do not expect to work!) I emailed them for the kernel source but just received a form email saying they will get back to me..... oh well I will as again.
Just playing around for now to see if a newer kernel will tweek up the speed on this device as it is very laggy.
Domenic
I may be using an older version of split_bootimg.pl?
On another note, I was able to execute unmkbootimg on a different linux server. I was attempting to run it on a PIII 800 so it needs something > a pentium (I guess).
./unmkbootimg boot.img
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
Kernel size 8112836
Kernel address 0x40008000
Ramdisk size 210343
Ramdisk address 0x41000000
Secondary size 0
Secondary address 0x40f00000
Kernel tags address 0x40000100
Flash page size 2048
Board name is ""
Command line "console=ttyS0,115200 rw init=/init loglevel=8"
This image is built using standard mkbootimg
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x40000000 --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' -o new_boot.img
---------------
Domenic
think the parameters you're searching for are specific for building the new kernel without proper source code to extract them from?
maybe you could get them from dmesg while the tablet is running?
else think there might be a way to grep the variable names in the existing kernel binary or headers?
i also would like a fresh kernel.
maybe useful stuff here:
https://vilimpoc.org/research/sh3dev/kernel-hacking.html
http://forum.xda-developers.com/showpost.php?p=46668556&postcount=31
thanks jjchico
i haven't checked this out yet, but may be useful.
Well I have build a new kernel and copied the modules over, but I does not boot. It appears that it never mounts the ramdisk as it never gets to the second splash screen, but I am flying blind as there is no serial port to debug with. I suspect that I do not quite understand the boot process for this tablet.... here is what is on the nanda vfat partition: (good information here http://rhombus-tech.net/allwinner_a10/a10_boot_process/)
since this is in my linux.ini
cat linux.ini
[segment]
img_name = c:\linux\u-boot.bin
img_size = 0x80000
img_base = 0x4A000000
[script_info]
script_base = 0x43000000
script_size = 0x10000
[logo_info]
logo_name = c:\linux\linux.bmp
logo_show = 1
Not quite certain how to setup img_base on my compile I guess.
I have tried the linix.ini from the link above but the tablet booted to livesuite image... that is a fail.
Not being a kernel developer.... I am wondering if the option to setup SUNXI_NAND_COMPAT_DEV is creating /dev/block/nandX or /dev/nandX as this will definatly impact the init.sun4i.rc file as it is mounting /dev/block/nandX This could be my first issue.... but then does /init first display the initlogo.rle or start processing init.sun4i.rc. Well if the first thing it does in load initlogo.rle then I am not even getting this far....below is the description of SUNXI_NAND_COMPAT_DEV
Symbol: SUNXI_NAND_COMPAT_DEV [=y] │
│ Type : boolean │
│ Prompt: Create old nand device names (nanda-nandz) │
│ Defined at drivers/block/Kconfig:564 │
│ Depends on: BLK_DEV [=y] && SUNXI_NAND [=y] │
│ Location: │
│ -> Device Drivers │
│ -> Block devices (BLK_DEV [=y]) │
│ -> SUNXI Nandflash Driver (SUNXI_NAND [=y]) │
well a little more reading leads me to this page on the CarbonRom http://www.slatedroid.com/topic/64378-rom-carbonrom-422/ turns out that if you want to run a 3.4 kernel you MUST update u-boot (http://www.mediafire...4ro667xcfkd2dv7).... so I have flashed the CarbonRom and it does boot with the u-boot update. Not to worry the new u-boot will still boot the old kernel. The only issue I have with the CarbonRom kernel is the missing dmard06 driver so no touch screen..... I may get a new kernel working yet!
domenictroilo said:
well a little more reading leads me to this page on the CarbonRom http://www.slatedroid.com/topic/64378-rom-carbonrom-422/ turns out that if you want to run a 3.4 kernel you MUST update u-boot (http://www.mediafire...4ro667xcfkd2dv7).... so I have flashed the CarbonRom and it does boot with the u-boot update. Not to worry the new u-boot will still boot the old kernel. The only issue I have with the CarbonRom kernel is the missing dmard06 driver so no touch screen..... I may get a new kernel working yet!
Click to expand...
Click to collapse
https://github.com/fsebentley/linux_allwinner_drivers_input_touchscreen_mods
https://groups.google.com/forum/#!topic/linux-sunxi/D0n8dyaVA34
?
bigsupersquid said:
https://github.com/fsebentley/linux_allwinner_drivers_input_touchscreen_mods
https://groups.google.com/forum/#!topic/linux-sunxi/D0n8dyaVA34
?
Click to expand...
Click to collapse
the patch compiles,you need to comment out #include <linux/earlysuspend.h> as it is not supported on the newer kernel and not required by the driver anyway. I just need to get the kernel to actually load lol..... I have at least gotten past the boot screen now, but it hangs.... I will try a different arm tool chain and see what happens next.....
So close but yet so far..... well I have the new kernel installed and booted with adb shell available but it turns out the new mma7660.ko is not compatable with my device I get this error from dmesg over and over and over....
<4>[ 3254.934675] incomplete xfer (0x20)
<3>[ 3254.938093] Assertion failed! drivers/hwmon/mma7660.c,196,mma7660_read_xyz,result>=0
Will rename the driver and see if I can get past init further in the boot....
Edit
Well more issues with drivers the dmard06 is not compatible either, I had more success with the Carbon Kernel I will see if I can find the source git, should be around....
dmesg | busybox grep dmard
<4>[ 5.408528] dmard06: init
<3>[ 5.447835] dmard06gsensor_fetch_sysconfig_para: after: gsensor_twi_addr is 0x4c, dirty_addr_buf: 0x4c. dirty_addr_buf[1]: 0xfffe
<4>[ 5.488546] dmard06_init: after fetch_sysconfig_para: normal_i2c: 0x4c. normal_i2c[1]: 0xfffe
<6>[ 5.508612] gsensor_detect: Detected chip dmard06 at adapter 1, address 0x4c
<4>[ 5.601533] dmard06 gsensor I2C err = 0!
<4>[ 5.613430] dmard06 probe failed
<4>[ 5.624926] dmard06: probe of 1-004c failed with error -1
This all makes some sense as Polaroid has not get gotten me the kernel and the drivers they load (their kernel have very unique names:
Module Size Used by Not tainted
8192cu 575431 0
rtl8150 8910 0
mcs7830 6557 0
qf9700 8513 0
asix 22500 0
usbnet 23745 3 mcs7830,qf9700,asix
dmard06_gl 8202 2
mma7660 6541 0
mali 130177 14
ump 42178 19 mali
gt811_ts_828 19947 0
sun4i_csi0 27946 0
nt99250 14254 1
gc0308 12848 1
videobuf_dma_contig 5659 1 sun4i_csi0
videobuf_core 18067 2 sun4i_csi0,videobuf_dma_contig
Well more issues with drivers the dmard06 is not compatible either, I had more success with the Carbon Kernel I will see if I can find the kernel source git, should be around....
dmesg | busybox grep dmard
<4>[ 5.408528] dmard06: init
<3>[ 5.447835] dmard06gsensor_fetch_sysconfig_para: after: gsensor_twi_addr is 0x4c, dirty_addr_buf: 0x4c. dirty_addr_buf[1]: 0xfffe
<4>[ 5.488546] dmard06_init: after fetch_sysconfig_para: normal_i2c: 0x4c. normal_i2c[1]: 0xfffe
<6>[ 5.508612] gsensor_detect: Detected chip dmard06 at adapter 1, address 0x4c
<4>[ 5.601533] dmard06 gsensor I2C err = 0!
<4>[ 5.613430] dmard06 probe failed
<4>[ 5.624926] dmard06: probe of 1-004c failed with error -1
This all makes some sense as Polaroid has not provided me the kernel they used and the drivers they load have unique names see below from the original stock rom:
Module Size Used by Not tainted
8192cu 575431 0
rtl8150 8910 0
mcs7830 6557 0
qf9700 8513 0
asix 22500 0
usbnet 23745 3 mcs7830,qf9700,asix
dmard06_gl 8202 2
mma7660 6541 0
mali 130177 14
ump 42178 19 mali
gt811_ts_828 19947 0
sun4i_csi0 27946 0
nt99250 14254 1
gc0308 12848 1
videobuf_dma_contig 5659 1 sun4i_csi0
videobuf_core 18067 2 sun4i_csi0,videobuf_dma_contig
I suspect after all the trouble I had with LG source that there are device-specific bits in the drivers.
Polaroid will most likely have to cough up source to get it all working.
Have you considered trying punchmod to use the old drivers? I dunno if that'd work considering the stock kernel is a lower version... but it might be worth a try.
bigsupersquid said:
I suspect after all the trouble I had with LG source that there are device-specific bits in the drivers.
Polaroid will most likely have to cough up source to get it all working.
Have you considered trying punchmod to use the old drivers? I dunno if that'd work considering the stock kernel is a lower version... but it might be worth a try.
Click to expand...
Click to collapse
I have changed the vermagic on the old modules and tried with the newer kernel but no go.... the latest 3.0 sunxi kernel is at 3.0.96 so I will build this one and see if I can get the special 3.0.8 polaroid modules to load.
I have a ticket open with Polaroid lol I guess we will see if the cough up a kernel or not.... I would not put money on it...
domenictroilo said:
I have changed the vermagic on the old modules and tried with the newer kernel but no go.... the latest 3.0 sunxi kernel is at 3.0.96 so I will build this one and see if I can get the special 3.0.8 polaroid modules to load.
I have a ticket open with Polaroid lol I guess we will see if the cough up a kernel or not.... I would not put money on it...
Click to expand...
Click to collapse
I've had an open ticket since November from talking on the phone after email did nothing.
nothing but autoresponder.
bigsupersquid said:
I've had an open ticket since November from talking on the phone after email did nothing.
nothing but autoresponder.
Click to expand...
Click to collapse
Do you believe that something like this http://gpl-violations.org/faq/violation-faq.html could force them to provide the source code? I could try to get the group at "FreakTab" to make the same requests for the kernel sources. Maybe with enough requests the gpl-violations group could take it on?
(K I am getting off topic here sorry anyone out there......)
I have attempted to build the 3.0.96 kernel but it did not boot.... back to hacking at the .config to see what I have missed (I need to move my build environment off this old p3 800 lol)
Instruction to build a kernel from Samsung Sources:
1. Download and unpack source from http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=sm-t525
2. Download and upack android ndk from https://developer.android.com/tools/sdk/ndk/index.html
3. Set enviroment varibles (use gcc 4.6, not 4.8):
export CROSS_COMPILE="~/android/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-"
export ARCH="arm"
Click to expand...
Click to collapse
4. If you want to add loadable modules support, apply patch modules_support.patch from attach
patch -p1 < modules_support.patch
Click to expand...
Click to collapse
5. Create kernel config
make VARIANT_DEFCONFIG=msm8974_sec_picassoeur_defconfig msm8974_sec_defconfig SELINUX_DEFCONFIG=selinux_defconfig
Click to expand...
Click to collapse
6. Buld kernel
make -j3
Click to expand...
Click to collapse
7. Buld device tree image
./tools/dtbTool -o dt.img -s 2048 -p ./scripts/dtc/ ./arch/arm/boot/
Click to expand...
Click to collapse
8. Buld boot.img (default ramdisk image in attach)
./tools/mkbootimg --kernel ./arch/arm/boot/zImage --ramdisk ramdisk.cpio.gz --cmdline 'console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3' --base 0x00000000 --pagesize 2048 --ramdisk_offset 0x02000000 --tags_offset 0x01E00000 --dt dt.img -o boot.img
Click to expand...
Click to collapse
9. Create .tar.md5 to flash with Odin
tar -H ustar -c boot.img > boot.tar
md5sum -t boot.tar >> boot.tar
mv boot.tar boot.tar.md5
Click to expand...
Click to collapse
10. To fix Wi-Fi edit build.prop on your device, change ro.securestorage.support fron true to false
ro.securestorage.support=false
Click to expand...
Click to collapse
GitHub: https://github.com/vanyasvl/android_kernel_samsung_picassoeur
I'm not a builder, but when wifi doesn't work that usually means a mismatch between kernel and rom.
Sent from my SM-T320 using Tapatalk
Hello. I'm trying to build stock Samsung kernel for Tab Pro 10.1 Sm-T525 and I have a problem:<br />
Wi-fi isn't working on builded kernel. All kernel configs are default from Samsung, bluetooth and Lte works ok.<br />
<br />
I need help with debug wifi problem.<br />
"ip a" command shows wlan0 network device, but wifi can't be enabled from configuration<br />
<br />
My steps to build kernel:<br />
Download source from http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=sm-t525<br />
unpack it to ~/android/kernel<br />
<br />
cd ~/android/kernel<br />
export CROSS_COMPILE="/home/vanyas/android/android-ndk-r9d_x64/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-"<br />
export ARCH="arm"<br />
<br />
make VARIANT_DEFCONFIG=msm8974_sec_picassoeur_defconfig msm8974_sec_defconfig SELINUX_DEFCONFIG=selinux_defconfig<br />
make -j3<br />
<br />
./tools/dtbTool -o dt.img -s 2048 -p ./scripts/dtc/ ./arch/arm/boot/<br />
<br />
unpack original boot.img with split_boot to boot folder<br />
<br />
./tools/mkbootimg --kernel ./arch/arm/boot/zImage --ramdisk boot/boot.img-ramdisk.cpio.gz --cmdline 'console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3' --base 0x00000000 --pagesize 2048 --ramdisk_offset 0x02000000 --tags_offset 0x01E00000 --dt dt.img -o boot.img<br />
<br />
tar -H ustar -c boot.img > boot.tar<br />
md5sum -t boot.tar >> boot.tar<br />
mv boot.tar boot.tar.md5
Click to expand...
Click to collapse
Click to expand...
Click to collapse
For the sm-t320, the kernel is built with version checks on the modules. This is what I did to allow the wlan module to load:
https://github.com/crpalmer/android...mmit/76275b29746dfeab37efeab6c2787af9acd3394c
You'd obviously need to specify the right version string (it should be in the output of dmesg if this is why your wlan isn't working).
Also, if you plan on sharing the kernel, you should zip the .tar.md5 file as I had problems with it failing to flash after downloading when I released just a .tar.md5.
crpalmer said:
For the sm-t320, the kernel is built with version checks on the modules. This is what I did to allow the wlan module to load:
https://github.com/crpalmer/android...mmit/76275b29746dfeab37efeab6c2787af9acd3394c
You'd obviously need to specify the right version string (it should be in the output of dmesg if this is why your wlan isn't working).
Also, if you plan on sharing the kernel, you should zip the .tar.md5 file as I had problems with it failing to flash after downloading when I released just a .tar.md5.
Click to expand...
Click to collapse
Thanks, but it is not a module load problem. SM-T525 kernel builds without modules support and wifi driver (bcm4339) compilled into the kernel.
vanyas said:
Thanks, but it is not a module load problem. SM-T525 kernel builds without modules support and wifi driver (bcm4339) compilled into the kernel.
Click to expand...
Click to collapse
That's interesting. The sm-t320 is a prima chipset which is built as a module.
Do you see anything in the logcat or the dmesg related to the wlan, bcm4339, wifi, etc?
There are patches for SM-T525 kernel source that resolve problem with "modules support" compilation
--- kernel_orig/arch/arm/mm/proc-syms.c 2014-04-09 12:10:04.846114000 +1100
+++ kernel/arch/arm/mm/proc-syms.c 2014-04-09 11:54:33.894114000 +1100
@@ -18,7 +18,6 @@
#ifndef MULTI_CPU
EXPORT_SYMBOL(cpu_dcache_clean_area);
EXPORT_SYMBOL(cpu_set_pte_ext);
-EXPORT_SYMBOL(cpu_tima_set_pte_ext);
#else
EXPORT_SYMBOL(processor);
#endif
--- kernel_orig/arch/arm/mach-msm/sec-switch.c 2014-01-23 15:34:20.000000000 +1100
+++ kernel/arch/arm/mach-msm/sec-switch.c 2014-04-09 11:29:26.322114000 +1100
@@ -2565,7 +2565,7 @@
pr_info("%s: Ignore Cable setting, Not LPM mode\n", __func__);
}
}
-EXPORT_SYMBOL(fsa9485_set_mhl_cable)
+EXPORT_SYMBOL(fsa9485_set_mhl_cable);
boon fsa9485_muic_is_mhl_attached(void)
{
--- kernel_orig/Makefile 2014-01-23 15:34:19.000000000 +1100
+++ kernel/Makefile 2014-04-09 20:55:48.278114000 +1100
@@ -351,7 +351,7 @@
CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
-Wbitwise -Wno-return-void $(CF)
-CFLAGS_MODULE =
+CFLAGS_MODULE = -fno-pic
AFLAGS_MODULE =
LDFLAGS_MODULE =
CFLAGS_KERNEL =
Click to expand...
Click to collapse
Yes! I did it!
To fix wifi: ro.securestorage.support=false in build.prop
thornev said:
I'm not a builder, but when wifi doesn't work that usually means a mismatch between kernel and rom.
Sent from my SM-T320 using Tapatalk
Click to expand...
Click to collapse
I am a builder and what he said is correct.
Samsung did some crazy stuff with Knox.
scrosler said:
I am a builder and what he said is correct.
Samsung did some crazy stuff with Knox.
Click to expand...
Click to collapse
can you make a thread showing us some the difficulties you encountered working around Knox?
Silkmeister
@Silkmeister1, @Scott, @vanyas, @crpalmer:
I do have a WiFi/BT issue with my (second hand) device. Wifi/BT is not to be enabled in Android. My first suspect was a broken connection, but couldn't found something obvious.
I tried to update Stock Rom and found and issue with ODIN. Stock Rom was not installable, returns with size error in hidden image. (??? what is in there ???). Installed latest LOS and checked the boot messages.
Do you think this can be a software issue? Is there anything missing (stuff in hidden partition) ?
Code:
failed to power up wifi chip, retry again (4 left) **
[ 4.035535] ## wifi_remove
[ 4.035538] wifi_set_power = 0
[ 4.035541] ------------------------------------------------
[ 4.035542] ------------------------------------------------
[ 4.035544] brcm_wlan_power Enter: power off
[ 4.035548] WL_REG_ON off-step : [1]
[ 4.035554] WL_REG_ON off-step-2 : [0]
[ 4.139482] wifi_set_carddetect = 0
[ 4.139485] brcm_wifi_status:359 status 0
[ 4.139487] mmc0: Slot status change detected (1 -> 0)
[ 4.139870] wifi_set_power = 1
[ 4.139873] ------------------------------------------------
[ 4.139874] ------------------------------------------------
[ 4.139876] brcm_wlan_power Enter: power on
[ 4.139880] WL_REG_ON on-step : [0]
[ 4.139887] WL_REG_ON on-step-2 : [1]
[ 4.349477] wifi_set_carddetect = 1
[ 4.349480] brcm_wifi_status:359 status 1
…
Complete bootlog can be seen here in the attachment:
https://forum.xda-developers.com/showpost.php?p=72624259&postcount=213
Any help is welcome!
I am following this tutorial on my desire 610: http://http://whiteboard.ping.se/Android/Debian
All has gone well so far, the system works in chroot, etc etc etc, thats not the problem. My problem is that i cant seem to pack a boot image that works for the phone. I know the problem is with my boot image, because if the init script had been initalised, I had a line at the start which would start a log file, and the system would bootloop. Instead it takes me to the fastboot menu when i power on.
I have used the tool to unpack the boot image, found at http://whiteboard.ping.se/Android/Unmkbootimg , and its output was this:
Code:
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
Kernel size 6004624
Kernel address 0x8000
Ramdisk size 1017204
Ramdisk address 0x2008000
Secondary size 0
Secondary address 0xf00000
Kernel tags address 0x1e00000
Flash page size 2048
Board name is ""
Command line "console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3"
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0xFE208100
OFF_RAMDISK_ADDR is 0x00208100
OFF_SECOND_ADDR is 0xFF100100
Please modify mkbootimg.c using the above values to build your image.
****************
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x1dfff00 --cmdline 'console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3' -o new_boot.img
---------------
I have tried doing as it says and compiling mkbootimg with those settings, however it still does not work. Could anyone possibly see what im doing wrong? And if not, does anyone have a copy of mkbootimg that works for the Desire 610?
Thanks in advance
falseascension said:
I am following this tutorial on my desire 610: http://http://whiteboard.ping.se/Android/Debian
All has gone well so far, the system works in chroot, etc etc etc, thats not the problem. My problem is that i cant seem to pack a boot image that works for the phone. I know the problem is with my boot image, because if the init script had been initalised, I had a line at the start which would start a log file, and the system would bootloop. Instead it takes me to the fastboot menu when i power on.
I have used the tool to unpack the boot image, found at http://whiteboard.ping.se/Android/Unmkbootimg , and its output was this:
Code:
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
Kernel size 6004624
Kernel address 0x8000
Ramdisk size 1017204
Ramdisk address 0x2008000
Secondary size 0
Secondary address 0xf00000
Kernel tags address 0x1e00000
Flash page size 2048
Board name is ""
Command line "console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3"
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0xFE208100
OFF_RAMDISK_ADDR is 0x00208100
OFF_SECOND_ADDR is 0xFF100100
Please modify mkbootimg.c using the above values to build your image.
****************
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x1dfff00 --cmdline 'console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3' -o new_boot.img
---------------
I have tried doing as it says and compiling mkbootimg with those settings, however it still does not work. Could anyone possibly see what im doing wrong? And if not, does anyone have a copy of mkbootimg that works for the Desire 610?
Thanks in advance
Click to expand...
Click to collapse
I just use Blobtools and linux's standard abootimg. I'll find some links and do a quick Howto when I get home tonight.
MiniBlu
MiniBlu said:
I just use Blobtools and linux's standard abootimg. I'll find some links and do a quick Howto when I get home tonight.
MiniBlu
Click to expand...
Click to collapse
Cheers! looking forward to getting this thing actually working
Aha! Using abootimg made it work. Wish i knew about that earlier...
There's still a few errors though, need to fix that. Thanks for your help, you literally saved probably hours and hours more work if I hadnt known about this. Much appreciated
Hello Everyone,
I'm porting twrp recovery for GFive 77A. but facing the below problem to unpack original recovery.img using carliv. how do i solve that problem? please find recovery.img-ramdisk.gz
Code:
Your image: recoveryold.img
Create the recoveryold folder.
Printing information for "recovery.img"
Unpack image utility by [email protected]
[!] This image has a MTK header
Header:
Magic : ANDROID!
Magic offset : 0
Page size : 2048 (0x00000800)
Base address : 0x10000000
Kernel address : 0x10008000
Kernel size : 3983464 (0x003cc868)
Kernel offset : 0x00008000
>> kernel written to 'recoveryold/recovery.img-kernel' (3982952 bytes)
Ramdisk address : 0x11000000
Ramdisk size : 1145048 (0x001178d8)
Ramdisk offset : 0x01000000
>> ramdisk written to 'recoveryold/recovery.img-ramdisk.gz' (1144536 bytes)
Second address : 0x10f00000
Tags address : 0x10000100
Tags offset : 0x00000100
Compression used: gz
Unpacking the ramdisk....
../recovery.img-ramdisk.gz:
gzip: ../recovery.img-ramdisk.gz: unexpected end of file
cpio: premature end of file
Your ramdisk archive is corrupt or unknown format. Exit script.