[HOW-TO] A Guide to KEXEC and HARDBOOT for ARMv7a Boards - Nexus 6 Developer Discussion [Developers Only]

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.

Related

[BASIC DONE] A simplified 2ndinit (2ndihkvc) for experimenting

>>>> In a post further down, I have released a updated zip file which contains the 2ndihkvc program as well as its source as well as few support scripts to allow experimentation with this mechanism of multiple user spaces <<<<
Hi All
I have been following the below thread, as well as working on my own on some of the concepts. You can get the details till now from my posts in the below thread.
http://forum.xda-developers.com/showthread.php?t=1378886
I was not able to get the SETREGS to succeed in setting PC required for the current/existing 2nd-init logic, nor wait was waiting to lock the process, SO I tried a new and simpler alternate method for triggering/execve the init process a 2nd time using only POKE and it seems to have succeeded. I am guessing this based on my nooktablet having got messed up and it keeps rebooting again and again when it reaches my logic potentially. I have to restore back to factory settings and try afresh in the morning (Well it is almost morning ;-) now here) with few more debug messages to pin point it fully.
The code I am injecting directly into init process is in the attached txt file which is actually a .s (assembly file). (NOTE: Currently I am not handling environment variables, not sure if that is causing my boot to keep looping).
In turn the logic to hijack the init process and inject the code is as simple as
Step1) PTRACE_ATTACH
Step2) PTRACE_GETREGS
Step3) PTRACE_POKETEXT (Regs.ARM_pc, code to inject)
Step4) PTRACE_CONT
Step5) PTRACE_DETACH
I will upload the code in a day or two - however the jist of the logic is above, if anyone wants to experiment on their own.
NOTE: The code is very simple and experimental and expects the pc address to be known before hand to massage the .s file appropriately.
NOTE: The above algo with the corresponding .s file is still EXPERIMENTAL and also requires additional shell scripts to get access to the boot flow to trigger the hijack. And the current code will break the nooktab booting, so don't experiment this logic and the .s file unless you know what you are doing.
NOTE: I am not that much into Custom Roms etc, so don't expect anything much shortly wrt Custom Roms etc, this is just a experimentation for myself and to feel happy inspite of BN removing some useful features like sideloading as well as forcing a signed bootloader on everyone.
can you make a 2-init zip like on the milestone
http://forum.xda-developers.com/showthread.php?t=998425
because then the devs can go on and make a recovery
Bit more exploration with init hijacking - 2ndihkvc src package for EXPERIMENTATION
Hi,
NOTE: Source code package is attached with this message. However this is WIP and provided for anyone wanting to EXPERIMENT on their own parallel to me. Because I think the basic logic is done now. It is more of cleaning up the init rc files and or killing some additional tasks before restarting init or some such things HOPEFULLY (NO harm in hoping and being positive . HOWEVER NOTE that the current version will loop your boot and fail. I have put a timed triggering logic to try and reduce the risk, check out the documents in the package, but it can factory reset or worst case wipe your partitions and render the nooktab dead.
After yesterdays initial init hijacking, I have cleaned up the .s file so that it passes the Args properly as well as added the environment variables set by Android by default. Also the ptrace code I have updated to do relocation (using a simple custom table) of injected code. Also rather than a minimal ptrace code, I have put a bit more full fledged one with my logic as well as skrilax's logic as well as reg dumping and few other stuff to help experimenters.
In turn I have cross verified, that init is actually getting restarted and it is running thro the scripts and setting up the properties as specified by my modified default.prop as well as in the process rerunning all the commands/services/prgs.
However some where beyond rild/vold sequence it seems to be blocking and looping the boot. Also I had modified the init a bit, have to check that also once later.
Enjoy and experiment
NOTE: Not sure how to avoid having to put the same message in two threads. I created this thread only becasue the original thread was in the wrong category (i.e non development), when it should have been in development also.
This is interesting. I have minimal experience with assembly, none of it ARM. I would like to help, if possible. I appreciate the work you have put into this. I'm really hoping to be able to have CM7 on this tablet eventually.
Sent from my BNTV250 using xda premium
Potentially working Alternate Userspace in uSD using 2ndihkvc
Hi All,
I have updated my 2ndihkvc package a bit more and now you can boot into a ALTERNATE Android user space in uSD (NOTE: Userspace only and not kernel - locked bootloader doesn't allow alternate kernel).
For this you require to copy your required android /system and /data partitions into a MicroSD card in its 2nd and 3rd partitions which should be ext4 (specified in the init.omap4430.rc file in 2ndihkvc directory).
NOTE: Best way of getting a working /system and /data partitions is to ==> After rooting your Nook and removing all unwanted Apps/Junk, make a copy of the /system partition from eMMC to uSD. Same for /data/partition. Then you can copy what ever additional applications you want in this uSD based Android /system/app or /data/app partition. Thus you can have different sets of Android user space in different uSD cards.
Follow the instructions in INSTALL file for experimenting this on your rooted NookTab. BUT REMEMBER IT IS STILL EXPERIMENTAL. ALSO as a SAFETY FEATURE, as of now it will boot into this ALTERNATE MODE (in uSD) only when the current HOUR is specified in the start2ndihkvc.sh file appropriately. Otherwise it tries to boot into the your normal Andorid system in eMMC. This should hopefull CATCH any mistake, BUT THIS IS NOT GUARENTEED AND THIS IS A DANGEROUS THING TO EXPERIMENT, UNLESS YOU KNOW WHAT YOU ARE DOING.
NOTE: One time it did reboot from my alternate android system, I haven't debugged this yet, as it has not occured after it (Well I have tried only once more) so cann't say one way or the other yet. But definitely, there are some corner cases.
NOTE: If something gets messed up or if something is different or even if there is some corner case in my code, which I haven't handled yet, it may MESS UP your NOOK TAB so EXPERIMENT WITH THIS only if you know how to recover on your own, provided the NOOKTAB is recoverable (90% should be, but NO GAURENTEE).
Now the BRAVE HEARTS can experiment and Enjoy a alternate Andorid system in uSD card.
NOTE: With this one should be able to boot into any Custom ROM after suitable updation of the scripts in my zip file, as well as by copying their /system and /data/ partitions into uSD 2nd and 3rd partitions. AS long AS that Custome ROM doesn't have any specific kernel requirements.
BYPASS Kernel and Ramdisk check for People with UART ACCESS
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).
How can I run 2ndihkvc just to load a new default.prop using the existing userspace? What I did so far was to remount / in rw, updated default.prop, pushed 2ndihkvc to /data/local/, changed permissions to 755 and executed. Here is the output
Code:
# ./2ndihkvc -p 1 -w 0 -c 0 -m 2
INFO:2ndihkvc:v30Dec_2020:
INFO:2ndihkvc: Tracing process with pid = 1
INFO:2ndihkvc: NewPrg = /init
WARN: RESPECT_WAIT disabled
WARN: Mode = MODE_INJECT_HKVC2
INFO: ContType = CONTINUE
INFO:2ndihkvc:PTRACE: Attached to (1)
INFO:2ndihkvc: Giving 2 secs to the likely traced process
ERROR:2ndihkvc:WAIT:Failed (No child processes)
INFO:2ndihkvc:hkvc2: InjectAddr (Regs->ARM_pc) = 0xffff0520
INFO:2ndihkvc:hkvc2: /init found at offset 0x100
INFO:2ndihkvc:hkvc2:ProgramToExecute: /init replaced with /init
INFO:2ndihkvc:hkvc2: At offset 0x208 relocating from 0x100 to 0xffff0620
INFO:2ndihkvc:hkvc2: At offset 0x200 relocating from 0x208 to 0xffff0728
INFO:2ndihkvc:hkvc2: At offset 0x280 relocating from 0x288 to 0xffff07a8
INFO:2ndihkvc:hkvc2: At offset 0x288 relocating from 0x300 to 0xffff0820
INFO:2ndihkvc:hkvc2: At offset 0x28c relocating from 0x307 to 0xffff0827
INFO:2ndihkvc:hkvc2: At offset 0x290 relocating from 0x312 to 0xffff0832
ERROR:PTRACE:POKE failed at location ffff0520
INFO:2ndihkvc:PTRACE: Continue/SingleStep ...
INFO:2ndihkvc: Detaching...
ERROR:2ndihkvc:PTRACE: Failed DETACH (No such process)
#
Do I need to push your init to /system/2ndihkvc/init? I am just trying to play around with it and Adam's BHT just to see what I can do them. Thanks.
Hi Brianf21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
hkvc said:
Hi Brian21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
Click to expand...
Click to collapse
brianf21 said:
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
Click to expand...
Click to collapse
If all you are interested is run 2ndihkvc with a modified default.prop but no other modification (i.e no uSD /system and /data partitions), then
a) overwrite the init.omap4430.rc in /system/2ndihkvc with the one in / . However if you have already booted into a system with 2ndihkvc then in /data/local/tmp.
Or if required you can directly edit the init.omap4430.rc in /system/2ndihkvc and update the mount commands in there to mount from emmc instead of uSD.
b) Remove the 2 lines in restart-userspace.sh corresponding to mount -o move ....
This will allow you to boot into a system with a modified default.prop but no other change from a runtime perspective (unless I have forgotten something).
Also 2ndihkvc will be applied each time boot into NookTab provided the current hour matches the hour set in start2ndihkvc.sh. Once the current hour no longer matches the hour set in the sh file, it will boot into the normal BN Nooktab environment.
NOTE: I purposefully modified the init.omap4430.rc file to replace the /system and /data from emmc to uSD, so that if someone is experimenting something, he doesn't corrupt the emmc easily as long as he doesn't become root user. HOWEVER with root access emmc can still get corrupted if one is not careful, because eMMC is still available and mounted.
tried but rebooted few times until factory reset kicked in
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
chrmhoffmann said:
Hi,
The device booted a few times until it restored factory. Uff.
Click to expand...
Click to collapse
If it's counting boots like the Nook Color you can stop it by running this (if the rom partition is mounted at /rom-- it's p2 on nc and I guess p5 on nt).
chrmhoffmann said:
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
Click to expand...
Click to collapse
Hi,
The missing init.rc is not a glitch, I purposefully left it out while packaging, so that one doesn't modify it drastically and botch up the boot. init.4430.rc is the only thing required to change the mount partitions.
Also if you are using my default start2ndihkvc.sh script, then it has a time check, so while xperimenting if you have goofed up. Just let the time you have set in this script pass by (i.e don't power on), then it will automatically go back to the stock NT boot, thus avoiding the factory reset.

[TUT] Building your own Xperia Play Kernel

Since We have such a fantastic tutorial on how to build your own CM9, I thought I'd add one for building a kernel.
Edit: updated kernel sources for jellybean
First off:
You NEED Linux. DO NOT TRY THIS ON WINDOWS, IT WON'T WORK.
Sources: https://github.com/freexperia/semc-kernel-msm7x30-ics
https://github.com/DarkforestGroup/sony-kernel-msm7x30-ics
https://github.com/DooMLoRD/Xperia-2011-Kernel-2.6.32.9
http://forum.xda-developers.com/showthread.php?t=1556971
http://forum.xda-developers.com/showthread.php?t=1477845
http://developer.sonymobile.com/wp/2011/05/06/how-to-build-a-linux-kernel/
DooMLoRD, KeiranFTW & Atarii.
Prepping:
1) Grab the toolchain I have here (Android NDK R5b), it's the only one I've been able to use that doesn't throw errors when compiling: http://db.tt/hE3TmJJi Doom has provided a better toolchain https://github.com/DooMLoRD/android_prebuilt_toolchains[/QUOTE] you can get it using
Code:
git clone https://github.com/DooMLoRD/android_prebuilt_toolchains.git -b master
(thanks Doom!!)
Building a kernel from fxp sources
1) Terminal for any commands, file explorer for finding stuff & gedit for changes.
2) open up terminal, mkdir (no spaces)
3) cd
4) git clone https://github.com/CyanogenMod/semc-kernel-msm-7x30 -b jellybean (no spaces)
5) cd /semc-kernel-msm-7x30-ics (if you didn't rename it)
6) (If this is after the first time, and lets say a week has past do this step, otherwise ignore) git pull (automatically updates any files)
7) First important step: Find the defconfig that fxp uses. They are located in arch/arm/config. fxp_zeus_defconfig is the name of theirs
8) copy fxp_zeus_defconfig & rename to _zeus_defconfig (for example, mine will be pax_zeus_defconfig)
9) open up your defconfig & put it into another workspace, we'll mess with it later
10) Hop onto DooMLoRD's github, his we'll use for references.
11) Adding governors: https://github.com/DooMLoRD/Xperia-...mmit/bec19001ded34077d7776639834a1229b69e5f87
A1) Well, as I look into this, fxp has a ton of governors not used... (located in /drivers/cpufreq/
A2) Check the Kconfig file to see that they're all in there (they must just not be in the defconfig file)
A3) Edit the deconfig file you created in lines 467-474 removing "#" from any you want to add (and add in any you might've added by adding the line CONFIG_CPU_FREQ_GOV_=y
A4) If you want to add more governors, check out the Commits from DooMLoRD's build to add in when needed (anytime you see a "+" that means line added, "-" means line deleted)
12) Adding IO Schedulers: https://github.com/DooMLoRD/Xperia-...mmit/0ae625f7561c559d4933284f489733bf5eb66e96
B1) Navigate to /block folder
B2) Once again, FXP has a ton of IO Schedulers added, but not used in Play kernel:
B3) Open up Kconfig.ioshced to make sure they're in there (and add any you want)
B4) Edit the defconfig file you created (lines 121-137) & fix it to your liking (same as above)
B5) If you want to add more, see Doom's commits to add 'em
13) Turning off ALS
C1) Navigate to /arch/arm/mach-msm
C2) Open up board-semc_zeus.c
C3) Search for .als_connected (it on line 1349)
C4) Change the variable from 1 to 0
14) Overclocking
D1) open up arch/arm/mach-msm/acpuclock-7x30.c
D2) Lines 96 - 144 contain the PLL2 table, which is used to set clock speeds, note FXP can go all the way up to 2ghz, they just stop it short.
15) Building the Kernel
E1) Save your defconfig file, you'll need it now.
E2) naviage to folder (in terminal)
E3) Type in "ARCH=arm CROSS_COMPILE= ../ramdisk.img
F17) cd ../
17) Putting the ramdisk & kernel together
G1) By now (hopefully) the kernel is done compiling. (time for terminal, you should still be in folder you were above)
G2) cp ~//arch/arm/boot/zImage ./
G3) mkbootimg --base 0x00200000 --kernel zImage --ramdisk ramdisk.img -o .img
18) Flashing it for testing.
H1) Keep your copy of FXP's kernel around, just in case any issues happen
H2) fastboot boot .img
H3) If it boots & works, SUCCESS!! you modified your own custom kernel!
H4) If it doesn't boot (at all, just a vibrate & blank screen for 10-20 seconds) there's a problem with the ramdisk, sometimes it's bad, sometimes is needs filler, overall, it's just a pain in the butt to figure out.
H5) If it boots & bootloops the splash screen, well, that's an issue with the ramdisk again, that possibly, your ramdisk does not match you rom. Recovery, reflash rom & try again.
Courtesy of Atarii reminding me
19) Adding your wifi modules (they get built when you build the kernel) into the ramdisk
I1) Let's pretend that you haven't gotten through step F16, we're gonna add the wifi modules in.
I2) The wifi modules are located in /drivers/net/wireless/
I3) Copy bcm4329.ko to ~/ramdisk/working/modules/
I4) Add in the following lines to init.semc.rc
Code:
#load bcm4329 module
insmod /modules/bcm4329.ko
I5) Now your modules will autoload on boot!
Pax

