Related
I wish to open New Thread for enable focus into developing custom rom for dell venue and expecting get some suggestion, comment, help from other members of this forum :
I have wrote brief guide to prepare build environment and build kernel & rom for dell venue HERE
I do test to emulator and device all build result before posting to this thread, but need other user/member willing to test the build and post any suggestion, comment etc.
Starting by building froyo base rom, to test and ensure the buiild process is correct and exepcting to build further base i.e gingerbread and ice cream sandwich
since I'm terrible noob in android development, help, guide, suggestions are very welcome
-update-
Kernel Build
I have been succesfully "build" a kernel HERE
I splited 408-kernel to "borrow" the ramdisk (To make it easy I renamed file boot.img of 408-kernel into boot408.img.
Code:
[[email protected] venimg-1]$ split_bootimg.pl boot408.img
Page size: 2048 (0x00000800)
Kernel size: 3092536 (0x002f3038)
Ramdisk size: 168270 (0x0002914e)
Second size: 0 (0x00000000)
Board name:
Command line: androidboot.hardware=venue
Writing boot408.img-kernel ... complete.
Writing boot408.img-ramdisk.gz ... complete.
extracted ramdisk
Code:
[[email protected] ramdisk]$ gzip -dc ../boot408.img-ramdisk.gz | cpio -i
561 blocks
edited ro.secure=1 to re.secure=0
recreate cpio archive
Code:
$ mkbootfs ./ramdisk | gzip > ramdisk-408-2.gz
recreate boot image by using new build kernel named zImage-05
Code:
$ mkbootimg --cmdline 'androidboot.hardware=venue console=null' --kernel zImage-05 --ramdisk ramdisk-408-2.gz -o boot408-2.img
flash boot408-2.img > NO LUCKS > NOT BOOTING .. I'm clueless. Anybody give an idea ?
-update-
My failed to make "succesfull build kernel" to "boot" is the absent of info : BOARD_KERNEL_BASE (address) for dell venue. Someone can appoint me where I can get this info?
please test
changkho1908 said:
please test
Click to expand...
Click to collapse
this is very early stage of development build with available source. As I found HERE available ICS Chocolate Branch Manifest for msm7627. I will personally do experiment to build this ICS branch for dell venue.
I still need help from someone to understand and appoint a clue to this information at the end of build process :
Code:
.....
APK certs list: out/target/product/msm7627_surf/obj/PACKAGING/apkcerts_intermediates/msm7627_surf-apkcerts-eng.x.txt
Package target files: out/target/product/msm7627_surf/obj/PACKAGING/target_files_intermediates/msm7627_surf-target_files-eng.x.zip
Package OTA: out/target/product/msm7627_surf/update.zip
./build/tools/releasetools/ota_from_target_files:63: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
import sha
unzipping target target-files...
using device-specific extensions in device/qcom/common
[B][I][COLOR="Red"]unable to load device-specific module; assuming none[/COLOR][/I][/B]
done.
sysmtem is alive but boot (kenel) is still NON BOOTABLE ... I believed by working together we will have "something" for this device
The 40x roms are based off of the MSM8x60 branches, as they dont implicitly list 8260 they likely used 8660 as their base.
I dont know if the 8x60 is closer to the 8x50 then the 7627, but just pointing it out.
You might be better off at least getting 2.2/2.3 to boot first, you may very well need to deal with the drivers and at least 2.2/2.3 have working binary-only drivers.
TheManii said:
The 40x roms are based off of the MSM8x60 branches, as they dont implicitly list 8260 they likely used 8660 as their base.
I dont know if the 8x60 is closer to the 8x50 then the 7627, but just pointing it out.
You might be better off at least getting 2.2/2.3 to boot first, you may very well need to deal with the drivers and at least 2.2/2.3 have working binary-only drivers.
Click to expand...
Click to collapse
Dear TheManii,
I believed you are one who having well understanding on this funky smart phone. please let me know qsd8x50 : is the name of processor isnt it > qualcom snap dragon (qsd) and how about MSM8x60 <-- this is name of BOARD of Name or Processor. When coming into building kernel I need to have correct understanding. So far I know only the ARCH. Is there any wiki or site page to refer. This is example when I was on old time with gentoo linux on compiling kernel for PC > Safe Cflags. Board understanding will help in configure config file, processor understanding will help in overclocking or set best and safe for building kernel.
binary only available driver will always make head-ache in open source community. Hopefully vendor releasing the driver copy sorry for the question, I'm really new to this embedded device
Snapdragon is the device family, 8250 is the specific SOC used in the venue.
Like I stated earlier, dell used the 8x60 branch as their base as qualcomm/CAF no longer supports 8x50 devices. I dont know if it's better or worse as the group that makes the roms pretty much does a terrible job at it, the venue has only a fraction of the issues of the streak 5 (due mainly to drivers), but there's not much you can say to defend them when it takes over a year to release GB (in fact it was just days after ICS was released) for the venue.
Dell cant and wont release the drivers to any of their devices, most of them except the streak 5 arent unusual anyway. The reason ICS has a beta for the S7 is this very fact.
You can likely base it on the nexus one/passion as it's likely not terribly different from it.
I dont expect the GB drivers to simply work in ICS, and since we dont have them you'd pretty much need to rewrite/port from a similar device using the same hardware.
At least with the current drivers, you could theoretically build the rest of the system and drop in the current ones. I've never had the time to try so myself but this is pretty much how cyanogen is ported to some devices.
That's pretty much ALL the info for the venue, as I'm the closest to a dev for it (at least on xda, there's other devs but they dont speak english much/visit xda much so it doesnt really make much of a difference in the end) and that's about as much as I can offer.
I cant really offer much more as I've never attempted to build android itself. Most I've done is build the makefiles to compile CWM. The makefiles for android is a lot more complex then merely porting CWM
dear all,
can someone appoint me out to have correct GB manifest on codeaurora ? I tried
Code:
[email protected]:~/dell-venue$ gingerbread_rel -m M7630AABBQMLZA404020.xml ^C
[email protected]:~/dell-venue$ repo init -u git://codeaurora.org/platform/manifest.git -b gingerbread_rel -m M7630AABBQMLZA404020.xml --repo-url=git://codeaurora.org/tools/repo.git
.repo/manifests/: manifest switched gingerbread_chocolate...gingerbread_rel
.repo/manifests/: discarding 70 commits removed from upstream
fatal: manifest 'M7630AABBQMLZA404020.xml' not available
fatal: cannot link manifest M7630AABBQMLZA404020.xml
I did many googling, still No lucks I agree to Guru TheManii advise to make GB kernel booting first then investigate to port ICS into dell venue.
***dell venue make me very currious (and also fustating)***
x1123 said:
dear all,
can someone appoint me out to have correct GB manifest on codeaurora ? I tried
Code:
[email protected]:~/dell-venue$ gingerbread_rel -m M7630AABBQMLZA404020.xml ^C
[email protected]:~/dell-venue$ repo init -u git://codeaurora.org/platform/manifest.git -b gingerbread_rel -m M7630AABBQMLZA404020.xml --repo-url=git://codeaurora.org/tools/repo.git
.repo/manifests/: manifest switched gingerbread_chocolate...gingerbread_rel
.repo/manifests/: discarding 70 commits removed from upstream
fatal: manifest 'M7630AABBQMLZA404020.xml' not available
fatal: cannot link manifest M7630AABBQMLZA404020.xml
I did many googling, still No lucks I agree to Guru TheManii advise to make GB kernel booting first then investigate to port ICS into dell venue.
***dell venue make me very currious (and also fustating)***
Click to expand...
Click to collapse
good luck for you, we are always support you
changkho1908 said:
good luck for you, we are always support you
Click to expand...
Click to collapse
cũng chỉ biết good luck for you àh
nguyen_vh said:
cũng chỉ biết good luck for you àh
Click to expand...
Click to collapse
đệt, chú muốn thế nào nữa
I tested to build android and using three source : codeaurora, cyanogen, aosp. To build GB on codeaurora I just can not find correct manifest. On cyanogen just wont build (for certain device) without proper propreitary binary drivers. On aosp ... well, build is easier. From TheManii advise I build GB aosp > passion and will not boot to be flashed to dell venue. I change the kernel with 408, rom is alive on device, but No wireless functionality work, either gsm or wifi. Anyone can give a clue where to get radio.img for dell venue? to build booting customs android kernel for venue still no lucks for me.
if someone want to take a look please download passion build packed with 408 kernel HERE flashable via cwm recovery. This will not brick your device.
To turn back device into normal android usage just flash TheManii StreakDroid4-250 without wipe anything. I put StreakDroid4-250 file also HERE just for make easier to download from my region (Indonesia).
split / unpack / repack boot.img
Hi Guys,
My biggest problem to determine how to pack kernel into boot image is solved. I optimistic to have booting kernel and pack into boot image. I cant determine the board kernel base address. Now I found out the base address is 0x20000000 (twenty million). I have test the coomand line and work well. This is the test procedure > download live boot.img (mean its proved bootable). I toke 408-boot image from many Streakdriod4 rom ... thanks to TheManii :
Code:
$ split_bootimage.pl 408boot.img
(I renamed boot.img to 408boot.img for easy remember)
output
Code:
Page size: 2048 (0x00000800)
Kernel size: 3092536 (0x002f3038)
Ramdisk size: 168270 (0x0002914e)
Second size: 0 (0x00000000)
Board name:
Command line: androidboot.hardware=venue
Writing 408boot.img-kernel ... complete.
Writing 408boot.img-ramdisk.gz ... complete.
...
Now I have in the folder > 3 files : 408boot.img 408boot.img-kernel 408boot.img-rakdisk.gz. We test our command line > to repack kernel and ramdisk into boot image and must be flashable to device and booting :
Code:
$ mkbootimg --kernel 408boot.img-kernel --ramdisk 408boot.img-ramdisk.gz --pagesize 2048 --cmdline "androidboot.hardware=venue" --board venue --base 0x20000000 -o new408boot.img <ENTER>
You should have new408boot.img bootable into our venue viat fastboot > test >
Code:
$sudo fastboot earse boot (to ensure existing boot is clean)
$sudo fastboot flash boot new408boot.img
$sudo fastboot reboot
...
Mu dell venue with TheManii rom booting properly.
But we need to ensure everything work well. Let us utilize second procedure well known in the world
Code:
$rm 408boot.img-kernel 408boot.img-ramdisk.gz new408boot.img [B][COLOR="Red"](to clean the folder).[/COLOR][/B]
$unpack-bootimg.pl 408boot.img [ENTER]
OUTPUT WILL BE
Code:
kernel written to 408boot.img-kernel.gz
ramdisk written to 408boot.img-ramdisk.cpio.gz
561 blocks
extracted ramdisk contents to directory 408boot.img-ramdisk/
By using UNPACK method we will have THREE file (four including 408boot.img) in folder
408boot.img 408boot.img-ramdisk 408boot-ramdisk.cpio.gz 408boot.img-kernel.gz
I choose unpack method since I wanna to test all command line available in internet is working properly. I change initlogo.rle with one I download from internet and edit default.prop file.
Code:
$nano -w 408boot.img-ramdisk/default.prop
EDIT THE text > ro.secure=1 TO ro.secure=0.
change initlogo.rle with other FILENAME.rle (You can download from internet)
Now we have ramdisk file (folder) with different default.prop file and initlogo.rle file (different image .. default is dell logo)
Create new ramdisk file to enable us create bootable image
Code:
$mkbootfs 408boot.img-ramdisk | gzip > new408-ramdisk [ENTER]
we should have file named new408-ramdisk gziped
Now repack kernel and new ramdisk >
Code:
$mkbootimg --kernel 408boot.img-kernel.gz --ramdisk new408-ramdisk --pagesize 2048 --board venue --cmdline "androidboot.hardware=venue --base 0x20000000 -o realynewboot.img [ENTER]
...
flash realynewboot.img via fastboot my boot splash changed into image attached ...
for step by step ... i put on MY BLOG
I share this to have someone try together to compile a kernel and convert into bootable image. with this kernel proble tackled ... build ROM is easier
Booting kernel
Hi Folks,
attached is booting kernel for dell venue. I tried on GB Rom (TheManii Rom) Steakdroid4-2.5.0.
Build info :
- Build from source tree : DJSteve-StreakKernel-92bf64f
- using 408config > extracted from 408boot.img
- switched off back cover awareness (I dont know what exact name) feature
- ramdisk > splitted ramdisk from 408-boot image.
- flashable via fastboot
- download atachement
- boot to fastboot
-$ sudo fastboot erase boot
-$ sudo fastboot flash boot djsteveboot.img
-$ sudo fastboot reboot
NOTE
This is development stage kernel. so please only try if you can tackle all problem. Good news flash the boot WILL NOT brick Your device
share here the result
x1123 said:
- switched off back cover awareness (I dont know what exact name) feature
Click to expand...
Click to collapse
It's redundant on the V at least, as it has no door sensor/doesnt care if the back cover is off. I do that all the time to hot swap memory cards.
Even the stock kernel will allow you to remove the door and not complain
Hi, I built a kernel too but based on Venue (4.06) sources.
http://forum.xda-developers.com/showthread.php?p=23544539#post23544539
You can check my sources here :
https://github.com/adridu59/dell-venue-kernel
The Venue codename is 'toucan'.
There are Venue-specific files and I do not know whether they are present in the Streak source you used.
I am developing a CM7 build myself. In fact, things are OK except the fact that the kernel is still stock 408 (things about setting up the working environment is here: http://forum.xda-developers.com/showthread.php?t=1687679).
After being able to build CM7 myself, I will turn back with the kernel issue for 2.3.x. Then, proceed to Android 4 ICS. God bless all of us!
After lots of discussion about the famous "SuperBrick" issue on GT-I9100 4.0.4 stock kernels, I wrote a script to allow everyone to check it on their own and hopefully patch it if needed.
Main goal - Detection
Detect if a STOCK kernel has MMC_CAP_ERASE enabled (unsafe) or not (safe).
I have validated it against XWLPG, XWLPM, XWLPO, XWLPT, XXLP5, XXLP5-CFRoot and all of them were detected correctly: safe on 4.0.3 kernels, unsafe on 4.0.4 ones.
I also checked it against Siyah 3.5.2 (despite knowing from the sources it's safe) and it was also correctly detected.
However, for custom kernels I don't expect the code patterns to be always the same and therefore it's possible that the detection is inconclusive - you will see that in the output.
Secondary goal - Fixing (instructions provided, not the tools)
When an unsafe kernel is detected, provide instructions on how to patch the code so it's safe.
For that, you'll need:
* an external kernel unpack/repack script (just search the forum as there are several available)
* a Linux box
* a hex editor
* any other requirements for the repack script: CROSS_COMPILE, etc.
Requirements for this script
This is pretty much self contained and can be run on either:
* Linux
* Windows with Cygwin
Running on the device itself would be theoretically possible but it ultimately depends on the installed Busybox version, in particular the parameters accepted by the "grep" command.
On my v1.20.0-cm9 version it's not possible to make it work.
Sample outputs
Here are some executions against existing kernel images:
The latest XWLPT (4.0.4):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPT/zImage
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
1 ocurrences of the bad code signature
0 ocurrences of the good code signature
***************
!!! WARNING !!!
***************
[COLOR="Red"]The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices[/COLOR]
Unpacked kernel code stored at: XWLPT/zImage_unpacked
The unsafe instruction can be found at offset 0x00594ec0
==================== Disassembly of the instruction ====================
XWLPT/zImage_instruction: file format binary
Disassembly of section .data:
00000000 <.data>:
0: e3811b01 orr r1, r1, #1024 ; 0x400
========================================================================
*** Instructions for patching ***
- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x00594ec0, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled
XWLPG (4.0.3):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPG/zImage
Kernel: Linux version 3.0.15-I9100XWLPG-CL619441 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu May 24 18:09:27 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
[COLOR="SeaGreen"]The kernel appears to be good (MMC_CAP_ERASE disabled)[/COLOR]
XXLQ5-CFRoot (4.0.4):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XXLQ5_CFRoot/zImage
Kernel: Linux version 3.0.15-I9100XXLQ5-CL753921 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu Jun 28 14:16:15 KST 2012
1 ocurrences of the bad code signature
0 ocurrences of the good code signature
***************
!!! WARNING !!!
***************
[COLOR="Red"]The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices[/COLOR]
Unpacked kernel code stored at: XXLQ5_CFRoot/zImage_unpacked
The unsafe instruction can be found at offset 0x00594ef4
==================== Disassembly of the instruction ====================
XXLQ5_CFRoot/zImage_instruction: file format binary
Disassembly of section .data:
00000000 <.data>:
0: e3811b01 orr r1, r1, #1024 ; 0x400
========================================================================
*** Instructions for patching ***
- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x00594ef4, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled
Finally, here's the expected output of a kernel after the patch has been applied.
I didn't actually do the entire kernel repack, but I changed the code and compressed the file in a similar way as it will appear in a "complete" zImage file.
Patched XWLPM:
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPM-patched/zImage
Kernel: Linux version 3.0.15-I9100XWLPM-CL837163 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu Jul 5 11:26:14 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
[COLOR="Blue"]The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe[/COLOR]
Disclaimers
My main goal here is to provide information, not a one-click solution. I'm personally not worried about this issue since I run a kernel compiled from sources rather than a stock one.
Despite my best effort, I can't promise that:
- The detection will be flawless (although checks exist to make sure there's exactly 1 occurrence of either the "good code snippet" or the "bad code snippet" and an inconclusive result is reported if that's not the case)
- The patch will work or even be a runnable kernel (you might need to reflash another one from download mode). I have not performed the full unpack/repack process to test it out, although it's something already done elsewhere such as the CF-Root kernels and others.
That being said, enjoy
(Reserved)
WOW, << That's one small step for man, one giant leap for "s2 community" >> !!!!!
Now this is what XDA is all about. Good stuff man, much appreciated!
sorry for my "stupid" question;
I've a linux notebook, I've connected my device with the usb cable. Now how can I send command to the device? with adb and android sdk?
Tkanks
hahaha yes man nice one... i hope that give us some nice ''stock'' roms
ps i was number 500 that hit your thanks button LOL
xky1980 said:
sorry for my "stupid" question;
I've a linux notebook, I've connected my device with the usb cable. Now how can I send command to the device? with adb and android sdk?
Tkanks
Click to expand...
Click to collapse
If you read the requirements section, you'll see it's not likely that it runs successfully on the device itself, due to BusyBox limitations.
Just place the zImage file somewhere on your notebook, along with the script, and run it from a terminal.
Tungstwenty said:
If you read the requirements section, you'll see it's not likely that it runs successfully on the device itself, due to BusyBox limitations.
Just place the zImage file somewhere on your notebook, along with the script, and run it from a terminal.
Click to expand...
Click to collapse
Oooohh! So the kernel must be read from the same path of the script, not from the device! OK thanks
Inviato dal mio GT-I9100 con Tapatalk 2
---------- Post added at 09:18 AM ---------- Previous post was at 09:02 AM ----------
I've executed the script with siyah 3.5.2
the result is: The kernel appears to be good (MMC_CAP_ERASE disabled)
So it means that is possible to safely make wipes and nandroid restores from recovery on my XWLPT?
Thanks
Genius!
Sent from my GT-I9100 using Tapatalk 2
great work
Amazing work
Sent from my GT-I9100 using xda premium
Did someone test it on S2 with CWM ?
Great work dude!!
Keep it up
00raq00 said:
Did someone test it on S2 with CWM ?
Click to expand...
Click to collapse
What do you mean?
If you're talking about the detection, there's no such kernel as "CWM"
What exists is:
1. stock kernels, with stock recovery (faulty for all 4.0.4 builds so far)
2. CF-Root, which is just the stock kernel code but with stock recovery replaced by CWM, root included, etc. (but it's still the original kernel code and it still has he bug)
3. custom kernels built by kernel developers from source, which unless they forgot to do so, has the source code changed to be safe
If you're asking about item no 2, I *think* Chainfire changed the code of the CWM version he included in the package to make it safer, but the kernel is still vulnerable and flashing a .zip file in recovery (which could run some code it might include) is still potentially unsafe.
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Code:
repack-zImage.sh -u
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 4184870 6277305 5231087 4707978 4969533 5100311 5165700 5133005
5116657 5108483 5112570 5114614 5113592 5114103 5113847 5113975 5114039 5114071
5114055 5114047[COLOR="Red"]/usr/local/bin/repack-zImage.sh: line 284: [: : integer expression expected[/COLOR]
padding check (may take some time): 1
Found uncompressed ramdisk.
Detecting padding (may take some time): 1
Unpacking initramfs
4300 blocks
4300 blocks
Success.
The unpacked files and the initramfs directory are in './zImage_unpacked'.
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
Creating piggy.gz
Padding './zImage_packing/piggy.gz' to 5114048 bytes (+1)
Assembling zImage
Successfully created './zImage_packing/zImage'
Generated file: './zImage_packing/zImage.tar'
This checks out OK as having been patched OK.
Code:
./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
but sadly gets stuck at the boot screen
Does anyone know what I have done wrong and might be able to help? I'll share the kernel if I can get it built.
Peter
Tungstwenty said:
What do you mean?
If you're talking about the detection, there's no such kernel as "CWM"
What exists is:
1. stock kernels, with stock recovery (faulty for all 4.0.4 builds so far)
2. CF-Root, which is just the stock kernel code but with stock recovery replaced by CWM, root included, etc. (but it's still the original kernel code and it still has he bug)
3. custom kernels built by kernel developers from source, which unless they forgot to do so, has the source code changed to be safe
If you're asking about item no 2, I *think* Chainfire changed the code of the CWM version he included in the package to make it safer, but the kernel is still vulnerable and flashing a .zip file in recovery (which could run some code it might include) is still potentially unsafe.
Click to expand...
Click to collapse
If we can detect brick bug in kernel and know what must be changed so why we can't fix stock kernel? If we can fix stock kernel my question is did someone do that and test it with fake cwm and wipe?
Sent from my GT-I9100 using Tapatalk 2
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Code:
repack-zImage.sh -u
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 4184870 6277305 5231087 4707978 4969533 5100311 5165700 5133005
5116657 5108483 5112570 5114614 5113592 5114103 5113847 5113975 5114039 5114071
5114055 5114047[COLOR="Red"]/usr/local/bin/repack-zImage.sh: line 284: [: : integer expression expected[/COLOR]
padding check (may take some time): 1
Found uncompressed ramdisk.
Detecting padding (may take some time): 1
Unpacking initramfs
4300 blocks
4300 blocks
Success.
The unpacked files and the initramfs directory are in './zImage_unpacked'.
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
Creating piggy.gz
Padding './zImage_packing/piggy.gz' to 5114048 bytes (+1)
Assembling zImage
Successfully created './zImage_packing/zImage'
Generated file: './zImage_packing/zImage.tar'
This checks out OK as having been patched OK.
Code:
./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
but sadly gets stuck at the boot screen
Does anyone know what I have done wrong and might be able to help? I'll share the kernel if I can get it built.
Peter
Click to expand...
Click to collapse
Did you use this script here http://forum.xda-developers.com/showthread.php?t=901152 ? I used that one and asked tungstwenty for help. He discovered, that that one was faulty. I have my own kernel build now but still couldn't test it.
Safe version of XWLPT stock.
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Edit: Variable was assigned to nul rather than zero and was not a real problem.
Code:
repack-zImage.sh -u....
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
...[CODE]./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
Click to expand...
Click to collapse
I have now rebuilt this and it works! and it is available at the Dropbox link below.
http://dl.dropbox.com/u/46833344/Kernel_XWLPT_eMMC_safe.tar
Does someone else want to check this out? I re-did the build above after fixing two unassigned variables in repack-zImage (fixed build files below)
http://dl.dropbox.com/u/46833344/repack-zImage.v6-fixed-scripts.tar.gz
whiskerp said:
I have now rebuilt this and it works! and it is available at the Dropbox link below.
http://dl.dropbox.com/u/46833344/Kernel_XWLPT_eMMC_safe.tar
Does someone else want to check this out? I re-did the build above after fixing two unassigned variables in repack-zImage (fixed build files below)
http://dl.dropbox.com/u/46833344/repack-zImage.v6-fixed-scripts.tar.gz
Click to expand...
Click to collapse
Did you already test CWM Wipe?
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
...
Click to expand...
Click to collapse
darth_mickrig said:
Did you use this script here http://forum.xda-developers.com/showthread.php?t=901152 ? I used that one and asked tungstwenty for help. He discovered, that that one was faulty. I have my own kernel build now but still couldn't test it.
Click to expand...
Click to collapse
whiskerp said:
I have now rebuilt this and it works!
Click to expand...
Click to collapse
After having the detection, I was also trying to get it to work using exactly that same repacker script, which darth_mickrig tipped me about.
I also found it has some errors, not only in the line you mentioned but also in the packing when using "-3" so that piggy can be edited directly rather that its inner blocks in separate files (which would require subtracting something from the offset displayed by my script).
wiskerp, I'm glad you had it sorted out already. I didn't have a chance to properly testing my patched+repacked zImage from one of the 4.0.4 versions (was planning on testing it despite the fact that I'm running a 4.0.3 ROM) so your feedback is great.
The repack-zImage.v6 script appears to no longer be maintained and its author doesn't post on XDA for a while now, but I'll try to see if I can reach him to know whether he's ok with updating that script for newer kernels in addition to fixing the existing bugs. It might work properly in other shells / bash versions, who knows...
In the meantime, I was also asked by a couple of N7000 guys to make the detection work for their kernels, which apart from the "really stock" ones have a different compression - lzma/xz instead of gzip on the outer layer. On the inner parts (initramfs) it's also not working correctly, so I'll need to check it out. CF-Root, for instance, uses a different compression than the base stock, probably so that the additional payload fits the partition size.
Oh, one note:
Keep in mind that despite being a patch on the stock kernel, the yellow triangle will appear and the counter will be incremented if you flash the patched version through Odin. It's no longer properly signed by Samsung.
Kudos to wiskerp for beating me to share a patched version :highfive:. I had already done the repackaging and was waiting to get home to flash and try it out to see if it would boot before posting it
Hi,
I would like to add some usb devices drivers like usb serial etc
I already rooted my kyobo, with the boot.img I found on this forum
I pulled the /boot/config.gz to build my own kernel
I load the config with make menuconfig save it but after the config is very deifferent from the one I pulled
I build the msn kernel 2.6.35 downloaded from google with that config, but my zImage seems to be small against the boot.img/zImage currently installed
[email protected]****u:~/kyobo/msm$ ls -l arch/arm/boot/zImage
-rwxrwxr-x 1 jpdumont jpdumont 3103940 Dec 26 15:15 arch/arm/boot/zImage (the zImage generated with my kernel build)
[email protected]****u:~/kyobo/msm$ ls -l ../boot/zImage
-rw-rw-r-- 1 jpdumont jpdumont 3661940 Dec 26 15:04 ../boot/zImage (the zImage extracted from boot.img currently installed on my rooted device)
So i'm affraid to install my own boot.img
Is there any method to test a kernel without risk on the device itself ???
Thanks in advance
JP
Hi JP,
How is this project with the Kyobo progressing?
I've recently picked one up myself and am trying to achieve the same thing, except for sailing rather than soaring. I've overcome the first hurdle in a different manner, I've used the TetherGPS app to wifi in my gps location in from an android phone. I took a bit of fiddling as the "ACCESS MOCK LOCATION" is not available in the development menu of Kyobo. Instead I've edited the settings.db and changed a 0 to 1 next to MOCK LOCATION to get it working.
I'd still like to get other NMEA data in from various instruments in the future and will possibly continue down the wifi route rather that the usb option you are attempting.
regards Simo
What is Kexec?
"Kexec", which is short for 'Kernel Execution' is derived from the Linux Kernel call "exec". It allows the "live" booting of a new kernel "over" the currently booted kernel without taking the device down for a reboot. This is extremely useful on locked bootloader devices, as a user with root authentication can boot a custom kernel without rebooting, and undergoing the security checks enforced by the bootloader. On unlocked devices, it can be used to "multi-boot" kernels on a device without requiring the kernels to be installed to the /boot partition.
Whilst Kexec is extremely useful, it also can be extremely hard to implement, as it needs to take all devices down, and bring them back up along with the new kernel, this can lead to some serious bugs, like devices not working after soft-boot, kernel corruption, device hangs, etc. This make it very device specific, and hard to get fully working, as it requires retrieving kernel crash logs, (often) UART serial output, and a ton of debugging.
What about this whole "Hardboot" thing?
The solution to this was written (initially) by Mike Kassick, who had the idea to "Hardboot" a kernel. Which is when a kernel is loaded into memory, a flag is set, the device is taken down for a full reboot, then the flag is read out by the primary kernel very early in the boot sequence, at which point, the "primary" kernel directly loads the new "secondary" kernel/ramdisk/passes arguements/etc.
This is much easier to implement than the normal Kexec SysCall, as it jumps to the new kernel before most devices are initiated, and in doing this, we allow the secondary kernel to initialize all the devices on its own, and not have to worry about taking them down.
Many people unknowingly make use of Kexec in the form of MultiROM, so, today, I thought I would do a write up on how to use it in practice.
Necessary Components:
* Boot.img (alternatively, the zImage-dtb/ramdisk you want to use)
* Unmkbootimg
* Kexec Binary (can be found in your specific devices MultiROM zip)
* Kexec Hardboot enabled Kernel installed (most custom kernels have it)
* Root Access
Downloads:
All the Binaries I've cross compiled/found can be downloaded here: https://www.dropbox.com/sh/7g5jcofv8j2gwg9/AAA-2b-wLiHq2z0nCMIHSHooa?dl=0
All the Linux Binaries you'll want/need are here: https://www.dropbox.com/sh/qcho8bhaoi8cdkc/AACGvmIQlb_3I9OQtNMqIQwva?dl=0
If you use Windows/Mac, just find the binaries equivalents for your platform.
How to use it?
1. Take the aforementioned Kexec Binary, and place it in /system/bin using ADB or A File Explorer, granting it permissions drwxdr-xdr-x (or chmod 0755 it)
2. Over on your desktop, make sure you have Unmkbootimg in an Executable location, and that you've blessed them as executable (chmod 0755 filename). Then run
Code:
unmkbootimg /path/to/your/boot.img
This will dump a zImage (rename it to zImage-dtb now, for semantics sake), and a ramdisk, labeled initramfs.cpio.gz (Initial RAM File System, in the form of a cpio.gz archive).
Now, put the kernel and ramdisk in a folder on your SD Card via MTP/ADB Push, I called mine "kexecstuffs".
3. Now open a mobile terminal, or an ADB Shell, and run
Code:
su
cd /sdcard/PathToYourFolder/
kexec --load-hardboot zImage-dtb –initrd=initramfs.cpio.gz --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --boardname=shamu –dtb
Now, lets dissect the different arguments we are passing to Kexec:
--load-hardboot = Tells Kexec to make use of the Kexec Hardboot kernel function, and take the device down for a full reboot as opposed to soft-booting, like that used in the standard Kexec Linux SysCall
zImage-dtb = Name of your kernel file
--initrd = Points to the ramdisk to be used when booting the new kernel, if not set, the current ramdisk in the /boot partition. Most archive types are supported.
--mem-min = A reasonable value in memory where the kernel is loaded, serves as space for Kexec to do its work
--command-line = What arguments are passed to the new kernel, using "$(cat /proc/cmdline)" allows you to pass the currently booted kernel's arguments to the new kernel, which is what we want in the case of Shamu
--dtb = Defines that the board makes use of an Appended Device Tree, can be passed without a value (which will rely on Tasssdar's “boardname” value), or can have a compressed DTB image as its value
--boardname = Tasssdar's way to handle different DTB styles, we just need to pass “shamu” to it, and it'll use our DTB style
Now that we have successfully loaded the kernel into memory, lets execute it!
4. In that same Mobile Terminal/ADB Shell, run:
Code:
kexec -e
Although this guide is for the Nexus 6 (shamu), it should work all devices supported bu MultiROM, or on any device with a kernel that supports Kexec/Kexec Hardboot.
I hope this helped you to better understand what Kexec is/how to use it.
I'm not an active developer but I'm also not a *total* noob -- I've successfully compiled usable kernels for Nexus 4, Moto G, HP TouchPad -- but I'm not making much headway on my Z5C kernel.
I want to run an otherwise stock Sony ROM on my phone, but make a couple of minor tweaks to the kernel. With that in view, I downloaded the source tree from Sony's dev site for the kernel that matches the one that shipped with the ROM I am currently running (at the moment, for Reasons, it's a Lollipop one, and I'm not really interested in debating that point anyway), and then I started by building a kernel with ZERO changes applied first. But it will not boot. Instead, with my first attempt at a kernel compiled from scratch, after the Sony Xperia boot logo and before the boot animation would normally kick in, the screen goes black and the notification LED blinks red 4 times, and then it reboots and starts over (bootloop).
I'm not sure what I am supposed to do to diagnose the problem since the screen doesn't display anything and it never gets far along enough in the boot process to where the USB port is initialized. And, yes, the bootloader is unlocked (I can flash a stock kernel to the phone with the DRM fix applied, and that boots and works just fine).
Here is what I have done so far:
Downloaded the kernel sources that match my ROM's kernel at https://developer.sonymobile.com/do...rchives/open-source-archive-for-32-0-a-6-200/
Downloaded the GCC 4.9 for ARM64 cross-compiler / toolchain from https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
Applied kitakami_defconfig and suzuran_diffconfig, and built the kernel. It compiled cleanly without any errors.
Extracted kernel.elf from my ROM's kernel.sin, and then unpacked the binary image, initramfs, and device tree blob from that.
Re-packaged a new kernel into .img format for Fastboot flash by substituting in my kernel image binary for the official Sony one, but keeping the original ramdisk and DTB.
Flashed image to boot partition with Fastboot == bootloop
Flashed original kernel back == works fine
Decided to try creating a new DTB instead of reusing the one from the original kernel...but dtbTool spits out this:
Code:
Found file: msm8994-v2.0-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Found file: msm8994-v2.1-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Grabbed dtbToolCM from https://github.com/xiaolu/mkbootimg_tools instead, which seems to work.
Substituted in the new DTB image for the original Sony one, repackaged up a new boot.img, flashed that == bootloop
Tested my mkbootimg and the parameters I was using by extracting kernel, ramdisk, and DTB from original kernel.elf, then repackaging them all together into a boot.img and flashing that to the phone with Fastboot == works just fine
Hypothesized that perhaps my kernel didn't like the Sony kernel modules on the system partition because of version magic mismatch, so I changed CONFIG_LOCALVERSION from "-perf" to "-perf-g75e6207" in .config and rebuilt kernel, repackaged, reflashed with Fastboot == bootloop ... ARGH
So at this point, I'm at a loss. I've proven that it's not the way I am packaging up the boot image because if I repack the original Sony kernel binary up with the original ramdisk and DTB and then flash that file to the boot partition, that has no problem booting the phone. Is there some modification that I need to make to the contents of the ramdisk? I'd think I should just be able to use the stock Sony ramdisk unmodified, especially if the kernel itself doesn't differ at all (same sources, same .config) from the one Sony compiled, but...?
Any leads that any experienced Xperia Z-series kernel hackers out there can supply before I end up tearing my hair out would be greatly appreciated.
Thanks so so so much,
-- Nathan
[UPDATE]: Just tried assembling with mkqcdtbootimg instead. No go. Also unpacked the image made by that utility and verified that everything (e.g. offsets, etc.) looked sane. GARGH.
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
nlra said:
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
Click to expand...
Click to collapse
I think that cannot be possible. There are lots of kernels out there compiled with toolchains different than the stock one (e.g. Androplus kernel is compiled with UBERTC 4.9)
I am in the same situation as you, but with the Xperia X Compact:
-Untouched copyleft source code
-Untouched ramdisk
-Using AOSP mkbootimg (the new one written in Python: https://android.googlesource.com/platform/system/core/+/nougat-release/mkbootimg/mkbootimg) with arguments specified in README_Xperia (https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/README_Xperia)
And still no boot... I am about to give up on this as I cannot find any other solution...
You can see my build script here for reference: https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/utils/build.sh
bamsbamx said:
I think that cannot be possible.
Click to expand...
Click to collapse
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
nlra said:
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
Click to expand...
Click to collapse
Yeah, sorry about that, I didnt push the new commits to Github yet because of the kernel not booting, the current script I am using is this one:
Code:
#!/bin/bash
RED=1
GREEN=2
BLUE=4
colorPrint() {
tput setaf $2
echo $1
tput sgr0
}
colorPrint "Initializing workspace..." $BLUE
#Device config
device=kugo
#Workspace directories
workdir="$(pwd)"
outputfolder=${workdir}/OUTPUT
outputdir=${outputfolder}/${device}
toolchains=${workdir}/toolchains
ramdisk=${workdir}/ramdisks/${device}/ramdisk
export ARCH=arm64
export CROSS_COMPILE=${toolchains}/aarch64-linux-android-4.9-kernel/bin/aarch64-linux-android-
export KBUILD_DIFFCONFIG=kugo_diffconfig
colorPrint "Cleaning previous builds..." $BLUE
rm -rf $outputdir
mkdir -p $outputdir
colorPrint "Configuring kernel..." $BLUE
make msm-perf_defconfig O=$outputdir
colorPrint "Building kernel..." $BLUE
time make -j8 O=$outputdir 2>&1
if [ ! -f $outputdir/arch/arm64/boot/Image.gz-dtb ]; then
colorPrint "ERROR: kernel image not found. Kernel build failed" $RED
exit 1
fi
if [ ! -e $outputdir/ramdisk.cpio.gz ]; then
colorPrint "ERROR: ramdisk image file not found. Compression failed" $RED
exit 1
fi
colorPrint "Packaging boot image file" $BLUE
${workdir}/utils/mkbootimg \
--kernel $outputdir/arch/arm64/boot/Image.gz-dtb \
--ramdisk $outputdir/ramdisk.cpio.gz \
--base 0x20000000 \
--ramdisk_offset 0x02000000 \
--pagesize 2048 \
--tags_offset 0x01E00000 \
--cmdline "androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 zram.backend=z3fold earlyprintk" \
--output $outputdir/boot.img
if [ ! -f $outputdir/boot.img ]; then
colorPrint "ERROR: boot image file not found. boot packaging failed" $RED
exit 1
fi
colorPrint "DONE" $GREEN
colorPrint "boot image file can be found at ${outputdir}/boot.img" $GREEN
This one is for the build 34.3.A.0.217... However, I already had managed to boot copyleft kernel builds in other versions (such as 34.2.A.0.XXX) using the Github script, the UBERTC 4.9 Toolchain and not changing the GCC version, although I had to set # CONFIG_MODULE_SIG_FORCE is not set There must be something strange here
I think there must be something with kernel files permissions, or... maybe this? https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
zacharias.maladroit said:
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
Click to expand...
Click to collapse
Hi,
Nope, I didnt disable RIC neither dm-verity, the only thing I changed was CONFIG_MODULE_SIG_FORCE to 'is not set'. But I guess that wasnt the cause of kernel not booting since my /system partition is untouched. I tried both with mkqcdtbootimg and mkbootimg but still nothing
Hey @nlra, I figured out the problem (finally). The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken (resulting in a 7.0MB ramdisk.cpio.gz file)
I managed to pull up the boot.img from the device (via dd if=/dev/block/mmcplk0p33 of=/sdcard/boot.img) and then extract the ramdisk from it, resulting in a 11.4MB file
Then, I was able to boot it BOTH USING mkqcdtbootimg file and mkbootimg python script from AOSP nougat-release branch
Thats it
bamsbamx said:
The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken
Click to expand...
Click to collapse
Nice! Glad you figured out what was going on in your case, and thanks for confirming that both mkqcdbootimg and mkbootimg both work for building the X Compact boot image.
-- Nathan