Related
Check this out !
Anyone in relation with those guys ? How could we get out tablet to support it ?
Pretty amazing !
Link here : http://www.engadget.com/2011/04/11/cyanogenmod-7-0-is-now-final-ready-for-your-consumption/
I know Dexter is the eLocity king atm, but it must be tirering to be a one man army !
Again and again and again...
Without kernel source we unable to do custom ROMs. Only modifications over stock.
Not a development topic...
5[Strogino] said:
Again and again and again...
Without kernel source we unable to do custom ROMs. Only modifications over stock.
Not a development topic...
Click to expand...
Click to collapse
maybe I should put my old signature back on? lol
the Synergy Bluetooth implementation is nowhere close to standard implementation, so although we might get a CM6/7 on this tablet, even without 2.6.36.3 kernel maybe, we still need more coding done to support the BT implemention otherwise the port will be without Bluetooth support..
I got, as example, the FolioMod ported easily, but Bluetooth did not work, same with the Blur port.. and since our kernel has no real loopdevice or devicemapper support and modules needs to be specifically compiled with the revisions used in our kernel, the "move2sd" function is also missing here, and other nice function as optimized filesystems using loopdevice for faster database updates etc..
it will be hard! , and the drivers without any source, makes its practically impossible to do a kernel based on nvidia's git tree alone..
Moved to proper forum
Kernel available??
Mr. Clown said:
Moved to proper forum
Click to expand...
Click to collapse
See on http://www.elocitynow.com/downloads/open-source.tar
and chacksum http://www.elocitynow.com/downloads/.checksum.md5
ming_a said:
See on http://www.elocitynow.com/downloads/open-source.tar
and chacksum http://www.elocitynow.com/downloads/.checksum.md5
Click to expand...
Click to collapse
Yep. Did you find it here:
http://www.elocitynow.com/developers.shtml
Billy
Hi to all!
I've created this topic that we can discuss about the CM7 and CM9 ROMs that are in development, and not flood the development topic with Q&As. Feel free to post!
How to avoid bricking the SGS+
I've heard that this phone is somewhat easy to brick. This made me think twice before doing some 'serious stuff' with the phone, like trying to make a CM7 or ICS ROM. Can somebody tell me how to avoid bricking this phone? And is it risky to flash source-built ROMs? It would be good if someone tell me the partitions of the phone (in which is stored what: e.g. in which partition is the kernel, the bootloader, etc.).
Thanks in advance!
You can get the most important partitions from the wiki: http://forum.xda-developers.com/wiki/Samsung_Galaxy_S/GT-I9001#Partitions
I once dumped all partitions and can verify that the most important stuff is below the kernel partition, so don't mess with them. mmcblk0p14 is a parameter partition (thx skywalker01) for the bootloader, that is what causes some devices (including mine) not to work 100% correct with CWM. You can only get out of recovery boot loop by dd'ing zeros to that partition.
despotovski01 said:
I've heard that this phone is somewhat easy to brick. This made me think twice before doing some 'serious stuff' with the phone, like trying to make a CM7 or ICS ROM. Can somebody tell me how to avoid bricking this phone? And is it risky to flash source-built ROMs? It would be good if someone tell me the partitions of the phone (in which is stored what: e.g. in which partition is the kernel, the bootloader, etc.).
Thanks in advance!
Click to expand...
Click to collapse
looking back at this post u gave very high expectations . Anyways, building a rom from source isn't hard at all, the tough part is to make the hardware work, so most probably u'll end up with a non working touchscreen for a start, not to mention u need a kernel that'll make it boot at all. As for the partitions, skywalker is the man to ask, i can tell u though that the kernel (boot.img) is in /dev/block/mmcblk0p8 .
rayiskon said:
looking back at this post u gave very high expectations . Anyways, building a rom from source isn't hard at all, the tough part is to make the hardware work, so most probably u'll end up with a non working touchscreen for a start, not to mention u need a kernel that'll make it boot at all. As for the partitions, skywalker is the man to ask, i can tell u though that the kernel (boot.img) is in /dev/block/mmcblk0p8 .
Click to expand...
Click to collapse
Thanks. I was looking for the bootloader partition, because if you mess it up, your phone wouldn't boot at all. If you mess up the kernel partition, your phone won't be able to boot into the OS, but it will be able to boot in CWM and Download mode. I'm asking this here because I heard that this phone has weird partitions, so I want to be sure I'm not going to brick my phone doing these stuff.
Hello all
Today i've made small performance comparation of CM7 KANG and Teamhacksung's ICS b14.
Please note that this KANG is used by me for everyday use with over 60 apps installed, without any scripts etc. (only Chainfire 3D @ nVidia) and ICS is freshly installed. All tests made on airplane mode.
Standard 1000MHz, ondemand, no UV/OV.
I plan to made comparation with latest Samsung ROM.
despotovski01 said:
Thanks. I was looking for the bootloader partition, because if you mess it up, your phone wouldn't boot at all. If you mess up the kernel partition, your phone won't be able to boot into the OS, but it will be able to boot in CWM and Download mode. I'm asking this here because I heard that this phone has weird partitions, so I want to be sure I'm not going to brick my phone doing these stuff.
Click to expand...
Click to collapse
as wintel already said and as it's mentioned in the wiki (WARNING: Partitions below 8 contain absolutely vital stuff like the primary boot loader responsible for low-level hardware initialization. Messing with them is what leads to fully bricked phones because you will not be able to get into download mode anymore! ) . but for any detailed info, contact skywalker
rayiskon said:
as wintel already said and as it's mentioned in the wiki (WARNING: Partitions below 8 contain absolutely vital stuff like the primary boot loader responsible for low-level hardware initialization. Messing with them is what leads to fully bricked phones because you will not be able to get into download mode anymore! ) . but for any detailed info, contact skywalker
Click to expand...
Click to collapse
Thanks, I've sent him a PM.
GIBbeerSKY said:
Hello all
Today i've made small performance comparation of CM7 KANG and Teamhacksung's ICS b14.
Please note that this KANG is used by me for everyday use with over 60 apps installed, without any scripts etc. (only Chainfire 3D @ nVidia) and ICS is freshly installed. All tests made on airplane mode.
Standard 1000MHz, ondemand, no UV/OV.
I plan to made comparation with latest Samsung ROM.
Click to expand...
Click to collapse
Are you talking about SGS i9000 or SGS+ i9001?
I'm sorry, I've missed the "1" at end of model.
well is there any hopes that the CM7 or CM9 will be issued soon for the i9001?
one more thing, should I buy the i9001 or the i9000 is better??
YMYA said:
well is there any hopes that the CM7 or CM9 will be issued soon for the i9001?
one more thing, should I buy the i9001 or the i9000 is better??
Click to expand...
Click to collapse
i think u already made ur choice. here and here
rayiskon said:
i think u already made ur choice. here and here
Click to expand...
Click to collapse
tht wasn't mine..
so what do you suggest?
YMYA said:
tht wasn't mine..
so what do you suggest?
Click to expand...
Click to collapse
neither. S2 or galaxy nexus
rayiskon said:
neither. S2 or galaxy nexus
Click to expand...
Click to collapse
what if i have to choose one of them..which one is better?
YMYA said:
what if i have to choose one of them..which one is better?
Click to expand...
Click to collapse
http://www.gsmarena.com/compare.php3?idPhone1=3115&idPhone2=3908
S+ has a stronger CPU , GPU comes about the same when u update gpu drives,other stuff are more or less similar. so S+ is a lil stronger, but if u care for community support (ICS etc..) u will go for I9000.
rayiskon said:
http://www.gsmarena.com/compare.php3?idPhone1=3115&idPhone2=3908
S+ has a stronger CPU , GPU comes about the same when u update gpu drives,other stuff are more or less similar. so S+ is a lil stronger, but if u care for community support (ICS etc..) u will go for I9000.
Click to expand...
Click to collapse
I am aware about all of this..i mean whats ur personal opinion..if u have to buy one of them which one will YOU get?
YMYA said:
I am aware about all of this..i mean whats ur personal opinion..if u have to buy one of them which one will YOU get?
Click to expand...
Click to collapse
although the lack of community support is a very big minus, but i'd still get the S+ , coz it's better. the only thing i miss is to try an ICS build, but i'm sure it will be here sooner or later.
DroidXDA
SGS+ News :: We almost to booting stage with now fixing the kernel (we hope it will work out) :: do support us by clicking our advert at our blog thanks Have A nice Days
Click to expand...
Click to collapse
Just to let you know...So hopefully they will get it working
What Build is current cm9 ?
One Question, What is the Build Number of our cm9 ? because i want to patch LunarUi Theme ,but it has many zips for many builds of cm9 , thanks
My question is can I use a devices stock kernel to create a build for said device?
My T-Mobile Sony Xperia Z has a locked bootloader and can only run roms using the stock kernel. I've seen other AOSP looking roms run off a devices stock kernel so I was hoping it possible.
Can anyone guide me in this? I would love for my phone to have HALO and different modes like phablet or tablet mode from Paranoid Android. Is this possible with a stock kernel or would features like that require a custom one? I assume it could be run just like Facebook Messenger does it..just as an app I mean.
knightsray said:
My question is can I use a devices stock kernel to create a build for said device?
My T-Mobile Sony Xperia Z has a locked bootloader and can only run roms using the stock kernel. I've seen other AOSP looking roms run off a devices stock kernel so I was hoping it possible.
Can anyone guide me in this? I would love for my phone to have HALO and different modes like phablet or tablet mode from Paranoid Android. Is this possible with a stock kernel or would features like that require a custom one? I assume it could be run just like Facebook Messenger does it..just as an app I mean.
Click to expand...
Click to collapse
Why do you think this isn't done already if it was this easy? The PA, CM framework and such needs code in the kernel and the stock kernel can't be remade because nobody's got the signing code for it, except Sony.
You'll need a unlocked bootloader for Omni ROM.
@MikeChannon, I think this thread can be closed.
Skickat från min C6603 via Tapatalk 2
TheHawk002 said:
Why do you think this isn't done already if it was this easy? The PA, CM framework and such needs code in the kernel and the stock kernel can't be remade because nobody's got the signing code for it, except Sony.
You'll need a unlocked bootloader for Omni ROM.
@MikeChannon, I think this thread can be closed.
Skickat från min C6603 via Tapatalk 2
Click to expand...
Click to collapse
You're wrong. It's not impossible to use stock kernel with a custom ROM, sometimes it's even inevitable, because there are no kernel sources available or the bootloader cannot be unlocked.
Adam77Root said:
You're wrong. It's not impossible to use stock kernel with a custom ROM, sometimes it's even inevitable, because there are no kernel sources available or the bootloader cannot be unlocked.
Click to expand...
Click to collapse
It's pretty much impossible to do so with an AOSP-based firmware. Occasionally it's tried, but always leads to poor results (see CM9 ICS builds for I9100 prior to kernel source release that used an initramfs repack.)
At a minimum it requires initramfs changes, and since the initramfs is signature-checked as part of the kernel image on every device I know of, it's not possible without terrible terrible hacks. Personally, I would prefer to not bother at all supporting any locked device that requires workarounds in the build. It leads to difficult to maintain code, and if people want to run an open source firmware, they should just not buy a locked (or non-unlockable) device in the first place.
Entropy512 said:
It's pretty much impossible to do so with an AOSP-based firmware. Occasionally it's tried, but always leads to poor results (see CM9 ICS builds for I9100 prior to kernel source release that used an initramfs repack.)
At a minimum it requires initramfs changes, and since the initramfs is signature-checked as part of the kernel image on every device I know of, it's not possible without terrible terrible hacks. Personally, I would prefer to not bother at all supporting any locked device that requires workarounds in the build. It leads to difficult to maintain code, and if people want to run an open source firmware, they should just not buy a locked (or non-unlockable) device in the first place.
Click to expand...
Click to collapse
I also prefer having sources and building kernels rather than doing bad hacks, I just pointed out that it's possible and sometimes is a must (Not talking about Omni, just in general.), there are devices without unlockable BL. E.g. we were using 2nd-init method on p880 before official JB came out and BL unlock became possible.
Adam77Root said:
I also prefer having sources and building kernels rather than doing bad hacks, I just pointed out that it's possible and sometimes is a must (Not talking about Omni, just in general.), there are devices without unlockable BL. E.g. we were using 2nd-init method on p880 before official JB came out and BL unlock became possible.
Click to expand...
Click to collapse
May I ask if you ever had a AOSP based firmware or just remakes of the stock ROM to look like AOSP? Because there you've the big difference. It's (obviously, because Entropy is Entropy ) just like @Entropy512 said.
Skickat från min C6603 via Tapatalk 2
TheHawk002 said:
May I ask if you ever had a AOSP based firmware or just remakes of the stock ROM to look like AOSP? Because there you've the big difference. It's (obviously, because Entropy is Entropy ) just like @Entropy512 said.
Skickat från min C6603 via Tapatalk 2
Click to expand...
Click to collapse
Yes, I did. I know the difference between a themed and a real AOSP rom. If I didn't, I wouldn't be a RD. What I wrote is totally possible and legit.
Sent from my OmniROM-powered LG Optimus 4X HD
Guys,
Naturally, as the title states, its a general discussion thread for huashan LBL users. I want to discuss some things with like-minded people and hopefully once the momentum builds, we can try to achieve something.
Android L official release is just around the corner and our official fate is sealed by Sony @ 4.3.
But i plan on trying to port L using existing 4.3 kernel and make it at least boot so we know later on its a possibility for Locked Bootloader to have Android L.
Unlocked Bootloader guys are advised to stay away, as sooner or later, they will get proper AOSP 5.0.
Some points i want to make important.
1. This is NOT a cheer thread. Dont just post to show your excitement. It blocks the purpose of healthy discussion.
2. This is not for people who want new android. Have some sense, it isnt going to come anytime soon.
3. This is strictly for Locked Bootloader guys. So any other person coming and commenting might just be wasting his time.
Although, if you really have some positive thing to contribute, than whatever you have, LBL or UBL, please do share with all.
This is a good starting place to study.
https://github.com/Android-L-Porting-Team/Android-L-Mako/commits/master?page=3
Lets begin !
Im not sure how much id be able to contribute but ill be willing to help any way I can do. Do we even have a vague idea of what kernel modules would be needed for L? Im assuming thats what we'd need as I remember Bagyusz saying thats what he had to do for KK.
Has any of the freexperia team looked at L yet to your knowledge? Perhaps they may be able to give some small insight into drivers etc for LBL/UBL.
Will PA still be updated while this is being looked at? I'm assuming PAC wont need anything now unless problems occur as its all automated. Until L is working PA is a good thing for those wanting L due to them implementing features from L in KK such as recents and tinted bars (if they ever release them to legacy!!).
Oblox said:
Im not sure how much id be able to contribute but ill be willing to help any way I can do. Do we even have a vague idea of what kernel modules would be needed for L? Im assuming thats what we'd need as I remember Bagyusz saying thats what he had to do for KK.
Has any of the freexperia team looked at L yet to your knowledge? Perhaps they may be able to give some small insight into drivers etc for LBL/UBL.
Will PA still be updated while this is being looked at? I'm assuming PAC wont need anything now unless problems occur as its all automated. Until L is working PA is a good thing for those wanting L due to them implementing features from L in KK such as recents and tinted bars (if they ever release them to legacy!!).
Click to expand...
Click to collapse
Dont worry so much. PA is at a stage that if u have linux, u can just compile it right away and all is on Auto.
I will release milestone builds... No point pushing weekly updates if there arent any major changes.
For PAC, i have even taken that burden off and compiling and uploading is not my headache now.
And apart from above, i dont use PA personally. PAC suits me best.
As you stated the main concern is how well "the sealed by Sony @ 4.3. bootloader" will be able to cope with android L?
I really appreciate your enthusiasm. And yes there is only one way to find out. And that is to actually try porting it.
mmfh said:
As you stated the main concern is how well "the sealed by Sony @ 4.3. bootloader" will be able to cope with android L?
I really appreciate your enthusiasm. And yes there is only one way to find out. And that is to actually try porting it.
Click to expand...
Click to collapse
Porting is not an issue. We need a team. Not a band, but maybe 3 people. One compiler, One to tinker with trees and files, One tester. Just my suggestion.
One person cannot do it alone, unless he is an expert dev.
And about coping with L, all current devices having L port are using 4.4 kernel. And our 4.3 copes with 4.4. Technically there are not much issues compatibility wise. Just ramdisk and correct blobs.
I may be wrong, but thats why this discussion is goign on, if someone wants to correct me, please do.
I think this is an interesting project, XDA needs ppl like U
you think is easy port L with 4.3 kernel? I mean I'm just talking w/o reference, but Sony is just (until now) ignoring ART which is the biggest change for L (since 4.4 but well, now is not optional), and I think that could be a barrier to port new android for older phones (like SP)... what do you think about?
I hope this thread came with great news in the near future, :good:
This can be either hard or easy, hell or heaven, depending on the changes in L official release. Up until now, the changes are lying in ramdisk, but some features aren't available in the beta release.
But here are a few things that I noticed right now, before the official release:
1. UBL and LBL are stuck with 4.3 blobs. We are already using patched libraries, I guess it will get worse later, even on UBL.
2. I think we should wait until the CM12(?) will be working on UBL, while helping with bringing it up. If it works on UBL, then we should tinker with the LBL version. Actually, we have the hijack part, and we have the patches needed. I think it will be easy to get it to boot.
3. I think when @delewer finishes his kexec modules, some people that are experienced with kernel development could port it to SP, and then we could use it on forever locked phones. It will take some time, but will be the best for our phones.
So overall, if we have some luck, we would only have to kang CM trees, add the patches for hwcomposer, etc., add hijack and maybe some kernel modules. But we can be extremely unlucky and... I don't even want to imagine the worst case scenario.
Dont worry, the ground work is there. bagyusz gave us a great gift. I am sure Final release wont have boot-related changes. Maybe framework and libs, but not more.
The best thing is, 4.3 SONY rom DID NOT support ART. Bagyusz made it work even on LBL. and as Android L only supports ART, so thats the most important point i think.
Hmm, is ART even kernel-dependent?
I think that's not the case, and it's just great for us. So, bagyusz did a great work(it's just amazing), but I don't think he made any change to support ART.
And yeah, maybe there are just changes in frameworks and libs, but I'm still paranoid about this.
Anyway, I think that we are going to make it. That's what I feel, and I hope it comes true
neXus PRIME said:
Porting is not an issue. We need a team. Not a band, but maybe 3 people. One compiler, One to tinker with trees and files, One tester. Just my suggestion.
One person cannot do it alone, unless he is an expert dev.
And about coping with L, all current devices having L port are using 4.4 kernel. And our 4.3 copes with 4.4. Technically there are not much issues compatibility wise. Just ramdisk and correct blobs.
I may be wrong, but thats why this discussion is goign on, if someone wants to correct me, please do.
Click to expand...
Click to collapse
As I'm far from developer, I'm afraid cannot be of big help to you.
But I'm willing to contribute by testing builds and discovering bugs.
MrSteve555 said:
Hmm, is ART even kernel-dependent?
I think that's not the case, and it's just great for us. So, bagyusz did a great work(it's just amazing), but I don't think he made any change to support ART.
And yeah, maybe there are just changes in frameworks and libs, but I'm still paranoid about this.
Anyway, I think that we are going to make it. That's what I feel, and I hope it comes true
Click to expand...
Click to collapse
Not kernel dependant, i know, but you know what, booting a new android version using old kernel with just hijack n scripts is one HELL of a job.
And ART even didnt work for a long time on AOSP CM for huashan on UBL.
My point was, what we have here is a 4.3 kernel and blobs which might or might not be enough for android L. But before official release, we can try to port L from mako, by replacing blobs and ramdisk and boot, so that we have at least a proof of concept that LBL CAN boot L. Just boot. Nothing else.
neXus PRIME said:
Not kernel dependant, i know, but you know what, booting a new android version using old kernel with just hijack n scripts is one HELL of a job.
And ART even didnt work for a long time on AOSP CM for huashan on UBL.
My point was, what we have here is a 4.3 kernel and blobs which might or might not be enough for android L. But before official release, we can try to port L from mako, by replacing blobs and ramdisk and boot, so that we have at least a proof of concept that LBL CAN boot L. Just boot. Nothing else.
Click to expand...
Click to collapse
"Just" hijack? Bagyusz gave us an excellent base(hijack), and I bet we can boot FFOS or Ubuntu on that.
I didn't even know that ART didn't work on huashan before. Wasn't it a Gapps problem?
And yeah, these maybe aren't enough, as we are already patching some libs.
Ans one thing - I don't think we could port that from mako. It uses a little different base, and it isn't a CAF base. I think we should just wait
MrSteve555 said:
"Just" hijack? Bagyusz gave us an excellent base(hijack), and I bet we can boot FFOS or Ubuntu on that.
I didn't even know that ART didn't work on huashan before. Wasn't it a Gapps problem?
And yeah, these maybe aren't enough, as we are already patching some libs.
Ans one thing - I don't think we could port that from mako. It uses a little different base, and it isn't a CAF base. I think we should just wait
Click to expand...
Click to collapse
Just hijack meant different in a positive sense. But maybe it came out wrong.
And I'm talking about porting. Framework. Not building from source. They are actually doing same thing. I'll have to give it some time though.
neXus PRIME said:
Just hijack meant different in a positive sense. But maybe it came out wrong.
And I'm talking about porting. Framework. Not building from source. They are actually doing same thing. I'll have to give it some time though.
Click to expand...
Click to collapse
Yes, I know what you are trying to say with porting L. Actually, there would be a few things that would break:
1. The YUV color palette support (fixable with our hwcomposer, gralloc etc)
2. GPU drivers - this is the "best" part. L is precompiled, and I think it uses the libRS override, which doesn't work on our huashan because of a kernel difference (if we could build from source, we could just not enable it). There are a few other things that aren't compatible. So even if we got it to boot, it would just show black screen, and I assume by "just booting" you mean actually seeing the effort
3. The whole "thing" is built off AOSP repos, not CAF ones. Idk if SP's stock kernel would play nicely with the whole different stuff.
These are just my assumptions, in the end everything could work just fine. If you have the sufficient time, it's nice to try. Just deleting the mako proprietary stuff, and adding the needed huashan blobs + adding correct ramdisk would get it to the bootable/half working state (or there is a chance that the "build" wouldn't even boot.). I guess it's not done yet for a reason.
Anyway, I have to squash one last bug in my CM builds. If it will work, I could also try porting the magical "L".
Yo peeps,
Code:
[COLOR="Red"]For people who say I will wait for official update STAY OUT![/COLOR]
So i was trying to port the G2's Lollipop update to G1. Many of you may think itz quite useless, well i just decided to try because i am a big dev here to compile AOSP or CM12 roms without a proper device tree. So while we wait for Official Update or until CM/AOSP becomes stable i thought maybe i could try porting. So i managed to get the system and boot.img made a zip and now the problem seems with the kernel. I get a fall through to fastboot mode when i use their kernel and when i use ours it gets stuck on bootlogo. Both the kernels are of 3.4.42 and i am not good at kernels like the way i am at kang so if someone could help me with the kernel part maybe we can get L earlier.
This thread is for only people who can encourage and try helping! Others please excuse.
I unpacked both the boot.img made a zip of it and uploaded so that it would be easier for people to help. I dont mind testing it numerous times. Willing to listen and try anything and everything that can make it boot. So here are the kernels.
Hope to find help!
@VictoriousShooter
@rr46000
@S0bes
@yajnab
I think it is impossible without kernel source... This way you can play with Ramdisk only. Moto g2 has little bit different hw..
only difference is screen size and camera, the processor, graphics chip, ram, battery and sensors are the same. so it is possible to port g2 update to g1.
AgentChaos said:
only difference is screen size and camera, the processor, graphics chip, ram, battery and sensors are the same. so it is possible to port g2 update to g1.
Click to expand...
Click to collapse
The ROM itself-yes
Kernel-no.
I know almost nothing about kernels and all related with it things and even do not know why I was mentioned by OP
But I have a question. Can we just flash firmware from G2? Can it brick our device completely in a worse way?
Why am I saying such a bool****? Read first line in that post again
Never the less I remember guys who flashed android 2.3 on samsung galaxy gio from galaxy ace and phone booted and even hadn't critical bugs...
S0bes said:
I know almost nothing about kernels and all related with it things and even do not know why I was mentioned by OP
But I have a question. Can we just flash firmware from G2? Can it brick our device completely in a worse way?
Why am I saying such a bool****? Read first line in that post again
Never the less I remember guys who flashed android 2.3 on samsung galaxy gio from galaxy ace and phone booted and even hadn't critical bugs...
Click to expand...
Click to collapse
I have flashed ZTE warp cm10 on ZTE v9a with kernel built by myself and it was also working... But with warp kernel there was no chance to boot v9 device up.
I think with flashing g2 lollipop over g1 shouldn't brake your phone permanently, unless you are not flashing modern etc. (just flashing system and kernel). But I cannot promise nothing will be broken
Try using a CWM flashable version of the G2 rom along with the CM12 kernel? You might be able to get some kind of result from it?
Justice™ said:
Try using a CWM flashable version of the G2 rom along with the CM12 kernel? You might be able to get some kind of result from it?
Click to expand...
Click to collapse
cm kernels wouldnt work on stock roms bro.. tried it.
fabus said:
I have flashed ZTE warp cm10 on ZTE v9a with kernel built by myself and it was also working... But with warp kernel there was no chance to boot v9 device up.
I think with flashing g2 lollipop over g1 shouldn't brake your phone permanently, unless you are not flashing modern etc. (just flashing system and kernel). But I cannot promise nothing will be broken
Click to expand...
Click to collapse
S0bes said:
I know almost nothing about kernels and all related with it things and even do not know why I was mentioned by OP
But I have a question. Can we just flash firmware from G2? Can it brick our device completely in a worse way?
Why am I saying such a bool****? Read first line in that post again
Never the less I remember guys who flashed android 2.3 on samsung galaxy gio from galaxy ace and phone booted and even hadn't critical bugs...
Click to expand...
Click to collapse
@S0bes i thought you may know something so kinda tagged u bro btw i tried flashing g2's stock firmware image it doesnt brick or anything but since they have a different kernel it still goes to fall through to fastboot mode even on g2's stock roms. the main difference is that 5.0 uses ART and ours DALVIK and hence i believe that what the issue.
yeshwanthvshenoy said:
i tried flashing g2's stock firmware image it doesnt brick or anything but since they have a different kernel it still goes to fall through to fastboot mode even on g2's stock roms. the main difference is that 5.0 uses ART and ours DALVIK and hence i believe that what the issue.
Click to expand...
Click to collapse
I do not believe so. Neither Android 4.4.4 Moto G LTE nor, Moto G (2014) Kernels (or ROMs) boot on Moto G (2013.)
@yeshwanthvshenoy I know you stated you are a big dev, but since you are, you already know kernels can't be ported from an image. You need the source code. Unless you have a magical way of changing code without needing to decompile.
Still... if you are having fin making zips, go ahead, don't let my words discourage you. But... this is a dead end.
Agreed with @fermasia
if porting kernel without source was such an easy task by this time we had so many kernels
Only way is directly flash 2nd gen kernels to try our luck if some things work
All the best [emoji4]
reversegear said:
Agreed with @fermasia
if porting kernel without source was such an easy task by this time we had so many kernels
Only way is directly flash 2nd gen kernels to try our luck if some things work
All the best [emoji4]
Click to expand...
Click to collapse
I dont think there will be any luck since G 2014 has a different MSM board and that has to do with the result you will get. So if you manually flash XT1064 firmware on an XT1032 just expect a beautiful soft brick in the best of the cases... Just wait for official OTA, there are just days left for it!!! Next week we will se some news.
for this you need a new kernel for G1, which we dont have. (and even if we had it then we had the ROM too)
you will have to use the old kernel with the new ROM. which will obviously create tons of error.
have you tried CM12 kernel with the ROM?
For the kernel, try following and check if there is some progress.
Decompile both the kernels with dsixdia kitchen. You will get ramdisk and Zimage for each kernel. Try following combination.
4.4.4 Zimage (G1) + 5.0 Ramdisk (G2) + Modules (G1)
If no, try using init.rc of G1 and give another try.
I'm not planning on helping you do this, but the g2 and g1 use the same kernel. You only have to enable certain things in the defconfigs...
Somcom3X said:
I'm not planning on helping you do this, but the g2 and g1 use the same kernel. You only have to enable certain things in the defconfigs...
Click to expand...
Click to collapse
They are using the kernel source, but even kernel source for g2 hasn't been released so far...
fabus said:
They are using the kernel source, but even kernel source for g2 hasn't been released so far...
Click to expand...
Click to collapse
You don't really need it, decompile the boot.img and replace the zimage inside with a compiled one.
I don't recommend doing this. Porting in this case is pointless.
By the way, kernel source was released a while ago.
Good luck on the kernel. Though I highly suspect that Motorola will give us Lollipop on the Moto G before anyone is able to come up with a working port.
Somcom3X said:
You don't really need it, decompile the boot.img and replace the zimage inside with a compiled one.
I don't recommend doing this. Porting in this case is pointless.
By the way, kernel source was released a while ago.
Click to expand...
Click to collapse
thanks for the info and help all of u are extending i know maybe this may not work out but itz just a try. and @Somcom3X can u please a little more of the above statements u said about changing defconfigs and few other stuff. Should i use G2's zimage and G1's ramdisk or any file that u think would make it boot? Can u specify the file name if so.
Get the basic source of the G1. Match the changes made to G2 for the L. Best to getthe old G1 kernel source and modify the things needed for the L. Test and Go.
Unless its creating changes in filesystem its good to play with.
---------- Post added at 03:13 PM ---------- Previous post was at 03:13 PM ----------
yeshwanthvshenoy said:
thanks for the info and help all of u are extending i know maybe this may not work out but itz just a try. and @Somcom3X can u please a little more of the above statements u said about changing defconfigs and few other stuff. Should i use G2's zimage and G1's ramdisk or any file that u think would make it boot? Can u specify the file name if so.
Click to expand...
Click to collapse
G2 device board name differs. It will be just foolish and waste of time