look im a n00b(still learning android stuff),
so this question is just out of curosity
why cant we have kernel 2.6.32 ??
well google said froyo needs atleast 2.6.32 to run
but we here are running gingerbread smoothly on 2.6.29(thnaks to all the awsoms devs )
can someone knowledgble reply
thank you ;p
Simply because the kernel drivers needed for the X8 only exist in Linux 2.6.29 as published by Sony Ericsson.
If you would want to use a newer Kernel release (i.e. the ones Google is using for their Android builds) you need to port the drivers to that kernel version - read: make them fit the kernel.
That's a very tedious process, so it's easier for the ROM and Kernel developers to base their work upon the original SEMC Linux 2.6.29 sources.
on short: its easier to port drivers from 2.6.32 or 35 or 38 than make the base 2.6.32.... working on our phone
as b.jay said, porting kernels takes a long time, and if you recive only a couple of errors in the middle of it, BOOM, you gotta go back to the sart and track what wrong command you typed or what code is wrong etc. thats why no one has ported 2.6.32 kernel.
to many drivers to cope with, to much errors that you will recive. porting roms is easyer
thanks guyz for the answers....in short it is possible to have kernel 2.6.32....maybe nAa can port it....he has already backported some stuff.
It is possibe given someone wants to spend an insane amount of time (edit: we're talking several weeks to several months here) in forward-porting the Shakira specific drivers and additions to the ARM Linux code base.
I don't see it happen as it's a enormous undertaking for a single developer to port the whole stuff - that would require a medium-sized team of coders a) knowing what to port / b) well versed in Linux Kernel hacking / c) knowing how to code for ARM (edit: as the existing sources most likely need to be adapted to the Kernel ABI (in this case 2.6.3.x), which is not exactly stable in Linux and changes erratically as Linus' maintainers see fit. Also, don't forget that the changes need to be tested to see if the kernel boots and works flawlessly).
Don't hang your hopes too high.
need to much time to update linux version of kernel
But for instance lg optimus p350 has almost same specs but runs .32 kernel.it has same qualcomm 600 mhz cpu,ardeno 200,and 140 mb ram.so x8 has even better specs.so i dont se why this wouldnt be possible.
Sent from my GT-I5800 using xda premium
Since nobody seems to check the Q&A forum [Q] Kernel compiled in Ubuntu 12.04 fails
So i havent worked on a kernel in a while and decided id start workin on one again. Well I recently updated to 12.04 lts and no changes to my old source I just did a test compile and it wont boot. Same toolchain, source, ramdisk, etc.
Is there some sort of issue with compiling on 12.04?
Even redownloaded the source from my github and tried the toolchain recommended by samsung, stock tool chain, and 3 others and i still get nuthin. Just trying to compile a 2.2 kernel for the vibrant. No source i download works am i missing something?
does ANYONE have any ideas? I dont care who you are just something! I been at this for a freakin week and cant figure it out, ......i've changed nuthing but the OS and i really dont want to have to redo my entire setup because it is such a huge pain
Are you sure the kernel works? What is causing it to not boot?
I build ICS kernels just fine.
Check this and update tools for 12.04 http://source.android.com/source/initializing.html
trailblazerz11 said:
Are you sure the kernel works? What is causing it to not boot?
I build ICS kernels just fine.
Check this and update tools for 12.04 http://source.android.com/source/initializing.html
Click to expand...
Click to collapse
100% sure it works, its the same source as my old nightly# 3 kernel which i can flash and works fine. Its a 2.2 kernel so thatd be the main diff there, and I've already done the setup of the build environment. I dont get past the vibrant logo so i have no idea what the problem is >.< its driving me nuts
i tried the linaro TC, 2 diff code sourcery, google toolchain even, and no luck
I even started a fresh kernel from scratch and added just the EXT4/voodoo stuff and my ramdisk and still nuthin
so i remade my voodoo ramdisk and that still doesnt work.
I'm out of ideas, I've quadruple checked to make sure all my tools and erthing are installed......idk what the issue is
Not a developer but wouldn't downgrading to an older Ubuntu fix the problem? Btw I loved your gingerbread kernels and I hope you can get back to the top again Aim for 400mb ram with 720p and you will achieve something high
helikido said:
Not a developer but wouldn't downgrading to an older Ubuntu fix the problem? Btw I loved your gingerbread kernels and I hope you can get back to the top again Aim for 400mb ram with 720p and you will achieve something high
Click to expand...
Click to collapse
Id rather not but it seems that might be the case -_- I gotta look into how well older versions of ubuntu suppport the BullDozer cores before i do i guess.....
also I only made GB kernels for the NS4g i think ? o .o Vibrant I had been workin on it but I like being able to have MSAA in my games and what felt like greater stability, so i scrapt the new projects in favor of specific features i use :3
Ecotox I really wish you or another dev could make an updated CM7.2 kernel with Voodoo Color, OC/UV, and performance tweaks since Glitch is outdated and probably won't be updated for CM7.2. I know most devs have gone to ICS kernels, but CM 7.2 is still snappier and better for gaming then ICS.
hurtz777 said:
Ecotox I really wish you or another dev could make an updated CM7.2 kernel with Voodoo Color, OC/UV, and performance tweaks since Glitch is outdated and probably won't be updated for CM7.2. I know most devs have gone to ICS kernels, but CM 7.2 is still snappier and better for gaming then ICS.
Click to expand...
Click to collapse
I've been gone working on a game project, so I really haven't been doing much android stuff in months. If I get some time I might but can't make promises. Don't take this the wrong way but I'm looking for some help if anyone has any ideas not requests or compliments on previous work (though both are appreciated)
Sent from my Galaxy Nexus using Tapatalk 2
Can you use windows xp to compile kernels?
helikido said:
Can you use windows xp to compile kernels?
Click to expand...
Click to collapse
no
10 char
No but ty for the try....looks like imma have to revert back to 11.10...so let it be known for best results on compiling android use Ubuntu 11. If u have Ubuntu 12 and it works fine then leave it and good for u
Sent from my Nexus S 4G using Tapatalk 2
Hey there! Try downgrading gcc and g++ to version 4.4. If that doesn't work you can always just set up a dev VM in xen or vmware instead of blowing away the whole box. Hope that helps.
[INFO] Android 4.3 JSS15J&JSS15Q vs. JWR66V&JWR66Y, Custom Kernels and Graphic Issues
So, since this issue pops up often in various threads ever since 4.3 was released, I thought I'd make a thread I could point people to instead of repeating the same explanation over and over.
This has been discussed greatly in various Kernel/ROM development threads and I've been even getting PM's about it so I'll try explaining everything here. Most info is taken from discussions made on CyanogenMod-related threads, Franco kernel thread, thracemerin's WiFi-fix thread, and Google-related sources, so thanks also goes to everyone who participated.
On to business...
Background:
When Google released Android 4.3, it came in a few forms. One is the familiar OTA update zip and factory images. This is what people refer to as 'stock'. The build number for that stock release is JWR66V, also known as Android 4.3r1. This was later updated to JWR66Y (Android 4.3r1.1).
As you all know, Android is open source, which leads us to the Android Open Source Project (AOSP). This is where the source for Android located, and one could build the operating system/kernel (with provided drivers) from scratch and make a working flashable operating system. This is also the 'base' for custom ROMs.
AOSP has newer android revisions - Android 4.3r2.1, build number JSS15J, and Android 4.3r2.2, build number JSS15Q. These builds are newer than 'stock' JWR66V/JWR66Y, but they are official, are made by Google, and are available for anyone to build from scratch, just like JWR66V/JWR66Y. The differences are Google Apps, such as Google+, YouTube, Gmail, etc, which will not be included in an AOSP build, but could be downloaded from the store (or available as a flashable zip) anyway. AOSP also has a different browser while 'stock' comes with Google Chrome (which you could manually download if you wanted to). The system itself is still the same Android. If one decides to build Android from the older JWR66V/JWR66Y revisions, they will have the same system as someone else who flashed stock.
Why didn't Google release JSS15J as stock?
A Google employee mistakenly thought that JSS15J only has changes related exclusively to the new Nexus 7 device. He later apologized and acknowledged his mistake. JSS15J has an updated Nexus 4 kernel with dozens of GPU commits/improvements.
Which build is better?
Depending on who you ask. If newer is better, JSS15Q is better. If factory images are better, JWR66Y is better.
Which build should I use?
People who like factory images will stay with factory images. People who like the stock experience but care less about "factory images" could use a clean non-customized JSS15Q build. In a way, JSS15Q could be considered 'stock AOSP' if it's not customized. It's even more minimalistic than what comes with the factory images, because applications such as Google Keep/Earth/Maps and so on are not forced as system apps, and can be optionally installed from the store only if you want them.
Any other differences besides the updated kernel/GPU commits?
Most changes are under-the-hood. There was an updated network setting found in JSS15J/Q that doesn't exist in JWR66V/Y.
I heard something about a Wi-Fi change though?
There is indeed a major difference related to Wi-Fi. I won't get into many details here as there is a dedicated thread with months of discussions, but in short, JWR66V & JWR66Y still have the Wi-Fi notification delay issue that 4.2.2 had. This is because Google turned off ARP offloading for those builds, but later turned it on in JSS15J & JSS15Q. It was also on in JWR66N, the leaked unofficial build that we got prior to the official release.
If Google were to build a new factory images now from JSS15Q, it would have ARP offloading on, and Wi-Fi notification delays fixed. The change is only to an .ini file and the drivers are the same, so while a fix is needed for JWR66V/JWR66Y, it's a simpler fix. If you use JSS15Q you don't have to flash any Wi-Fi fixes at all.
What does this mean for Custom ROMs?
Custom ROMs are usually synced with the latest AOSP revisions and changes. CyanogenMod's Android build is JSS15Q, and the same goes for rasbeanjelly, Carbon, and most custom ROMs. Clean or clean-ish JSS15Q AOSP builds are also available for those who still want both the newest revision and the stock experience, just check the development threads.
HELP! My screen is stuttering and/or has weird green colors and/or doesn't respond properly to touch and/or is yelling at me!
That is mostly why this thread was needed. As mentioned before, JSS15J&JSS15Q have an updated kernel with some GPU fixes. This means that your kernel MUST match your ROM for the issue to go away. There are workarounds, such as disabling hardware overlays, but that is not really a solution. No hardware overlays = reduced performance and possibly other issues.
The basic rule is this:
If you use JWR66V/JWR66Y, either stay with its stock kernel, or MAKE SURE the custom kernel you flash was based on JWR sources.
If you use JSS15J/JSS15Q, either stay with its stock kernel, or MAKE SURE the custom kernel you flash was based on JSS sources.
This is of course a headache for kernel developers, as they need to either drop support for one version, or release two versions each time. Many kernel developers are already offering two version of their kernels - one for JWR-based builds and one for JSS-builds.
This means that if you use the AOSP build or most custom ROMs, you will have the screen issues if you use JWR-based kernels.
So there you have it. Unless some other solution is found, there will have to be 2 kernels - one for each build.
Well done
Wayne Tech Nexus
Anyone have links to a pure AOSP build with literally no alterations?
Sent from my Nexus 4 using Tapatalk 4 Beta
jaju123 said:
Anyone have links to a pure AOSP build with literally no alterations?
Click to expand...
Click to collapse
There are two I know of, they do have some very slight changes you could read about in their threads, I don't know of one with literally zero alterations whatsoever, but again the changes are very minor:
[ROM][JSS15J] aosp 4.3 for Nexus 4
[ROM][28/07/2013] AOSP JSS15J KALO v3.0
Cheers for the clear up, was doing my head in with all the weird builds
Sent from my Nexus 4 using Tapatalk 4 Beta
Is there any way we can (nicely) ask Google to release a factory image from the JSS build? I think that would be the perfect solution, and I don't think it is really too hard for them to push it.
redsmith said:
Is there any way we can (nicely) ask Google to release a factory image from the JSS build? I think that would be the perfect solution, and I don't think it is really too hard for them to push it.
Click to expand...
Click to collapse
They could definitely do it if they wanted to, probably somewhat easily too. The OTA is being pushed slowly for a reason - not just for bandwidth purposes, but so that if some mistake happened, not all devices would be affected. It's probably not a very high priority for them like what happened previously with the December bug, but they could release a JSS15J-from-JDQ39 OTA to devices that haven't been updated yet, and JSS15J-from-JWR6V for those who did update. Posting factory images is easier, and the binaries are already good for both JWR6V and JSS15J. If they chose to release it, we'd forget about this whole thing 1-2 weeks later. But it's hard to say if they'll listen. Might be worth a try as long as it's done in nice/acceptable ways and not by spamming/yelling/threatening and so on.
They won't release new factory images...
Jean-Baptiste Queru said so...
He said both branchs are the same with the only difference in JSS15J being the new stuff for Nexus 7...
The new GPU commits are from the other branch... So that both matchs and don't give tearing effects or other problems...
Enviado do meu Nexus 4
He had some update statements since. Here they are:
In theory, JSS15J should work just as well as JWR66V for the existing devices. In practice, I expect that there could be minor differences (except for the new Nexus 7 where there are big differences), so if you're targeting a single device you might as well use the source code that matches the retail version the most. Personally, I like to live more on the bleeding edge, so when I carry an AOSP device I'm more likely to be running the master branch.
Click to expand...
Click to collapse
Here's an long-ish explanation of what happened:
-For a number of reasons, the kernel is built separately from the Android tree. We submit binaries of the kernel in the Android tree.
-Those binaries are large. In Google's internal tree, there are 1.5GB of Nexus 4 kernel binaries. With the way our tools work, that's 1.5GB of data that needs to be downloaded and stored by each user in each source tree. At the same time, the binaries don't have any significant value, since the value is in the source history, which is stored separately.
-To avoid making every AOSP user download gigabytes of unnecessary kernel binaries, starting with Nexus 4 (and now also in the new Nexus 7), we've been storing kernel binaries in dedicated projects, and I maintain a parallel history for AOSP that only contains the binaries that are necessary. Right now for Nexus 4, that tree is 31MB (to compare to 1.5GB).
-The retail release process of a new version is actually different for existing devices and for the new Nexus 7. To better reflect that, they each got their release branch, with existing devices in the JW branch (jb-mr2-release) and the new Nexus 7 in the JS branch (jb-mr2.0-release). JW entered final stabilization earlier than JS, which means that the jb-mr2-dev branch and the master branch in AOSP are closer to JS than to JW.
-To save space in the AOSP kernel projects, I try to have as few kernel binaries as possible in there, which means that I prepare those branches at the last minute (in this case I did that on Monday). During testing, I don't stage those projects and I manually use kernels directly from the development branches. For Nexus 4, when I did the final staging on Monday, I only included into the AOSP what ships to end users, i.e. from the JW branch, so I explicitly didn't include the kernel from the JS branch and I used the kernel from JW everywhere instead.
-Since the only changes in JS (compared to JW) were supposed to be related to the new devices, I assumed that the N4 kernel would be the same between the two (without actually checking), and I did all my testing of jb-mr2.0-release, jb-mr2-dev and master with the JS kernel (which was easier as it allowed me to use the same process for Nexus 4 and for the new Nexus 7). One of the changes done for the new devices was in the GPU code, in a way that required a new kernel for Nexus 4.
-The fix was to add the JS kernel to the relevant branches in AOSP.
So, there you have it: I mistakenly assumed there there'd be no kernel changes for N4 between JW and JS, and from there I did all my testing with the wrong kernel.
Sorry about that.
JBQ
Click to expand...
Click to collapse
markd0wn said:
He had some update statements since. Here they are:
Click to expand...
Click to collapse
So peolple who are on stock are outdated and still not enjoying all the gpu optizations?
Correct me if im wrong
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
C4SCA said:
So peolple who are on stock are outdated and still not enjoying all the gpu optizations?
Correct me if im wrong
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
Click to expand...
Click to collapse
Technically you are not wrong. It's a fact that JSS15J and its kernel has GPU optimizations/commits that are not included in the JWR66V build.
markd0wn said:
Technically you are not wrong. It's a fact that JSS15J and its kernel has GPU optimizations/commits that are not included in the JWR66V build.
Click to expand...
Click to collapse
So this 4.3 update is a huge fail for nexus 4 owners... And i was thinking that i wasnt going root it again...
Google messed up this time
4.3 is almost all about the gpu opt. and now people dont have it all on stock? ? ?
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
C4SCA said:
So this 4.3 update is a huge fail for nexus 4 owners... And i was thinking that i wasnt going root it again...
Google messed up this time
4.3 is almost all about the gpu opt. and now people dont have it all on stock? ? ?
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
Click to expand...
Click to collapse
I don't know how huge those optimizations are. I'm sure someone will do some GPU-specific benchmark comparison between the builds at some point and see. But yes, a mistake did occur. The average person will be updated to JWR66V (at least at this point) only. Others could install JSS15J manually from one of the threads mentioned in the previous page.
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
markd0wn said:
They could definitely do it if they wanted to, probably somewhat easily too. The OTA is being pushed slowly for a reason - not just for bandwidth purposes, but so that if some mistake happened, not all devices would be affected. It's probably not a very high priority for them like what happened previously with the December bug, but they could release a JSS15J-from-JDQ39 OTA to devices that haven't been updated yet, and JSS15J-from-JWR6V for those who did update. Posting factory images is easier, and the binaries are already good for both JWR6V and JSS15J. If they chose to release it, we'd forget about this whole thing 1-2 weeks later. But it's hard to say if they'll listen. Might be worth a try as long as it's done in nice/acceptable ways and not by spamming/yelling/threatening and so on.
Click to expand...
Click to collapse
Agreed. Any way we can contact them? Maybe in their support pages? I'm kind of lost here =D
We should definitely give it a try, we've got nothing to lose.
Why I can't boot into recovery?
I flashed factory image JWR few days ago, everything was good until today I just realized that I cannot boot into stock recovery. Everytime I enter bootloader and select recovery I only get dead android image with red exclamation mark.
Anybody experience this too?
Wonderful! I've been looking for somerthing since 25/07!
Thanks!!
simorangkir_dcs said:
I flashed factory image JWR few days ago, everything was good until today I just realized that I cannot boot into stock recovery. Everytime I enter bootloader and select recovery I only get dead android image with red exclamation mark.
Anybody experience this too?
Click to expand...
Click to collapse
Hold volume up + down and press the power button (may have to do it a few times). The stock recovery has its options hidden unless you press that combination once you get to the screen you are seeing.
Sent from my Nexus 4 using Tapatalk 4 Beta
mattkroeder said:
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
Click to expand...
Click to collapse
Can someone confirm this?
mattkroeder said:
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
Click to expand...
Click to collapse
Same too ,i feel stock smoother than AOSP .
Sent from my Nexus 4 using Tapatalk 4 Beta
And if so, how much longer do you think? Have you seen any hints or rumors plastered on the net? Do you have any links to evidence of 3.10 coming? Are we missing out on anything of importance that 3.10 brings?
Does anyone know why we are still on 3.1, which was released in 2011? I thought Nexus devices got all the good stuff first... Or are only custom roms and kernels using 3.1?
Android devices rarely get new kernel versions anyway since the kernels tend to be customized to work with a specific device, and the binary drivers are built for a specific version of the kernel. This is not as bad as it sounds tho, since a lot of stuff can be backported meaning you get functionality from a newer kernel without the actual kernel version changing. Even more common with custom kernels. For example there's ROMs for our device that uses the F2FS file system which first appeared in the 3.8 kernel and gotten big changes every version after that, and it runs just fine backported to the 3.1 kernel.
hencke said:
Android devices rarely get new kernel versions anyway since the kernels tend to be customized to work with a specific device, and the binary drivers are built for a specific version of the kernel. This is not as bad as it sounds tho, since a lot of stuff can be backported meaning you get functionality from a newer kernel without the actual kernel version changing. Even more common with custom kernels. For example there's ROMs for our device that uses the F2FS file system which first appeared in the 3.8 kernel and gotten big changes every version after that, and it runs just fine backported to the 3.1 kernel.
Click to expand...
Click to collapse
Ok, so this quote here from Linux.com about commits that look like they are made for Nexus 7 2012, is just wishful thinking? I hope not because 3.10 is a massive jump in technology, and possibly even in performance for our device.
there are architecture-specific commits for 3.10 in the kernel/tegra project, which points to development for the 2012 Nexus 7.
Click to expand...
Click to collapse
http://www.linux.com/news/embedded-...roid-will-be-updated-to-the-v310-linux-kernel
EDIT: Ok, I see now, so many new things from 3.4 and 3.8 may already be in our 3.1 custom kernels? If Google releases a 3.10 for the N7 I hope our devs take advantage of it, instead of porting things over to 3.1. I'd like to see our device get Android 5.0 and kernel 3.10, that would really make me feel like this was one of the best investments I have ever made.
As I said, lots of the improvements from newer kernels have already been backported so there wouldn't be as big a difference in performance as you might think. The tegra commits are interesting, but sadly does not confirm anything. For example, the android police article on those same commits mentions that screenshots from the nexus 4 and 5 with the new android version still show them on kernel 3.4. The chance that the 2012 nexus 7 would get a kernel update while the nexus 5 seems awefully slim. I hope I'm wrong tho, since I think it would make things simpler for the custom kernel developers to base stuff on a newer kernel but I wouldn't get my hopes up...
hencke said:
As I said, lots of the improvements from newer kernels have already been backported so there wouldn't be as big a difference in performance as you might think. The tegra commits are interesting, but sadly does not confirm anything. For example, the android police article on those same commits mentions that screenshots from the nexus 4 and 5 with the new android version still show them on kernel 3.4. The chance that the 2012 nexus 7 would get a kernel update while the nexus 5 seems awefully slim. I hope I'm wrong tho, since I think it would make things simpler for the custom kernel developers to base stuff on a newer kernel but I wouldn't get my hopes up...
Click to expand...
Click to collapse
Ok, thanks for making it a little more clearer to me. I kept thinking our 3.1 kernel from 2011 was holding us back from getting one last great update. I think features are no longer needed and I just want them to push performance as far as this thing can be taken. So with ART and F2FS finally coming, I was hoping a better kernel would grace us as well. lol, but it looks like a newer kernel wouldn't do much that the devs haven't already done.
Thanks buddy for jumping in and clearing some of that up for me. :good:
Nvidia released their kernel 3.4.35 for tegra3
Hello all! Hope all is well by you.
Based on what I've seen on this forum, the latest available kernel for the Touchpad is version 3.4.x - an older, unmaintained LTS branch, forked from Qualcomm's repos.
It seems that the mainline kernel source has code for the MSM8660 platform (what the Touchpad is based on) which leads me to wonder if it's possible to get a mainline kernel running on the device.
If my optimism serves me right, this could open the doors to running more non-Android systems on the device!
So far my attempts at booting my compilations have yielded nothing more than a hang at the HP splash logo. I've tried different GCC versions from Linaro (targeting arm-eabi) to no avail.
I'm unsure if I'd need to tweak any DTBs, though the 3.4 kernels don't seem to make use of those.
Of course a splash logo isn't too verbose... might anyone know if there's a serial console I can access over USB or some hidden port internally? Has anyone else made a similar attempt with any progress?
Cheers!
PieGuy128 said:
Hello all! Hope all is well by you.
Based on what I've seen on this forum, the latest available kernel for the Touchpad is version 3.4.x - an older, unmaintained LTS branch, forked from Qualcomm's repos.
It seems that the mainline kernel source has code for the MSM8660 platform (what the Touchpad is based on) which leads me to wonder if it's possible to get a mainline kernel running on the device.
If my optimism serves me right, this could open the doors to running more non-Android systems on the device!
So far my attempts at booting my compilations have yielded nothing more than a hang at the HP splash logo. I've tried different GCC versions from Linaro (targeting arm-eabi) to no avail.
I'm unsure if I'd need to tweak any DTBs, though the 3.4 kernels don't seem to make use of those.
Of course a splash logo isn't too verbose... might anyone know if there's a serial console I can access over USB or some hidden port internally? Has anyone else made a similar attempt with any progress?
Cheers!
Click to expand...
Click to collapse
I am not an expert, but have learned a lot by tweaking the kernel for the Hp Touchpad. To my basic understating none of the native driver codes were release as they are not "open source". How the developers got it working is by tweaking the hardware from what is "based on". If the drivers where open source, it could possible be more helpful on getting a lot more done. All I can do is provide some links from others that had tried:
The LuneOS is using the same kernel branch as Android, but there is no development for the kernel:
https://www.webos-ports.org/wiki/Main_Page
https://www.webos-ports.org/wiki/Main_Page
It will be great to have a kernel to run Linux natively.
Here are some work around that others had used:
https://github.com/mikestaszel/ArchLinuxARM-TouchPad
https://github.com/CalcProgrammer1/kernel_tenderloin_debian
https://forum.xda-developers.com/showthread.php?t=2761381
I did the following videos running Ubuntu (arm) as Chroot and is very fast !
https://www.youtube.com/channel/UCKoir6bzzPU-Uq9UjcRR3hw
Good luck learning!
@PieGuy128
Take a look at this post from @elginsk8r about a possible 5.0 Kernel:
There is a 5.0 kernel floating around that looks promising (uses mesa rather than proprietary blobs for display) albeit missing some key hardware support in it's current state. If anyone would like to take a look at the kernel sources and see what can be done it can be found here https://github.com/flto/linux/tree/msm8660. Building and booting instructions are here https://github.com/flto/linux/wiki
original post:
https://forum.xda-developers.com/showpost.php?p=83040029&postcount=273