[9001][KERNEL][GB] SkyHigh V1.5 [Updated 08-02-13] [Additional BigMem edition]

This is the official thread of my SkyHigh kernel for the Samsung Galaxy S Plus aka GT-I9001. V1.5 is my final release, please read the FAQ in post #2 for more details. Please refer to post #3 for changelogs of new releases, all available downloads are at the bottom of this first post. If you don't know how to get back to stock kernel you MUST NOT install this !

Disclaimer: this piece of software is not for the unexperienced and might bring you in a situation you can't resolve yourself. So don't use it if you fear the potential danger of bricking your device. I am responsible for nothing related to this kernel and therefore won't help. If you decide to use it anyway you agree to be ultimately responsible for all consequences that may occur. So you have been warned !

Terms of use: Remember the power of reading ! If you can't find some particular information on the first page use the search function, it is your best friend.
Besides there are even guides and tutorials all over the forum and in most cases your question was already answered.
If you take a moment and read through the WHOLE post below and a few more moments to read some of all the stuff in other device related threads of this forum, you will find ALL you need just there.
It's not invisible so you CAN find it. And forum rules and good manners tell you to do it exactly like this. And I WILL ignore every question that is already answered here.
Obey the rules !




This kernel is meant for use with ANY Gingerbread stock ROM and custom ROMs as well (i.e. Android V 2.3.x only !). To prevent compatibility problems with custom ROMs that include system tweaks like Thunderbolt and Adrenaline Shot any existing init.d folder will be purged while installing the SkyHigh kernel. This is not a bug but a mandatory feature !
If you think you have an important script you will still need with SkyHigh like the screenstate_scaling script, copy it to your (internal) sdcard first then copy it back to the empty init.d after installing SkyHigh.
init.d support means that SkyHigh kernel will execute any scripts inside a folder /system/etc/init.d automatically but obviously only if these exist.
If you are using a custom ROM without init.d folder or any stock ROM you might have to create the init.d folder yourself. For more details there are tutorials in this forum.

Install instructions:

1. If you don't have CWM (FeaMod Recovery) install this first. If you never heard of that learn all about it here:
http://xdaforums.com/showthread.php?t=1331164
2. Now make a complete nandroid backup of your phone with CWM
3. Download the attached CWM zip package
4. Copy it to your internal sdcard
5. In CWM choose "install zip from sdcard", then "choose zip from internal sdcard"
6. Select the downloaded file "GT-I9001_SkyHigh_kernel_V1.x_CWM_signed.zip"
7. Confirm install with "Yes"
8. Wait till you see the message "Reboot to use SkyHigh kernel V1.x !"
9. Do so like the message says.

10. On first boot this may take a while. You will see the Samsung logo and then a black screen for at least 2 minutes up to 5 minutes. If this happens hang on, don't touch anything and don't switch the phone off or pull the battery. This would most probably break your ROM !

11. Usually many files and databases are optimized on first boot but eventually you will see the lock screen or PIN dialog. Then you are all set and beginning with the next boot this will be much faster, promised

Remark: especially on preoptimized (custom) ROMs this won't happen since there's not much to optimize. So it's no bug but a feature when it doesn't happen and your phone boots up in less than a minute

​

• If you want FeaMod Recovery together with SkyHigh kernel just follow the install instructions above. Install desired version of FeaMod first and then SkyHigh. You will end up with the combination you wanted.
• If anything went wrong during install just try again.
• If you have any issues with your sdcard(s) this is not due to SkyHigh or its install procedure. I will never ever even touch your sdcard(s). But it is always a good idea to have a rather current backup of the sdcard(s) handy. CWM makes no backup of these, so you have to do that manually.
• If your phone doesn't boot even after 10 minutes waiting (see step 10.) or you end up with a damaged system because you didn't wait long enough just go back into CWM and restore the backup you made.
• If you can't boot into recovery anymore just install FeaMod 1.2 via Odin again.
• If you got severe errors AND didn't make a backup because you knew better than the developer don't even dare to beg for help.

If you encounter any other errors report them here but be sure that this is no feature or problem that was already described above or in the FAQ below.

