Related
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
chuckhriczko said:
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
Click to expand...
Click to collapse
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Kcarpenter said:
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Click to expand...
Click to collapse
If someone has made a github project please let me know. I havent made a 2.6.29 github project yet. I am currently doing one for 2.6.27.
I created a 2.6.27 repo this morning when the source was released. And I've checked out 2.6.29, just haven't set it up in github.
Really?
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
It's not that simple. For starters we have to copy over the drivers for our phone and make sure they compile correctly. On top of that HTC modified quite a bit of the kernel. Porting it over will happen but it may take some time. Like I said before I am new to the linux kernel deal but I do know it is more difficult than it seems.
I'd say a completely functional port will take roughly 2 weeks time for a hobbyist. I'm not sure though as I'm still new to messing with linux kernels. I'm looking into a port of my own. Debating 2.6.29 or porting the android specific bits to a newer linux kernel. Chances are porting the hero specific stuff to the android 2.6.29 kernel source will be much simpler. It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight. I wish I was a bit more profficient with C programming too. I guess now I have a good reason to do just that.
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
edit: didnt release chuckriczko answered your question..
obelisk79 said:
It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight.
Click to expand...
Click to collapse
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
gu1dry said:
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
Click to expand...
Click to collapse
no kidding... I wasn't expecting to wake up to a new release. Of course I could just run linux on my laptop and call it a day
Yeah, the reason it's better to start with .29 than jump to .32, because a lot of the work has already been done for us in .29. In fact, if you really investigate the kernel source they released, vs the kernel on our phones, you'll notice that HTC has already backported some of the .29 changes in the android-msm-2.6.29 branch into the source they released, which was *not* initially the case in the kernel that they shipped.
What we need to do to get .29 actually working, is the opposite: forward-port the HTC changes for hero/c into the .29 source.
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
maejrep said:
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
Click to expand...
Click to collapse
Great work! As I said before I am new to this linux kernel stuff and don't think I can help but I am cloning the repo so I can take a look anyway.
Any progress with getting it to boot?
Any update on this project?
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
theoottesen said:
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
Click to expand...
Click to collapse
I checked the githup out. still doesn't boot
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
maejrep said:
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
Click to expand...
Click to collapse
So if I understand correctly, the devs that worked on the kernel for the Nexus One got lazy and never tried to see if it compiled on the Sapphire?
If they were developing the kernel for the nexus id hardly call them lazy for not taking the time to check it on other devices.
I've been thinking about the possibility of extracting the firmware from a Galaxy Tab 2 (ICS) and merging it with the kernel and build.prop from the 7 Plus (Honeycomb).
Technically I can't think of a reason that it wouldn't work, I'd think that the challenge would be getting the kludged FW back onto a 7 plus.
Would it be a futile effort? Maybe if Samsung releases ICS for the Plus, but who knows when that will be.
I don't have any experience on these two Android device other than in an end user capacity (though I have been reading) and very little on a few other Android devices so I dunno if it's feasible, but I thought I'd mention the idea.
Anyone with deeper experience on these things think it might be viable?
I know the devices have different hardware specs so I don't know if it would meld...
fewt said:
Technically I can't think of a reason that it wouldn't work, I'd think that the challenge would be getting the kludged FW back onto a 7 plus.
/QUOTE]
technically: different hardwares, the ics may need some changes on kernell itself to work, so you may not be able to use hc one.
besides the differences of one device to other is not just encapsulated on kernel, the dalvik virtual machine needs to be ported to every machine depending on aspects.
Enviado do meu MB525 usando o Tapatalk
Click to expand...
Click to collapse
leodfs said:
fewt said:
Technically I can't think of a reason that it wouldn't work, I'd think that the challenge would be getting the kludged FW back onto a 7 plus.
Click to expand...
Click to collapse
technically: different hardwares, the ics may need some changes on kernell itself to work, so you may not be able to use hc one.
besides the differences of one device to other is not just encapsulated on kernel, the dalvik virtual machine needs to be ported to every machine depending on aspects.
Enviado do meu MB525 usando o Tapatalk
Click to expand...
Click to collapse
Technically, it shouldn't as kernel interfaces don't change that much between releases. Since both processors are ARM, I wouldn't expect a problem with the Dalvik VM either but I guess I could be wrong there.
Would be interesting to see, but I can tell there isn't any interest in it. I've been trying to find a good reference on where to get started with this stuff, but it just seems like a hodgepodge of information sprawled all over the place.
Anyone have a solid guide to getting started building custom firmware that isn't the great google?
fewt said:
Technically, it shouldn't as kernel interfaces don't change that much between releases. Since both processors are ARM, I wouldn't expect a problem with the Dalvik VM either but I guess I could be wrong there.
Would be interesting to see, but I can tell there isn't any interest in it. I've been trying to find a good reference on where to get started with this stuff, but it just seems like a hodgepodge of information sprawled all over the place.
Anyone have a solid guide to getting started building custom firmware that isn't the great google?
Click to expand...
Click to collapse
I suggest you read the CyanogenMod 9 thread in development as you will experience the same problems porting this over without a working ICS kernel.
Here are some threads I've found useful on porting and building from source:
http://www.iphoneandroidtips.org/miui/how-to-port-miui-v4-to-android-phones/
http://forum.xda-developers.com/showthread.php?t=1153233
http://forum.xda-developers.com/showthread.php?t=1499411
http://forum.xda-developers.com/showthread.php?t=1169570
http://forums.androidcentral.com/ht...how-build-your-own-kernel-package-source.html
http://source.android.com/source/index.html
http://wiki.cyanogenmod.com/wiki/Building_Kernel_from_source
These threads are for all different models of phones and the methods may or may not work for our tablets but the principles are pretty much the same. In the instance of porting over MIUI 4 you have to start with a working CM9 ROM as it requires a working AOSP ICS kernel, which we don't have yet. Our devs are working their butts off trying to port one over from another device but its slow going without the proper source code that Samsung won't release.
I would think if it were as easy as combining the two, who would need XDA?
kzoodroid said:
I suggest you read the CyanogenMod 9 thread in development as you will experience the same problems porting this over without a working ICS kernel.
Here are some threads I've found useful on porting and building from source:
http://www.iphoneandroidtips.org/miui/how-to-port-miui-v4-to-android-phones/
http://forum.xda-developers.com/showthread.php?t=1153233
http://forum.xda-developers.com/showthread.php?t=1499411
http://forum.xda-developers.com/showthread.php?t=1169570
http://forums.androidcentral.com/ht...how-build-your-own-kernel-package-source.html
http://source.android.com/source/index.html
http://wiki.cyanogenmod.com/wiki/Building_Kernel_from_source
These threads are for all different models of phones and the methods may or may not work for our tablets but the principles are pretty much the same. In the instance of porting over MIUI 4 you have to start with a working CM9 ROM as it requires a working AOSP ICS kernel, which we don't have yet. Our devs are working their butts off trying to port one over from another device but its slow going without the proper source code that Samsung won't release.
Click to expand...
Click to collapse
This is awesome, I really appreciate you taking the time to write it up.
I hope you have success, either way you will learn, that's why we bought our android for.
I think there's a lot of interest, but this thing is dangerous, lots of devs have their devices bricked trying port or improve,.
My advice is not of an android developer, but of someone that has some experience of customizing or compiling the Linux Kernel. any little thing you forget render you with a system that will not boot. And even if they use the same kernel, ics may need some things activated that hc may not
Sent from my GT-P6210 using Tapatalk 2 Beta-5
Apologies if this has been covered, but I've done multiple searches and have yet to find an answer. I'm in the process of picking a new phone, and I'm down to the galaxy nexus and gs3. (Damn you google for not releasing the n4 on vzw). In any case, my concern is around updates. I realize the CM team will continue to support the gs3 well into the future, but my question revolves around kernels. It's my understanding that the CM team will simply update the userspace - in order for there to be an updated kernel, there would need to be a release from Samsung for the appropriate kernel. In other words, if google updates android 5.x to a linux 3.6 kernel, and the last Samsung release was 4.2 running the 3.4 kernel, while I will get the 5.x android userland, I will be stuck with the old kernel, and potentially sub-par battery life/performance enhancements/etc. To the point I may not even be able to upgrade if they make significant enough changes to the kernel/userland interaction.
Are my assumptions correct, or am I off-base? I just don't want to get stuck like I am today with my droid-x that stopped being supported ages ago by motorola, and just barely supported by the community a year later.
There are custom kernels that have their own linux merges in so it would be very feasible that we have linux kernel updates beyond what Samsung gives us. The NA variant is on basically every carrier in NA so I am sure there are atleast a few excellent kernel devs who own the device that would be able to do this.
That isn't to say it isn't possible for us to get abandoned. But I think the dev community for this phone will last longer than previous phones.
con247 said:
There are custom kernels that have their own linux merges in so it would be very feasible that we have linux kernel updates beyond what Samsung gives us. The NA variant is on basically every carrier in NA so I am sure there are atleast a few excellent kernel devs who own the device that would be able to do this.
That isn't to say it isn't possible for us to get abandoned. But I think the dev community for this phone will last longer than previous phones.
Click to expand...
Click to collapse
I understand that as a whole it won't get abandoned. Unless Samsung is open sourcing drivers though, I don't see how it's possible to release updated kernels if Linus decides the kernel/driver interaction is going to change - which has happened in the past and likely will again in the next 2 years. Without the source to the drivers, I don't really see how the devs could hack something together short of trying to re-write them entirely.
I have been working on getting a build environment to be able to see if I could build from source. I have an XT905 (basically an XT907 with different mobile frequencies), which can almost use an XT897 ROM. Just need to replace the Bluetooth and screen drivers and some build props. Anyway, I finally managed to produce a built ROM from source. So I looked into what would need to be done to bring in the CPU overclocking from @arrrghhh kernel.
Surprisingly, the higher CPU clock frequencies were already defined in the code, but turned off with a build flag. So, on my last build (and now the only one I have actually flashed), I turned the OC flag ON. And when I booted, installed Kernel Adiutor, and checked the available frequencies, sure enough they were there!
In short, I can now build an OC'd Lineage 6.0.1 ROM from Source! and anyone else can too!
Now don't get too excited, as i wont be releasing any build I do too soon (and my build is for XT905), but the source is there for anyone taking the time to build it for themselves, or if another dev wants to build it for you. I may release one in the future. But without regular releases, all would be best to stick with the official build. Even better would be to convince the official builds to include the OC option.
The real purpose of this thread is simply to let people know the option is there, and the code is there. I have been running it for the last few minutes, and unusually, it has not hit deep sleep, while my daily version hits deep sleep almost the instant the screen is off
Hey there! Any updates on this? I'd really like to help, and I have some Java/Android Framework knowledge so please tell me if you need help. Unfortunately, I can't build a ROM from source because my internet is reaaaaaally slow (100KB/s of download at much) and I don't have enough storage. I really, really want a somewhat stable Marshmallow ROM for my xt907 (I'd prefer AOSP, but LOS is vanilla enough, at least), it's my development phone and I can't upgrade to something better/newer.
BTW, do the xt897 builds boot right away in your xt905? Could you provide me those drivers (compiled) so I can try in my xt907?
EDIT: Well, they actually boot! The touchscreen doesn't work, though (that's what the drivers you were talking about are for, I suppose), I think I'll create a script that adds the necessary changes to the zip, once I find out what files need to be replaced, or are the drivers tied to the kernel?
Hi everyone,
I bugged HMD about not releasing more recent source code for the Nokia 8 and a few days ago they updated their site with links to code for the Android 9 builds. Note they still haven't published the latest build (5.150) nor and 4.88 builds nor any Android 7.1x builds.
I checked the archives and they are different from the previous 4.84 release, but I've no idea if they are buildable. They still look like they might be missing some useful bits, from my limited knowledge. Those of you who know what to do with this can test it and see if it's useful to you.
Let me know if you would like me to keep bugging them about the 4.88 build's code, or even any earlier 3.x builds.
Have fun!
Cheers
Thanks for bugging them!
Sadly it still contains the same device tree typos that the previous NB1 and even A1N sources contained, so without fixing them those trees do build but won't work correctly as the display won't be accessed correctly (half the screen will be white IIRC).
To be clear, this is what I mean: https://github.com/resident-nokia/u...f68ad2f#diff-6ea71fa79b281dd80cbab0bea96d9472
Also, as a funfact: A quick diff I did showed that the 5140 source is identical to the 4120 kernel source from Nokia 8 Sirocco that was released around December if I am not mistaken (minus the device tree files and some places where device names were hardcoded). That would mean that our kernel hasn't seen an update since December (actually even September, since thats the first CAF tag (Qualcomm upstream) that has changes you can find in those sources). Customer service I guess ¯\_(ツ)_/¯
Hi @THMSP!
Thanks for checking it out, shame it's still got errors in it. That's very interesting about the comparison with the Sirocco and the last change being in September. I suppose a new build doesn't automatically mean a new kernel though.
Since both the Android 8 and 9 source contain errors my only wonder is if the Android 7 source would also have errors, or if it might actually work?! I will ask them for it.
Cheers
EDIT: So the device tree is there after all? I had obviously misunderstood some of the other conversations I'd read, I had always thought it was missing. So it seems the device tree is there, but broken? Or only partially there, and what is there is broken?
The device tree files are all there, but they contain four serious typos that cause them to not actually work when you boot your compiled kernel. The rest of the source code does work. Correcting those typos is not much of a deal, but it is annoying (and personally I wonder how on earth they even maintain these sources).
The other annyoing issue is that for any custom or mismatching kernel the wifi driver won't load (because of signature enforcement for kernel modules), so if you want to make a kernel that doesn't break wifi, you need to add the Qualcomm wifi driver yourself (which then requires additional patches to actually work as well).
When you do those two things, the kernel will work just like the one that Nokia is shipping. For example, my TWRP builds for NB1 actually use the kernel source code for Sirocco, but with the (corrected) device tree files from NB1, and a patched version of the qualcomm wifi driver compiled into the kernel directly.
I am not sure if the nougat sources would help that much to be honest. It's not like those sources are broken because HMD / FIH don't know how to fix them, I bet they break them on purpose (or they get broken by the tool they use to package them). So any further release by them will probably contain the same stupid errors.
Wow! That's a lot to do to make them usable. I agree that I have many questions about QC and QA in the software for these phones, not only because of the source code releases.
You did very well making the device tree for the NB1 then and getting TWRP running, well done! And thanks
Like many I'm interested in the possibility of running other OSes on the NB1, particularly /e/ and any that run on Halium. I presume it will still take a lot of work to get another OS running on the NB1, but is it doable? I think in all cases these projects start from a LOS base.
Cheers
madb1lly said:
Wow! That's a lot to do to make them usable. I agree that I have many questions about QC and QA in the software for these phones, not only because of the source code releases.
You did very well making the device tree for the NB1 then and getting TWRP running, well done! And thanks
Like many I'm interested in the possibility of running other OSes on the NB1, particularly /e/ and any that run on Halium. I presume it will still take a lot of work to get another OS running on the NB1, but is it doable? I think in all cases these projects start from a LOS base.
Cheers
Click to expand...
Click to collapse
Most of the work regarding TWRP and the kernel was actually done by @dg28gadhavi - I just tried to update everything a bit and adapt it to all the new bootloader bugs features that were introduced over time. He deserves all the credit, otherwise I would've had nothing to learn all this stuff from.
Regarding custom ROMs: Sure it is possible. But it is a huge amount of work, that requires you to risk your device (Snapdragon chips are unbrickable, but you couldn't use it as a daily driver), with potentially very few people actually caring (or even donating etc.). When you reached the point where you are able to port a ROM, you have the knowledge to make the changes that you need yourself with Magisk as well. So the only real reason to port a ROM is to give something to the community. And the Nokia 8 community simply isn't big enough that anyone would do that, imo.
Well thanks for @dg28gadhavi as well then!
Yes, I have read that Magisk can do most of what a custom Android ROM might have done. I have some reservations about Magisk, since it's not open source I don't know if I fully trust it, but that could also be the case for most of the software I use! Personally I'm interested most in /e/, which is currently built of a LOS base, but I don't know if all the customisations they've done (mainly to remove any communication with Google services) can be done with Magisk.
As for Halium-relate OSes (Ubuntu Touch, Plasma Mobile, Sailfish OS, LuneOS... some others too), Magisk can't recreate those as they're basically completely different from Android, they just run off the Android kernel and use libhybris to interface with the Bionic library drivers; the rest of Android is not used.
Anyway, this is all beyond my available time at present, so I will just have to carry on with stock Android maybe with some Magisk customisations until my phone breaks!
Cheers
madb1lly said:
I have some reservations about Magisk, since it's not open source I don't know if I fully trust it
Click to expand...
Click to collapse
Magisk is completely opensource, it has always been: https://github.com/topjohnwu/Magisk
You might be thinking about SuperSU which was / is indeed closed source