Related
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.
On all roms there is a banding problem due to our screens 65 k colors.
But launcherpro fixes the banding problems on widgets But on some gingerbread roms it does not.
I have not made this fix. But I have tested it on some roms. Im am just sharing this. credit goes to Tytung who took his time and fixed this in his latest 2.5 rom and GPC + other developers that may have found this already.
I have tried it on Tyweens cm7 rom, Tytungs rom and some other. But it "maybe" works on others to? Like gpc's one?
= When using launcher pro with this fix. The launcher will have no banding problems on widgets and on the homescreen. But other banding problems will still be there like it was before.
So without fix ,the clock widget will look like crap in launcher pro in tyweens cm7 rom. But with the fix it will look smooth.
The zip changes the libsurfaceflinger.so.
Flash in cwm.
Thank God, at last! Great stuff
works on tyween cm7.
thank you! this is the main reason i switch some roms lol
will this work on other HD2 NAND roms using launcherpro? like using hyperdroid CM7?
The source code
If you are a developer of source code maker, the following is my fix for banding issue. (NOT Tytung, i don't know how he fix it )
The source code path :
/frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp
Function position:
Code:
sp<Layer> SurfaceFlinger::createNormalSurface(
const sp<Client>& client, DisplayID display,
uint32_t w, uint32_t h, uint32_t flags,
PixelFormat& format)
{
// initialize the surfaces
switch (format) { // TODO: take h/w into account
case PIXEL_FORMAT_TRANSPARENT:
case PIXEL_FORMAT_TRANSLUCENT:
format = PIXEL_FORMAT_RGBA_8888;
break;
case PIXEL_FORMAT_OPAQUE:
//format = PIXEL_FORMAT_RGBX_8888;
format = PIXEL_FORMAT_RGB_565;
break;
}
sp<Layer> layer = new Layer(this, display, client);
status_t err = layer->setBuffers(w, h, format, flags);
if (LIKELY(err != NO_ERROR)) {
LOGE("createNormalSurfaceLocked() failed (%s)", strerror(-err));
layer.clear();
}
return layer;
}
Modified code:
Code:
case PIXEL_FORMAT_OPAQUE:
//format = PIXEL_FORMAT_RGBX_8888;
format = PIXEL_FORMAT_RGB_565;
break;
Reason:
It is caused by the display driver is not match with HD2. The gingerbread has fix it on driver level with new pixel format RGBX_8888, however it is still not working for HD2. So we have to force the default pixel format into RGB565
iamgpc said:
If you are a developer of source code maker, the following is my fix for banding issue. (NOT Tytung, i don't know how he fix it )
skip...
Click to expand...
Click to collapse
I think I need to clarify something.
Gpc sent a private message and asked me how I fixed the color banding issue on 27th March 2011, 09:50 PM.
P.S.: Admin can confirm this.
Because I was busy at that time, I replied his question by only giving him this link including libsurfaceflinger.so.
Then maybe he fixed this issue from the source code by himself, but he really got hints from me.
Let us go back about 20 days ago.
In fact, I tried to solve this color banding issue since 13th March 2011, and I shared my possible method in my thread.
http://forum.xda-developers.com/showpost.php?p=12049180&postcount=2487
When I had time, I released a modified/recompiled libsurfaceflinger.so on 21st March 2011, and requested other users to test it.
http://forum.xda-developers.com/showpost.php?p=12241393&postcount=2846
Then I included this .so file in my v2.5 ROM.
Gpc saw my change log and sent me a private message, and ...
That's the whole story.
what stops this being implemented throughout the UI (i.e. notification bar, buttons etc)?
I'm not getting 3g, only EDGE on this ROM. My APN settings are right and data is definitely on so I don't know what the problem is. I have a T-Mobile HD2 and T-Mobile. Please help.
Tried this fix, and i am truly impressed! No longer banding using ADW Ex and even XDA App! It does not seem to "fix" only launcher pro to me!
EDIT : copilot still has banding though, but not a big deal given the improvements elsewhere!
tytung said:
When I had time, I released a modified/recompiled libsurfaceflinger.so on 21st March 2011, and requested other users to test it.
http://forum.xda-developers.com/showpost.php?p=12241393&postcount=2846.
Click to expand...
Click to collapse
humm,
Do you modify the libsurfaceflinger like mine? Do you compile with BOARD_NO_RGBX_8888 := true to fix this isse?
Because my libsurfaceflinger is changed for my personal using. I also modify somewhere else for my testing, so that I cannot use your libsurfaceflinger.
I don't know what you modify in your source code, so I have to find out the root cause.
According to Google search on "android color banding", you can find a JAVA solution on color banding.
http://stuffthathappens.com/blog/2010/06/04/android-color-banding/
It says the PixelFormat will take effect on banding issue. Take a look on surfaceflinger source code, you can find out the PixelFormat.OPAQUE and PixelFormat.RGBA_8888 will cause the different result.
Finally, you just have to modify the PixelFormat.OPAQUE from RGBX_8888 to RGB_565
iamgpc said:
humm,
Do you modify the libsurfaceflinger like mine? Do you compile with BOARD_NO_RGBX_8888 := true to fix this isse?
Because my libsurfaceflinger is changed for my personal using. I also modify somewhere else for my testing, so that I cannot use your libsurfaceflinger.
I don't know what you modify in your source code, so I have to find out the root cause.
According to Google search on "android color banding", you can find a JAVA solution on color banding.
http://stuffthathappens.com/blog/2010/06/04/android-color-banding/
It says the PixelFormat will take effect on banding issue. Take a look on surfaceflinger source code, you can find out the PixelFormat.OPAQUE and PixelFormat.RGBA_8888 will cause the different result.
Finally, you just have to modify the PixelFormat.OPAQUE from RGBX_8888 to RGB_565
Click to expand...
Click to collapse
Yes, I compiled with BOARD_NO_RGBX_8888 := true to fix this issue.
BTW, you didn't know how I modified my source code because you didn't say that you want to see my modified source code in the private message.
Anyway, I only changed the color support of the config file from RGBX_8888 to RGB_565.
And you don't need to modify SurfaceFlinger.cpp because setting NO_RGBX_8888 in config file is enough.
Below is the detail.
Before Google released Gingerbread OTA 2.3.3, we could only use Froyo OTA's proprietary files to work with Gingerbread source code when we compiled AOSP Gingerbread 2.3.2 or 2.3.1.
And Froyo's proprietary files are not compatible with Gingerbread source code, so we needed to fix the RGB_565 problem by applying the following two commits at that time.
https://github.com/CyanogenMod/andr...mmit/d06cf2371b2db46ab4ecedea832e4c17f3591165
https://github.com/CyanogenMod/andr...mmit/baa078471f4198bd73819794f2713a845305a227
After Google released Gingerbread OTA 2.3.3, we used Gingerbread OTA's proprietary files to work with Gingerbread source code when we compiled AOSP Gingerbread 2.3.3.
At the same time, I removed these two commits above when compiling a new GB 2.3.3 ROM.
That's why hg3atintin (Thanks to him.) told me that my GB 2.3.3 ROM had the color banding issue but my GB 2.3.2 ROM didn't.
Finally, I added back these two commits and compiled a new surfaceflinger.so.
Then the color banding issue is improved.
it fixed my launcherpro , calculator had severe banding but its fixed too
nice job mate
How do I apply this fix to my AmericAndroid SD build? Any help would be appreciated...
P.S. I searched this thread and others and cant figure it out, please point me in the right direx... What is CWM btw because it says to flash with CWM?
How does this banding look like?
edit: sorry wrong thread
nice! gonna try this out
ludetekniq said:
How do I apply this fix to my AmericAndroid SD build? Any help would be appreciated...
P.S. I searched this thread and others and cant figure it out, please point me in the right direx... What is CWM btw because it says to flash with CWM?
Click to expand...
Click to collapse
Hi ludetekniq.
You're in the wrong place. This is NAND development forum and not SD development. You can only install this fix if you have a NAND Rom in your HD2.
EDIT: CWM = Clockworkmod Recovery. It's a tool that we use, to help flashing and recover Roms on NAND.
silly question..lol
what is the banding problem? )
alaaassem said:
silly question..lol
what is the banding problem? )
Click to expand...
Click to collapse
Well... from what I understood, its an issue related to the color depth of HD2 screens. Our HD2 Android is displaying 16 bit color insted of 32 bit because of a driver's issue... it loses quality because it's displaying less colors. With 32 bit you will see a smoother color gradient.
Please devs correct me if i'm wrong!
Cheers from Portugal!
[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
I've been working on getting Ubuntu running on my Sprint Galaxy S3 using the same method I used on my Epic 4G - kexec from recovery loading the root filesystem off a partition on an SD card.
What I've done so far:
* Found a kexec loader to boot into a custom kernel, which is required for booting off an SD card, among other things;
* Compiled a custom kernel with KGSL DRM support enabled for Freedreno;
* Built a minimal Ubuntu 13.10 armhf rootfs and compiled the Freedreno DRM/DDX/Mesa Gallium driver with changes to support the Adreno 225 and stub occlusion query (possibility of full dekstop OpenGL 2.1 support!);
* Got X11 working with USB keyboard, touchscreen, and fbdev. Still working on getting the Freedreno DDX to load.
I still get a kernel oops with the camera driver (http://pastebin.com/egZbxsED), but it apparently doesn't affect stability or cause reboots anymore.
Working so far:
* USB Host - only tested with a keyboard, but other input/storage/audio/video devices should also work.
* Framebuffer console - thanks castrwilliam!
* Touchscreen works with X.org fbdev driver and the following added to /usr/share/X11/xorg.conf.d/11-evdev-quirks.conf:
Code:
Section InputClass
Identifier "Touchscreen"
Driver "evdev"
MatchProduct "sec_touchscreen"
EndSection
* Power and volume buttons
Untested:
* Bluetooth - might need firmware
* Sensors - should work just fine
* Home, menu and back buttons should work but probably need mapping
Unlikely to work due to proprietary Android-only blobs:
* Camera
Kernel config changes:
# IMPORTANT: remove the line that says "depends on !MSM_KGSL_DRM" from drivers/gpu/msm/Kconfig:70
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_VT_CONSOLE=y
CONFIG_DRM=y
CONFIG_MSM_KGSL_DRM=y
I may eventually post a pre-built kernel, but if you don't know how to compile a kernel from source, this guide is not for you.
Likewise, if you don't know how to prepare an armhf Ubuntu root filesystem, this guide won't help much.
After building the kernel, copy arch/arm/boot/zImage to your SD card along with the attached zImage.zip (CWM-flashable kexec loader).
It might need modifications (META-INF/com/google/android/updater-script) depending on how you have your card set up.
UPDATE: Unfortunately, this phone hasn't been a good fit for me. I never got very far booting Ubuntu or Freedreno, so I decided to sell it.
For anyone still interested in this project, I believe castrwilliam has the required patches.
When I get my next Snapdragon device (either the new Nexus 7, a Nexus 4, a Galaxy S4, or another phone with Adreno 320 graphics), I will post the Mesa patches for occlusion query support. Sorry I wasn't more helpful with this device.
Added to favourites, I'll see what I can do with it over the weekend
Sent from my SPH-L710 using Tapatalk 4 Beta
Great work. Good luck debugging.
Sent from my SPH-L710 using xda app-developers app
Maybe taking a look at how Motorola worked Ubuntu, in a way, with Webtop that came on the Photon. The Photon has the integrated Ubuntu-based 'Webtop' application from Motorola. The Webtop application is launched when the phone is connnected to the external display through Laptop dock or HD multimedia dock. In Webtop mode, offering similar user interface of typical Ubuntu desktop, the phone can run several applications on external display such as Firefox web browser, SNS clients and 'mobile view' application enabling total access of the Photon and its screen. In September 2011, Motorola released the source code of Webtop application at SourceForge.
I know it's not an app you're trying to use but it may help in finding how to work some of the kinks you have. I hope that helps
Hi, I'm the person maintaining Ubuntu currently for HP Touchpad (http://forum.xda-developers.com/showthread.php?t=2225462) (which also uses an MSM SOC.) It's starting to show its age... I'm trying to get this to where you have it currently on a Verizon S3 / d2vzw (obviously, kexec'ing into a Verizon kernel instead.) Maybe we could collaborate?
Currently I have the KT747 kernel (kexec host support as well as guest) (compiled as a zImage. If you can provide me with access to the patches you have for freedreno and hopefully also an initramfs image (I'm going to mod the HPTP rootfs, so no need there)... I'd love it.
My only modifications to the kernel so far are the ones I mentioned in the OP and three of Rob Clark's Freedreno commits from the mako-kernel branch of kernel-msm on his GitHub - namely, "kgsl: drm: remove checking on 'active'", "video/msm: add true ARGB", and "kgsl: fix null ptr on cache flush".
At one point I had X11 working with freedreno displaying the GNOME background, but the screen blanked after 10 seconds and I couldn't recover from that. Unfortunately, after experimenting with different kernel config options, I lost that semi-working configuration and the GPU started to page fault, sometimes displaying a corrupted screen and sometimes rebooting before displaying anything.
Believe me, I've been working on this for weeks, and it's very frustrating that it doesn't even sort of work. My minimal modifications to Mesa to get it to recognize the Adreno 225 are highly unlikely to be the cause of the problems, and I highly doubt the differences between the 220 and 225 are to blame since it was working at one point. It's a one liner, figured out from from freedreno/mesa issue #2.
Castrwilliam, the initramfs is the least of your worries. I don't use one, since its only function is to display the Plymouth splash, which doesn't work anyway.
gTan64 said:
...
Castrwilliam, the initramfs is the least of your worries. I don't use one, since its only function is to display the Plymouth splash, which doesn't work anyway.
Click to expand...
Click to collapse
Yeah, I realized how you were doing this after looking at the kexec script. I was trying to boot from Android, not recovery, and was under the impression you had put a disk image on external SD, and then made the initramfs loop-mount that and boot from it... but now I see you partitioned it.
It's a shame you don't have your original config, I'll try to get it booting again on my end. I remember doing something like this a while back, where I made like 10 differently configured kernels at once, and tested them each in turn. I imagine the ramconsole would help a good bit so that I could look a how far we're getting. (The touchpad has its own version of that, which you can read directly from the bootloader (bootie.) Then again, it also has LVM volumes for storage instead of actual partitions (except for boot) - which makes it uber easy to boot lots of OSes.)
Currently I'm not doing too well. I remember that kexec did work at one point on d2vzw hardware but I'm assuming that it still does now (new bootloaders, 3.4 kernels, ...) I do kexec -e, the reboot happens, I see the Samsung bootloader screen, then the screen blanks for like 5 seconds and it reboots again - back into android.
castrwilliam said:
I imagine the ramconsole would help a good bit so that I could look a how far we're getting...
the screen blanks for like 5 seconds and it reboots again - back into android.
Click to expand...
Click to collapse
The RAM console should be enabled by default, so check /proc/last_kmsg once Android boots back up.
It could be something simple like the root filesystem not mounting, either due to how you partitioned the card or not having time to settle, hence rootwait. Or it could be something else. I haven't gotten any useful output in /proc/last_kmsg with the framebuffer console enabled, so make sure that's disabled unless you want a headache and a psychiatrist visit.
Unfortunately, I've spent way too much energy trying to debug the GPU page fault, and I probably won't have much time to work on it after next month. I want this bug dead and forgotten, so more eyes would be great!
X11 works (shows something on screen) with the X.org "fbdev" driver. I can't reproduce anything with "freedreno" (or "modesetting", which I accidentally loaded at one point...)
The touch screen doesn't respond, but the power key works and brings up a shutdown dialog.
Screenshot attached. I used the 13.04 Touchpad rootfs with some modifications...
Okay, you can get the fbcon working by either loading it as a module during boot OR changing its "module_init" macro in drivers/video/console/fbcon.c to "late_initcall".
Picture attached. Sorry for blurriness, I don't have an actual digital camera, only what's on my sig. This should make debugging a bit easier.
Nice to see some more freedreno development on android phones
I'm using freedreno with a slightly different approach, starting it directly from android on a chrooted shell, which is a lot more easier to debug.
The kernel needs some fixes from the mako branch and the following configs:
Code:
CONFIG_DEVTMPFS=y
CONFIG_VT=y
CONFIG_DRM=y
CONFIG_MSM_KGSL_2D=y
CONFIG_MSM_KGSL_DRM=y
Rob Clark (the maintainer of freedreno) has been working on his own kernel driver for adreno gpu:
https://github.com/freedreno/kernel-msm/commits/ifc6410-drm
This would be a nice addition/replacement for the current qualcomm gpu driver.
Wootever said:
Nice to see some more freedreno development on android phones
I'm using freedreno with a slightly different approach, starting it directly from android on a chrooted shell, which is a lot more easier to debug.
The kernel needs some fixes from the mako branch and the following configs:
Code:
CONFIG_DEVTMPFS=y
CONFIG_VT=y
CONFIG_DRM=y
CONFIG_MSM_KGSL_2D=y
CONFIG_MSM_KGSL_DRM=y
Rob Clark (the maintainer of freedreno) has been working on his own kernel driver for adreno gpu:
https://github.com/freedreno/kernel-msm/commits/ifc6410-drm
This would be a nice addition/replacement for the current qualcomm gpu driver.
Click to expand...
Click to collapse
How do you stop the SurfaceFlinger (I think that's proper terminology) from hogging the framebuffer?
Semi Working Freedreno/X11
castrwilliam said:
How do you stop the SurfaceFlinger (I think that's proper terminology) from hogging the framebuffer?
Click to expand...
Click to collapse
HEY, look what I did?!
(There are a lot of patches req'd to get this far. Even at this point, there's a weird bug where the cursor loops across the edge of the screen and windows overlap themselves. If you want to know, I'll elaborate in a further post, otherwise, let's get that touchscreen working for release!)
Thanks to Rob Clark (again, the author of freedreno) who helped me get this far on his IRC channel at Freenode.
castrwilliam said:
HEY, look what I did?!
(There are a lot of patches req'd to get this far. Even at this point, there's a weird bug where the cursor loops across the edge of the screen and windows overlap themselves. If you want to know, I'll elaborate in a further post, otherwise, let's get that touchscreen working for release!)
Thanks to Rob Clark (again, the author of freedreno) who helped me get this far on his IRC channel at Freenode.
Click to expand...
Click to collapse
Are we keeping track of all the necessary patches? I'm on https://github.com/CyanogenMod/android_kernel_samsung_d2, branch cm-10.2_kgsl, with the per-process pagetable hack, the "active" kgsl_drm fix, Adreno 225 case in Mesa (freedreno_screen.c), and my stub occlusion query hack. I wasn't on #freedreno when Rob Clark pointed out the libdrm bug I heard about from the Wiki - did you fix that? I'm still getting the assert crashes.
I'll be on #freedreno at some point tomorrow.
gTan64 said:
Are we keeping track of all the necessary patches? I'm on https://github.com/CyanogenMod/android_kernel_samsung_d2, branch cm-10.2_kgsl, with the per-process pagetable hack, the "active" kgsl_drm fix, Adreno 225 case in Mesa (freedreno_screen.c), and my stub occlusion query hack. I wasn't on #freedreno when Rob Clark pointed out the libdrm bug I heard about from the Wiki - did you fix that? I'm still getting the assert crashes.
I'll be on #freedreno at some point tomorrow.
Click to expand...
Click to collapse
I got this to work by using a fairly old libdrm, but a new DDX (xf86-video-freedreno). I haven't fixed the assert bug on the newer ones.
You need to patch the DDX's msm-device.c to set the width to 736 (has to be a multiple of 32), and then disable/comment out/delete where it calls the mode-set function (there's a comment about making xrandr happy in the right place.) I can make a patch soon, but I have a feeling that this is what made the other bug happen with the looping cursor.
edit -- I fixed the looping cursor. A patch is attached...
Youtube video of it working: http://www.youtube.com/watch?v=rh9wmmYuKxY
Tips:
Set the firnware path for the dhd (wi-fi) driver to /system/etc/wifi/bcmdhd_sta.bin (WITHOUT the _b2 buffix, it will be added by the module). Set the nvram file to /system/etc/wifi/nvram_net.txt. Then, add the Android partitions to the /etc/fstab (mmcblk0p14 is system.)
apt-get install xserver-xorg-input-multitouch and then add a config file under /usr/share/X11/xorg.conf.d/ to get the touchscreen working. It will act like a laptop trackpad. You MUST use the multitouch driver. "evdev" will segfault the server on any touch. Note that you can match the TS in an InputClass with its udev name, "sec_touchscreen".
The date that I compiled the working Freedreno libdrm was the date that Ubuntu 13.04 was released. I'm working on narrowing it down to a Git SHA1 revision. I used Rob Clark's repository, not the freedesktop one.
Use the master branch of the DDX, sorry for the earlier confusion.
For battery savings, you might want to cherry pick the DPMS commit from the a3xx branch of the DDX.
castrwilliam said:
How do you stop the SurfaceFlinger (I think that's proper terminology) from hogging the framebuffer?
Click to expand...
Click to collapse
There are two binaries you can execute with adb shell stop/start that kills and restart the android proccesses, allowing access to the framebuffer.
Okay, so 2-D does work with my mods, but I just tried 3-D last night (ran es2gears with the Adreno 225 mod in place on mesa) and the pagefaults returned.
I did notice something about your pagefault reboots, though: they shouldn't necessarily be happening, it's a NULL pointer dereference that can be fixed in the handler by doing this in drivers/gpu/msm/kgsl_iommu.c (function is kgsl_iommu_fault_handler):
Change
Code:
curr_context->pagefault = 1;
curr_context->pagefault_ts = curr_global_ts;
To:
Code:
if (curr_context) {
curr_context->pagefault = 1;
curr_context->pagefault_ts = curr_global_ts;
}
So anyone got any updates for this if not i will start building upon what is there if it is ok
Sent from my SCH-S960L using xda premium
allenjthomsen said:
So anyone got any updates for this if not i will start building upon what is there if it is ok
Sent from my SCH-S960L using xda premium
Click to expand...
Click to collapse
I guess it is OK. Hopefully you can make a dent in this development. Keeping my eye on this thread.
No longer developing for this phone
Unfortunately, this phone hasn't been a good fit for me. I never got very far booting Ubuntu or Freedreno, so I decided to sell it.
For anyone still interested in this project, I believe castrwilliam has the required patches.
When I get my next Snapdragon device (either the new Nexus 7, a Nexus 4, a Galaxy S4, or another phone with Adreno 320 graphics), I will post the Mesa patches for occlusion query support.
I'm posting this now and hope in doing so some new input can be reached. Due to recent new and old exploits we need this, I have hardened the kernel some, from CopperheadOS, and put in place full "Harden usercopy", updated it to 3.10.108, and before I go any further in breaking the kernel i release this WIP. I refer to this post ( https://forum.xda-developers.com/showpost.php?p=80265757&postcount=50 ) for the current state of mobile calls etc.
Fastboot images:
190919: https://drive.google.com/open?id=1OAzYc_D_FHbbmIyFiSVtGLolB2EfiE40
290819: https://drive.google.com/open?id=1d8FNiFlMN6Bey6xD606pBomqBgSiZ-MO
Features:
OS Version: 8.1.0 Oreo
Kernel: Linux 3.10.108
Important informations:
You should be familiar with general installation of custom roms.
Required for installation: fastboot
This ROM needs a clean install, old /data may cause problems!
Working:
WIFI
Bluetooth
OTG-USB
NFC
These things are NOT working.
Camera; is not included due to inconsistency in the build currently. But failed to connect to the camera last time it did.
GSM; this will require reworking some android code, making some progress i think.
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf8internal20RepeatedPtrFieldBase4SwapEPS2_" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
FM-Radio (not included)
GPS
Bugs:
Installing apps freeze the phone for a while.
Basically, this release needs help.
Source:
https://github.com/threader/local_manifests
https://github.com/threader/kernel
https://github.com/threader/android_device_sony_sumire
https://github.com/threader/android_device_sony_kitakami-common
Patch for external/protobuf attached to this thread.
Modified libcneapiclient.so attached.
Credits:
Everyone involved with the Sony-msm8994 project ( https://github.com/sony-msm8994/android_device_sony_kitakami-common/commits/lineage-15.1 )
Mr. Open devices "jerpelea", for actually answering some of my stupid questions I should have realized myself.
Berni-0815 for trying to do this for the z5c and leaving useful resources.
And everyone posting and following the Guide to port to Lineage-16.0 thread by algui91 (https://forum.xda-developers.com/xperia-z5/general/guide-to-port-to-lineage-16-0-t3931428) and willing to participate, this is a community effort after all.
Please don't quote this thread, I will edit it as I release new builds and make progress.
I was unsuccessful in building a flashable zip image first time I tried some moons ago, I don't know if this was due to the need of a TWRP update or just my half arsed attempt, I would appreciate if someone could direct me to correctly doing so.
Cheers
How can i help including the fact that i am nearly noob in Linux / Unix and havent built any custom ROM at the moment?
DP
threader said:
BuzzerHead.
Click to expand...
Click to collapse
let me think on that, but there are two things that's needed, a libcneapiclient.so that is msm8996 perhaps and for Android 8.x, maybe we can decompile and figure out the differences. And a Qualcomm trust zone from from maybe 8996 to hack and plug the holes. I'm still reading up.on this though but if you Google "chipsec Qualcomm trust zone" or indeed just the first results for " Qualcomm trust zone" you certainly see the problem ( https://blog.quarkslab.com/introduction-to-trusted-execution-environment-arms-trustzone.html , https://www.blackhat.com/docs/us-14/materials/us-14-Rosenberg-Reflections-on-Trusting-TrustZone.pdf )
I'm re-working the external/protobuf modifications just now as I think that is why the bug i listes occurred.
Edit:
Right, great, after unhacking the hacks and returning the protobuf API to its original state I'm stuck an error before the quite impossible error i had earlier, so this is not going as quickly as i thought, either.
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io17CodedOutputStream13WriteVarint32Ej" referenced by "/system/vendor/lib64/libcneapiclient.so"..
This is a clearly defined symbol already but perhaps not behaving as intended and an error my previous attempt somehow worked around.
The following might be the reason it hangs during package install though;
Code:
09-16 18:46:55.875 865 956 W SchedPolicy: add_tid_to_cgroup failed to write '1947' (Permission denied); fd=3
09-16 18:46:38.393 865 1126 W NativeCrashListener: Couldn't find ProcessRecord for pid 2958
Any news?
Is this project dead? Seeing a newer version of LOS on this device would be nice.
Sent from my SM-T580 using XDA Labs
TALUAtXDA said:
Is this project dead? Seeing a newer version of LOS on this device would be nice.
Sent from my SM-T580 using XDA Labs
Click to expand...
Click to collapse
It's resting... My life up ended and screwed my peace and tranquility, I simply have not had the time to look at it, I'm having a look now as long as the peace lasts.
I see there is a 10.0 now, with some collaboration maybe we can get this all working, I argued a lot with the vendor libs, i just need to get a grip on what's going on there with the other project. As far as i can tell quickly looking at it I can merge some of those changes to the unified kernel 3.10.108 I'm using and see how things go, It will take a some time to get going again. As far as the kernel goes I ought get it up to 3.12, there are some pagetable ioslation patches that are required for safe operation etc, but I paused kernel work until i could get Android in shape, then life happened....