[Q] Help completing a10 allwinner kernel compiling guide

Hi all,
My aim has been to compile a kernel for an Allwinner a10 F1-LY tablet (pengpod 700) that features PS3 and other gamepad support. I can upgrade my ROM to Cyanogenmod 10 to achieve this but then the hard buttons and screen rotation stop working.
After days of searching, reading and testing, I feel like I am close but need help getting over the line. I am running a virtualbox installation of Xubuntu.
Once I have this running, I will contribute a guide with screenshots back to the community.
My steps:
0. My device is running this ROM, which is JB 4.1.1 with root and CWM 5.5 installed. The image is based on a Seby build, and modified by Magica.
1. Install virtualbox and then 32 bit Ubuntu 13.0.4. Make sure you have 3D acceleration enabled and a decent amount of RAM allocated or it will run incredibly slow.
2. Install guest additions and a shared folder with the windows host machine.
3. Install some packages for later use:
Code:
sudo apt-get install gedit git ncurses5 jre-default
4. Make a folder in the home directory to work from. Open a terminal in it and then install the kernal library:
Code:
git clone https://github.com/linux-sunxi/linux-sunxi linux-sunxi
cd linux-sunxi
git checkout sunxi-3.0
5. Install the cross compile tool chain.
Download http://www.codesourcery.com/sgpp/lite/arm/portal/package7853/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi.bin
Install with:
Code:
sudo ./arm-2010.09-50-arm-none-linux-gnueabi.bin
6. Setup kernel config.
Code:
make ARCH=arm sun4i_crane_defconfig
make menuconfig ARCH=arm
The second line opens up a GUI for configuring the kernel, where I activated the following options using here as a guide::
Code:
--- Networking support <*>
Bluetooth subsystem support --->
<*> HIDP protocol support
Bluetooth device drivers --->
<*> HCI USB driver
[*] HID Devices --->
Special HID drivers --->
<*> Sony PS3 controller
<*> DragonRise Inc. game controller
[*] DragonRise Inc. force feedback
<*> Pantherlord/GreenAsia game controller
[*] Pantherlord force feedback support
<*> GreenAsia (Product ID 0x12) game controller support
[*] GreenAsia (Product ID 0x12) force feedback support
<*> SmartJoy PLUS PS2/USB adapter support
[*] SmartJoy PLUS PS2/USB adapter force feedback support
I'm not sure if my thinking is correct here, but I went through the config and changed any modular options to included, to avoid the need for additional files to be copied to the device.
7. Compile kernel:
Code:
make ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-
This runs for a long time and will eventually produce a zImage file in the linux-sunxi/arch-arm-boot/ folder.
8. Get original boot.img from device.
To do this I booted into recovery mode and used the backup feature. This made a folder on my external SD card with boot.img and other archives. I then copied boot.img to the shared folder on my windows host.
9. Split original boot.img into zImage and ramdisk, replace zImage
Make a new folder in your home directory to keep this clean. Copy the original boot.img into this folder.
I downloaded and unzipped Adi_Pat's scripts from here. into the new folder.
The boot.img file will be unpacked with:
Code:
./extract.sh
Your zImage will be in kernel/zImage
Your ramdisk will be in ramdisk folder (unpacked)
Click to expand...
Click to collapse
I then deleted the zImage in the kernel folder and replaced it with the one compiled earlier from linux-sunxi/arch/arm/boot/. The ramdisk was left alone.
10. Modify script and repack boot.img
I'm aware that Adi_pat's script is for a different device, so I modified the pack_boot.sh script to suit the a10. Line 31 becomes:
Code:
./tools/mkbootimg --kernel kernel/zImage --ramdisk ramdisk.gz -o out/boot.img --base 0x40000000 --cmdline 'console=ttyS0,115200 tw init=/init loglevel=8' --pagesize 2048
This is based on searching and the the information given when running extract.sh. The updated script can now be executed:
Code:
./pack_boot.sh
A new boot.img is created at out/boot.img.
11. Put new boot.img onto device and flash.
I copied the new boot.img into my shared folder and then onto a SD card. Using a root file explorer on the device, move the boot.img file to the /sdcard directory. Open Novo7 tools and then go to the flash boot.img option.
12. Reboot device
When the device reboots, it hangs on the first Android logo, so clearly something has been done incorrectly. Fortunately I can recover to a working device from the backup in CWM recovery in just a few minutes.
Obviously I'm doing something wrong here, and would appreciate any pointers to get it working.
I have searched and read for days, so I am sorry if I have missed a thread that answers this for me.
Many thanks in advance.
lawgic said:
Hi all,
My aim has been to compile a kernel for an Allwinner a10 F1-LY tablet (pengpod 700) that features PS3 and other gamepad support. I can upgrade my ROM to Cyanogenmod 10 to achieve this but then the hard buttons and screen rotation stop working.
After days of searching, reading and testing, I feel like I am close but need help getting over the line. I am running a virtualbox installation of Xubuntu.
Once I have this running, I will contribute a guide with screenshots back to the community.
My steps:
0. My device is running this ROM, which is JB 4.1.1 with root and CWM 5.5 installed. The image is based on a Seby build, and modified by Magica.
1. Install virtualbox and then 32 bit Ubuntu 13.0.4. Make sure you have 3D acceleration enabled and a decent amount of RAM allocated or it will run incredibly slow.
2. Install guest additions and a shared folder with the windows host machine.
3. Install some packages for later use:
Code:
sudo apt-get install gedit git ncurses5 jre-default
4. Make a folder in the home directory to work from. Open a terminal in it and then install the kernal library:
Code:
git clone https://github.com/linux-sunxi/linux-sunxi linux-sunxi
cd linux-sunxi
git checkout sunxi-3.0
5. Install the cross compile tool chain.
Download http://www.codesourcery.com/sgpp/lite/arm/portal/package7853/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi.bin
Install with:
Code:
sudo ./arm-2010.09-50-arm-none-linux-gnueabi.bin
6. Setup kernel config.
Code:
make ARCH=arm sun4i_crane_defconfig
make menuconfig ARCH=arm
The second line opens up a GUI for configuring the kernel, where I activated the following options using here as a guide::
Code:
--- Networking support <*>
Bluetooth subsystem support --->
<*> HIDP protocol support
Bluetooth device drivers --->
<*> HCI USB driver
[*] HID Devices --->
Special HID drivers --->
<*> Sony PS3 controller
<*> DragonRise Inc. game controller
[*] DragonRise Inc. force feedback
<*> Pantherlord/GreenAsia game controller
[*] Pantherlord force feedback support
<*> GreenAsia (Product ID 0x12) game controller support
[*] GreenAsia (Product ID 0x12) force feedback support
<*> SmartJoy PLUS PS2/USB adapter support
[*] SmartJoy PLUS PS2/USB adapter force feedback support
I'm not sure if my thinking is correct here, but I went through the config and changed any modular options to included, to avoid the need for additional files to be copied to the device.
7. Compile kernel:
Code:
make ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-
This runs for a long time and will eventually produce a zImage file in the linux-sunxi/arch-arm-boot/ folder.
8. Get original boot.img from device.
To do this I booted into recovery mode and used the backup feature. This made a folder on my external SD card with boot.img and other archives. I then copied boot.img to the shared folder on my windows host.
9. Split original boot.img into zImage and ramdisk, replace zImage
Make a new folder in your home directory to keep this clean. Copy the original boot.img into this folder.
I downloaded and unzipped Adi_Pat's scripts from here. into the new folder.
The boot.img file will be unpacked with:
Code:
./extract.sh
I then deleted the zImage in the kernel folder and replaced it with the one compiled earlier from linux-sunxi/arch/arm/boot/. The ramdisk was left alone.
10. Modify script and repack boot.img
I'm aware that Adi_pat's script is for a different device, so I modified the pack_boot.sh script to suit the a10. Line 31 becomes:
Code:
./tools/mkbootimg --kernel kernel/zImage --ramdisk ramdisk.gz -o out/boot.img --base 0x40000000 --cmdline 'console=ttyS0,115200 tw init=/init loglevel=8' --pagesize 2048
This is based on searching and the the information given when running extract.sh. The updated script can now be executed:
Code:
./pack_boot.sh
A new boot.img is created at out/boot.img.
11. Put new boot.img onto device and flash.
I copied the new boot.img into my shared folder and then onto a SD card. Using a root file explorer on the device, move the boot.img file to the /sdcard directory. Open Novo7 tools and then go to the flash boot.img option.
12. Reboot device
When the device reboots, it hangs on the first Android logo, so clearly something has been done incorrectly. Fortunately I can recover to a working device from the backup in CWM recovery in just a few minutes.
Obviously I'm doing something wrong here, and would appreciate any pointers to get it working.
I have searched and read for days, so I am sorry if I have missed a thread that answers this for me.
Many thanks in advance.
Click to expand...
Click to collapse
I am heavily into the allwinner tablets and would like to get CM10 install. I ran into the same issue until I build kernel 3.0.8 but you MUST put the generated NAND.KO file into the ramdisk folder and edit the init.sun4i.rc file to load it before anything else...this should get rid of the issue. I have a serial port I added to my tablet so Its a bit easier to troubleshoot and edit uboot vars when needed. If you would like to collaborate let me know.i have a 95% working android build environment that works for my tablet, only the gsensor is inverted which is a simple fix.
Michael Pizzileo
BinaryDroid
I am working with a Polaroid Tablet (pmid10c) and have been attempting to build and install a newer kernel with no success. Any help/guidance would be great. I am currently working in this thread: http://forum.xda-developers.com/showthread.php?p=46685741#post46685741 please chime in with any advice you may have.
Thanks