While V1.3 lacks some of the features above (especially the Thunderbolt/AS tweaks) it is totally safe with sd cards, at least I never got a single report on that issue. The older V1.3 is still added as attachment for your convenience although V1.4d already fixes all sd card problems.

Final update V1.5 officially released !

Please refer to the first 3 posts, I updated them all with a lot of details.

The rest is up to broodplank, good luck mate, I say farewell so long,
skywalker01

broodplank1337 said:

Ok, first of all thank you very much for your extended reply, I always learn a lot from your long and well explained replies. In my eyes you're a true developer!

Click to expand...

Click to collapse

Thanks again for all your appreciation (like always) but I have to make an announcement to everyone who answered here:
the only reason why I give those long explanations is to encourage everyone who reads them to try to develop something on their own.

But since a huge lack of spare time is my crucial problem and writing such tutorials and essays is a bigger time killer than development itself - like I already tried to explain in previous posts - continuing with these long posts would be completely contrary to intention and my personal needs.
I really have a lot of numerous duties in my "real" life and continuing here would mean neglecting those duties as well as closely related persons.
So I hope that everyone understands that I have chosen to concentrate rather on real life than on xda which means that I just can't put most proposals here into action.

But don't hesitate, I also decided to give you the latest kernel V1.5 but remember that the practical differences are quite limited. Regard it like a service pack for windows, all the features are the same as in V1.4d. And there is an additional BigMem version. That's all what you will see unless you have a peek into the source code. There are hundreds of changes for stability and efficiency but no new features.

Like I also mentioned already I didn't test the new version thoroughly. So I will NOT publish it before I'm sure that there are no major bugs in it and my proposal is that I will give it to some beta testers first that can test it on their own phones and give me short reports if they found something strange AND different to V1.4d.

So any volunteers may send me a pm and I will give you a copy of V1.5 or V1.5bm or both for testing.

broodplank1337 said:

GB isn't bad at all, atleast in gb everything works the way it should (fm radio and gps working fine), but the samsung layer on top of it kinda screws it up I think, also the reason why the didn't release ics for i9001, the TW framework would take to much memory...

Click to expand...

Click to collapse

Well, honestly I doubt that this is the real reason. It's all about money: development costs a lot of time and staff and therefore a lot of money.
Only major devices - that means with a high selling rate - and those who use the same hardware as the bestsellers (not much additional development necessary) will be updated for a long time and even with major updates like new os versions.
Since both conditions don't apply to our I9001 it would be economically inefficient by the manufacturer to do it anyway and it would be rather silly by the customers to watch for this to happen
So just take this as an advice when you buy your next device (of any type that can be updated, so this is even true for software based TVs for instance !): if you want major updates and long time support buy ONLY bestsellers and never niche products or low budget products like the I9001.
This may sound unfair, theoretical, flashy or whatever but reality and experience proof that this is the only reliable method.

broodplank1337 said:

look at aosp, CLEAN and fast, my AOSP runs faster then GB stock roms from samsung, but I haven't planned planned any successful route in navigation since i switched to ICS, which kinda bothers me. although using a custom gb rom and your kernel makes things a lot better

Click to expand...

Click to collapse

I totally agree with that. Guess what I am running
First I customized my GB stock ROM and since this wasn't enough I took manveru0's Feacore Phoenix kernel. But when he stopped his development the kernel wasn't yet good enough for my personal demands so I continued his work primarily to suit my own demands.
Remember that even back then I only published my kernel in an own thread due to public demand and I still had a lot more spare time than today.

broodplank1337 said:

And I've studied the layer architecture once, but it was to long ago to remember. I did remember that dalvik actually is VM that runs on top of your android installation, and it converts it input to smali for faster processing (don't know if it actually does get faster by doing this), I think if they build the java interpreter natively it would boost the performance in general. (correct me if im wrong)

Click to expand...

Click to collapse

