[REF] Source code: Unified git repo for GT-I9000 Gingerbread kernel source - Galaxy S I9000 Android Development

Here we go
Common gingerbread-samsung git branch for all of us
This branch contains the fixed Gingerbread source (compiling and working) everyone of us may use as reference git repository.
Fixed in this source:
- all cleaned up gitignores
- missing FSR in Makefile
Take also a look at the updated README.txt that will explain you how to compile and get it working with modules
Also: makes sure you disable, in .config:
[*] Automatically append version information to the version string in menuconfig or CONFIG_LOCALVERSION_AUTO in .config
It will help each developer to exchange patches easily because of the common starting point.
bilboa1 said:
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
I certainly support this idea.
Click to expand...
Click to collapse
How you can fork this repository:
- clone it via github directly
or, if you prefer keeping only this gingerbread branch directly, on your dev computer:
Code:
git clone git://github.com/project-voodoo/linux_gt-i9000.git -b gingerbread-samsung
cd linux_gt-i9000
git remote rm origin
git remote add origin git://your-new-remote-repository.git
git remote add common git://github.com/project-voodoo/linux_gt-i9000.git
This way, for people re-using Vodooo sound for example, it will be as easy as:
Code:
git fetch common
git merge gingerbread-voodoo-sound
If you have more idea of collaboration like that, express yourself
FAQ:
Q: Bleh! I hate this Kernel/ directory.
A: Yes, this was the case for the original commits but now it's a standard Linux repository with everything on its root.
But it didn't worked as expected, so I had to make the change, sorry for the inconvenience to the early adopters.
Q: What happens when Samsung update their source code tarballs
A: I'll update the common git repository accordingly (hopefully fast enough for you)
On your side, all you'll need to do will is.
Code:
git fetch common
− or git fetch git://github.com/project-voodoo/linux_gt-i9000.git
git merge gingerbread-samsung
Say good bye to messy tarballs!
PS: if you're looking to initramfs, take a shot at https://github.com/project-voodoo/samsung_initramfs − contribution welcome.

Good idea, I second that, it will be easier

wrong link
Github reads http://project-voodo.org/

What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
Forking in git hub is VERY VERY easy btw.
I certainly support this idea.

Awesome! - I also support this idea

United Galaxy S Developers
Nice idea! Perfect spirit of open source

I hope good things come out og this.

Great move Supercurio - once again !

Simply awesome men

Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?

pikachu01 said:
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
Click to expand...
Click to collapse
The gingerbread-samsung branch promoted here will only contain Samsung kernel sources and won't interfere with other developers modifications.
Only exception is if this source is broken and needs something to work, like nikademus's patch: https://github.com/project-voodoo/linux_gt-i9000/commit/6c8f989f58999770d23236bb172c3a4e1c80586b

