[An Idea] Kernel 3.x, filesystem, etc...

13 posts in this topic

First of all, i want to apologize all of you, who think, that this topic is another waste of time - maybe you're right.

Before Blade i used to use Samsung Galaxy Spica. It is one of first android phones, abandoned by samsung long time ago (android 2.1).

But there is (or was) a group of great people, who gave spica second (and maybe third) life. Of course - there is one big disadvantage - memory (RAM). Spica has 160MB of available RAM, and actualy, max 50-60MB free memory with clean system (A2.2). with gingerbread even less. The second problem - lack of good graphic drivers was partialy solved by one man. He wrote those drivers (some kind of "universal ones") from a scratch.

Moreover - he "made" 3.x kernel for spica from a scratch too - including all drivers, that wasn't compatible with older versions. With this, and with change of filesystem (to UBIFS) - spica was really fast in some ways. The biggest boost was in I/O i think)

That young man works now at samsung (R&D).

Why i am writing this? Yes, i know that spica and blade are quite different devices with different SoCs, but... but maybe guys that understand linux, kernel compilling and so on, could use some of that "things" to make our blades even better.f

I know, that some of our developers tried to port 3.x kernel to our blade. Maybe there is something helpful on his github?

Share this post

Link to post

Share on other sites

First of all, i want to apologize all of you, who think, that this topic is another waste of time - maybe you're right.

Before Blade i used to use Samsung Galaxy Spica. It is one of first android phones, abandoned by samsung long time ago (android 2.1).

But there is (or was) a group of great people, who gave spica second (and maybe third) life. Of course - there is one big disadvantage - memory (RAM). Spica has 160MB of available RAM, and actualy, max 50-60MB free memory with clean system (A2.2). with gingerbread even less. The second problem - lack of good graphic drivers was partialy solved by one man. He wrote those drivers (some kind of "universal ones") from a scratch.

Moreover - he "made" 3.x kernel for spica from a scratch too - including all drivers, that wasn't compatible with older versions. With this, and with change of filesystem (to UBIFS) - spica was really fast in some ways. The biggest boost was in I/O i think)

That young man works now at samsung (R&D).

Why i am writing this? Yes, i know that spica and blade are quite different devices with different SoCs, but... but maybe guys that understand linux, kernel compilling and so on, could use some of that "things" to make our blades even better.f

I know, that some of our developers tried to port 3.x kernel to our blade. Maybe there is something helpful on his github?

As i told at the beginning - if my ideas are nothing but a junk - mods: feel free to delete that thread.

Watchu talkin 'bout, squadzone has been running kernel version 3.33.33.33 on his 2.3.8 ROM which has special api's (not one, several of them apparently, no one knows what the special api's are for but they are awesome if squadzone do say so himself).

Link to post

Share on other sites

If you want a serious answer, all my testing has resulted in the same thing as most others, it's better to just use 2.6.35 (actually that isn't the real version number but you know that if you know anything about Blade kernel dev)because 3+ versions tend to be dreadfully slow when hacked together to support our HW.

I'm basing a chainloader kernel on it though, along with touch from team win and some parts of newer CWM for Samsung (which actually has chainloader capabilities built in).

So there is that i guess.

0

Share this post

Link to post

Share on other sites

Watchu talkin 'bout, squadzone has been running kernel version 3.33.33.33 on his 2.3.8 ROM which has special api's (not one, several of them apparently, no one knows what the special api's are for but they are awesome if squadzone do say so himself).

Share this post

Link to post

Share on other sites

squadzone even admitted he was bullshitting about it being a 3.x kernel

Kernels can be backported so you can split any kernel from drivers and code, it took me a full 0.5 seconds to find out that it's not just 2.6.35 but also an elderly version at that.

And his entire codebase is just hacked framework based on CM7.2, there are no new API's and backported stuff is just theme addons for Holo launcher that has been available for CM7 since before the Holo was released for CM9.

It's just bullsheit.

If you want a clean and nice CM7 you go with targetbsp's cm7, everyone knows that.

Share this post

Link to post

Share on other sites

I didn't say that spica's kernel will work with blade. And i didn't say that porting will be easy thing... I say only that making it from a scratch (like Tom3q did for spica) basing on newest kernel would make huge boost. But if nobody can do it/cares - no problem for me. I skipped to Galaxy Ace II anyway...

0

Share this post

Link to post

Share on other sites

I didn't say that spica's kernel will work with blade. And i didn't say that porting will be easy thing... I say only that making it from a scratch (like Tom3q did for spica) basing on newest kernel would make huge boost. But if nobody can do it/cares - no problem for me. I skipped to Galaxy Ace II anyway...

3.0 Kernel would be really good and could speed up android really much but 2.6.3# kernel on ZTE blade with CM10 i good and really fast and blade can't be much more faster..

I saw somewhere 3.0 kernel for LG P500, which would be easier to modify for blade..