Sorry, but it is exactly the other way round. Native interpreters are always slow as hell. Only compilers (and assemblers) will deliver rather fast executable code.
Since Java is an interpreted language and therefore has natively a tremendous performance problem this is usually boosted by precompilation.
The Java source code will be first "precompiled" by the Java "precompiler" into .class files. Then Google uses the dx tool (dexer, part of Android SDK) to translate the .class files into Dalvik's proprietary format ie. to dex code, so that's the precompiled Java bytecode. This Java bytecode is packed into the apk files you execute in Android.
If you start an App (which is an apk file) the dalvik engine will unpack the apk file and execute the precompiled Java bytecode (which resides in classes.dex). It should be very obvious (if not tell me and I will give you another hint) that this is MUCH faster than interpreting native Java source code. But it is still much slower than compiled executables of a "real" compiler language like C or Pascal and all their derivatives.

So what about smali now, what is it actually ?

Well, just have a look on Google's developer pages, I'm just citing here:

"smali/baksmali is an assembler/disassembler for the dex format used by dalvik, Android's Java VM implementation. The syntax is loosely based on Jasmin's/dedexer's syntax, and supports the full functionality of the dex format (annotations, debug info, line info, etc.)

The names "smali" and "baksmali" are the Icelandic equivalents of "assembler" and "disassembler" respectively. Why Icelandic you ask? Because dalvik was named for an Icelandic fishing village. "

Can you see now what smali and baksmali actually do ?

Just in case one additional hint: on which platform(s) run(s) smali/baksmali and why is your statement above about smali not really correct ?

broodplank1337 said:

I didn't know that the intermediate layer was all about the device specific things, I assumed it had some preparation files for building the component, which is true, but didn't know the device specific values were hidden in there. Learned something new .
I know the libs are highly hardware dependent, that's also the reason I used the CM9 libs in the first place, because they are the closest you can get to the AOSP libs, also I think it's a pity that samsung only released like 0.5% of their sources, if they included all libs building aosp would have been way easier.

Click to expand...

Click to collapse

Of course, but I already commented on this, did you read that ?
http://xdaforums.com/showpost.php?p=33442132&postcount=499 (last lines)

broodplank1337 said:

And idd the device specific stuff is mostly in /external and /hardware, that's why I figured to use those folders from cm in the aosp environment, and it does improve the compilation process by loads, but still doesn't generate any working stuff. On the bright side, the Galaxy W (i8150), which is almost identically to the i9001 is getting official CM support, so that means this can become handy for me as well.

Click to expand...

Click to collapse

Maybe yes, maybe not. But I'm repeating this now for the thousand and first time I guess: i8150 and i9001 are NOT so identical like 100% of the users here think. Many sensors including camera sensors and sound processing are completely different just for instance. You MUST look at the kernel sources to see the numerous differences. If you don't do that or don't understand the differences between ANCORA and ARIESVE in the source code I doubt that it is possible at all to compile a fully working AOSP for the I9001 (without CM or other custom AOSP files that is).

broodplank1337 said:

Thanks for the explanation about the layers, I didn't know there was a max of 1 level regarding communication.

Click to expand...

Click to collapse

That's only one fact about layers you must learn IMHO. Layers are EXTREMELY important since nearly everything in computers works in layers of some kind. It's one of the basic principles of software engineering and you can find it almost everywhere. In protocols like network protocols (OSI model !), http, printer protocols and so on, but also in interpreting and compiling software (see above, "compiler construction").
But these are all very complex topics and most of them fill at least one complete semester if you study computer sciences. That's why I always say you need YEARS just to learn the basics. And I think you are the only one in the I9001 forum who should be able to confirm this because you are trying for a whole year now and AFAICS you are also the only one who started from null and actually still continues and didn't give up just after a few weeks or months like all the others that contacted me for starting help (and I gave 'em a lot of it).

broodplank1337 said:

And idd it's theoretically impossible to compile it in a working state for the i9001.

Also I don't know what CM exactly did to get it working, I think they first collected a lot of hardware and external libs then rewrote the framework (I really don't know to be honest). Could you give me a push in the right direction?. I thought about some ways, but I don't know what is the most effective, for example I spend the whole weekend on some small part that actually isn't going to make a big difference after all, wouldn't like that to happen.