It seems that JVK and JVB was pulled from Kies because of an update problem. Looks like we're going to have new ROMs to play with in a week or two (maybe less)
Edit: What about the SSL fix (http://forum.xda-developers.com/showthread.php?t=1040005)

Great, good idea. That's how community development should work!

zorxd said:
Great, good idea. That's how community development should work!
Click to expand...
Click to collapse
Agreed! Thanks for getting things started Supercurio! Now I have to start making a Vibrant branch.

Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...

ttabbal said:
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
Click to expand...
Click to collapse
The code has many similarities with Nexus S one (build from it IMO) and is preempt too

Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?

supercurio said:
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Click to expand...
Click to collapse
Excellent! I just did a defconfig to check it out and saw the preempt in there.. Nice to see Samsung fixing things up a little. Now I need to get a GB ROM to install so I can try to boot.
Thanks again. I'll send a pull request when I have a Vibrant branch ready. Going for minimal modifications, fix touch button mapping and such. People can add whatever they want after that. Now I need to learn the new code tree... wheee! Hopefully the basics are the same, getting the changes into an i9k froyo kernel is pretty easy.

zorxd said:
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
Click to expand...
Click to collapse
You will need an initramfs... anyone have a default one we can start with for 2.3?
zImage will have to be in a TAR file to flash with Odin. Heimdall can flash a bare zImage, as can the SGS Kernel Flasher tool for Android.
Oh... think I saw a setting in "make menuconfig" for the cross-compiler prefix. Might be able to avoid Makefile mods....

Sorry for the newb question, but how do we generate the initramfs? I guess we could take the one from stock JVB. But how do we extract it and how do we combine our compiled kernel with it?
On a side note, I noticed that CFQ is the default scheduler. Isn't it better to use No-op for flash memory?

Related

Extracting kernel config from I9000XXJP3

Dear all,
Did anyone succeed extracting kernel configuration from I9000XXJP3? Kernel version is 2.6.32.9, the vermagic is "2.6.32.9 mod_unload ARMv7"
extract-ikconfig doesn't work on it.
I succeeded extracting a zImage gzipped payload, but it seems not to contain any configuration in it (see attached).
/proc/config.gz doesn't exist, Samsung open source package (downloaded from Samsung open source site) contains only Android 2.1 Eclair or previous versions.
My target is to build tun.ko and, eventually, ext3/ext4 modules to make them working in Samsung Galaxy S I9000 with rooted I9000XXJP3.
Any idea?
Without froyo source code or a good Samsung Kernel (es. for himem capable) I think is impossible to play good with theses beta roms.
Ciao
Any news? I need tun.ko for jp3 too..
I have tried to compile the 2.6.32.9 kernel editing the .config in 2.6.9, the module tun.ko is accepted by the device, but I get a kernel panic!
redsh said:
I have tried to compile the 2.6.32.9 kernel editing the .config in 2.6.9, the module tun.ko is accepted by the device, but I get a kernel panic!
Click to expand...
Click to collapse
Did you use the stock linux kernel? Or the common from android.kernel.org?
I'm trying the same thing actually. Isn't there any default config for the processor that might work? I tried with the config from .29 but when loading the module it says wrong format.
try to build 2.6.32 with the 2.6.29 config ("yes" all missing stuff)
turn on your galaxy, adb push the tun.ko
try to load it, it will say "missing symbols" blabla
find the config options that match those symbols, enable them, recompile, try again
Great to see some people who are hacking the kernel! Keep it up!
But I'm afraid it is not going to be as easy as dropping aries_rev03_defconfig as .config in a 2.6.32 kernel tree and doing 'make oldconfig'. That's because many of Samsung's changes have not been included in the newer mainline kernel versions yet.
Samsung added quite a lot of low-level board support for their dev boards (and for the SGS, of course), did some customization and added a few drivers which you will need to forward-port to the newer kernel.
Please have a look at this thread, in which I've started a breakdown of the Samsung patches against Android Eclair's 2.6.29 kernel.
The best course of action I think is to git clone Android's kernel from AOSP, checkout the android-2.6.29 branch, apply Samsung's patches to that, then attempt to rebase your tree to a newer kernel version. (Note, you may want to start with small steps, to get a feel for what you're up against )
Note that there probably will be lots of merge conflicts which you need to resolve, and after dealing with all those, you also have to make sure that everything else that's merged still works as expected, but at least that will show you the amount of work involved. You will basically be doing all the work that Samsung is doing right now for their kernel for FroYo. It will be interesting to follow their progress on the mailing lists and on IRC.
bilboa1 said:
try to build 2.6.32 with the 2.6.29 config ("yes" all missing stuff)
turn on your galaxy, adb push the tun.ko
try to load it, it will say "missing symbols" blabla
find the config options that match those symbols, enable them, recompile, try again
Click to expand...
Click to collapse
Thats exactly what I did, but I got wrong module format... which is a fatal error. I need to invest further in the used config... maybe i did not pick up the right one properly..
miki4242 said:
Great to see some people who are hacking the kernel! Keep it up!
But I'm afraid it is not going to be as easy as dropping aries_rev03_defconfig as .config in a 2.6.32 kernel tree and doing 'make oldconfig'. That's because many of Samsung's changes have not been included in the newer mainline kernel versions yet.
Samsung added quite a lot of low-level board support for their dev boards (and for the SGS, of course), did some customization and added a few drivers which you will need to forward-port to the newer kernel.
Please have a look at this thread, in which I've started a breakdown of the Samsung patches against Android Eclair's 2.6.29 kernel.
The best course of action I think is to git clone Android's kernel from AOSP, checkout the android-2.6.29 branch, apply Samsung's patches to that, then attempt to rebase your tree to a newer kernel version. (Note, you may want to start with small steps, to get a feel for what you're up against )
Note that there probably will be lots of merge conflicts which you need to resolve, and after dealing with all those, you also have to make sure that everything else that's merged still works as expected, but at least that will show you the amount of work involved. You will basically be doing all the work that Samsung is doing right now for their kernel for FroYo. It will be interesting to follow their progress on the mailing lists and on IRC.
Click to expand...
Click to collapse
Yes that would be a lot of work. Maybe its better to just wait until they release the kernel from froyo. I read that they release their opensource stuff rather fast. But just for adding a module like ext4 I don't think you need those patches, because imho they didn't touch the fs of the kernel. We just need an adaquate kernel config and adding modules should be possible.
Phlogiston said:
Thats exactly what I did, but I got wrong module format... which is a fatal error. I need to invest further in the used config... maybe i did not pick up the right one properly..
Click to expand...
Click to collapse
Make sure you're using the same kernel version number and build number, because samsung kernels do not have the option to load incorrect module versions
Yes i've set the subversion as well but without the patches from samsung its impossible it seems. We need to wait and hope that they release the froyo kernel sources soon....
bilboa1 said:
Make sure you're using the same kernel version number and build number, because samsung kernels do not have the option to load incorrect module versions
Click to expand...
Click to collapse
Are you sure they set CONFIG_MODVERSIONS? It's off in the downloadable sources.
Just compare the output of `modinfo -F vermagic <yourmodule>` to `modinfo -F vermagic <modulewhichloads>` or to /proc/version .
did this get solved yet? I google'd for the tun.ko file for my i9000 using jp3 but nothing yet... if you have a proper one for the MoDaCo version here please attach it! ~
I think I saw someone's post with tun.ko for FroYo beta somewhere in these forums, I mean i9000 Android Dev. One of the guys here has found a way to compile kernel for jp* here. I am sure.
I actually found it attached somewhere in the forum and it was 1,5447 mb big I think it was... but it still didn't work for me so I presumed the kernel or something must have been wrong.

[KERNEL][HOWTO] E4GT Community Kernel - Updated: 2/26/2012

See second post for changes.
My phone has a nicely corrupted bit of memory right where my data partition is supposed to be so I can't really test any changes on kernels at the moment. Once my replacement gets here, I have quite a few changes to test and then push. Hopefully others are haveing some good luck with there own kernels.
This first post is going to look a little rough until I take the time to pretty it up, but I figured I would get at least this up and let it evolve from there. I know I gloss over some stuff(what the hell is a defconfig, you ask?) but I will flesh this out over the next few days (Years, really. Damn contracts)
Project Goals:
Provide a standard base and scripts for building kernels for the E4GT.
Attempt to provide reasonable documentation of the build/debug/pray-for-success process so that those that wish to learn, can.
What is included in the current base:
Completely Stock EL29 Kernel
initramfs for Samsung based ROMs with ClockworkMod and root
Codesourcery 2009q3-68 toolchain
Base for creating a ClockworkMod flashable kernel
Build script to tie it all together
Getting started:
Install Ubuntu or Linux distro of your choice. This guide is written for Ubuntu as that seems to be the most common choice for Android Development.
Install required packages
Install Oracle Java JDK, setup the Android SDK, and install other required packages from terminal.
For 32-bit installs:
Code:
sudo apt-get install git-core gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev
and 64-bit:
Code:
sudo apt-get install git-core gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib
Download base
In terminal emulator, go to the directory you'd like to download to and type:
Code:
git clone git://github.com/SweetwaterBurns/xda-base.git
Pick a branch. Currently available are powersave, performance and master(all identical until things start moving forward a bit, I intend to keep master updated with the latest stock kernal) and select it with
Code:
git checkout powersaveorwhateverbranchnameyouactuallywantipromisetonotactuallymakeabranchthatisquitethisridiculousmaybe
Profit!
In a terminal emulator, change to the xda-base directory and type
Code:
./build.sh
and wait... congratulations you've just compiled your own kernel.
But wait there's more The build script will let you build with more then just the included source and toolchains. The basic format is ./build.sh kernel initramfs defconfig toolchain. All you have to do is copy the files into the appropriate directories and you're good to go.
So, if for example you wanted to build an EK02 kernel using Team Rogue's initramfs, the Linaro 11.12 toolchain and your perfect_defconfig, you would copy the source to xda-base/kernels/EK02, place the initramfs in xda-base/initramfs/rogue, and the toolchain to xda-base/toolchain/linaro. Place perfect_defconfig into EK02/arch/arm/configs/ and type the following command from the xda-base directory:
Code:
./build.sh EK02 rogue perfect linaro
The flashable zip is saved in xda-base using the defconfig, date and time in order to keep your files somewhat organized. I'm going to add kernel version to that in my next update, as well.
The base is essentially a snapshot of where we are at this stage of development and hopefully the community can help us improve it. Everything seems to be working, but if you come across any bugs/fixes, please share.
If you'd like you propose any changes, submit a request via git and I'll add them to the repo if it makes sense.
I'm typing a lot of this up from memory so please forgive any mistakes or omissions. If you find any let me know and I will update ASAP. If it seems confusing, let me know where clarification is needed. My goal is to figure this stuff out and help others while doing it. Any criticism will be taken constructively and I hope this helps spawn few more talented devs for the E4GT.
Known Issues:
Don't choose reboot to recovery after flashing Blazer 3.9(possibly others) I was able to reproduce this on Team Rogue's el29 repack as well.
I didn't realize that git doesn't push empty directories which caused issues with modules not being copied in to the initramfs. I'm going to fix by adding a check to create the files if necessary into the build script. in the meantime, just create initramfs/initramfsroot/lib/modules and remember to make sure that the directories are in any alternate recoveries you use.
Changelog:
2/26/2012
Added a quick howto on working with git and submitting pull requests to post #4. As soon as new phone gets here, I'll be uploading some new changes to performance.
2/13/2012
All right.
There are now branches for powersave, performance, and stock. Once you have cloned the repo you can select which one to use by typing
Code:
git checkout powersave
or whatever. The only difference between the repos at the moment is that I renamed the kernel source directory to match the branch name and edited the build.sh to build the respective variants by default. If anyone has any requests for other branches, let me know.
I also added a check to the build.sh to ensure that there is a lib/module directory in the initramfs that modules can be copied into.
Proposals:
I'm thinking about setting up a few different branches for the kernels. One for the latest clean stock kernel, one for those who would like to focus on performance, one for those that are more worried about battery, and possibly a bleeding edge kitchen sink kernel. More than I can handle myself, honestly, but if those of you that are already making modifications start pushing it should be doable.
Done
How to use git and submit pull requests on github.
If you haven't already, create an account on github Navigate to the xda-base repo and click fork in the upper right.
In a terminal emulator, go to the directory you would like to store your source in and clone your new fork with
Code:
git clone [email protected]:USERNAME/xda-base.git
git remote add upstream git://github.com/SweetwaterBurns/xda-base.git
The second part adds the original repository as an upstream source so that you can keep your code base updated with any changes.
Probably one of the most useful tools available is branches, essentially if you would like to add or change a feature, you would create a branch for working on it. Having it contained with in it's own branch is good for several reasons. It makes it easier to find any changes that you made without pulling in any extra cruft from other things you might be working on and helps prevent any conflicts that might arrise from working on too many things at once with in the same source tree.
Branches can be created locally with
git branch BRANCHNAME
For example, if you wanted to branch the performance kernel you would
Code:
git checkout performance
git branch performance-FEATURE
git checkout performance-FEATURE
This creates a local branch that you can work with, if you would like to push it to github for others to work on or to use it to submit a pull request:
Code:
git push origin BRANCHNAME
Branches can be deleted locally and remotely with
Code:
git branch -d BRANCHNAME
git push origin :BRANCHNAME
Make any changes you'd like and tell git which files you've changed with
Code:
git add CHANGED FILES HERE
Then commit those changes with
Code:
git commit -m 'Description of changes here'
If you would like to submit a pull request upstream, first fetch upstream and merge it with your work to make sure that any changes that have already been pulled don't conflict with your changes and that it can be merged cleanly. Use whatever branch you used as your base for the merge, i.e. for changes you'd like to submit to the performance branch
Code:
git fetch upstream
git merge upstream/performance
This will spit out any conflicts that need fixed and you can repeat the process until it merges clean.
Push your branch to github and navigate to it's page. Github has a pretty good write-up on sending pull requests and the process is really pretty simple.
Any questions, ask away.Any errors, let me know.
To Do:
Show how to add a remote repository and use it to port features using 'git cherry-pick' or whatever.
and one more for whatever else we might need.
Good job! Looking forward to see what comes from this. Good to see a forum to learn from.
Sent from the future
thatdudepoops said:
Good job! Looking forward to see what comes from this. Good to see a forum to learn from.
Sent from the future
Click to expand...
Click to collapse
Couldn't agree more! Thanks. I am eager to step things up myself. I am glad that this thread was started. Thanks OP.
Sent from my SPH-D710 using xda premium
This looks very interesting. Definitely will be watching this thread. Thanks.
Sent via EM waves.
nice work sir! Can't wait to see where this goes from here.
Sent from my SPH-D710 using Tapatalk
Well, I guess my first request is how to add boot animation support to a kernel? Is it as simple as adding the lines to the init.rc?
dtm_stretch said:
Well, I guess my first request is how to add boot animation support to a kernel? Is it as simple as adding the lines to the init.rc?
Click to expand...
Click to collapse
I think the init.rc file I uploaded has it in it.
Give it a try.
agat63 said:
I think the init.rc file I uploaded has it in it.
Give it a try.
Click to expand...
Click to collapse
Oh yeah, duh! I got it, I just didn't name the bootanimation.zip to sanim.zip
dtm_stretch said:
Oh yeah, duh! I got it, I just didn't name the bootanimation.zip to sanim.zip
Click to expand...
Click to collapse
I can either add a line to the init.rc to soft link bootanimation.zip to sanim.zip or put it in the CWM update script. I'm leaning towards the update script as it really should only need to be done once.
Also, be prepared for issues flashing Blazer 3.9 the flash didn't quite take when I tried it this morning.
SweetwaterBurns said:
links to outside resources or maybe a picture of a unicorn that my daughter drew
Click to expand...
Click to collapse
I can't wait.... to see that unicorn
njudell said:
SO, there's a great thread in the developer's section: [KERNEL][HOWTO] E4GT Community Kernel - 2/12/2012
Really nice job. I've built & flashed the kernel. BUT, the WIFI won't turn on, and 3G data won't flow, even though it shows 3G connectivity (Sprint Epic 4G Touch, rooted to L29 with CWM earlier...). Anybody have a clue what I may have messed up? Just ran the straight defaults, figuring that would get me into the least amount of trouble. One diagnostic: there was a number of segment mismatch warnings - I've had those in embedded kernels in the past, and they're usually not meaningful. Maybe this time is different?
Click to expand...
Click to collapse
Sent from my SPH-D710 using xda premium
This guy could not post in Dev
Sent from my SPH-D710 using xda premium
He can PM me and we can try to go over his settings to see what's wrong.
his reply
"Okay, found the problem, and I feel very slightly less stupid. Watching the build go by, I noticed diagnostics that the script was unable to copy the driver modules to the temporary initramfs lib/modules directory. In reading the script, I saw that the build.sh was wiping the temporary initramfs lib directory. SO I added a couple of lines to the build.sh script (the middle two lines are mine):
#Find all compiled modules and copy them for the final build
mkdir $INITRAMFS_TMP/lib
mkdir $INITRAMFS_TMP/lib/modules
find -name '*.ko' -exec cp -av {} $INITRAMFS_TMP/lib/modules/ \;
Which allows the script to copy the loadable modules, and POOF! Now I've got WIFI and such...
The script in the git repository should either get modified, or some additional tests on running the script implemented. One of my thoughts was that having dash as the shell script might be causing problems (I've had that before) - but that wasn't the problem.
-neil
A) Yes, this should be posted in the thread, but I can't because I'm a newbie
B) Therefore, this should heavily count as one of my 10 required posts to get there."
"he doesnt have 10 post so i posted here for him " his thread is in q & a if you want to reply to him
Just built a custom PC, might check this out and see how little I know about the linux world. But you gots to start somewhere right?
xlGmanlx said:
Just built a custom PC, might check this out and see how little I know about the linux world. But you gots to start somewhere right?
Click to expand...
Click to collapse
Its all about the desire to learn. Some start with theming. Then there are those that make ROMs but don't necessarily know how to make a kernel. There's a lot to learn. Its all about having the will and time to do it. The more development the better imo
Sent from my SPH-D710 using xda premium
xlGmanlx said:
Just built a custom PC, might check this out and see how little I know about the linux world. But you gots to start somewhere right?
Click to expand...
Click to collapse
Yup, just compiled my first fully working kernel yesterday.
Already overclocked it to 1.6 with extra added cpu steps for lower clock speeds...
Just tried adding and defaulting bfq scheduler but the jf4s module wouldn't compile after wards for some reason..
Ill figure it out eventually.. Right now im adding smartass / v2 see if it works...
EDIT: That didn't work either hmmmmm... Anyone know why when you edit the c1_rev5 config file the j4fs module doesn't compile?

[KERNEL][SOURCE][android_kernel_lge_msm7x27-3.0.x (3.0.8)]

I waited to post this over here until it was debugged and all the hardware works.
Even though this forum's been kinda dead quiet for a while, xda gets searched and I want this source code out there.
Derived from androidarmv6 project and tweaked over to thunderc from the p500 developers' awesome work getting it running on the Optimus One.
source:
https://github.com/bigsupersquid/and...7x27-3.0.x.git
(branch squid, for lack of imagination.)
make thunderc-test_defconfig
you'll want to change or remove the toolchain path in the config. it is highly unlikely that your cross toolchain is in the same path as mine.
I set it in the config to avoid having to add "CROSS_COMPILE=/blah/blah/etc" to the make command every time I rebuild the kernel.
it is for jellybean and kitkat roms.
use on older android versions messes up various things. Especially USB.
it conflicts with /sbin/chargerlogo or /sbin/charger for offline charging and bootloops unless that file is removed.
Use the attached removecharger.zip in recovery with signature verification off for that if you don't want to edit the ramdisk yourself.
md5sum b1a9f21285e09e06dc94422a8578dc98
enjoy
@bigsupersquid Know if anyone's willing to have a stab at building Firefox OS, now with the 3.x kernel?
EDIT: Well apparently there's no full ArmV6 support in it so, I guess not...

[PATCH] Kexec-hardboot patch

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 me 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.
Standard kexec call unfortunatelly does not work on Nexus 4. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a commong thing among Android devices, which is why kexec-hardboot was made.
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 I 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/Tasssadar/7833796, 4.4 AOSP kernel repo
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 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.
For hammerhead, I've improved the patch a bit - only the host needs to be patched now and I've added support for DTB.
Merged, thanks again for the awesome work @Tasssadar!
Good deal.My day is getting better.
@show-p1984 would love to see this in bricked kernel too! ?
@neobuddy89 did you see this?
Sent from Nexus 5 on Slimkat
thanks for the hard work.. thats awesome.
AndroidSlave said:
@neobuddy89 did you see this?
Sent from Nexus 5 on Slimkat
Click to expand...
Click to collapse
Yeah, I saw this.
neobuddy89 said:
Yeah, I saw this.
Click to expand...
Click to collapse
I asked that 6 months ago
Sent from my Nexus 5 using Tapatalk
awesome work bro...
much needed..
AndroidSlave said:
I asked that 6 months ago
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Yeah, I know and I saw that days back..
Enough of OT. :fingers-crossed:
Help with applying the patch
Okay so I have my aosp kernel made. I have my working directory too. Can you just guide me on how do I apply this partch to it?
Is it possible to add that patch from a on the fly flashable zip ?
@Anoopnk since the patch is for the kernel(zImage) its not possible to patch it like that. Or you have to compile the kernel or you need to ask your kernel dev friendly or he can include it in his kernel.
Hello, first I'd like to apologize for dredging up an old thread. Second, I am attempting to build a CM13+kali+kexec compatible kernel, with extra wifi drivers as the base kernel doesnt support my wifi card. Based on that goal, I have a multi-part question for the OP, or anyone else with the know-how to assist me in my quest.
1)Is there a source available for your kernel_kexec_hammerhead_cm13-01-2c39db662.zip listed on the multirom page for nexus 5? I'm attempting to build a new kernel, for kali+CM13+multirom, and your android_kernel_google_msm git only has branches going up to CM12. It would be far easier for me to start with a 'clean' CM13+kexec source then trying to patch myself as per question #2
2) I've attempted to patch a plain old hammerhead_defconfig from CM13 git, however I believe I am doing so wrong. I have managed to compile kexec-tools and aquired the hammerhead 3.4.x patch. Now am I supposed to patch my produced zImage-dtb AFTER build, running the patch from the kexec-tools folder and against the zImage-dtb? Is it something like 'KEXEC.patch -p1 < zimage-dtb'
Any clarification on the use of the kexec-tools patch, or simply a link to github source of a 'clean' CM13 kernel with the kexec patch already applied, would be incredibly helpfull on my journey down the rabbit hole
~EDIT~
Ok so I've managed to figure out the patch and feel like a dumbass. For anyone else looking to get into kernel dev, and wanting to use the kexec patch, heres the basics:
1- run patch within your kernel source directory
2-ensure that the config settings in OP are set (I had to add them to my source by hand as they werent there)
3-when zipping up your kernel, add the sbin and lib/kexec-tools folders from the kexec-tools source build, and be sure your updater-script / updater-binary is set to move these folders into /sbin and /lib respectively.
4-Flash and enjoy Kexec! (check with multirom manager)

