4.9 was released and Nexus 5 it's support by mainline kernel
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-ARM-Pull
Interesting. This might bring development back to the phone. Also 4.8 and 4.9 have some amazing features and speed improvements.
Will any dev merge and update our kernel? will this function with our android latest version?
santi1993 said:
Will any dev merge and update our kernel? will this function with our android latest version?
Click to expand...
Click to collapse
No, it's probably not even functional in many aspects, there will be a lot of patching/fixing needed to get it to work.
There is already been discussed about his.
Yes, it's impossible use 4.9 without patch related to panel, exc exc
So what does exactly the "Nexus 5 support" on this kernel mean if you can't run Android on it without patching? Would it potentially help running Linux distros on our devices or?
TheReduxPL said:
So what does exactly the "Nexus 5 support" on this kernel mean if you can't run Android on it without patching? Would it potentially help running Linux distros on our devices or?
Click to expand...
Click to collapse
There is support for the kernel, so yes, you could now run Arch, Debian, OpenWRT, or DD-WRT much more easily.
Android utilizes old libraries that are not compatible with new kernels (that's at least my understanding of the matter), so you would need to patch it to run a newer kernel, and that could only get you so far.
The newest kernel version that anyone had managed to boot Android with is the latest 4.4.x LTS release.
I wonder if someone could backport the necessary changes from 4.9 to the latest 4.4.x release though, that would already be something.
Thank you! I really like the concept of running *WRT on Nexus - I wonder how would functionality like network booting work like...
Could the mainline kernel also be used for other non-Android OSs like Ubuntu (Touch) or Sailfish OS?
TheReduxPL said:
Thank you! I really like the concept of running *WRT on Nexus - I wonder how would functionality like network booting work like...
Could the mainline kernel also be used for other non-Android OSs like Ubuntu (Touch) or Sailfish OS?
Click to expand...
Click to collapse
I don't think so, as they rely on Android bits to work with the bootloader and recovery.
But perhaps there is a chance with the new OS that KDE are cooking, which is supposed to be completely independent of Android.
The 4.10 kernel brings in mainline support for the Nexus 6P and the Nexus 5X.
I wish that mainline support would arrive for the Nexus 4.
moriel5 said:
The newest kernel version that anyone had managed to boot Android with is the latest 4.4.x LTS release.
Click to expand...
Click to collapse
Update: Apparently Android 6.0.x and up can now utilize kernel 4.9.x.
As there is a build of Android 7.1.x for the x86 platform (I have no idea whether it is an official build of Android-x86, nor do I know the precise Android version, though) with a 4.9.x kernel (again, I have no idea precisely which version).
My source is a newly thread opened in the Remix OS forum, in which the OP asks for the possibility of updating the kernel in Remix OS, and mentions that he/she managed to boot it (only in debug mode, though) with the aforementioned kernel.
The source: https://forum.xda-developers.com/remix/remix-os/remix-3-0-207-kernel-t3546057
anyone managed to boot a hh from any kind of 4.9 compilation?
Sent from my Nexus 5 CAF using Tapatalk
Hey folks!
I'm playing around with one of my nexus 5 devices for a while now... right now i got Maru OS installed and it's nice
But anyway this is another story.
santi1993 said:
anyone managed to boot a hh from any kind of 4.9 compilation?
Click to expand...
Click to collapse
Yeah i did!
Used this kernel (which is 4.9.27):
https://git.linaro.org/landing-team...rnel-debian-qcom-dragonboard410c-17.04.tar.gz
... and used Linaro GCC 4.8-2014.04 toolchain (had to use the 32Bit version here).
Then:
make qcom_defconfig
make
make qcom-msm8974-lge-nexus5-hammerhead.dtb
Then later on:
cat arch/arm/boot/zImage arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dtb > arch/arm/boot/zImage-dtb
Then i took twrp-3.0.3-0-hammerhead.img and extracted it with abootimg.
Changed the cmdline parameter for console to console=ttyMSM0,115200,n8
Took the new kernel and rebuild the recovery image to be my test image (just quick'n'dirty)
Then via adb:
reboot bootloader
... and afterwards injected the boot image (e.g.):
fastboot boot hammerhead-kernel4.img
See the attached file for the output.
This log was taken with a serial console cable attached to the earphone plug.
Cheers,
scholbert
scholbert said:
Hey folks!
I'm playing around with one of my nexus 5 devices for a while now... right now i got Maru OS installed and it's nice
But anyway this is another story.
Yeah i did!
Used this kernel (which is 4.9.27):
https://git.linaro.org/landing-team...rnel-debian-qcom-dragonboard410c-17.04.tar.gz
... and used Linaro GCC 4.8-2014.04 toolchain (had to use the 32Bit version here).
Then:
make qcom_defconfig
make
make qcom-msm8974-lge-nexus5-hammerhead.dtb
Then later on:
cat arch/arm/boot/zImage arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dtb > arch/arm/boot/zImage-dtb
Then i took twrp-3.0.3-0-hammerhead.img and extracted it with abootimg.
Changed the cmdline parameter for console to console=ttyMSM0,115200,n8
Took the new kernel and rebuild the recovery image to be my test image (just quick'n'dirty)
Then via adb:
reboot bootloader
... and afterwards injected the boot image (e.g.):
fastboot boot hammerhead-kernel4.img
See the attached file for the output.
This log was taken with a serial console cable attached to the earphone plug.
Cheers,
scholbert
Click to expand...
Click to collapse
Linux version 4.9.27 ([email protected])
Wow, you are one of the coolest users on there! i doubt anyone could boot it up!
You rock! hope we can get a public release to test it out!
scholbert said:
Hey folks!
I'm playing around with one of my nexus 5 devices for a while now... right now i got Maru OS installed and it's nice
But anyway this is another story.
Yeah i did!
Used this kernel (which is 4.9.27):
https://git.linaro.org/landing-team...rnel-debian-qcom-dragonboard410c-17.04.tar.gz
... and used Linaro GCC 4.8-2014.04 toolchain (had to use the 32Bit version here).
Then:
make qcom_defconfig
make
make qcom-msm8974-lge-nexus5-hammerhead.dtb
Then later on:
cat arch/arm/boot/zImage arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dtb > arch/arm/boot/zImage-dtb
Then i took twrp-3.0.3-0-hammerhead.img and extracted it with abootimg.
Changed the cmdline parameter for console to console=ttyMSM0,115200,n8
Took the new kernel and rebuild the recovery image to be my test image (just quick'n'dirty)
Then via adb:
reboot bootloader
... and afterwards injected the boot image (e.g.):
fastboot boot hammerhead-kernel4.img
See the attached file for the output.
This log was taken with a serial console cable attached to the earphone plug.
Cheers,
scholbert
Click to expand...
Click to collapse
Hey that's amazing. I've been working on this too. So where exactly did you enter the command line parameter for console? Can you list out that command?
Sent from my Nexus 5 using XDA Labs
santi1993 said:
Linux version 4.9.27 ([email protected])
Wow, you are one of the coolest users on there! i doubt anyone could boot it up!
You rock! hope we can get a public release to test it out!
Click to expand...
Click to collapse
Thanks for appreciation, but what do you expect from "public release"?
As many other already posted here, this kernel is far away from the 3.4 Images for daily use.
So this is just for fun of course :angel:
Icyphox said:
Hey that's amazing. I've been working on this too. So where exactly did you enter the command line parameter for console? Can you list out that command?
Sent from my Nexus 5 using XDA Labs
Click to expand...
Click to collapse
Have a look at the tool abootimg.
You could use a bootimg.cfg fle and change the cmdline for your boot image individually.
E.g.:
Code:
bootsize = 0xe48800
pagesize = 0x800
kerneladdr = 0x8000
ramdiskaddr = 0x2900000
secondaddr = 0xf00000
tagsaddr = 0x2700000
name =
cmdline = console=ttyMSM0,115200,n8 androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1 androidboot.selinux=permissive
The other parameters are fixed values for hammerhead... and the bootsize value depends on the size needed for your image.
In this case it's just the default value used for TWRP.
Then use the tool like this:
abootimg --create hammerhead-kernel4.img -f bootimg.cfg -k zImage-dtb -r initrd.img
Best regards,
scholbert
scholbert said:
Thanks for appreciation, but what do you expect from "public release"?
As many other already posted here, this kernel is far away from the 3.4 Images for daily use.
So this is just for fun of course :angel:
Have a look at the tool abootimg.
You could use a bootimg.cfg fle and change the cmdline for your boot image individually.
E.g.:
The other parameters are fixed values for hammerhead... and the bootsize value depends on the size needed for your image.
In this case it's just the default value used for TWRP.
Then use the tool like this:
abootimg --create hammerhead-kernel4.img -f bootimg.cfg -k zImage-dtb -r initrd.img
Best regards,
scholbert
Click to expand...
Click to collapse
Wonderful! The heads-up I needed was the bootimg.cfg. Thanks a bunch. Also, is your ROM usable with this kernel?
Sent from my Nexus 5 using XDA Labs
Icyphox said:
Wonderful! The heads-up I needed was the bootimg.cfg. Thanks a bunch. Also, is your ROM usable with this kernel?
Sent from my Nexus 5 using XDA Labs
Click to expand...
Click to collapse
No far away from any use together with a ROM or even anything the TWRP image uses inside.
No graphics... no usb...
This is just a proof of concept, playing around with the dts files and kernel. Nothing more.
If someone would create a console based ramdisk with some tools included, you may dig a little deeper into the soc or check which parts are responsive or not.
Cheers,
scholbert
It has been quite some time.
Does anyone think that using PostMarketOS's kernel as a stepping stone may help get at least kernel 4.4 to a daily-driver ready status?
Update: Perhaps it would also be a good idea to use the Nexus 7 (2013)'s sources to try porting the newer kernel there to the Nexus 4 (as they share the same SOC).
scholbert said:
Hey folks!
I'm playing around with one of my nexus 5 devices for a while now... right now i got Maru OS installed and it's nice
But anyway this is another story.
Yeah i did!
Used this kernel (which is 4.9.27):
https://git.linaro.org/landing-team...rnel-debian-qcom-dragonboard410c-17.04.tar.gz
... and used Linaro GCC 4.8-2014.04 toolchain (had to use the 32Bit version here).
Then:
make qcom_defconfig
make
make qcom-msm8974-lge-nexus5-hammerhead.dtb
Then later on:
cat arch/arm/boot/zImage arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dtb > arch/arm/boot/zImage-dtb
Then i took twrp-3.0.3-0-hammerhead.img and extracted it with abootimg.
Changed the cmdline parameter for console to console=ttyMSM0,115200,n8
Took the new kernel and rebuild the recovery image to be my test image (just quick'n'dirty)
Then via adb:
reboot bootloader
... and afterwards injected the boot image (e.g.):
fastboot boot hammerhead-kernel4.img
See the attached file for the output.
This log was taken with a serial console cable attached to the earphone plug.
Cheers,
scholbert
Click to expand...
Click to collapse
From the logs, it looks like the reason the boot stops is because of init.rc errors. I might be able to help with that, but my nexus 5's battery is toast.
Related
This method should work for Android 2.2 releases. This only works for 1.2.6 and 1.5.7. It does not work with 1.8.3, and so will almost surely not work for Android 2.3 releases. They have said the week of July 8th they will release the 1.8.3 source. As an alternative, I have figured out how to load a sbf from Latin America that is also Android 2.2.2, and we have it's kernel source. I have tested compiling a custom kernel for it, and it works. I advise only people interested in playing with custom kernels use this method.
Install Ubuntu Maverick with the gnueabi.
Packages:
binutils-arm-linux-gnueabi
cpp-4.4-arm-linux-gnueabi
cpp-4.5-arm-linux-gnueabi
g++-4.4-arm-linux-gnueabi
gcc-4.4-arm-linux-gnueabi
gcc-4.4-arm-linux-gnueabi-base
gcc-4.5-arm-linux-gnueabi
gcc-4.5-arm-linux-gnueabi-base
gcc-arm-linux-gnueabi
Argentina SBF
Run sbf_flash -x against it to break it into CG files. You only need CG56(boot), CG57(system), and CG58(webtop). You might be able to stick with the 1.8.3 AT&T webtop, I haven't tested.
Use fastboot to write them to the phone. It has to be moto-fastboot.
fastboot flash system CG57.img
fastboot flash webtop CG58.img
Use split_bootimg.pl to split CG56 into the kernel and ramdisk files.
Once you have compiled your own kernel
fastboot flash:raw boot zImage CG56.img-ramdisk.gz
Compiling a custom kernel
Download /proc/config.gz from a phone running the release you want to compile a kernel for
mkdir ~/atrix-kernel
cd ~/atrix-kernel
tar zxf ~/kernel.tgz
cp -a ~/config.gz .
gunzip config.gz
cp -a config .config
Edit .config if you want
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make oldconfig
make zImage
make modules
The resulting zImage is arch/arm/boot/zImage.
Use an existing ramdisk. Modify it if you want.
On phone:
dd if=/dev/block/mmcblk0p11 of=/tmp/boot.img
On computer, as root:
mkdir /mnt/boot
mount ~/boot.img /mnt/boot -o loop,ro
Use split_bootimg.pl to pull the ramdisk.gz out of boot.img
Read more at http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
If it mounts, you have the boot image. I can't guarntee it is mmcblk0p11 in all cases. It should also be 8mb.
fastboot flash:raw boot zImage ramdisk.gz
or
fastboot flash boot boot.img
If you want to change kernel command line arguments use mkbootimg. Run dmesg | less on your phone to copy YOUR kernel arguments.
Example:
mkbootimg --kernel zImage --ramdisk ramdisk.gz --cmdline "[email protected] [email protected] [email protected] vmalloc=320M video=tegrafb console=null usbcore.old_scheme_first=1 tegraboot=sdmmc tegrapart=mbr:1100:100:800,kpanic:2500:400:800 security=tomoyo androidboot.serialno=AGGB2I1532" -o boot.img
moto-fastboot
http://forum.xda-developers.com/showthread.php?t=1138092
fastboot 64-bit
http://forum.xda-developers.com/attachment.php?attachmentid=634867&d=1308871353
fastboot 32-bit
http://forum.xda-developers.com/attachment.php?attachmentid=635031&d=1308879588
mkbootimg 32-bit, should work for 64-bit if you have the libraries:
http://proton.cygnusx-1.org/~edgan/mkbootimg
split_bootimg.pl
http://code.lardcave.net/entries/2010/11/24/164025/split_bootimg.pl
http://zen-droid.googlecode.com/files/split_bootimg.pl
sbf_flash
http://blog.opticaldelusion.org/2010/05/sbfflash.html
1.2.6 AT&T kernel.tgz
http://sourceforge.net/projects/atrix.motorola/files/Atrix ATT/OLYFR_U4_1.2.6/kernel.tgz/download
0.50.0 Personal Argentina kernel.tgz
http://sourceforge.net/projects/atrix.motorola/files/Atrix LATAM/OLYLA_U4_0.50.0/kernel.tgz/download
Excellent work Edgan!
i've been fumbling around for a while now getting things set up, i wish i would have known this before.
thanks for the post/instructions!
this is what moto says about it:
https://sourceforge.net/projects/atrix.motorola/files/Atrix ATT/OLYFR_U4_1.2.6/
1. Create a workspace containing vanilla 'android-2.2.1_r1' release from Google.
2. Overlay Motorola-provided published repos on top of original Google versions.
3. Build user space components (see end of this document for the list of supported targets):
cd <workspace>
. build/envsetup.sh
lunch generic-user
make TARGET_BOARD_PLATFORM=tegra TARGET_ARCH_VARIANT=armv7-a \ arch_variant_cflags="-march=armv7-a -mtune=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16" \ BOARD_HAVE_BLUETOOTH=true BOARD_HAVE_BLUETOOTH_BCM=true \ BOARD_GPS_LIBRARIES= WPA_SUPPLICANT_VERSION=VER_0_6_X <list-of-targets>
4. Building kernel and kernel modules.
cd <workspace>/kernel
export ARCH=arm
export CROSS_COMPILE="arm-eabi-"
make tegra_olympus_android_defconfig
make FACTORY_BUILD=false BUILD_ID=OLYFR_U4_1.2.6
cd <workspace>/vendor/bcm/wlan/osrc/open-src/src/dhd/linux
make ANDROID_BUILD_TOP=<workspace> BUILD_ID=OLYFR_U4_1.2.6
Appendix A: list of supported targets
out/target/product/generic/system/bin/bluetoothd
out/target/product/generic/system/bin/brcm_patchram_plus
out/target/product/generic/system/bin/busybox
out/target/product/generic/system/bin/dnsmasq
out/target/product/generic/system/bin/dumpe2fs
out/target/product/generic/system/bin/dund
out/target/product/generic/system/bin/e2fsck
out/target/product/generic/system/bin/hciattach
out/target/product/generic/system/bin/iptables
out/target/product/generic/system/bin/iwconfig
out/target/product/generic/system/bin/iwevent
out/target/product/generic/system/bin/iwgetid
out/target/product/generic/system/bin/iwlist
out/target/product/generic/system/bin/iwpriv
out/target/product/generic/system/bin/iwspy
out/target/product/generic/system/bin/mke2fs
out/target/product/generic/system/bin/pand
out/target/product/generic/system/bin/resize2fs
out/target/product/generic/system/bin/sdptool
out/target/product/generic/system/bin/tc
out/target/product/generic/system/bin/tune2fs
out/target/product/generic/system/framework/jcifs-krb5-1.3.12.jar
out/target/product/generic/system/lib/bluez-plugin/audio.so
out/target/product/generic/system/lib/bluez-plugin/input.so
out/target/product/generic/system/lib/liba2dp.so
out/target/product/generic/system/lib/libbluetoothd.so
out/target/product/generic/system/lib/libbluetooth.so
out/target/product/generic/system/lib/libext2_blkid.so
out/target/product/generic/system/lib/libext2_com_err.so
out/target/product/generic/system/lib/libext2_e2p.so
out/target/product/generic/system/lib/libext2fs.so
out/target/product/generic/system/lib/libext2_profile.so
out/target/product/generic/system/lib/libext2_uuid.so
out/target/product/generic/system/lib/libiprouteutil.so
out/target/product/generic/system/lib/libnetlink.so
out/target/product/generic/system/lib/libwbxmlparser.so
out/target/product/generic/system/xbin/avinfo
out/target/product/generic/system/xbin/hciconfig
out/target/product/generic/system/xbin/hcitool
out/target/product/generic/system/xbin/l2ping
i had problems compiling, but i hope tonight my luck is better. vanilla compiled fine, but not after i added the Atrix stuff to it.
i took everything and untar'd it in my working directory and created any directory structures that didn't exist, but i was a little uncertain as to what to do with a handful of them, like the kernel.tgz. you supposed to created that directory then untar it?
Should be stickified. This will be a useful resource for prospective rom builders.
Sent from my MB860 using XDA App
This is awesome! Thank you. I have been playing around with a build environment for a day or two. When I try the "make tegra_olympus_android_defconfig " it spits out an error at me...prolly missing something.
Sorry, I don't really know all that much about this, but could we use this to compile CM6? It wouldn't be ideal, but would be better than stock until someone who knows what they're doing makes a CM7 build.
Sent from my MB860 using XDA App
lunder said:
Sorry, I don't really know all that much about this, but could we use this to compile CM6? It wouldn't be ideal, but would be better than stock until someone who knows what they're doing makes a CM7 build.
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
kholk said earlier he got CM7 and will release when he is home.
anyways
I got my kernel build, now how do i use it to create a custom rom, could someone point me towards the info, or atlest give me som sort of hint!
samcripp said:
kholk said earlier he got CM7 and will release when he is home.
Click to expand...
Click to collapse
Some point me in the direction of where this was stated... been away from the computer since Friday... thanks
Swiftks said:
Some point me in the direction of where this was stated... been away from the computer since Friday... thanks
Click to expand...
Click to collapse
he said this on irc
samcripp said:
he said this on irc
Click to expand...
Click to collapse
did he say he had it or he was working it... to my understanding, porting CM7 is a long task. dont get me wrong, kholk is phenomenal but its hard to belive development has started, and its released soon. would be nice though, maybe hes been working hardcore on it and the port is going smoothly
Regardless, either way it's good news. I also hear that the official CM7 dev team is getting or has already gotten a Atrix too. Hope that maybe some time in the not to distant future we can get an "official" CM7 rom, built specifically around the Atrix & its hardware.
Sent from my MB860 using XDA Premium App
Swiftks said:
Regardless, either way it's good news. I also hear that the official CM7 dev team is getting or has already gotten a Atrix too. Hope that maybe some time in the not to distant future we can get an "official" CM7 rom, built specifically around the Atrix & its hardware.
Sent from my MB860 using XDA Premium App
Click to expand...
Click to collapse
agreed bud, couldent have said it any better
how many of you could compile an oc kernel? maybe thermal throttling disabled
anybody already working on it?
Swiftks said:
Regardless, either way it's good news. I also hear that the official CM7 dev team is getting or has already gotten a Atrix too. Hope that maybe some time in the not to distant future we can get an "official" CM7 rom, built specifically around the Atrix & its hardware.
Sent from my MB860 using XDA Premium App
Click to expand...
Click to collapse
Kholk has a engineering device and not a retail ATT model.
It is completely realistic that he could have a CM7 build that he was developing the whole time on his device but waiting for the bootloader to get unlocked to release it.
We just have to wait and see what goodies kholk desides to release.
Edit: sorry this is all way off topic and I should not have added additional comments based on off-topic items.
we will be getting a 4.1.83 source release around the 7 or 8th of july.
Watch out my thread at moto's open source forum:
http://sourceforge.net/motorola/atrix/discussion/general_comments/thread/c63fc4c9/
franciscojavierleon said:
we will be getting a 4.1.83 source release around the 7 or 8th of july.
Watch out my thread at moto's open source forum:
http://sourceforge.net/motorola/atrix/discussion/general_comments/thread/c63fc4c9/
Click to expand...
Click to collapse
That is great news. We are dying on irc without those
Sent from my MB860 using XDA Premium App
That is great news That the 4.1.83 kernel source is coming out in a week or so. Since it has not released yet, we won't be getting a 2.3.4 kernel for a bit I don't think. I am a bit new to this kind of stuff.
If you have an AOSP system.img and ram disk, do you just package the ram disk with the kernel into a boot.img and run it (and maybe pray )? I don't believe its as simple as that but that is why I ask
What channel are you guys hanging out on re: IRC? I would love to chip in on the kernel dev/community rolls as I have a lot of relevant experience.
Hello everyone.
This guide will help you in building a kernel from source for your Nexus 4
Later, when 4.2 hits AOSP, i'll add a guide for building that too
You will need a computer running Linux / OSX to build the kernel, natively, or via a VM.
This guide assumes you’re running any Linux distro.
Getting a toolchain:
You need a toolchain to build the kernel.
The preferred one is Google’s toolchain, the same they use to build AOSP.
In a terminal, type:
Code:
git clone [url]https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/[/url]
export PATH=$PATH:$(pwd)/arm-linux-androideabi-4.6/bin
export CROSS_COMPILE=arm-linux-androideabi-
TIp: paste the export statements in your ~/.bashrc to have them exported each login.
Getting the kernel source:
The kernel source for Nexus devices is available from Google’s servers.
Nexus 4 : https://android.googlesource.com/kernel/msm
Github Mirror: https://github.com/android/kernel_msm
Open the terminal, and type the below commands to get the kernel source on your computer.
Code:
mkdir -p android/kernel
cd android/kernel
For Nexus 4, we get the msm kernel sources.
Code:
git clone [url]https://android.googlesource.com/kernel/msm[/url]
Next, we change our directory to the newly fetched source.
Type
Code:
cd msm
Figuring out what to build:
Now, we need to figure out which revision to build.
You need to be exactly sure about this, otherwise there are chances that the compiled kernel won’t work.
The commit to build upon can be found by a few ways.
To get the kernel sources matching the device tree, type the below in the device tree.
Code:
git log kernel
Next, type the below in the kernel tree
Code:
git checkout <commit>
The commit of the version running of the current review units is 7a47627, which is same as branch android-msm-mako-3.4-jb-mr1-fr .
Compiling:
Name of defconfig: mako_defconfig
cd to the directory of the kernel source, then type the below in a terminal.
Code:
export ARCH=arm
export SUBARCH=arm
Code:
make <name_of_defconfig>
make
The kernel image will be ready at arch/arm/boot/zImage
To flash it, you need to make it into a boot.img, more on that later, when we have more sources.
1) what is the branch "android-msm-mako-3.4-jb-mr1-fr" for?
2) what does mr1 mean? sounds like milestone/alpha/beta. Maybe it's not final? Last commit is 2 weeks ago.
3) great guide
m11kkaa said:
1) what is the branch "android-msm-mako-3.4-jb-mr1-fr" for?
2) what does mr1 mean? sounds like milestone/alpha/beta. Maybe it's not final? Last commit is 2 weeks ago.
3) great guide
Click to expand...
Click to collapse
mr1 could stand for "Milestone Release 1", it might not be final.
That being said, you should never checkout a branch directly for compiling a kernel, but the commit directly.
cdesai said:
...You need a toolchain to build the kernel. The preferred one is Google’s toolchain, the same they use to build AOSP.
Click to expand...
Click to collapse
Could you also use linaro to compile the kernel? I believe it's a toolchain anyway, but I'm not too sure on it's benefits or compatibility...
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
randomblame said:
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
Click to expand...
Click to collapse
Are you planning on developing for the N4?
Loved your work on the DHD
espionage724 said:
Could you also use linaro to compile the kernel? I believe it's a toolchain anyway, but I'm not too sure on it's benefits or compatibility...
Click to expand...
Click to collapse
Linaro isn't a toolchain, but they do make toolchains.
Yes, you can use it to compile the kernel, though it may not compile at all with it, or not work well - your mileage may vary.
randomblame said:
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
Click to expand...
Click to collapse
Nope, LZO compression is enabled by default
cdesai said:
Linaro isn't a toolchain, but they do make toolchains.
Yes, you can use it to compile the kernel, though it may not compile at all with it, or not work well - your mileage may vary.
Click to expand...
Click to collapse
Linaro has proven to increase android performance up 30 - 100% not sure if that is with -O3 optimizations or not. That is all I use on my kernels
Sucks this phone is not coming to Sprint, might be time to change carriers...
randomblame said:
nice didn't realize kernel source was already available- can't wait to test this zImage and start testing changes noticed they left out kernel compression makes for a big zimage
Click to expand...
Click to collapse
-mvectorize-with-neon-quad ---> I use this in my makefile for cflags and drops the zImage size from 5.0mb to 4.4mb.
cdesai said:
Linaro isn't a toolchain, but they do make toolchains.
Yes, you can use it to compile the kernel, though it may not compile at all with it, or not work well - your mileage may vary.
Nope, LZO compression is enabled by default
Click to expand...
Click to collapse
ah I didn't see it - 6+mb still pretty big from what I'm used to at least
I'm going through the mind numbing process of bringing in mainline patches and squashing them all together. I'm up to 3.4.1 ... woot where's the hang me emoticon lol
*finally got smart and cloned mainline and reset the head back to each sublevel and merged into my local n4 source
got it all the way up to date with mainline 3.4.18
Thanks cdesai. I didn't think anything was out yet!!
randomblame said:
ah I didn't see it - 6+mb still pretty big from what I'm used to at least
I'm going through the mind numbing process of bringing in mainline patches and squashing them all together. I'm up to 3.4.1 ... woot where's the hang me emoticon lol
*finally got smart and cloned mainline and reset the head back to each sublevel and merged into my local n4 source
got it all the way up to date with mainline 3.4.18
Click to expand...
Click to collapse
Yea, it's big, but partitions on new devices are big as well.
y u no use git to merge
Just add korg as a remote, fetch, merge.
Each version is tagged, so you can do that incrementally too.
Also, kernel.org hosts patches as well, if you prefer that way.
snowman77 said:
Thanks cdesai. I didn't think anything was out yet!!
Click to expand...
Click to collapse
Google <3
I got it straightened out so it's up to date with mainline and I think I've got overclocking up to 1.89ghz ready lots of more fun to be had but damn I'm just teasing myself till tuesday/whenever the thing comes in the mail. hard to test anything without hardware.
I may need a tip. I have followed your guide - which I find great and simple - but I'm having a problem with the arm binaries when I launch the make command after checking out the remotes/origin/android-msm-mako-3.4-jb-mr1-fr and executed make mako_defconfig:
Code:
/bin/sh: 1: arm-linux-androideabi-ld: not found
I have cloned the toolchain and msm repos, and added to the PATH environment var the location of the bin directory. I can reach arm-linux-androideabi-ld from the command line, but no luck executing it:
Code:
[email protected]:~/android/kernel/msm$ /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
bash: /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld: No such file or directory
And it is there with execution rights:
Code:
[email protected]:~/android/kernel/msm$ ll /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
-rwxrwxr-x 1 echedey echedey 3145332 Nov 10 16:32 /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld*
My repos are in these paths:
Code:
/home/echedey/android/arm-linux-androideabi-4.6
/home/echedey/android/kernel
And my $PATH is:
Code:
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/echedey/android/arm-linux-androideabi-4.6/bi
Am I missing anything?
josjator said:
I may need a tip. I have followed your guide - which I find great and simple - but I'm having a problem with the arm binaries when I launch the make command after checking out the remotes/origin/android-msm-mako-3.4-jb-mr1-fr and executed make mako_defconfig:
Code:
/bin/sh: 1: arm-linux-androideabi-ld: not found
I have cloned the toolchain and msm repos, and added to the PATH environment var the location of the bin directory. I can reach arm-linux-androideabi-ld from the command line, but no luck executing it:
Code:
[email protected]:~/android/kernel/msm$ /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
bash: /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld: No such file or directory
And it is there with execution rights:
Code:
[email protected]:~/android/kernel/msm$ ll /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld
-rwxrwxr-x 1 echedey echedey 3145332 Nov 10 16:32 /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld*
My repos are in these paths:
Code:
/home/echedey/android/arm-linux-androideabi-4.6
/home/echedey/android/kernel
And my $PATH is:
Code:
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/echedey/android/arm-linux-androideabi-4.6/bi
Am I missing anything?
Click to expand...
Click to collapse
You path has a "n" missing from bin at the end.
You could type arm- and try to use tab-completion to see if it's accessible, then the same thing with full path (~/android/arm-linux-androideabi-4.6)
cdesai said:
You path has a "n" missing from bin at the end.
You could type arm- and try to use tab-completion to see if it's accessible, then the same thing with full path (~/android/arm-linux-androideabi-4.6)
Click to expand...
Click to collapse
Sorry, the missing 'n' came from the c&p. I can actually see the file by tabing it from any path but after the auto completing it tells this weird thing:
Code:
[email protected]:~$ arm-linux-androideabi-ld
bash: /home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld: No such file or directory
I'm a experienced *nix user but I don't get this. The repos are correctly cloned and all files under bin has exec rights. I'm running ubuntu 12.10. Maybe a problem with the shell? I should try any other environment, but that would be like killing flies with missiles. Thanks for your help.
Do you definitely have the appropriate executable at
'/home/echedey/android/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-ld'?
Can you do an ls -lF of that directory?
Perhaps the arm-linux-androideabi-ld file there is actually just a symlink which has lost its target.
@josjator Yeah, seems I have the same problem as you. I'm also using Ubuntu 12.10 with a bash shell. I think it may be a recursive make/shell issue thing (sorry, I'm not too hot on make files). Will keep plugging away to see if I can resolve the problem.
The device trees have hit AOSP
https://android.googlesource.com/device/lge/mako/
dsana123 said:
@josjator Yeah, seems I have the same problem as you. I'm also using Ubuntu 12.10 with a bash shell. I think it may be a recursive make/shell issue thing (sorry, I'm not too hot on make files). Will keep plugging away to see if I can resolve the problem.
Click to expand...
Click to collapse
@josjator: Using the 4.7 toolchain sorted me out (at least it's building now and past the initial problem).
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7
Click to expand...
Click to collapse
The objdump and ld binaries are much happier now.
BTW, I did download the 4.6 toolchain again (just in case there was some problem in the initial git clone), but I still encountered objdump and ld problems.
Works like a champ on Ubuntu 12.10 exactly as outlined in the OP. Thanks!
Code:
[email protected]:~/Documents/AOSP/kernel/msm$ ls -l arch/arm/boot/zImage
-rwxrwxr-x 1 android android 6314888 Nov 16 23:45 arch/arm/boot/zImage
[email protected]:~/Documents/AOSP/kernel/msm$ uname -a
Linux ubuntu 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[email protected]:~/Documents/AOSP/kernel/msm$ arm-linux-androideabi-gcc -v
[...]
gcc version 4.6.x-google 20120106 (prerelease) (GCC)
I tried to boot Ubuntu on tf701t a lot of times. I made something, but i have a lot of problem. I need some help.
So, to boot Ubuntu necessary a few things:
1) Kernel. http://forum.xda-developers.com/showthread.php?t=2520862 I hope it's done.
2) Ramdisk with init. That is the most problematic part. I try to compile initrd same as to tf700 (http://forum.xda-developers.com/showthread.php?t=2026919) but nothing happend.
3) Rootfs. I think the tf700t's one suit. There are not much difference between tf700 and tf701
4) Blobs. I don't know is it necessary. I think, if kernel initialize screen (via framebuffer) and processor, blobs are not needed.
I think, that's all. I'll be glad for any ideas.
Trel725 said:
I tried to boot Ubuntu on tf701t a lot of times. I made something, but i have a lot of problem. I need some help.
So, to boot Ubuntu necessary a few things:
1) Kernel. http://forum.xda-developers.com/showthread.php?t=2520862 I hope it's done.
2) Ramdisk with init. That is the most problematic part. I try to compile initrd same as to tf700 (http://forum.xda-developers.com/showthread.php?t=2026919) but nothing happend.
3) Rootfs. I think the tf700t's one suit. There are not much difference between tf700 and tf701
4) Blobs. I don't know is it necessary. I think, if kernel initialize screen (via framebuffer) and processor, blobs are not needed.
I think, that's all. I'll be glad for any ideas.
Click to expand...
Click to collapse
Someone sent me this. https://developer.nvidia.com/linux-tegra-rel-17 . Says tegra 4 I dunno..Note it says dalmore developer board though.
Is buildroot useful for this? http://buildroot.uclibc.org/
Maybe set up a blog with what you've done step by step etc and someone will fill in the details.
I could not get a buildroot rootfs to boot myself. But I have no clue.
Thanks for your effort.
Have a look here for how they did it on the TF700.
http://forum.xda-developers.com/showthread.php?t=2387133
Thanks, that information useful.
What is "kexec.blob"? Is it kernel with blobs? Are blobs necessary for tf701?
I understood. That is boot.img, kernel+initrd. Initrd from rabits's project and I couldn't build init for tf701. This is main problem.
Trel725 said:
Thanks, that information useful.
What is "kexec.blob"? Is it kernel with blobs? Are blobs necessary for tf701?
I understood. That is boot.img, kernel+initrd. Initrd from rabits's project and I couldn't build init for tf701. This is main problem.
Click to expand...
Click to collapse
I see there in the Dalmore driver package from the first link i showed you there are various .dtb files(including one for macallan). device tree blobs no?
YayYouFixedIt said:
I see there in the Dalmore driver package from the first link i showed you there are various .dtb files(including one for macallan). device tree blobs no?
Click to expand...
Click to collapse
Yep. But that is compiled dtbs and I couldn't use it. Also there are dtbs (including for tf701) in kernel source (I posted link in first msg).
Today I got it! I had ran simple linux on this tablet. I use the fbcon as console output, and dock as keyboard. Keyboard works perfectly. Linux works not bad too. I was testing simple linux features like font changing, seeing images through fbi program, flashing arduino by avrdude, etc. Everything works. Also backlight is controllable. But unfortunately I couldn't run X nevertheless framebuffer output is working. I need help because I don't know how works the Android graphics output and how I can use it in pure linux.
https://source.android.com/devices/graphics/architecture.html
http://keyj.emphy.de/files/linuxgraphics_en.pdf
http://free-electrons.com/doc/training/android/android-slides.pdf
Some links that might offer some ideas to someone idk.
General informations:
This thread's aim is only to represent a central meeting and discussion point for BCM21553 developers and, in particular, for the open Kernel/ROM sources development for the Samsung Galaxy Pocket GT-S5300 (codenamed Cori).
Information for common users:
As already described in the previous section, if you are not a developer, please restrict your posts to the general discussion thread so that developers can maintain good communication. Every post that is not strictly respecting these rules will be reported to the forum moderators. Thanks for your understanding.
For any other BCM21553 device related question or information, please, use this thread as a reference point, instead:
[DEVS ONLY][BCM21553 series] CyanogenMod 11 for BCM21553 Development Discussion
As someone already might know, I'm streambinder, from MoltenMotherBoard team.
I have already followed some projects for the GT-S5300, but especially kept in contact
with some of the events related to the porting of ROM and Kernel sources for BCM21553 chipset based devices.
In this precise moment, the sources in my possession allow you to be able to compile
a bugfree CWM 5.0.2.8 (based on CyanogenMod 7 code) with a kernel based on the Samsung stock one.
The only - fundamental - problem was due to the fact that unless I hadn't used the prebuilt INIT binary
token in the Samsung stock firmware boot.img, the phone would not work - or, better, boot up.
This means that until the situation - regarding this issue - doesn't change, our access to the porting of custom ROM
would be barred.
Recently, I decided to give Cori another chance and rework my sources, looking at the wonderful work brought
by the BroadcomCM team on CyanogenMod 9 (in particular, thanks to @bieltv.3 and @Alberto96) and @psyke83 on CyanogenMod 11.
They've not only been able to run these two ROMs in a more or less crude way, but this developer has been able to write
the necessary strings to make the INIT binary of some of these BCM21553 devices opensource.
Strong of this informations, I readjusted some of the sources of BroadcomCM's CyangenMod 9, which includes
all the progress carried out by both the team and psyke83, in order to make them work even on Cori,
and am now next to the first test of the CWM 6.X.X.X, based on IceCreamSandwich code.
At the same time, @akhbh is working on the KitKat code based CWM.
I hope I can give more information about any progress as soon as possible.
The General Discussion thread for non-development issues is here:
*.[DISCUSSION] CyanogenMod 11 For Galaxy Pocket GT-S5300 Discussion Thread
Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?
streambinder said:
Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?
Click to expand...
Click to collapse
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.
akhbh said:
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.
Click to expand...
Click to collapse
Perfect.
Which kernel have you based your build on?
streambinder said:
Perfect.
Which kernel have you based your build on?
Click to expand...
Click to collapse
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources
akhbh said:
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources
Click to expand...
Click to collapse
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.
streambinder said:
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.
Click to expand...
Click to collapse
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September
akhbh said:
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September
Click to expand...
Click to collapse
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.
streambinder said:
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori | github.com
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.
Click to expand...
Click to collapse
have u tried to build cwm v6 from cm9 source ??
cleverior.ipul said:
have u tried to build cwm v6 from cm9 source ??
Click to expand...
Click to collapse
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that
akhbh said:
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that
Click to expand...
Click to collapse
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?
streambinder said:
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?
Click to expand...
Click to collapse
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources coz as said earlier, his kernel is used. Well, we were working together to bring cm11 but weren't successful
akhbh said:
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources.
Click to expand...
Click to collapse
Ok, please send it to me, will compare it with my package.
streambinder said:
Ok, please send it to me, will compare it with my package.
Click to expand...
Click to collapse
Here it is:
http://www.4shared.com/zip/1nKFbOJ2ba/ccccGetux_CM11.html
streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
here the link source https://github.com/cleverior/android_kernel_samsung_cori
i've changed the board name. If your device can not boot after using the zImage from this source, then rename init.bcm21553.rc to init.gt-s5300.rc.
@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed
akhbh said:
@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed
Click to expand...
Click to collapse
Sincerely don't what are you talking about.
Anyway, have to try to understand where's the problem with the not-booting CWM.
Will try with your sources and let you know.
In this post, I would like to explain what kexec-hardboot patch is.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Unlike grouper's kexec-hardboot patch, this one only requires the host kernel to be patched. This is one of the improvements Tasssadar made, and I think it is pretty significant.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Kernel patch: https://gist.github.com/PatrikKT/50faf32e8931d51c0c9a,
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_PROC_DEVICETREE=y
CONFIG_ATAGS_PROC=n # This one is turned on automatically, but it is not needed, so you can disable it.
All these options must be enabled.
Userspace kexec binary: https://github.com/Tasssadar/kexec-tools
I had to change some things in kexec userspace binary because of some kernel bugs, complete description is in that repository. You can get statically built binary at https://github.com/Tasssadar/multirom/blob/master/install_zip/prebuilt-installer/multirom/kexec
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --dtb
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - he used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped him out with that, thanks.
For hammerhead, he has improved the patch a bit - only the host needs to be patched now and he has added support for DTB.
This thread was used as a template Credits to @Tasssadar for his Nexus 5 patch
Awesome people helping with our G2's development. Thank YOU!
patrik.KT said:
I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition.
Click to expand...
Click to collapse
What benefit would there be to non-MultiROM users? (Just curious.)
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Any. Just any.
Actually I can't think of anything. It's only to bring the device to a full reboot to load a new kernel.
Odoslané z môjho HTC Desire 601
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Not for common user, in epic4g kexec used by kernel devs to test a new kernel build without replace the existing kernel.
They just load a temporary kernel to test. Then that kernel will gone after a reboot.
Hope to see new kernels that support MultiRom! Great work man!
Would this allow a multiboot with AOSP and Stock roms?
AbdulrahmanAmir said:
it doesnt work while i have stock and the secondary is aosp (dU-dirty.unicorn) when i boot the secondary it works sound only but no display just black screen plzz help
Click to expand...
Click to collapse
The patch is not necessary at the moment, because of the locked bootloader. It's just for devs to be prepared with their kernel when we can unlock the bootloader, so that multirom will work as it should.
Odoslané z môjho HTC Desire 601
Thanks for your great thread. But there is no instruction about how we can add that patch to kernel source. Could you write more details about implanting this patch?
No response??
mohamaadhosein said:
No response??
Click to expand...
Click to collapse
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Hey, some changes need to be made to the patch.
On line 353, change the number from 22 to 21. Also, it has some errors when modifying head.S, which I had to fix manually..
But guys, my kernel is building with the latest multirom. This **** is going to maybe work soon!
I'll keep you all posted.
Thank you man
Guys, I think I've done it. Kexec hardboot patched kernel for 5.1.1 and thus multirom compliant, which I am preparing to build with twrp. this is very exciting.
When will it be ready?
Are you kidding me? No ETAs. I literally haven't even announce it yet and somebody asks for an ETA.... It will be ready once I test everything to boot well on my device.
patrik.KT said:
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Click to expand...
Click to collapse
It says the patch is corrupted on the line 375