Click to expand...

Click to collapse

Well, but that's exactly how it works. I'm doing nothing else, that's the reason why it is so time consuming. This is mostly reverse software engineering and this is the most painful discipline you must know. Honestly, I can give only one advice there: if you can't stand it leave it.

But if you still want to continue this is what you should know and do:

the framework is mostly only cosmetic, written in Java and therefore hardware independent (!!!) as well as not part of the libraries.
So I actually have no idea what's your problem with the framework and why you are so focused on that part. From my point of view you are looking in the completely wrong places there. But I also don't know the vanilla AOSP source as mentioned before, so can you provide me some more details (compiler error messages that involve the framework sources for instance) ?

The problem are the libraries primarily. There are two solutions for that:

1. modify the source code of the Google standard libraries. If there is already some leaked source of the hardware manufacturer somewhere you are lucky and can use it. Otherwise reverse engineering and debugging are the only possibilities. The kernel driver source and the library sources of similar hardware are your only references. But IMHO you need very advanced programming skills and experience for that.
CM is a very good source for such already modified library sources so it is not only OK to use them it's even the best method.

2. the easier method is to use the already compiled libraries (.so files) that already come with the stock ROM of the device.
But there are a lot of difficulties that can come with this method which are often unsolvable. I bet you already experienced some of these problems, incompatibility (with the other AOSP libraries) is the primary one. If they are compatible you are lucky, just look at the vendor folder of already working CM devices. It is mandatory to fully understand the concept of CM's vendor folder and how it is integrated into CM compiling because IMHO this is the only method that a non-programmer can use to make AOSP work on a device that isn't yet fully supported by any AOSP sources.

broodplank1337 said:

Thanks in advance, and thank you for all your help skywalker01, you're great!

Click to expand...

Click to collapse

You're welcome and I hope these explanations were not too discouraging, as I mentioned above they should be encouraging.

But I also don't want to raise false hopes and as a final conclusion and advice I want to tell anybody my honest opinion: I already told others here that they are completely underestimating the complexity of OS development and I will try to explain now why this is true.

Just imagine you want to learn a new (spoken) language like Russian. If you are already a speaker of another Slavonic language like Polish and so on this should be much easier so in this case take instead Chinese for instance.
If you want to speak it really well and professionally, let's say to become a translator, you will also need years for that. And you can bet your a** that learning the basics of software engineering isn't easier than that.
And when you are trying to modify a whole operating system or doing reverse engineering which both belong to the premier class of software engineering these basics still won't be enough by far. While these rudimentary basics might already be enough for Java development they are only the first mandatory step for OS development and reverse engineering.

