Develop Bugs

[GUIDE][KERNEL] porting a kernel from another device

Made By :Spacecaker
What u need
windows or linux
ROM (that u wanna port to ace )
Dev Tools (like pack/unpack boot.img) Like this for windows and or linux
What u need to do??
unpack your boot.img
Change file on ramdisk
init.rc need to change >> (unpack the boot img from rom u wanna port
open init.rc and copy the stuff after BOOTPATH
change ramdisk/lib/modules >>> your modules ( not really importatnt )
repack ramdisk boot.img
Download the Guide below to get some pictures +
more tips download http://www.mediafire.com/download.php?u2ff9tthrrc29h1
Click to expand...
Click to collapse
orginel thread : http://forum.xda-developers.com/showthread.php?t=1574332

have you tried to port a kernel before? this guide doesn't mention about some spesific important stuff. it will definetely brick our device.

cool
a cool guide. find as pdf attached

this is only an example. our kernel partition is only 5mb. any size bigger wont work. then how about initbcrm2153 file?the zImage file? i've made two kernel. its difficult. port a kernel is more difficult and definetely not as easy as described in this post.

kurotsugi said:
this is only an example. our kernel partition is only 5mb. any size bigger wont work. then how about initbcrm2153 file?the zImage file? i've made two kernel. its difficult. port a kernel is more difficult and definetely not as easy as described in this post.
Click to expand...
Click to collapse
this guide is made by Spacecaker
he is developer ... so defenetly it will not brick our device .........

kurotsugi said:
this is only an example. our kernel partition is only 5mb. any size bigger wont work. then how about initbcrm2153 file?the zImage file? i've made two kernel. its difficult. port a kernel is more difficult and definetely not as easy as described in this post.
Click to expand...
Click to collapse
porting is too easy
if you have any doubts just check the attached file ! !
he also provided with SS ........
we can easily port it into our deveice

then...prove it. try to port a kernel from mini.
you also forgot this part. whithout this part our device won't work
===============================
then add/replace these in the rom it self ( copy from stock or cm7 )
These are Always needed !!
/lib/libril.so
/lib/libsecril-client.so
/lib/libsec-ril.so
/lib/libdiag.so
/system/hw
/system/modules
/system/etc/firmware , ppp, security, wifi, permission vold.stab
/system/user/keychars, keylayout
========================
one problem also comes from our recovery mode. unfortunately in our device it was stored inside kernel while in other device it was stored in different place.

It can Brick our Device
First Check it is Working and Then Post

thx for it i will try it

i dont think its that easy.. if it would hav been then we would hav had a kernel long back!!

hell_lock said:
i dont think its that easy.. if it would hav been then we would hav had a kernel long back!!
Click to expand...
Click to collapse
if porting means use kernel binary from one device to other device, not only not easy, but near to impossible. unlike pc which architecture is standardized, every cellphone have their own architecture make it impossible create generic kernel like you find in linux distro. you change hardware, it does't work. you mix with module from different version, it does't work. you mix with module from different compiler version, it does't work.
if porting means source code modification, that could be work, but need a lot of work. if someone ask how hard, last time i write my patch, i need about 6 hour just to add 2 lines modification in kernel source. i use linux in last 9 years and in real life i am a programmer, so reading c source code is something that i do almost everyday. still, i need that 6 hour because linux kernel source code is very complex.
and why op give this thread's title kernel. the tutorial is about using rom from other device using your original kernel.

irfanbagus said:
if porting means use kernel binary from one device to other device, not only not easy, but near to impossible. unlike pc which architecture is standardized, every cellphone have their own architecture make it impossible create generic kernel like you find in linux distro. you change hardware, it does't work. you mix with module from different version, it does't work. you mix with module from different compiler version, it does't work.
if porting means source code modification, that could be work, but need a lot of work. if someone ask how hard, last time i write my patch, i need about 6 hour just to add 2 lines modification in kernel source. i use linux in last 9 years and in real life i am a programmer, so reading c source code is something that i do almost everyday. still, i need that 6 hour because linux kernel source code is very complex.
and why op give this thread's title kernel. the tutorial is about using rom from other device using your original kernel.
Click to expand...
Click to collapse
thank you. i just wanna post the same thing before saw your post, and you're right indeed. theres no such thing as "porting kernel". binary kernel is specific, it'll only work with the device it were originally compiled for.

ROFL.....
BTW dont post tutorials , ports, etc that are somewhat copy paste and not tested it yourself..

Hey what about drivers... I wanted to get usb otg drivers on galaxy ace plus... Some dev ported it from galaxy s2 to galaxy s... But i dont have much knoladge of kernel development as i have windows... And i also found few lines about otg in my volt.fstab
# otg sdcard
{
ums_path = /dev/zero
asec = disable
}
usb_mount sdcard2 /mnt/sdcard/usbStorage auto /devices/platform/msm_hsusb_host.0
#end line ## keep this line
So i think it can support usb otg but doesnot have drivers...
Can any one help....or suggest something...
Sent from my GT-S7500 using xda premium

NICE!
Nice thanks!

kurotsugi said:
then...prove it. try to port a kernel from mini.
you also forgot this part. whithout this part our device won't work
===============================
then add/replace these in the rom it self ( copy from stock or cm7 )
These are Always needed !!
/lib/libril.so
/lib/libsecril-client.so
/lib/libsec-ril.so
/lib/libdiag.so
/system/hw
/system/modules
/system/etc/firmware , ppp, security, wifi, permission vold.stab
/system/user/keychars, keylayout
========================
one problem also comes from our recovery mode. unfortunately in our device it was stored inside kernel while in other device it was stored in different place.
Click to expand...
Click to collapse
Right. A Boot image is not completely independent of other partitions

[Kernel] TF300T JB kernel on TF300TG with ICS bootloader

Being one of those (few apparantly) with a TF300TG, I've been trying to get the JB kernel source from the TF300T up and running - more because I'd like to work on getting Native Linux running (and all of Nvidia's drivers want the 3.1.10 kernel - I've already tried using them on the ICS kernel with correct options) than Jellybean.
While I do have my blobs for NVflash, I'd still rather not try and flash the JB bootloader to my device.
Anyhow, I've done some digging, and what I can tell for sure is that is that JB kernel panics from trying to kill the idle task, this is specifically caused by bad_mode() in arch/arm/kernel/traps.c.
If anyone has any info on how the different bootloaders might be affecting the boot process, or a better way of debugging (at the moment, I adjust the amount of time before the device restarts due to the panic) please do contribute!
EDIT: Figures that just after I post this news of a JB update comes around. Still though, I'm curious as to what exactly the bootloader is doing differently.

here is the kernel command line for the JB bootloader , I believe that it is sent by the bootloader.
I really don't know how else the bootloader could cause kernel panics, but clearly it does.
Code:
<5>Kernel command line: tegra_wdt.heartbeat=30 tegraid=30.1.3.0.0 [email protected]
commchip_id=0 androidboot.serialno=015d15b4f8101214 androidboot.commchip_id=0
video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,0
usbcore.old_scheme_first=1 [email protected] [email protected]
core_edp_mv=0 audio_codec=wm8903 board_info=245:0:fc:cc:28 tegraboot=sdmmc gpt
gpt_sector=60440575 android.kerneltype=recovery androidboot.productid=0x02
androidboot.carrier=wifi-only

cb22 said:
Being one of those (few apparantly) with a TF300TG, I've been trying to get the JB kernel source from the TF300T up and running - more because I'd like to work on getting Native Linux running (and all of Nvidia's drivers want the 3.1.10 kernel - I've already tried using them on the ICS kernel with correct options) than Jellybean.
While I do have my blobs for NVflash, I'd still rather not try and flash the JB bootloader to my device.
Anyhow, I've done some digging, and what I can tell for sure is that is that JB kernel panics from trying to kill the idle task, this is specifically caused by bad_mode() in arch/arm/kernel/traps.c.
If anyone has any info on how the different bootloaders might be affecting the boot process, or a better way of debugging (at the moment, I adjust the amount of time before the device restarts due to the panic) please do contribute!
EDIT: Figures that just after I post this news of a JB update comes around. Still though, I'm curious as to what exactly the bootloader is doing differently.
Click to expand...
Click to collapse
Yeah, apparently a new kernel for the TG is being released. Anyway, I own a TF300T and I would love to see Ubuntu booting natively on my device, so if you need any tester for your future endeavors send me a PM.

The reason the JB kernel doesn't work on the ICS bootloader, and vice versa is due to something that has been enabled in the new boot process called Trusted Foundations. Trusted Foundations are an implementation of the Trustzone security features present in all arm Cortex-A* and ARM1176 SoCs. This feature needs to be implemented from boot time to be set up correctly, in JB ASUS enabled the Trusted Foundations feature in the bootloader, because of this it is also required in kernel. Theoretically if you were to change CONFIG_TRUSTED_FOUNDATIONS=y to =n the kernel will probably boot on the ICS bootloader.

[Q] Why did Huawei encript the Bootloader

Hey,
I'm asking myself, why Huawei used a crypted bootloader.
Ok, i can understand if they did this to prevent custom roms and kernel-modification ... but why did the release the aops-kernel-source, if you can't flash the finished kernel and use it to make a good-working aosp-based rom?
Why did they even release this kernel-source.

They are probably planning on removing the encryption in the near future, otherwise there would be no use for the AOSP kernel.

Sounds like this ..
But i think its a little bit frustrating, if you know the sources but you cant do anything ^^

Why u all so miss informed?
Source is real kernel who runs by Huawei. Its not "AOSP".
Bootloader (u-boot) just crc check then starts init ramdisk and boot Android.
Only Update.app use MD5 RSA for verify

[DEV][KERNEL]Kexec-hardboot patch

I would like to explain this a little bit:
What is kexec?
It is a function which allows you to boot an alternative kernel without needing to flash it or using `fastboot boot`. I am not going to write a thousand words to explain this, so if you want more info, search it yourself.
What is kexec hardboot?
It does the same as what kexec aims to do, but instead of booting another kernel directly, it reboots the device before doing so so that the hardware can be reinitialized by the bootloader. Normal kexec boots the kernel with the hardware in an unclean state, which is not very healthy. Kexec hardboot is somehow healthier.
I know I am not explaining very well, so please refer to the original thread by @Tasssadar
So what is this post about?
At this moment, there aren't any non-stock ROM, CAF or CM kernel isn't ported yet, so this is pretty useless actually.
In the future, if there are any custom ROMs, this will come in handy because it will allow "installing" multiple ROMs without having to flash them to the device memory.
Basically, this is just to prepare for the future.
Who should be reading this?
Well, developers who can properly compile a kernel.
Patches:
Kernel patch: https://gist.github.com/alvinhochun/7945428
Or, if you cloned my github stock kernel tree, check this: https://github.com/alvinhochun/sony-xperia-m-kernel/commit/2e818d81f21f6a627bc629e477052045426b0663
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
All these options must be enabled.​
Userspace kexec binary: Use the one compiled by @Tasssadar on http://forum.xda-developers.com/showthread.php?p=46223952​
Usage:
I have wrote a simple shell script to automatically set the correct cmdline here:
https://gist.github.com/alvinhochun/7945270
Basically, the most important thing is to make sure the addresses are correct and the cmdline has the proper information in it.
The script requires kernel to be packed with CWM which also provides /boot/busybox. You can use this tool: http://forum.xda-developers.com/showthread.php?t=2481864
Just download the kexec binary and put it in place.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices.
My patch is based on the one by @Tasssadar on http://forum.xda-developers.com/showthread.php?p=46223952

So, are this is like 'Live CD' for android?

Richardsentosa said:
So, are this is like 'Live CD' for android?
Click to expand...
Click to collapse
Well, that analogy can't exactly be used. It's more like the kernel acts as a bootloader that is used to boot another kernel.

alvinhochun said:
Well, that analogy can't exactly be used. It's more like the kernel acts as a bootloader that is used to boot another kernel.
Click to expand...
Click to collapse
after see N4 multiboot, i think this is a great feature.

alvinhochun said:
I would like to explain this a little bit:
What is kexec?
It is a function which allows you to boot an alternative kernel without needing to flash it or using `fastboot boot`. I am not going to write a thousand words to explain this, so if you want more info, search it yourself.
What is kexec hardboot?
It does the same as what kexec aims to do, but instead of booting another kernel directly, it reboots the device before doing so so that the hardware can be reinitialized by the bootloader. Normal kexec boots the kernel with the hardware in an unclean state, which is not very healthy. Kexec hardboot is somehow healthier.
I know I am not explaining very well, so please refer to the original thread by @Tasssadar
So what is this post about?
At this moment, there aren't any non-stock ROM, CAF or CM kernel isn't ported yet, so this is pretty useless actually.
In the future, if there are any custom ROMs, this will come in handy because it will allow "installing" multiple ROMs without having to flash them to the device memory.
Basically, this is just to prepare for the future.
Who should be reading this?
Well, developers who can properly compile a kernel.
Patches:
Kernel patch: https://gist.github.com/alvinhochun/7945428
Or, if you cloned my github stock kernel tree, check this: https://github.com/alvinhochun/sony-xperia-m-kernel/commit/2e818d81f21f6a627bc629e477052045426b0663
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
All these options must be enabled.​
Userspace kexec binary: Use the one compiled by @Tasssadar on http://forum.xda-developers.com/showthread.php?p=46223952​
Usage:
I have wrote a simple shell script to automatically set the correct cmdline here:
https://gist.github.com/alvinhochun/7945270
Basically, the most important thing is to make sure the addresses are correct and the cmdline has the proper information in it.
The script requires kernel to be packed with CWM which also provides /boot/busybox. You can use this tool: http://forum.xda-developers.com/showthread.php?t=2481864
Just download the kexec binary and put it in place.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices.
My patch is based on the one by @Tasssadar on http://forum.xda-developers.com/showthread.php?p=46223952
Click to expand...
Click to collapse
can we use this to boot cm10 cm11 on sony Xperia z?

nabelar82 said:
can we use this to boot cm10 cm11 on sony Xperia z?
Click to expand...
Click to collapse
I guess you are mislead this is a kernel feature and is not at all related to booting of a rom

SpinXO said:
I guess you are mislead this is a kernel feature and is not at all related to booting of a rom
Click to expand...
Click to collapse
Well I read that but I been looking the way that we can install cm11 on our xperia z with locked bootloader and this seems to help cause we can't flash boot img on locked bootloader

nabelar82 said:
Well I read that but I been looking the way that we can install cm11 on our xperia z with locked bootloader and this seems to help cause we can't flash boot img on locked bootloader
Click to expand...
Click to collapse
Not really.
But Recognized Developer @Rachit Rawat has explained how the Locked Bootloader CM is booted and I see @Olivier have worked on the same for Xperia S you can try to contact him
Explanation Link: http://forum.xda-developers.com/showthread.php?p=49073506#post49073506

nabelar82 said:
Well I read that but I been looking the way that we can install cm11 on our xperia z with locked bootloader and this seems to help cause we can't flash boot img on locked bootloader
Click to expand...
Click to collapse
Surely there is a way known as 2nd-init, with which we can change the ramdisk without changing the kernel.
Xperia SP has 3-4 ROMs booted with the same method on locked bootloader. You can search in SP forums and contact the respective persons for porting the feature.

aweosomeabhijeet said:
Surely there is a way known as 2nd-init, with which we can change the ramdisk without changing the kernel.
Xperia SP has 3-4 ROMs booted with the same method on locked bootloader. You can search in SP forums and contact the respective persons for porting the feature.
Click to expand...
Click to collapse
Well I am very interested on this patch but I am not a developer it will be very interesting if someone apply on a xperia z an we can test can someone try? I can test

aweosomeabhijeet said:
Surely there is a way known as 2nd-init, with which we can change the ramdisk without changing the kernel.
Xperia SP has 3-4 ROMs booted with the same method on locked bootloader. You can search in SP forums and contact the respective persons for porting the feature.
Click to expand...
Click to collapse
Contact Skrilax_CZ on freenode at channel #motomagic and he might be able to help us.

[EXPLOIT][HOW-TO] BypassLKM: bypass module signature verification on TW 4.3

I got this idea after reading about CVE-2013-6282 and seeing the source for it.
As we all know, anyone with MF3+ bootloaders on ATT/VZW cannot load custom kernels/recoveries. Hashcode saved the day with Safestrap, which allowed users to run custom ROMs using stock, signed boot.imgs (initramfs/kernel). Unfortunately booting a custom kernel is still not possible due to BL restrictions.
With this latest root exploit, it is possible to overwrite kernel memory and thus remove some of the restrictions of the stock kernel. Most important is the ability to insert kernel modules not signed by Samsung, specifically kexec. This module can allow one to load any custom kernel regardless of BL restrictions. Before you ask, I have never compiled nor worked with kexec!
I'm going to go over the process just for completeness, you can skip this section if you want. It's mostly for devs:
With 4.3, when you insert one of the included modules (ie, /system/lib/modules), you will see the following in dmesg:
Code:
<4>[ 2003.009063] TIMA: lkmauth--launch the tzapp to check kernel module; module len is 3224
<4>[ 2003.009124] TIMA: lkmauth -- hdr before kreq is : e3003000
<4>[ 2003.009155] TIMA: lkmauth--send cmd (tima_lkm) cmdlen(304:320), rsplen(264:320) id 0x00050000, req (0xE511C000), rsp(0xE511C140), module_start_addr(0xE3003000) module_len 3224
<4>[ 2003.012237] TIMA: lkmauth--verification succeeded.
Though I'm not intimately familiar with the workings of lkmauth, it's obvious it's querying the trustzone (TZ) to verify the module. If we now change one insignificant byte in the module, you get:
Code:
<4>[ 2301.298980] TIMA: lkmauth--launch the tzapp to check kernel module; module len is 3224
<4>[ 2301.299011] TIMA: lkmauth -- hdr before kreq is : e300c000
<4>[ 2301.299041] TIMA: lkmauth--send cmd (tima_lkm) cmdlen(304:320), rsplen(264:320) id 0x00050000, req (0xE511C000), rsp(0xE511C140), module_start_addr(0xE300C000) module_len 3224
<3>[ 2301.301391] TIMA: lkmauth--verification failed -1
<4>[ 2301.301544] TIMA: MSG=lkm_modified; result (TIMA_RESULT=MSG=lkm_modified;)
We can use these messages to narrow down the code in the kernel. I'm using ATT MK2 as the example here:
kernel/module.c
Code:
/* parse result */
if (krsp->ret == 0) {
pr_warn("TIMA: lkmauth--[B]verification succeeded[/B].\n");
ret = 0; /* ret should already be 0 before the assignment. */
} else {
pr_err("TIMA: lkmauth--[B]verification failed[/B] %d\n", krsp->ret);
ret = -1;
....
If we unpack boot.img, then decompress the zImage, we can find this code in the binary. Fire up IDA and set the base address to 0xC0008000. You should be able to resolve the above string reference to:
Code:
ROM:C00B9C20 44 11 98 E5 LDR R1, [R8,#0x144]
ROM:C00B9C24 00 00 51 E3 CMP R1, #0
[B][COLOR="Red"]ROM:C00B9C28 02 00 00 1A BNE loc_C00B9C38[/COLOR][/B]
ROM:C00B9C2C 54 01 9F E5 LDR R0, =a4TimaLkmauthVe ; "<4>TIMA: lkmauth--verification succeede"...
ROM:C00B9C30 CA 57 1D EB BL sub_C080FB60
ROM:C00B9C34 3C 00 00 EA B loc_C00B9D2C
That BNE is the target for our patch. So bypasslkm will basically overwrite that test with a NOP instruction thus forcing the authentication to succeed.
I tested inserting a modified stock module and one I compiled. Btw, if you wanna use the modules from the kernel source tree, be sure to add
-fno-pic to CFLAGS_MODULE in the Makefile.
-------------------------------------------------------------------------------------------------------------
Usage:
bypasslkm is run alone, and patches the kernel in memory. It does NOT make any changes to the filesystem, and a reboot will require re-executing the patch. Please note the patch will remain in memory until you run 'bypasslkm -r' OR reboot. THIS CAN LEAVE YOUR OS IN A VULNERABLE STATE TO MALWARE. Ideally, you would run the patch, insert your module, then run the patch with -r.
Typical usage:
adb push bypasslkm /data/local/tmp
cd /data/local/tmp
chmod 755 bypasslkm
./bypasslkm
insmod <modulename.ko>
./bypasslkm -r
Supported stock kernels: ATT MK2, VZW MK2, VZW MJ7
CREDITS
fi01 - awesome source for the CVE!
CUBE - getroot source!
djrbliss - thanks for the makefile =P
DOWNLOAD:
Get the latest from my git: https://github.com/jeboo/bypasslkm

Reserved!

Very nice work. Wish I had a MF3 device so I could try it.

Thank you @jeboo. I'll see what I can do with this
Sent from my XT926 using Tapatalk

Nice job man!
Sent from my SM-N900V using Tapatalk

Hashcode said:
Thank you @jeboo. I'll see what I can do with this
Sent from my XT926 using Tapatalk
Click to expand...
Click to collapse
it will help to crack the bootloader note 3?

This also works on the I545 with MI1 kernel...
This is directed at @Hashcode and @jeboo:
Guys, I just tried this on my I545 running the MI1 kernel, and it works. I am running Hyperdrive RLS 10.2 with the ATT compatibility pack (using AT&T service) -- but as you know, I am still stuck on the stock Verizon MI1 kernel. You should know that I flashed Hyperdrive over the stock ROM -- that's the only way (at the time) I could get it onto AT&T service here in the US.
My immediate question is how will this allow me to completely replace the stock kernel with something like the Infamous 4.6 OC kernel? I am just getting into this phase of development, so I am not as up on this as you guys are. I know every time I flash the Infamous kernel, the flash in SS seems to work -- but the phone always reboots to the stock 3.0.4 verizon kernel.
Of course, I had another thought, too -- I wonder if it is possible to use this to allow us to insert a module that does something similar to the Motorola Trust Zone unlock? Just another item for your consideration...
Here is a screen capture of me running bypasslkm:
=============================================
130|[email protected]:/data/local/tmp # ./bypasslkm
BypassLKM patch by Jeboo
usage: -r will restore kernel to original
Big thanks to fi01 & CUBE for their awesome CVE-2013-6282 exploit source!
ro.build.product=jflteatt
ro.build.displayid=JDQ39.I545VRUAME7
Patching kernel @ 0xC00B9C28: unsigned modules can now be inserted.
Done.
[email protected]:/data/local/tmp # ./bypasslkm -r
BypassLKM patch by Jeboo
usage: -r will restore kernel to original
Big thanks to fi01 & CUBE for their awesome CVE-2013-6282 exploit source!
ro.build.product=jflteatt
ro.build.displayid=JDQ39.I545VRUAME7
Patching kernel @ 0xC00B9C28: restoring original value.
Done.
[email protected]:/data/local/tmp #

I have an AMDL S4 so I'm already running AOSP ROM's, so I've never really paid attention to the problems which the newer S4's face.
Does the OP have a patch that allows the newer S4's to run AOSP now also?
Sorry if it's a stupid question.

Not quite yet...
CZ Eddie said:
I have an AMDL S4 so I'm already running AOSP ROM's, so I've never really paid attention to the problems which the newer S4's face.
Does the OP have a patch that allows the newer S4's to run AOSP now also?
Sorry if it's a stupid question.
Click to expand...
Click to collapse
Not quite yet -- but this is looking extremely promising!!

CZ Eddie said:
I have an AMDL S4 so I'm already running AOSP ROM's, so I've never really paid attention to the problems which the newer S4's face.
Does the OP have a patch that allows the newer S4's to run AOSP now also?
Sorry if it's a stupid question.
Click to expand...
Click to collapse
OP has an exploit that lets us load unsigned kernel modules. This means we can try to load up a kexec module, which would then load in a kernel over the stock one. So possibly, if it can be implemented.
budding_developer said:
This is directed at @Hashcode and @jeboo:
Guys, I just tried this on my I545 running the MI1 kernel, and it works. I am running Hyperdrive RLS 10.2 with the ATT compatibility pack (using AT&T service) -- but as you know, I am still stuck on the stock Verizon MI1 kernel. You should know that I flashed Hyperdrive over the stock ROM -- that's the only way (at the time) I could get it onto AT&T service here in the US.
My immediate question is how will this allow me to completely replace the stock kernel with something like the Infamous 4.6 OC kernel? I am just getting into this phase of development, so I am not as up on this as you guys are. I know every time I flash the Infamous kernel, the flash in SS seems to work -- but the phone always reboots to the stock 3.0.4 verizon kernel.
Of course, I had another thought, too -- I wonder if it is possible to use this to allow us to insert a module that does something similar to the Motorola Trust Zone unlock? Just another item for your consideration...
Click to expand...
Click to collapse
SS does not actually flash kernels, which is why it reboots to stock. The way this will allow you to run a different kernel is by loading in an unsigned kexec module and loading the new kernel over the stock one using that module. As for the Trust Zone unlock, someone with more real dev knowledge than me will have to look into that.

budding_developer said:
This is directed at @Hashcode and @jeboo:
Guys, I just tried this on my I545 running the MI1 kernel, and it works. I am running Hyperdrive RLS 10.2 with the ATT compatibility pack (using AT&T service) -- but as you know, I am still stuck on the stock Verizon MI1 kernel. You should know that I flashed Hyperdrive over the stock ROM -- that's the only way (at the time) I could get it onto AT&T service here in the US.
My immediate question is how will this allow me to completely replace the stock kernel with something like the Infamous 4.6 OC kernel? I am just getting into this phase of development, so I am not as up on this as you guys are. I know every time I flash the Infamous kernel, the flash in SS seems to work -- but the phone always reboots to the stock 3.0.4 verizon kernel.
Of course, I had another thought, too -- I wonder if it is possible to use this to allow us to insert a module that does something similar to the Motorola Trust Zone unlock? Just another item for your consideration...
Click to expand...
Click to collapse
Careful running this on unsupported kernels..I didn't add any sanity checking.

jeboo said:
Careful running this on unsupported kernels..I didn't add any sanity checking.
Click to expand...
Click to collapse
Didn't figure you did at this early stage... I am well equipped with everything I need to restore (short of JTAG, of course)... thanks for the warning, though!

I know it's early but are there any Modules handy for testing
SAFESTRAPPED ATT MK2 I337 S4

jball said:
I know it's early but are there any Modules handy for testing
SAFESTRAPPED ATT MK2 I337 S4
Click to expand...
Click to collapse
Too early, give it a week or so.. it's a long process being that no one is doing it full time...
Then again it's Christmas time, so maybe a few weeks..

tommydrum said:
Too early, give it a week or so.. it's a long process being that no one is doing it full time...
Then again it's Christmas time, so maybe a few weeks..
Click to expand...
Click to collapse
I've done some reading on it and trust me I do know it's not an easy thing for you and me.i don't put in development hours as I'm not a developer.i just want to Contribute anything I can even if it's just my phone.if you asked my wife I live and breath XDA .Thank you all for the Hard work your doing an awesome job
SAFESTRAPPED ATT MK2 I337 S4

jball said:
I've done some reading on it and trust me I do know it's not an easy thing for you and me.i don't put in development hours as I'm not a developer.i just want to Contribute anything I can even if it's just my phone.if you asked my wife I live and breath XDA .Thank you all for the Hard work your doing an awesome job
SAFESTRAPPED ATT MK2 I337 S4
Click to expand...
Click to collapse
I'd be willing to contribute my phone too .. even more since there's work around to odin bricked phone back on mk2

tommydrum said:
I'd be willing to contribute my phone too .. even more since there's work around to odin bricked phone back on mk2
Click to expand...
Click to collapse
What work around are you refering too? I thought there was no way to odin to MK2.
Sent from my GT-I9505 using XDA Premium 4 mobile app

cerobles1 said:
What work around are you refering too? I thought there was no way to odin to MK2.
Sent from my GT-I9505 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Let's not clutter this thread.Look it up please

i don't mean to be a noob but will this work on mf3?

Ask in another thread please..and we don't know, but there's a good chance yes..
Again..please only developers post on this thread!! Keep it clean!!