Dev Tools AARCH64 - bash, busybox, ssh srv/client, rsync, nano, live ramdisk patcher

Here we have a collection of development tools I've either created/painstakingly compiled or scavenged from other developers that I've found useful for this device. All of these files can be run directly from the device (via adb) without the need for external tools. Obviously this goes without saying, but you need to run a lot of this stuff as root for it to be useful. Theoretically they should work on any device with the aarch64 architecture.
bash
Good old BASH interpreter. Pretty sure I compiled this one myself. I think I statically linked it too so it should work in TWRP.
busybox
Self explanatory. Scavenged from elsewhere (probably cyanogenmod).
patchboot script
Made this myself; you have to edit the script to your own purposes prior to using it. Place the script in its own directory with the busybox and bash binaries. Basically what this does is take a boot.img file in the same directory as the script, splits it up into its components, decompresses the ramdisk, recompresses the ramdisk, and reconstitutes it into newboot.img. The whole purpose of this is to allow you to modify the ramdisk contents live on the device. Needs to be run with bash interpreter (./bash patchboot), and depends on busybox binary in the same directory. I've added some useful ### comments with an example of how to pull the current boot.img, how to add binary services to the boot image to run as as root at startup, and how to flash the new boot image back to the device.
dbserver script
Script to start an SSH server via the dropbear binary (pulled from SSHDroid app) in public key authentication mode. I have this start up automatically on my device via patchboot script above. 4 things to be aware of:
You need a dropbear_rsa_host_key file including a pub/priv key for SSH.
You allow clients in via the .ssh/authorized_keys file
Use the 'root' user to login.
This will create a /data/data/berserker.android.apps.sshdroid/home/ directory - so you probably shouldn't use this AND have SSHDroid installed at the same time.
ssh
dropbear SSH client. Scavenged it from an unknown source on XDA. dropbear is an enormous pain in the ass to compile for aarch64 - credit to whoever made this.
nano - Compiled this one myself.
Holy crap! nano text editor! No more annoying adb push/pull for on-device script editing Only works if you're ssh'ed into the device (I couldn't get it to work via ADB). Depends on the nano_bin file and terminfo directory (should be placed in the same directory as the nano script).
rsync
Compiled this myself. I set this up using the patchboot script above to backup my device to an rsync server daily (using the ssh client above).
dropbear multibinary added in a separate zip to the first post (recompiled it myself). Tested and operational for ssh client/server purposes (so you no longer need two separate binaries). It looks for the .ssh directory (containing known_hosts and authorized_keys files) in the current working directory at the time of binary execution.

Kernel compiled from Sony sources won't boot...help

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

Categories

Resources