Staying with this metaphor I will try to explain what you are actually asking. You ask how to compile ('translate') AOSP ("bible') for the I9001 ('into Russian'), where to start and what's the most efficient way. So it is like asking how to translate the bible into Russian.
The answer for that question is very easy: learn Russian first, and learn it very well. When you have done that, then you know automatically how to translate the bible (and anything else) into Russian, where to start and what's the most efficient way to do it.
There is no way to do it without learning the complete language and there is no way to just learn how to translate a single book. At least no way that I am aware of.
It's the very same with OS software development like I tried to explain above. You must read and learn the whole "story", there is no "partial" or "selective" way. Sorry if this sounds pretentious, but along with the advices above I can't give you a more honest and much better answer than that.

So there is still a very long path ahead of you and you have to make a decision. Do you really want to trudge through all of it till the end or do you rather take the next exit and continue with something less tormenting and more rewarding like scripting and modding. The latter ones are also the first steps in learning the basics of programming and you already know a lot of them, don't you ? So it would be a good opportunity to abandon that I9001 AOSP project in favor of more promising projects. A new GB kernel for instance, hahaha. But that's completely up to you and just a possibility to consider.

OK, I'm back again and now read thru all the thread and also thru the broodROM thread since RC4 uses SkyHigh V1.4 as default kernel.

For obvious reasons I can't reply to all single posts, but many questions were already answered by other users - thanks for that especially to chasemyass, I nearly agree 100% with all of your statements

So the most important issue with SkyHigh V1.4 seems to be the sd card issue. Actually I already feared that and therefore put from the very beginning that short remark in post#1 that the reason is NOT SkyHigh.

This seems to be misunderstood by many people and I will explain this more detailled now.

First I have to admit that the sd card corruption is a much more severe failure than I would have expected. But on the other hand this is actually no fault in the kernel but just another performance feature that is not compatible with every phone/sd card. So it's the same reason why OC and UV kernels don't run on every phone: you have to understand that all devices are not 100% the same. There are always very slight differences in all the tiny hardware components inside your phone which could result in more or less big differences when tweaking beyond the recommended limits.

But tweaking beyond the recommended limits is actually what every performance tweaked kernel does and you have read the disclaimer and the feature list, haven't you ? So you can't say you hadn't been warned.

Now let me explain why this has happened (on some devices). For that I will give you a short quote from another website first where the basics of overclocking are explained: "Also, not all processors are the same. For example, most i5-2500k's can overclock up to 4.5GHz or higher but I've heard of some units which are having difficulty in reaching even 4.0-4.2 GHz, though this is quite a rarity. They [the manufacturers] find a clock wherein all of their processors are stable and this is where they sell them at. This ensures that the processors will run at a level that will not cause a significant reduction in their longevity."

Note the first sentence "not all processors are the same" and the word "rarity" which means only a few specimens will fail and the majority will just work fine beyond the limits if you keep them somewhat reasonable. But finding good values for such a "reasonable" higher limit is quite an art which will consume much time and effort. I think I have already found these values for the cpu frequencies and voltages so I recommend you change nothing there. But the sd card tweaks are very new and have the potential to receive some fine tuning.

You have to think now further and transfer the overclocking facts to the hardware of our phone: Qualcomm says the scorpion cpu on our msm8255t based board can be operated safely at 1,5 GHz. But Samsung only sets it to 1,4 GHz. Why is that ? Because it is safer: the cpu will use a little less power and stays a little bit cooler ultimately resulting in an overall more stable operation.

And this is also basically what stock kernels (and ROMs) do: the working parameters are set to very conservative and secure values that will actually work on any device of the series no matter how bad the electronic tolerances of the individual components are.

But this also means a lot of the potential of the hardware remains unused just to make sure it will work on every single device.

Now you have to understand that these basic rules don't only apply to the cpu but also to all other components. And overclocking or underclocking frequencies are by far not the only values than can be tweaked beyond the recommended limits of the manufacturers. Undervolting and overvolting is also just one other method. Actually there are a lot of software values that don't have direct impact on the hardware but can lead to severe software failures like memory and media corruption.

For instance I used 4 different software techniques to speed up the sd card performance. While this works well on most of the devices it obviously fails on some which can't handle values beyond certain limits. But these limits are individual for any single phone so it is impossible to make the tweaks work on all devices. The reason is simple, by making the kernel compatible with all phones you will just end up with the parameters and values of a stock kernel wasting again all the extra potential of the hardware of most devices.

So the bad and sad news is that unfortunately not all users can use the benefits of tweaked kernels/software because their individual device can't handle the values which reach beyond the limits of their hardware.

So the reason for the sd card failures is not the kernel but the individual hardware on which it fails. Of course the kernel is the trigger which lets the affected hardware fail but that is something different.

In one sentence: it's not a bug, it's a feature !

But what I can do and will try at the weekend is to release a version with less aggressive sd card tweaks which is hopefully compatible with more devices.

But I won't revert too much because this would spoil the performance of the majority of the devices on which the current tweaks are working fine including my own phone.

And I hope that everybody understands that making a custom tailored kernel for every single i9001 is completely out of the question.

So to sum it up I can only give two advices right now:

1. try the new kernel version with a little bit reduced "sd card boost" when it's ready and published

2. if that also doesn't work for you just try another kernel that fits you well; for your convenience I will also add the last SkyHigh V1.3 to the first post later which seems to have no sd card issues (since it has only 1 of the 4 mentioned sd card tweaks of V1.4)