Hi All,
Running rooted Hero with Modaco 2.5.1 rom ( thanks Paul )
Was hoping someone could ( simplistically ) answer a few question for me.
As I understand it - one of the things holding back development of Hero ROMS is that HTC haven't released the kernel for the Hero.
1) What exactly IS the kernel in the greater scheme of things?
2) When are HTC likely to release it?
3) When it is released, what new things will it allow developers to do?
4) Anything else relevant to it worth knowing?
TIA
Look at these:
1. The kernel is the Operating System for the phone, it runs everything.
2. That is the magic question...
3. It'll allow more development in terms of mods. we'll be able to change alot more and get more out of the phones.
I'm sure others will have more detailed explanations.
Regarding question 2:
I've gotten response from HTC support the other day that the release is planned but no sure date could be given.
Date: 5th of October
My question:
Hello there, I realize that this might not be the normal kind of request you guys get, but here goes. This is probably not your average request and might require escalation. I was wondering when the source code for the Hero kernel was gonna be available at developer.htc.com?
Click to expand...
Click to collapse
Answer:
Hello
This is quite a normal question we get here at HTC. The source code is something that will becoming soon. We have had contact with those far higher than my self or are planning on adding the source code as soon as possible. I have not been given a time scale but bases on the code for the two other handsets i should expect it in the next couple of weeks.
Hope this helps.
Click to expand...
Click to collapse
So, educated guess would be around the release of the Hero in the US.
Some if I have this right -
The kernel is the basic underlying OS of the phone, and a ROM sits on top of this end gives us the end user experience ( and Sense UI is within the ROM ).
Am I right in thinking the kernel is linux based?
And a big magic question - when the kernel is released, will people be able to modify it and get the bluetooth working properly?
Sorry if it's a bit basic - but interesting to me....
The Kernel is not the OS (As most people understand an OS to be) (OS meaning Operating System)
It's at the core of the OS but is not the OS. You can keep the same build of an OS but update the kernel and vica versa. It is (put simply) what converts the hardware calls from the OS into something the hardware understands.
So (using current issues as explanation) The OS tries to load the GPS and the kernel isn't configured with the right settings the GPS won't load. Similarly if you try and use the trackball and it's not setup in the kernel then it won't do anything.
The OS will still work fine with other things but until the kernel has the right settings put into it it just won't see the parts of the phone it's not set up to.
Here is a technical description of a Kernel.
http://www.linfo.org/kernel.html
I'm sure I've just made it as clear as dishwater but if not I hope it's helped.
J-Zeus said:
Some if I have this right -
The kernel is the basic underlying OS of the phone, and a ROM sits on top of this end gives us the end user experience ( and Sense UI is within the ROM ).
Click to expand...
Click to collapse
Not exactly. To add to what akirainblack has said already...ROM stands for Read Only Memory. In this context it is a bit different as it is the complete package that makes up the Kernel, the OS and anything that is pre-installed to the phone. When you run the RUU (Rom Update Utilitiy) on your PC is completely refreshes the system software in your phone - Kernel, OS and any pre-installed apps - just as if you had bought it from the shop like that.
J-Zeus said:
Am I right in thinking the kernel is linux based?
Click to expand...
Click to collapse
Yes.
Hmmm...
simple question... when the kernel is available... would we be able to get a white taskbar on the Hero?
//Nik
When the kernel source is available, we should be able to rebuild Android completely from the source code repositories and do practically whatever you want.
Regards,
Dave
foxmeister said:
When the kernel source is available, we should be able to rebuild Android completely from the source code repositories and do practically whatever you want.
Regards,
Dave
Click to expand...
Click to collapse
Including getting Bluetooth working?
J-Zeus said:
Including getting Bluetooth working?
Click to expand...
Click to collapse
In theory, yes. In practice, the situation is a little more complicated, but at the very least I'd imagine it would be possible to get BlueX, or something like it, working on rooted Heros fairly quickly.
Regards,
Dave
Given that this is a Linux kernel, aren't HTC required by the GPL to make the source available to all Hero owners?
This is covering the same ground, but is another way to look at things regarding the kernel and the OS. The kernel abstracts the specifics of the hardware from the Android system. For example, when the Android system requests that the bluetooth hardware be enabled, the kernel can translate that request so that it works with the particular hardware of the phone - as the bluetooth hardware of the Magic may be different from the bluetooth hardware of the Hero. So the kernel, is an interface that translates and Android call to the specific hardware level controls necessary. The kernel sits between the hardware and the Android system.
It also means that releasing the kernel will not allow us to make changes to the Hero Android user interfaces. If we want to change colours, icons and so on in the Hero ROM, we would need the source code for their "tweaked" Android and maybe to some degree their TouchFlo software. I doubt they would give that away. It would allows us however, to tweak the kernel, or transplant the driver code for specific hardware pieces in the Hero, to a newer version kernel.
I understand that the release of the hero kernel, could help me with my cause (getting 1.5/1.6 'clean' android on my hero without any htc apps/front ends).
Somebody suggested contacting HTC and asking for it to be released.
I have a few questions regarding that:
1) Has this happened before? That HTC released an android kernel?
2) Did this happen after the request?
3) Who should we contact to get it? (which HTC division)
4) Is there a possibility that they don't want to release it, because it would allow people to copy parts of the proprietary interface?
E2K said:
1) Has this happened before? That HTC released an android kernel?
Click to expand...
Click to collapse
Take a look at http://developer.htc.com/
The Dream and Magic sources are available.
E2K said:
4) Is there a possibility that they don't want to release it, because it would allow people to copy parts of the proprietary interface?
Click to expand...
Click to collapse
The HTC Sense UI won't be included in the kernel source.
They dont have to release the source of them.
New question
Is it possible to create a new donut kernel (2.6.29) with the changes they made to the 1.5 kernel (2.6.27)?
Looks like they send you the hole kernel, not just some patches and new drivers...
mopodo said:
Take a look at http://developer.htc.com/
The Dream and Magic sources are available.
Click to expand...
Click to collapse
So this means that we could compile or 'cook' a working vanilla android 1.5 for the HTC hero, with everything working fully?
HTC HAS to release the kernel source as required under the GPL license that the kernel was released under. It is indeed a linux kernel and it contains the necessary parts to work the hardware along with extra drivers and modules (stupid monolithic kernels).
Here's what I don't get (and hopefully somebody will clarify this for me). Why hasn't anybody tried building android with the current kernel available? Android has the ability to be built around a pre-compiled kernel (it does this if you do a straight make right after repo sync with the pre-compiled dream kernel). You'd only need to re-build the wlan.ko module for the new kernel and the gps module would be compiled against the specified kernel, so it should work.
If I had Hero, I'd test it (if you want to trade your Hero for my G1, hit me up ), but there's no reason it shouldn't work.
Up to now, I've only seen ports, and those are hard to make work because of the pre-compiled files, so that leads to loads of file-swapping and finger-crossing, but an AOSP make should still work. Anybody wanna try it (or post me a hero kernel and I'll compile you a stock donut build to test).
jubeh said:
HTC HAS to release the kernel source as required under the GPL license that the kernel was released under. It is indeed a linux kernel and it contains the necessary parts to work the hardware along with extra drivers and modules (stupid monolithic kernels).
Here's what I don't get (and hopefully somebody will clarify this for me). Why hasn't anybody tried building android with the current kernel available? Android has the ability to be built around a pre-compiled kernel (it does this if you do a straight make right after repo sync with the pre-compiled dream kernel). You'd only need to re-build the wlan.ko module for the new kernel and the gps module would be compiled against the specified kernel, so it should work.
If I had Hero, I'd test it (if you want to trade your Hero for my G1, hit me up ), but there's no reason it shouldn't work.
Up to now, I've only seen ports, and those are hard to make work because of the pre-compiled files, so that leads to loads of file-swapping and finger-crossing, but an AOSP make should still work. Anybody wanna try it (or post me a hero kernel and I'll compile you a stock donut build to test).
Click to expand...
Click to collapse
Hi, thank you for this information. You make it sound like it's possible
I tried searching for the Hero Kernel, but I could only find this:
http://developer.htc.com/
The hero is not listed (maybe it shares a lot with the magic kernel?).
edit: this post dating from september 10 stated that HTC would "release the kernel source soon".
This was more than a month ago though..
edit2: calling HTC Netherlands right now..
edit3: after explainig the need for the kernel, I've been on hold for 10 minutes now..
edit4: more than 18 minutes now
edit5: after 26 minutes I hang up
Well I have a Hero running Modaco 2.2. I could post this kernel (where?) Or it surely could be extracted from one of the ROMs available on this very site
SquiffSquiff said:
Well I have a Hero running Modaco 2.2. I could post this kernel (where?) Or it surely could be extracted from one of the ROMs available on this very site
Click to expand...
Click to collapse
I could be wrong, but I believe there is a difference between the 'kernel', and the 'kernel source'. The second one is needed when you want to compile the kernel.
Speaking as one who has compiled kernels in the past there are three components required here:
The kernel source- this is typically available from http://kernel.org/ If HTC have made any changes to the source of the kernel itself then these should be apparent in their distribution of the kernel source
The relevant configuration file '.config' which should accompany their distribution of the kernel source and permit you to compile any other kernel as a drop in replacement.
Source code and makefiles for any custom kernel modules ('drivers' in windows terminology) In Linux these have to be compiled together with the kernel.
To use a cookery analogy:
The kernel source is the raw ingredients. It can be set up for anything from a supercomputer to a DVD player depending on how you use it. The kernel config is the method which will allow you to bake the type of cake you intend. The modules sources are any of HTC’s own custom ingredients required for everything to work. THe kernel is the finished cake which you eat.
Related
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.
Hi guys!
I'm wondering what I'd have to do if I wanted to modify the built in apps inside Android..
I've got a HTC Hero running FroydVillain 1.5.0. Let's say... I want to modify the messaging app that's included, MMS.apk. I wouldn't know how to go about this, and I have a few questions...
Firstly, what sources exactly are used for building the built in apps for a given ROM? The source code link in the FroydVillain post, for example, is just for the kernel. The rest of the OS isn't there.
Secondly, I hear that in order to modify a built in app, you need to build the entire OS. If I just download all the code from Google official repo, and compile that, will it just... work on my phone, provided I use a kernel that is specific to my phone?
Lastly, are there any tips anyone has for someone who just wants to modify a couple of the built in apps? Is it possible to build them as standalone apps? Or import them into Eclipse?
I've had a search around the forum and the internets in general, and people have asked similear questions, but I've yet to find a good answer. This thread comes to mind: http://forum.xda-developers.com/showthread.php?t=635197
If anyone could help me, or point me in the direction of any help, that'd be awesome! Thanks!!
FunkTrooper said:
Hi guys!
I'm wondering what I'd have to do if I wanted to modify the built in apps inside Android..
I've got a HTC Hero running FroydVillain 1.5.0. Let's say... I want to modify the messaging app that's included, MMS.apk. I wouldn't know how to go about this, and I have a few questions...
Firstly, what sources exactly are used for building the built in apps for a given ROM? The source code link in the FroydVillain post, for example, is just for the kernel. The rest of the OS isn't there.
Secondly, I hear that in order to modify a built in app, you need to build the entire OS. If I just download all the code from Google official repo, and compile that, will it just... work on my phone, provided I use a kernel that is specific to my phone?
Lastly, are there any tips anyone has for someone who just wants to modify a couple of the built in apps? Is it possible to build them as standalone apps? Or import them into Eclipse?
I've had a search around the forum and the internets in general, and people have asked similear questions, but I've yet to find a good answer. This thread comes to mind: http://forum.xda-developers.com/showthread.php?t=635197
If anyone could help me, or point me in the direction of any help, that'd be awesome! Thanks!!
Click to expand...
Click to collapse
1) The whole sources for everything are there
http://github.com/ninpo
2) You can import the sources to eclipse, but I think you will need to build the entire tree, as opposed to just what you change
3) Apktool lets you do smali and resource edits on an APK. Without knowing what you aim to do, it's hard to guide you specifically.
Most apps are based on the sources provided by google. I assume you are talking about Froyo Hero ROMs (i.e. FroydVillain), which apps are generally built from the source of CyanogenMod. Specifically for FroydVillain, if you look around ninpo github you will see some packages with some changes to their code, although it does seem that many of the changes in recent releases are not there. I have actually PMed ninpo about this and hopefully this is only a technicality.... I assume that the other packages and apps (most of them) he just compiled off the CM sources without changes.
In any case, if you compile an app either from the CM source or from google's original sources, it should work just to copy the apk file - just make sure you use an appropriate ROM (i.e. Froyo ROM if you built it from Froyo sources). The reason to want the CM sources, is that if they have incorporated further fixes (over the google sources) you may want them.
Finally, some more practical advice: I would start with the google sources: http://source.android.com/source/index.html since I have found these instructions and explanations easier to begin with - it should be quite straight forward to build these sources on a linux machine (or VM).
Then you can also try to tackle the cyanogen source: http://wiki.cyanogenmod.com/index.php?title=Building_from_source currently missing instructions on how to build for hero. But if you only want to copy apks out of it, you can just build a generic build (like in the google souce).
If you have specific problems, ask and I'll try to help you.
Good luck.
pulser_g2 said:
1) The whole sources for everything are there
http://github.com/ninpo
Click to expand...
Click to collapse
For example where are all the changes to the dalvik code? I do not follow closely enough the changes in Froyd to point out other things which might be missing (if at all), but there are relatively few committed changes to the CM code. Specifically the dalvik code, ninpo mentioned hundreds of changes which caught my interest and are definitively not there.
The kernel sources do seem to be up to date always - been following that one closely .
Thanks for the advice I love this forum!
What I'm trying to do, in case you're wondering, ultimately, is to modify the built-in messaging application to give the user the option of sending a message by the normal method, or by using their provider's free webtext service, something that all the carriers seem to offer here in Ireland.
So, for example, you'd press the Send button, and you'd be able to select one of those methods. (of course, you'd have to have a data connection for the webtext). There's also be an interface for entering your login credentials for your carrier's website.
I'm doing this party because it would be very useful. I also feel that it would give me a good introduction to how you'd go about modifying Android. I mean, from a programming point of view, it shouldn't be *too* hard to do. I already have a simple standalone app that I made which can send a text message via an Irish carrier's webtext service. But it's all good experience to try to modify other people big codebases.
I have a good bit of experience with web application development, but my experience with other programming is a little more limited. I usually use PHP, where there's none of this compiling nonsense. You just write scripts and off they go!
So I'm gonna go off and see if I can set up an environment where I can build.. the OS, I guess.
If I was to take the vanilla official Google sources, would they work on my phone? Or would I have to use an official Google developer phone... or the emulator? Or maybe if I stopped writing here and investigated those links you've provided, I'd know that by know.
Brb, investigating
Yeh investigating and just trying to do it is usually the best way
To clarify what I was trying to say above: All the java code is obvious very portable - one of the big advantages of java. In the case of android it is compiled to an .apk file and this file should be, at the very least, portable to all android "devices" running this android version. So the apk you build (for example from the vanilla 2.2 sources) should work on the emulator (good for initial debugging) and any 2.2 ROMs.
erasmux said:
For example where are all the changes to the dalvik code? I do not follow closely enough the changes in Froyd to point out other things which might be missing (if at all), but there are relatively few committed changes to the CM code. Specifically the dalvik code, ninpo mentioned hundreds of changes which caught my interest and are definitively not there.
The kernel sources do seem to be up to date always - been following that one closely .
Click to expand...
Click to collapse
I'm currently on "vacation" from any and all Android development for a week. I'll be back after the weekend, at which time my modifications will be cleaned up and committed to git. The kernel is always current with my latest kernel release due to GPL obligations. The extra time away has also highlighted some changes I need to make both to the kernel and to my Android modifications when I get back.
Hacre said:
I'm currently on "vacation" from any and all Android development for a week. I'll be back after the weekend, at which time my modifications will be cleaned up and committed to git. The kernel is always current with my latest kernel release due to GPL obligations. The extra time away has also highlighted some changes I need to make both to the kernel and to my Android modifications when I get back.
Click to expand...
Click to collapse
Thanks Ninpo
[This is not the place to say "this is awesome" or "thanks!"]
[DEVS ONLY]
I want to start this thread to keep up the progress on the port.
the bad news is that the SDK is incomplete for now, so (like other devices)
we will have to write our own code for the OS, the nook community
has done a wonderful job writing their own libraries and stuffs, so we will have to do the same.
Instead of pursuing different goals, let's focus on one thing at a time.
since GSM and CDMA versions are already out, it seems we suffer the same bugs, so for now let's unite strength and knowledge to overcome these.
I propose that the first goal to fix is the SurfaceFlinger, so we could at least see the apps, the buttons and the notifications.
it is currently throwing this:
04-06 22:01:35.495: ERROR/Surface(2960): dequeueBuffer failed (Out of memory)
this could lead us that it might coudln't start because of some malloc malfunction or something.
also that pvrsrvinit bugs me a lot.
update:
8/APR/2011
since DiP7 could fix SurfaceFlinger and other things using a different build from the GSM kernel, we have to dig deeper
======================================
CURRENT GOAL
Rebuild Kernel
======================================
Current approaches:
*none
Post any finding, guessing or anything, and please, please don't be afraid to ask anything you have a doubt, as a Dev you should not know everything, so we can help us each other
------------------------------------------
Google Easter egg:
while searching some info about the android.mk file , I put it on the chrome bar to search for that term, but instead I went to
http://android.mk
an easter egg web page from google lol
******TOOLS*********
How to send text and Keystrokes via ADB
http://bradchow.blogspot.com/2011/02/send-intent-and-key-event-by-adb.html
use DroidExplorer to easily access your device from your computer and makes changes from it
http://de.codeplex.com/
The Android Boot Process
http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html
---Kernel Tools----
CPU Datasheet
http://forum.xda-developers.com/showthread.php?t=745877
Samsung GIT
http://android.git.kernel.org/?p=kernel/samsung.git;a=summary
PowerVR SDK
http://www.imgtec.com/powervr/insider/powervr-sdk.asp
Source code of samsung firmwares(keep and eye on this)
http://opensource.samsung.com/
Asus pad honeycomb Kernel Source
http://forum.xda-developers.com/showthread.php?t=1026528
ellokomen said:
======================================
CURRENT GOAL
Find why SurfaceFlinger is not working
======================================
Click to expand...
Click to collapse
Mmmk.. Let me tell you a story.
A long time ago in a galaxy far away... No, that will take too long. In a nutshell, one third of the answer is here, another third is here and the rest is here. I'm not trying to be intentionally vague, I just haven't figured out how these three fit together yet.
Of course, there could also be some bit of code that I missed... some telling line in a debug log that I overlooked or some driver or library that I could have decompiled to sift through its juicy secrets. There could easily be a fix that would take seconds to add and make the whole thing fall in line...
Or we might have to work it from the ground up.
Either way it will happen. It's just a matter of whether it will happen next week, or next month.
(Watch it be a misplaced semi-colon, or a bad symlink... that's how these things go.)
updated approaches and new tools have been added
spacemoose1 said:
Mmmk.. Let me tell you a story.
A long time ago in a galaxy far away... No, that will take too long. In a nutshell, one third of the answer is here, another third is here and the rest is here. I'm not trying to be intentionally vague, I just haven't figured out how these three fit together yet.
Of course, there could also be some bit of code that I missed... some telling line in a debug log that I overlooked or some driver or library that I could have decompiled to sift through its juicy secrets. There could easily be a fix that would take seconds to add and make the whole thing fall in line...
Or we might have to work it from the ground up.
Either way it will happen. It's just a matter of whether it will happen next week, or next month.
(Watch it be a misplaced semi-colon, or a bad symlink... that's how these things go.)
Click to expand...
Click to collapse
The kernel source that you have linked to is 2.6.35.7 for the Nexus S gingerbread and is not fully maintained by samsung but rather by google.
However I do not think you are wrong that there is a problem somewhere in the kernel. The kernel that has been released for the galaxy tab is a mess of horrid code, I have had to re-write parts of kernel drivers just to get them to work under linux, I would not be surprised if similar patches are needed for honeycomb
lilstevie said:
The kernel source that you have linked to is 2.6.35.7 for the Nexus S gingerbread and is not fully maintained by samsung but rather by google.
However I do not think you are wrong that there is a problem somewhere in the kernel. The kernel that has been released for the galaxy tab is a mess of horrid code, I have had to re-write parts of kernel drivers just to get them to work under linux, I would not be surprised if similar patches are needed for honeycomb
Click to expand...
Click to collapse
you mean that you made a port of a Linux Distro into the tab?
ellokomen said:
you mean that you made a port of a Linux Distro into the tab?
Click to expand...
Click to collapse
yes click here for the thread on the port of ubuntu
Current kernel source
Do you guys have another link to the current spacemoose kernel source? The download link seems to be corrupted and won't untar. I want to get in on the fun
noobporter said:
Do you guys have another link to the current spacemoose kernel source? The download link seems to be corrupted and won't untar. I want to get in on the fun
Click to expand...
Click to collapse
here it is, bear in mind that this is for CDMA devices
Unfortunatey, we have 4 other honeycomb threads.
Not trying to be rude but spacemoose updates us in the cdma forums AND we have russian rom updates in the gsm forums.
I really dislike the idea of this thread, there is enough clutter amongst the other threads. Do we really need one more place to browse..
The first posts in the roms thread are kept updated by devs.. Is this not enough??
daml said:
Unfortunatey, we have 4 other honeycomb threads.
Not trying to be rude but spacemoose updates us in the cdma forums AND we have russian rom updates in the gsm forums.
I really dislike the idea of this thread, there is enough clutter amongst the other threads. Do we really need one more place to browse..
The first posts in the roms thread are kept updated by devs.. Is this not enough??
Click to expand...
Click to collapse
yeah but we need a place for the other devs to share their milestones, here is a place for technical discussion amongst us, to share the knowledge etc...
the other threads are flooded from non devs messages, so it´s kind of difficult to read 14 pages of information when the 80% is people complaining not making it boot
lilstevie said:
The kernel source that you have linked to is 2.6.35.7 for the Nexus S gingerbread and is not fully maintained by samsung but rather by google.
Click to expand...
Click to collapse
Yes, and it contains some support for our device (s5pc110), and some more that can be added (pvr) and the architecture necessary to fully support HC without patching the build itself. If we work only towards patching the system build to communicate with the hardware, we won't be able to run AOSP hc versions when the source drops without going through the same painstaking process of hacking the system to function (while creating numerous faults causing FCs in the process). If we build a new kernel, we can get the hardware to communicate in the way future android versions want it to and we can then do what we want with ease.
noobporter said:
Do you guys have another link to the current spacemoose kernel source? The download link seems to be corrupted and won't untar. I want to get in on the fun
Click to expand...
Click to collapse
D'oh! Nobody told me, LOL... I'll get another copy up.
spacemoose1 said:
D'oh! Nobody told me, LOL... I'll get another copy up.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1026528
hey spacemoose! the first portion of honeycomb source... The kernel source of the Asus EEE Pad Transformer... maybe it helps you with a few kernel issues, even if it's for another device... It's honeycomb!
Flokey said:
http://forum.xda-developers.com/showthread.php?t=1026528
hey spacemoose! the first portion of honeycomb source... The kernel source of the Asus EEE Pad Transformer... maybe it helps you with a few kernel issues, even if it's for another device... It's honeycomb!
Click to expand...
Click to collapse
Digging through it now.
spacemoose1 said:
Yes, and it contains some support for our device (s5pc110), and some more that can be added (pvr) and the architecture necessary to fully support HC without patching the build itself. If we work only towards patching the system build to communicate with the hardware, we won't be able to run AOSP hc versions when the source drops without going through the same painstaking process of hacking the system to function (while creating numerous faults causing FCs in the process). If we build a new kernel, we can get the hardware to communicate in the way future android versions want it to and we can then do what we want with ease.
Click to expand...
Click to collapse
Not enough really, PVR kernel module sources have been released from samsung for our device, and is available in update1 zip.
The kernel panics and we have no framebuffer from the nexus s, believe me that is the kernel I want to be running for my project, it is cleaner nicer and things are implemented overall better. unless you know of a solution for kernel debuging over usb
lilstevie said:
Not enough really, PVR kernel module sources have been released from samsung for our device, and is available in update1 zip.
The kernel panics and we have no framebuffer from the nexus s, believe me that is the kernel I want to be running for my project, it is cleaner nicer and things are implemented overall better. unless you know of a solution for kernel debuging over usb
Click to expand...
Click to collapse
Kernel debugging over USB = adb shell cat /proc/kmsg
You can make any kernel work for any device as long as you add the **** it needs. Just takes time. Working on it now.
Goal and tools updated*
spacemoose1 said:
Kernel debugging over USB = adb shell cat /proc/kmsg
You can make any kernel work for any device as long as you add the **** it needs. Just takes time. Working on it now.
Click to expand...
Click to collapse
You don't know what a kernel panic is do you?
lilstevie said:
You don't know what a kernel panic is do you?
Click to expand...
Click to collapse
I thought that linux throws a dump log when it makes a kernel panic specifying the memory address and the cause of crash
Hi,
Please can someone explain why Exynos has a bad rep for custom ROMs? Samsung release the kernel and I assume it contains either open source drivers or binary blobs. Either way we have a functional boot.img with a working ~3.4 kernel, that kernel should presumably boot any sensible 4.4+ system.img right?
I'm asking because I'm considering building a clean ASOP ROM for the Tab S just to get rid of the crazy amount of bloat. This is obviously trivial with the Nexus device line, but I'm just trying to understand why it's complex in this case? Can we not just use the stock kernel/drivers with any arbitrary userspace e.g ASOP git or CM? Does the SoC really matter to us for non-kernel projects? Or are all the problems purely in the custom kernel world?
Also, is there anything actually important in Samsung's userspace that i'm missing? It's really just the UI and little extra features for the camera and things right? I can't help but feel the speed gain from an ASOP built would be incredible, all the hardware should work just fine given a working stock kernel?
Thanks!
@eousphoros is working on porting CM right now. Why don't you PM him and see if you can put your heads together on it?
jasonfxp said:
Hi,
Please can someone explain why Exynos has a bad rep for custom ROMs? Samsung release the kernel and I assume it contains either open source drivers or binary blobs. Either way we have a functional boot.img with a working ~3.4 kernel, that kernel should presumably boot any sensible 4.4+ system.img right?
I'm asking because I'm considering building a clean ASOP ROM for the Tab S just to get rid of the crazy amount of bloat. This is obviously trivial with the Nexus device line, but I'm just trying to understand why it's complex in this case? Can we not just use the stock kernel/drivers with any arbitrary userspace e.g ASOP git or CM? Does the SoC really matter to us for non-kernel projects? Or are all the problems purely in the custom kernel world?
Also, is there anything actually important in Samsung's userspace that i'm missing? It's really just the UI and little extra features for the camera and things right? I can't help but feel the speed gain from an ASOP built would be incredible, all the hardware should work just fine given a working stock kernel?
Thanks!
Click to expand...
Click to collapse
The big problem I ran into is with gralloc/hwcomposer. The hwcomposer that ships with the device is 1.3 whereas the opensource is currently only 1.1. While the initial thought of just copying gralloc.exynos5.so hwcomposer.exynos5.so as propertietary blobs seems like it a good one, they are unfortunately linked to a ton of libraries in /system/lib that makes bringing them over troublesome at best. Though that being said that is the hack I used to get my one and only bootable rom up and running.
Going further the issue with the exynoshwc 1.1 that I have been fighting with is after opening up /dev/graphics/fb0 it trys to send it an ioctl that I assume is the S3C_WIN_CONFIG pointer and gets an ENOTTY back from the device. If you are interested in helping out please checkout the cyanogenmod porting thread in general where I have linked my local_manifests.xml with my git repo's and a blog of my progress.
Cheers.
EDIT: Has anyone ever requested source from samsung? What seems to be the most succesfull method?
WARNING:
This is not a post targeted to end users. It is a development reference. If you expect any installable download or even added features out of this thread, please close your browser. Thank you.
What is Umbrella?
Umbrella is a project that aims to make the kernel sources that HMD released for Nokia 8 Sirocco (A1N) compatible with the Nokia 8 (NB1). The idea behind this is to replace the outdated 8.0 kernel sources that HMD released for NB1 with more up to date ones that are used in the 9.0 builds for Nokia 8 Sirocco.
Why do this, you might ask. Well, the answer is simple: The devices are so similar that HMD / FIH already have their kernel sources in a shared source tree. You can validate that yourself, by downloading the kernel config from a stock NB1 kernel (under /proc/config.gz), unpacking it, and searching for the commended entry "CONFIG_FIH_A1N". What umbrella does is take the sources that were released for A1N, readd all device specific files for NB1 (they were pruned) from it's original kernel soure, and integrate the stock kernel config (also called defconf) from NB1.
Doing this also lead to some other small quality of life improvements that are not directly relevant to an end user.
Umbrella contains the latest changes from linux-stable (v4.4.179 at the time of writing, compared to the stock v4.4.153), and Qualcomms Codeaurora upstream
The WiFi driver from Qualcomm is compiled directly into the kernel, instead of being loaded as a module. This allows you to flash umbrella based kernels to every build version while keeping everything else working correctly. The stock kernels use signature enforcement, which means that the wifi module that is loaded from the system partition has to be signed against the kernel, which is not the case for every custom kernel or even the kernels that were built for a different security patch.
Unlike the officially released kernel sources, umbrella does not have stupid typos in it's device trees that cause the phone to display white bars on all of your screen etc.
Umbrella disables the block that FIH put in place to prevent users from rebooting into EDL mode from within android (using adb reboot edl).
Umbrella also includes a patch that causes the device to not reset it's entire memory when the kernel crashes, therefore retaining the last kernel output log, which can be used for debugging
You can compile the kernel with compilers newer than GCC 4.9 (not clang though), without having it immideately crash at boot.
It includes a tool that automatically sets up a crosscompiling environment for the kernel.
What Umbrella is not
Umbrella is not a project to add significant new features, or the ability to tweak things beyond what the stock kernel already offers (which is technically not that bad). It aims to be a reference kernel, a base for (potentially) other kernels that are based on it and add those features. I know that that is kind of a broad goal, considering I am the only one who seems to do actual development for this phone, but who knows. Having a lower entry level might help in case someone is curious and wants to get into kernel hacking. And I would certainly be happy if I wasn't the only one developing for this device.
If you want Umbrella to contain features like:
Overclocking
More governors / schedulers / whatever
Color / Sound / whatever control
Wakelock blocking
etc. etc. etc.
then please Alt-F4 your browser right now. Ok, don't do that but at least please don't request it because it will make you get ignored, nothing else.
Why the name Umbrella?
While I developed the initial prototype I watched through 3 Resident Evil movies, and this is kinda a zombie project, so I think the name fits quite well.
Why are you posting this?
I am posting this because I am hoping that it will be useful for anyone that would like to get into kernel development and tweaking without the hassle that comes with setting up the kernel sources that are released by HMD.
But, one disclaimer: I am not a kernel developer. I am a curious CS student suffering from a bad mix of too much time and stupid ideas that solve stupid problems. I am trying my best to produce something useful and be of help, but please don't expect wonders from me, thanks.
Links?
Source: https://github.com/resident-nokia/umbrella
Download: None, this is a development reference.
Looks promising
Sent from my NB1 using XDA Labs
Nice. this will likely be useful in the future
Updated the umbrella source to the latest 4.4.180 kernel, and May 07 CAF tag (LA.UM.7.4.r1-05100-8x98.0). Also readded some NB1 specific code where it was missing (discovered by doing a diff against the 5140 kernel source that Nokia recently released).
Just in case anyone actually cares about it
THMSP said:
Updated the umbrella source to the latest 4.4.180 kernel, and May 07 CAF tag (LA.UM.7.4.r1-05100-8x98.0). Also readded some NB1 specific code where it was missing (discovered by doing a diff against the 5140 kernel source that Nokia recently released).
Just in case anyone actually cares about it
Click to expand...
Click to collapse
I do. Who knows, in a year's time I might have enough knowledge to build a custom Rom for this phone
Kernel sources which is used on pie has been released officially. Finally, we have an "original" kernel and we've got closed one more step to custom roms.
https://www.nokia.com/phones/en_int/opensource/
techno_man000 said:
Kernel sources which is used on pie has been released officially. Finally, we have an "original" kernel and we've got closed one more step to custom roms.
https://www.nokia.com/phones/en_int/opensource/
Click to expand...
Click to collapse
@THMSP it would be interesting to let us know how different is your kernel mod from the newly released official pie kernel for Nokia 8
MDV106 said:
@THMSP it would be interesting to let us know how different is your kernel mod from the newly released official pie kernel for Nokia 8
Click to expand...
Click to collapse
As I described here: https://forum.xda-developers.com/nokia-8/development/official-source-code-releases-nokia-8-t3930324, they are identical. The only difference are the device tree files (which still contain typos that break the display), and of course all modifications I made to the sirocco kernel source that Umbrella is based on (wifi driver, EDL mode reactivation, upstreaming, etc.)
THMSP said:
As I described here: https://forum.xda-developers.com/nokia-8/development/official-source-code-releases-nokia-8-t3930324, they are identical. The only difference are the device tree files (which still contain typos that break the display), and of course all modifications I made to the sirocco kernel source that Umbrella is based on (wifi driver, EDL mode reactivation, upstreaming, etc.)
Click to expand...
Click to collapse
So, are these new codes broken like 4.84?
techno_man000 said:
So, are these new codes broken like 4.84?
Click to expand...
Click to collapse
I wouldn't call Nokia sources broken, but I would call them incomplete, outdated and impractical to work with. And that hasn't changed.
Iam currently building device tree for nokia 8..
Unable to figure out how to edit init folder specifically for nokia8
[email protected] said:
Iam currently building device tree for nokia 8..
Unable to figure out how to edit init folder specifically for nokia8
Click to expand...
Click to collapse
Please do so! We can't let this phone die so early!
which defconfig file should choose?
lk
[email protected] said:
which defconfig file should choose?
Click to expand...
Click to collapse
nb1_defconfig is for Nokia 8
Can somebody help me? I have built Lineage OS 16.0 for the Nokia 8 with the Umbrella Kernel. However I am facing issues with getting it into work. Firstly TWRP fails to flash it with error 7. I am including the recovery.log file in case anyone wants more detail. I then proceeded to extract the payload.bin file, and flashed boot.img and system.img seperately. However that didnt work either as my phone got stuck at the Bootloader unlocked warning screen. If anyone is interesteed I can upload the .zip outputed by the build
Device Tree: https://github.com/GPUCode/android_device_nokia_nb1
Recovery.log: https://hastebin.com/akohutiwed.sql
Thanks in advanced
emufan4568 said:
Can somebody help me? I have built Lineage OS 16.0 for the Nokia 8 with the Umbrella Kernel. However I am facing issues with getting it into work. Firstly TWRP fails to flash it with error 7. I am including the recovery.log file in case anyone wants more detail. I then proceeded to extract the payload.bin file, and flashed boot.img and system.img seperately. However that didnt work either as my phone got stuck at the Bootloader unlocked warning screen. If anyone is interesteed I can upload the .zip outputed by the build
Device Tree: https://github.com/GPUCode/android_device_nokia_nb1
Recovery.log: https://hastebin.com/akohutiwed.sql
Thanks in advanced
Click to expand...
Click to collapse
hey, did you wipe userdata before flashing this? I think you need to do that, like when switching to using GSIs.
also, have you checked this https://github.com/resident-nokia/twrp? Specifically the fstab file for NB1.
oaid said:
hey, did you wipe userdata before flashing this? I think you need to do that, like when switching to using GSIs.
Click to expand...
Click to collapse
Thanks for the suggestion. I have flashed GSIs before but never had any problems. Also I cannot find any userdata partition in TWRP. I asked in the Lineage OS discord and I was told that probably that TWRP image is broken. I am confused
emufan4568 said:
Thanks for the suggestion. I have flashed GSIs before but never had any problems. Also I cannot find any userdata partition in TWRP. I asked in the Lineage OS discord and I was told that probably that TWRP image is broken. I am confused
Click to expand...
Click to collapse
that's the data partition, if I'm not mistaken ?*
which twrp image are you using? Maybe try Dorian's latest?
oaid said:
that's the data partition, if I'm not mistaken ?*
which twrp image are you using? Maybe try Dorian's latest?
Click to expand...
Click to collapse
Yes I am using the latest TWRP. Before flashing I erased the data partition but still the error persisted