[DEVONLY] LineageOS 15

Hi,
this is the development thread for LineageOS development. The first release is out and this thread is for developer collaboration!
Everyone who knows C, Java and strace is welcome to participate. Please send git formatted patches!
HELP NEEDED
mixer_paths_tasha.xml and audio_platform_info.xml need tweaking
VoIP needs testing
WifiDisplay support
VoLTE (I can't test this)
Device Trees
https://github.com/cryptomilk/android_kernel_sony_msm8998
https://github.com/cryptomilk/android_device_sony_common-treble
https://github.com/cryptomilk/android_device_sony_yoshino
https://github.com/cryptomilk/android_device_sony_lilac
What about the bootloader?
blackknightavalon said:
What about the bootloader?
Click to expand...
Click to collapse
Just unlock it and have fun. Hopefully someone will be able to figure out a way to backup the DRM keys.
android_fury said:
Just unlock it and have fun. Hopefully someone will be able to figure out a way to backup the DRM keys.
Click to expand...
Click to collapse
And where, exactly, is the tutorial for that? It's not officially supported by Sony yet.
I think I read somewhere that you can select the XZ Premium on the list and follow the steps. Once a DRM backup is available, I may try doing that. By then, the actual XZ1C may already be on the list.
android_fury said:
I think I read somewhere that you can select the XZ Premium on the list and follow the steps. Once a DRM backup is available, I may try doing that. By then, the actual XZ1C may already be on the list.
Click to expand...
Click to collapse
I just checked a few minutes ago. XZ1C's not on there.
Good news !
I've setup initial repositories, yoshino and lilac. yoshino is a common base shared between devices and I have a Kernel tree over the latest msm-4.0 kernel tree and already compiled it after fixing a log of build issues. I will create repositories in the next days and upload the sources once I have a recovery.
modpunk said:
I've setup initial repositories, yoshino and lilac. yoshino is a common base shared between devices and I have a Kernel tree over the latest msm-4.0 kernel tree and already compiled it after fixing a log of build issues. I will create repositories in the next days and upload the sources once I have a recovery.
Click to expand...
Click to collapse
Great news! Thank you so much for your efforts to bring us LOS for this really awesome compact beast.
Thank you so far, modpunk! Looking forward to it. The phone is great, but stock rom leaves some things to be desired...
Thanks bro, just do it!
Regarding unlocking: I selected X Compact and followed the instructions. Everything worked perfectly and I'm now running AOSP.
Code:
----- Made recovery image: recovery.img --------
#### make completed successfully (11:06 (mm:ss)) ####
modpunk said:
I've setup initial repositories, yoshino and lilac. yoshino is a common base shared between devices and I have a Kernel tree over the latest msm-4.0 kernel tree and already compiled it after fixing a log of build issues. I will create repositories in the next days and upload the sources once I have a recovery.
Click to expand...
Click to collapse
How much are you borrowing from Sony's AOSP repositories? They've been committing pretty heavily to their kernel in particular.
Gairtial said:
How much are you borrowing from Sony's AOSP repositories? They've been committing pretty heavily to their kernel in particular.
Click to expand...
Click to collapse
There was no Kernel release for msm8998 in kernel-copyleft, so I took the msm-4.4 Kernel tree and the tarball they dropped. I've fixed several bugs in the Kernel, I always wonder how the Smartphone manufacturers get their stuff compiled.
You can find the kernel source tree here: https://github.com/cryptomilk/android_kernel_sony_msm8998
I've also added exfat support already.
I've looked at the device repo for their AOSP trees, but started a yoshino and lilac device tree from scratch. I prefer clean repositories. I will push them in the next days, I did quite some cleanup today.
I haven't ordered the device yet. Need to wait till next week, I just came back from a long vacation
modpunk said:
There was no Kernel release for msm8998 in kernel-copyleft, so I took the msm-4.4 Kernel tree and the tarball they dropped. I've fixed several bugs in the Kernel, I always wonder how the Smartphone manufacturers get their stuff compiled.
You can find the kernel source tree here: https://github.com/cryptomilk/android_kernel_sony_msm8998
I've also added exfat support already.
I've looked at the device repo for their AOSP trees, but started a yoshino and lilac device tree from scratch. I prefer clean repositories. I will push them in the next days, I did quite some cleanup today.
I haven't ordered the device yet. Need to wait till next week, I just came back from a long vacation
Click to expand...
Click to collapse
Why the copyleft archive? It doesn't look like they've touched it since April while they touched the regular one 2 hours ago.
I had no issues compiling and running the kernel from https://github.com/sonyxperiadev/kernel, though that was integrated with their entire AOSP tree, which seems to package its own versions of gcc and clang. Perhaps LineageOS includes different prebuilt compilers and that's why you see issues.
Really curious to see how LOS runs though. AOSP has some annoying performance issues and crashes.
Gairtial said:
Why the copyleft archive? It doesn't look like they've touched it since April while they touched the regular one 2 hours ago.
I had no issues compiling and running the kernel from https://github.com/sonyxperiadev/kernel, though that was integrated with their entire AOSP tree, which seems to package its own versions of gcc and clang. Perhaps LineageOS includes different prebuilt compilers and that's why you see issues.
Really curious to see how LOS runs though. AOSP has some annoying performance issues and crashes.
Click to expand...
Click to collapse
I've just tried to build the aosp/LA.UM.5.7.r1 tree from the sony kernel repo. This one has a lot of compiler errors which need fixing first. However for me it looks like that the msm-4.4 tree is much cleaner in this regard so maybe also more advanced.
modpunk said:
I've just tried to build the aosp/LA.UM.5.7.r1 tree from the sony kernel repo. This one has a lot of compiler errors which need fixing first. However for me it looks like that the msm-4.4 tree is much cleaner in this regard so maybe also more advanced.
Click to expand...
Click to collapse
Also fellow LineageOS developers said that the sony 'kernel' repo is a Proof of Concept repo and not what they use in production. So I stick to the production release of MSM.
modpunk said:
I've just tried to build the aosp/LA.UM.5.7.r1 tree from the sony kernel repo. This one has a lot of compiler errors which need fixing first. However for me it looks like that the msm-4.4 tree is much cleaner in this regard so maybe also more advanced.
Click to expand...
Click to collapse
Huh, what kinds of errors are you seeing? I really suspect it must be something different between LOS and AOSP and I'm wondering what it is.
modpunk said:
Also fellow LineageOS developers said that the sony 'kernel' repo is a Proof of Concept repo and not what they use in production. So I stick to the production release of MSM.
Click to expand...
Click to collapse
This may be true but it's also the repo where the most work is done. We should at least pay attention to it in case they commit fixes that are useful.
Also probably getting ahead of myself but I wonder if we can merge EAS... It's in AOSP's common kernel, is it around in LOS anywhere yet?
Gairtial said:
Huh, what kinds of errors are you seeing? I really suspect it must be something different between LOS and AOSP and I'm wondering what it is.
This may be true but it's also the repo where the most work is done. We should at least pay attention to it in case they commit fixes that are useful.
Also probably getting ahead of myself but I wonder if we can merge EAS... It's in AOSP's common kernel, is it around in LOS anywhere yet?
Click to expand...
Click to collapse
You get the errors with -Wmaybe-uninitialized which is a relatively new gcc feature. The Sony 'kernel' repo is their Proof of Concept repository. Yes, sure they are working on it it makes totally sense to try things out there first!
I dunno what EAS is or means ...

Categories

Resources