Database Info

[REF] Github repo for SGH-I997R Source Release

Inspired by supercurio creating a master git repo for SGH-I997R development, I'm in the process of uploading today's source release from Samsung of the Gingerbread kernel for the Rogers Infuse 4G. (I'm surprised none of the other kernel hackers here have already done it... )
See supercurio's post http://forum.xda-developers.com/showthread.php?t=1054738 for more info on why git is good, and superior to kernel devs using tarballs directly from Samsung. This method is already unofficially how the kernel devs have been working - nearly every kernel here is forked from gtg465x's github repo.
I don't plan on directly doing development on this repo - It's just here as a starting point for everyone else to fork from. Some of us have slow upstream, so it's easier to pull a fork than it is to push a tarball import. However I might consider pulling in basic fixes to this repo (.gitignore, Makefile fixes - basically the same things supercurio has fixed in his unified git repos). (Edit: I'm starting to consider doing things a bit differently in order to allow this to stay as a relevant reference - After all there are certain "core" features like Voodoo Lagfix/Sound that have no known detrimental effects and are basically expected from any kernel used by the community.)
One thing is that most of the other ref repos are on a github "team" account - mine is on a personal account. I'm going to look into whether I can change this without breaking the fork relationships.
The repo is located at https://github.com/Entropy512/linux_kernel_sgh-i997r
Initramfs from Wednesday's dump is at https://github.com/Entropy512/initramfs_sgh-i997r
Note: If someone creates a better "master" repo for everyone to track, I'll happily edit this post to point there.
Update: Merged a pull request from LinuxBozo that has a bunch of .gitignore fixes and Makefile fixes.

Good work! Looking now.

Entropy512 said:
Inspired by supercurio creating a master git repo for SGH-I997R development, I'm in the process of uploading today's source release from Samsung of the Gingerbread kernel for the Rogers Infuse 4G. (I'm surprised none of the other kernel hackers here have already done it... )
See supercurio's post http://forum.xda-developers.com/showthread.php?t=1054738 for more info on why git is good, and superior to kernel devs using tarballs directly from Samsung. This method is already unofficially how the kernel devs have been working - nearly every kernel here is forked from gtg465x's github repo.
I don't plan on directly doing development on this repo - It's just here as a starting point for everyone else to fork from. Some of us have slow upstream, so it's easier to pull a fork than it is to push a tarball import. However I might consider pulling in basic fixes to this repo (.gitignore, Makefile fixes - basically the same things supercurio has fixed in his unified git repos)
The repo is located at https://github.com/Entropy512/linux_kernel_sgh-i997r - There is nothing visible there yet as the push is still in progress. It should be done within 30 minutes or so.
I don't have an initramfs repo yet - we need an initramfs dump from a device first.
Note: If someone creates a better "master" repo for everyone to track, I'll happily edit this post to point there.
Click to expand...
Click to collapse
Absolutely awesome news :-D
Sent from my SAMSUNG-SGH-I997 using XDA Premium App

Oh blast, hadn't even seen that kernel code was available... thanks Entropy!

A personal favor I'd like to ask of people forking - try to keep things to one feature per commit. An example being LinuxBozo's ext4 backport to the Froyo kernels - it was simple and easy to apply to other kernels. As opposed to someone had a massive supercommit that added a whole bunch of stuff at once, making it hard to either pick-and-choose or hard to apply if they had already applied a single-feature commit for one of the features. (One example being a commit that combined something like TinyRCU, jhash3, and BFQ all in one. I don't remember exactly what it was.)

Entropy512 said:
A personal favor I'd like to ask of people forking - try to keep things to one feature per commit. An example being LinuxBozo's ext4 backport to the Froyo kernels - it was simple and easy to apply to other kernels. As opposed to someone had a massive supercommit that added a whole bunch of stuff at once, making it hard to either pick-and-choose or hard to apply if they had already applied a single-feature commit for one of the features. (One example being a commit that combined something like TinyRCU, jhash3, and BFQ all in one. I don't remember exactly what it was.)
Click to expand...
Click to collapse
Defuse kernel
Sent from my SAMSUNG-SGH-I997 using XDA Premium App

Is that all we needed for gb roms or is there still more needed?
Sent from my SAMSUNG-SGH-I997 using XDA Premium App

nelomen said:
Is that all we needed for gb roms or is there still more needed?
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
Click to expand...
Click to collapse
Initramfs, radio firmware dump, proper /system dump. Ours is incomplete.

Updates:
Merged LinuxBozo's pull request with build fixes
Merged LinuxBozo's pull request with the rainbow fix
Added initramfs repo

Entropy512 said:
Updates:
Merged LinuxBozo's pull request with build fixes
Merged LinuxBozo's pull request with the rainbow fix
Added initramfs repo
Click to expand...
Click to collapse
Nice!! Anything buildable yet?

ookba said:
Nice!! Anything buildable yet?
Click to expand...
Click to collapse
should be buildable since initramfs is available, tomorrow gtg's voodoo commit should be available too. this is all very exciting.

ookba said:
Nice!! Anything buildable yet?
Click to expand...
Click to collapse
A few more things got pulled in last night.
Kernel - not much
Initramfs - Working CWM - or at least it comes up, it hasn't been fully tested functionally yet
As of last night a few people have custom kernels running including myself, although some people still can't boot them. CWM wasn't working until past midnight...
Next up is voodoo - Not sure if I'll include that in the main initramfs repo or not. Maybe as a branch. It is a fairly standard mod, so it should be in a readily accessible repo

Bad news - as I said before CWM hadn't been fully tested.
Apparently, after further testing, it still does indeed have some pretty severe issues.

Sadface
10c

P1 Wookie said:
Sadface
10c
Click to expand...
Click to collapse
We have what seems to be working CWM and Voodoo thanks to gtg - in testing now.
The trolls in IRC aren't helping. Not a good time for the ops to be AFK.

trolls suck.
GL guys.

Entropy512 said:
We have what seems to be working CWM and Voodoo thanks to gtg - in testing now.
The trolls in IRC aren't helping. Not a good time for the ops to be AFK.
Click to expand...
Click to collapse
Gotta love the trolls.
Good luck guys. I know you all will figure it out

Well, thanks to the blasted trolls and the unfortunate circumstance of my only internet being my phone, I'm borked from being able to participate in the main infuse4g room as webchat is banned (for a good reason) and I can't get past the SASL issue otherwise.... oh well.

bedwa said:
Well, thanks to the blasted trolls and the unfortunate circumstance of my only internet being my phone, I'm borked from being able to participate in the main infuse4g room as webchat is banned (for a good reason) and I can't get past the SASL issue otherwise.... oh well.
Click to expand...
Click to collapse
why no use of a client?

drowningchild said:
why no use of a client?
Click to expand...
Click to collapse
Finally got it to work, had to hack a command line client.... urg.

ICS Binary for Tegra2 released

Hi,
Nvidia has just release binary and tools to build ICS ROM for Tegar2 plateforme...
http://developer.nvidia.com/tegra-resources
Bye

looks like (a lot of) the stuff needed to get our own built AOSP image running properly on the TF101.
Who knows, we might see a proper ICS rom before Asus releases their own .

I cant wait to see a ics-rom on my TF101!
Sent from my Galaxy Nexus using xda premium

Ohhhh... Nice.... I'm new around here does the transformer have a dev that build aosp roms from source (not kanged)

That page has been around forever and doesn't have what is necessary to get AOSP on pretty much anything.
There's been a few accounts posting that all around the same time frame the last few days all over the Tegra based device forums.....hmmmmmm.

thanks for this!reading ics 3ad it seems that it isn't so usefull...(http://forum.xda-developers.com/showpost.php?p=21768082&postcount=361)what are you think about that?

They posted an ICS device image for ventana. We can pull the required binaries from there as a starting point rather than trying to get ICS to work with the binaries pulled from honeycomb.
I'm downloading it now.
Thanks for the post!

daoist said:
They posted an ICS device image for ventana. We can pull the required binaries from there as a starting point rather than trying to get ICS to work with the binaries pulled from honeycomb.
I'm downloading it now.
Thanks for the post!
Click to expand...
Click to collapse
...we already have binaries that work with ICS, I've had builds in the public with working (and very smooth) graphics for weeks. If these ones are comparable then it'll be a nice source to pull them from, build a ROM without having to pull from a device etc. but they don't make anything any easier as you suggest.

paulburton said:
...we already have binaries that work with ICS, I've had builds in the public with working (and very smooth) graphics for weeks. If these ones are comparable then it'll be a nice source to pull them from, build a ROM without having to pull from a device etc. but they don't make anything any easier as you suggest.
Click to expand...
Click to collapse
But isn't there a new kernel in there or something to help with the (deep) sleep problems? Or is the reference board too diferent from our TF101 board?

It's all quite helpful. Cribbing stuff from a working compile is going to be easier than doing it from scratch.

dipje said:
But isn't there a new kernel in there or something to help with the (deep) sleep problems? Or is the reference board too diferent from our TF101 board?
Click to expand...
Click to collapse
There's a kernel binary, sure. It won't run on the TF101 though because as you mention it's not the same board. Ok, maybe it would run, but if it does then it'll have all the wrong peripheral setup etc. The source for the kernel is (presumably) the same nvidia source that's been available for a while and is the basis of the TF101 kernel I've been working on, so it shouldn't be significantly different.
daoist said:
It's all quite helpful. Cribbing stuff from a working compile is going to be easier than doing it from scratch.
Click to expand...
Click to collapse
'Cribbing' what exactly? I'm not sure what you think you can usefully take from this.

paulburton said:
There's a kernel binary, sure. It won't run on the TF101 though because as you mention it's not the same board. Ok, maybe it would run, but if it does then it'll have all the wrong peripheral setup etc. The source for the kernel is (presumably) the same nvidia source that's been available for a while and is the basis of the TF101 kernel I've been working on, so it shouldn't be significantly different.
'Cribbing' what exactly? I'm not sure what you think you can usefully take from this.
Click to expand...
Click to collapse
All the proprietary binaries/configs/etc. The sort of stuff we'd pull via extract-files.sh. Right now you've done an excellent job building it up from what we had in honeycomb. Now we have known-good files from ICS.

daoist said:
All the proprietary binaries/configs/etc. The sort of stuff we'd pull via extract-files.sh. Right now you've done an excellent job building it up from what we had in honeycomb. Now we have known-good files from ICS.
Click to expand...
Click to collapse
Well, no. The _only_ things that I intend to use binaries for are the graphics drivers and bluetooth firmware. Bluetooth firmware doesn't care at all which version of android you're running, so we can ignore that. Which just leaves graphics drivers, which are already taken from an ICS ROM (fortunately the TF101 isn't the only tegra 2 tablet!).

defy cm10.1 alpha

this is just a demo of a kernel based on quarx 3.0.8 kernel sources,maybe later i'll try to merge several fixes or something but till then lets say i've reached a small milestone like finishing to compile this kernel,booting it up,take some screenshots from it.
known bugs,just like initial quarxs or blenchose commits.
Warning:flash at your own responsability,works only with cm 10.1 under boot options by ticking 2ndboot and ticking adb disable
link to kernel:http://www.mediafire.com/?vdjoj438tlvz2lw
NOTE:kernel sources are based on quarx repo on github:https://github.com/Quarx2k/jordan-kernel

What's this? A fix for CM10.1 23/01?

I think it's a 3.0 kernel... so not a fix.

i think , quarx2k also made many changes with his CM 10.1-3.0 branch which corresponds to the 3.0 kernel ..( eg - hwcomposer sources)
so it will be better if u can compile and upload both ROM + KERNEL package in order to have maximum working efficiency

Shubhamqweasd said:
i think , quarx2k also made many changes with his CM 10.1-3.0 branch which corresponds to the 3.0 kernel ..( eg - hwcomposer sources)
so it will be better if u can compile and upload both ROM + KERNEL package in order to have maximum working efficiency
Click to expand...
Click to collapse
you're right,because i could not boot this kernel on 4.1.2 so tried with 4.2.1 without adb manual boot,the difference is that i added forced module unloading and allow old eabi binaries to run with this kernel trying to get some backwards compatibility thus my conclusion is that either this kernel needs scratch bins in the os for propper functioning

rodrigoswz said:
What's this? A fix for CM10.1 23/01?
Click to expand...
Click to collapse
nope,my bad to mention that is an kernel build on quarx repo

You know opening a new thread was unnecessary as we already have a 3.0 kernel thread and CM10.1 also.... BTW the kernel and CM10.1 are both easily compiled if you know what you're doing
Let's Go ^_^

Kayant said:
You know opening a new thread was unnecessary as we already have a 3.0 kernel thread and CM10.1 also.... BTW the kernel and CM10.1 are both easily compiled if you know what you're doing
Let's Go ^_^
Click to expand...
Click to collapse
The thread is already reported
Sent from my MB526 using xda premium

nogoodusername said:
The thread is already reported
Sent from my MB526 using xda premium
Click to expand...
Click to collapse
thank you for your support nogood username,that helps alot and to what i can do for this comunity,for example my own kernel sources for linux kernel 3.7.5,as of this post was just an test to see if it works and 3.7.5 yup it likes the cpcap drivers and firmware,just some gpu issues to display under menuconfig

drunk_ryder24 said:
thank you for your support nogood username,that helps alot and to what i can do for this comunity,for example my own kernel sources for linux kernel 3.7.5,as of this post was just an test to see if it works and 3.7.5 yup it likes the cpcap drivers and firmware,just some gpu issues to display under menuconfig
Click to expand...
Click to collapse
I appreciate your work, and I'm not the one that reported (as far as I remember)
Sent from my MB526 using xda premium

nogoodusername said:
I appreciate your work, and I'm not the one that reported (as far as I remember)
Sent from my MB526 using xda premium
Click to expand...
Click to collapse
maybe i started wrong but my intention was to give some help for the comunity,as for my attempt on kernel 3.7.5:bump cant port sgx drivers,got cpcap to show up in menuconfig even mapphone but its like impossible to show up,tried a workaround with similar devices to get the gpu drivers but no chance

drunk_ryder24 said:
maybe i started wrong but my intention was to give some help for the comunity,as for my attempt on kernel 3.7.5:bump cant port sgx drivers,got cpcap to show up in menuconfig even mapphone but its like impossible to show up,tried a workaround with similar devices to get the gpu drivers but no chance
Click to expand...
Click to collapse
Thanks for your efforts I think I was the one that reported it can't remember now ..... The reason I did it was because like you said you're trying to port 3.7.5 which we already have thread for where you cab discuss about porting 3.0.0 kernels
Some advice and questions......
I was wondering why are you trying to port 3.7.5 which is not even on any other android device yet??
IMO I think a higher version of the 3.0 base kernel is not needed as am sure most of the new things in it would not benefit us as we probably couldn't use it anyway since we have old drivers, old cpu/gpu etc.....
Getting it to show up in defconfig is not the hard part you can activate anything you want from there they are just the configuring files the hard part is configuring the activated drivers for the defy which requires dev work and debugging just look Quark's commits
I think what we have is fine and I don't think anything much higher would be any benefit for us also we have older drivers and the things we need for 4.2 to work properly are in 3.0.8 like the new wifi drivers maybe Quarx will update it to a higher minor version later like he did with 2.6.32.9 to 2.6.32.60......
Don't worry yourself to much there are many other things you can do to help us in the defy community. This is not worth your time trust me from experience :cyclops:
Btw the menuconfig iust activates the stuff you want for your device and mapphone_defconfig is where all the options you picked from menuconfig is stored. Each defconfig is different as they are specify to one device.

Kayant said:
Thanks for your efforts I think I was the one that reported it can't remember now ..... The reason I did it was because like you said you're trying to port 3.7.5 which we already have thread for where you cab discuss about porting 3.0.0 kernels
Some advice and questions......
I was wondering why are you trying to port 3.7.5 which is not even on any other android device yet??
IMO I think a higher version of the 3.0 base kernel is not needed as am sure most of the new things in it would not benefit us as we probably couldn't use it anyway since we have old drivers, old cpu/gpu etc.....
Getting it to show up in defconfig is not the hard part you can activate anything you want from there they are just the configuring files the hard part is configuring the activated drivers for the defy which requires dev work and debugging just look Quark's commits
I think what we have is fine and I don't think anything much higher would be any benefit for us also we have older drivers and the things we need for 4.2 to work properly are in 3.0.8 like the new wifi drivers maybe Quarx will update it to a higher minor version later like he did with 2.6.32.9 to 2.6.32.60......
Don't worry yourself to much there are many other things you can do to help us in the defy community. This is not worth your time trust me from experience :cyclops:
Btw the menuconfig iust activates the stuff you want for your device and mapphone_defconfig is where all the options you picked from menuconfig is stored. Each defconfig is different as they are specify to one device.
Click to expand...
Click to collapse
thats the whole point,everithing gets trouc the cross compiler even battery and every hw aspect for defy,but cant seem to get sgx drivers on it it boots but only backlight flickers,also the importance of this is that one day we might bump in a problem like this(maybe future android versions will use kernel 3.7.5 as default)and my opinion is that we should have some widen experience about it in any way possible

Kayant said:
Thanks for your efforts I think I was the one that reported it can't remember now ..... The reason I did it was because like you said you're trying to port 3.7.5 which we already have thread for where you cab discuss about porting 3.0.0 kernels
Some advice and questions......
I was wondering why are you trying to port 3.7.5 which is not even on any other android device yet??
IMO I think a higher version of the 3.0 base kernel is not needed as am sure most of the new things in it would not benefit us as we probably couldn't use it anyway since we have old drivers, old cpu/gpu etc.....
Getting it to show up in defconfig is not the hard part you can activate anything you want from there they are just the configuring files the hard part is configuring the activated drivers for the defy which requires dev work and debugging just look Quark's commits
I think what we have is fine and I don't think anything much higher would be any benefit for us also we have older drivers and the things we need for 4.2 to work properly are in 3.0.8 like the new wifi drivers maybe Quarx will update it to a higher minor version later like he did with 2.6.32.9 to 2.6.32.60......
Don't worry yourself to much there are many other things you can do to help us in the defy community. This is not worth your time trust me from experience :cyclops:
Btw the menuconfig iust activates the stuff you want for your device and mapphone_defconfig is where all the options you picked from menuconfig is stored. Each defconfig is different as they are specify to one device.
Click to expand...
Click to collapse
and how is that a problem if someone wants to attempt a higher version kernel?
if there is no benefit then there is no loss either

I understand your point and even I know nothing is impossible.
BUT, there has to be a logic in things that you are doing, isn't it? Believe me, Nobody is discouraging him. Anyways, its a matter of understanding and not a debate.
FYI and to my knowledge, very few devices like xperia T/V has kernel 3.4

abhifx said:
and how is that a problem if someone wants to attempt a higher version kernel?
if there is no benefit then there is no loss either
Click to expand...
Click to collapse
Like brajesh.sharma87 said am not trying to discourage him anything am just giving him some advice. This is mainly just my opinion based on experiences I had trying to port the newer wifi drivers from 3.0 base to our 2.6 kernel..... he doesn't have to listen to what am saying.
Like brajesh.sharma87 said it's matter of knowledge because the Linux kernel changes so much between versions and the work Quarx has done on the 3.0.8 base may become outdated and needs to be changed to get it to work for the new base.
Am just trying to put things into prospective as I think it's not worth his time and effort trying to port a higher version kernel without good knowledge and experience on kernel porting. Again that's for him to decide.
Drunk_ryder24 if you still want to try here are is something you can do that may help -
If you haven't already tried this but try cherry-picking Quarx's commits from the p-android-omap3-3.0 branch since the code is related to the defy but keep in mind not all of Quarx's work may work on the new base.

Kayant said:
Like brajesh.sharma87 said am not trying to discourage him anything am just giving him some advice. This is mainly just my opinion based on experiences I had trying to port the newer wifi drivers from 3.0 base to our 2.6 kernel..... he doesn't have to listen to what am saying.
Like brajesh.sharma87 said it's matter of knowledge because the Linux kernel changes so much between versions and the work Quarx has done on the 3.0.8 base may become outdated and needs to be changed to get it to work for the new base.
Am just trying to put things into prospective as I think it's not worth his time and effort trying to port a higher version kernel without good knowledge and experience on kernel porting. Again that's for him to decide.
Drunk_ryder24 if you still want to try here are is something you can do that may help -
If you haven't already tried this but try cherry-picking Quarx's commits from the p-android-omap3-3.0 branch since the code is related to the defy but keep in mind not all of Quarx's work may work on the new base.
Click to expand...
Click to collapse
well ive done cherry picking from quarx repo and i must say that quarx done an excelent job compiling the modules since they are recognized and compiled by the toolchain with no major errors,just a few ignorable errors,boy quarx must have nerves of steel to bare so much time in developing from scratch,oh btw i will post this as a reply in 4.1.2 tread,ive mixed kernel zimage and ramdisk of quarx 2.6.32.60 after applying sevenrock's kernel 2.6.32.9-the whole point is that it might have been something changed in either ril or wifi module cause 2.6.32.60 seems just a little laggy but no ringtone bug or reboots by this method

drunk_ryder24 said:
well ive done cherry picking from quarx repo and i must say that quarx done an excelent job compiling the modules since they are recognized and compiled by the toolchain with no major errors,just a few ignorable errors,boy quarx must have nerves of steel to bare so much time in developing from scratch,oh btw i will post this as a reply in 4.1.2 tread,ive mixed kernel zimage and ramdisk of quarx 2.6.32.60 after applying sevenrock's kernel 2.6.32.9-the whole point is that it might have been something changed in either ril or wifi module cause 2.6.32.60 seems just a little laggy but no ringtone bug or reboots by this method
Click to expand...
Click to collapse
That sounds good am I bit surprised it worked so well with not that much errors but thats's good Yh I know Quarx is unstoppable and good luck with the project ..... If you need any more advice or help just shoot me up with a pm and I will see what I can do

kayant said:
that sounds good am i bit surprised it worked so well with not that much errors but thats's good yh i know quarx is unstoppable and good luck with the project :d..... If you need any more advice or help just shoot me up with a pm and i will see what i can do
Click to expand...
Click to collapse
thanks for your support,its wellcomed

[Q] Gcc toolchain for kernel compiling?

Just wondering what toolchain I should be using to compile the kernel for this phone.
I tried the arm-eabi-4.4.3 that comes built with the AOSP-SDK package however that does not seem to work correctly.
Right now I have both Arrrghhh's repo and the one Linus maintains on my machine. The only "internet" I have is from tethering my phone though so I am limited on what I can download and try.
BTW, I also have a few of the Android source repos "synced" already like CM, AOKP, & AOSP, I figured I would start with kernels though.
EDIT: Also I should mention that I have compiled kernels before, however only deb-pkg's for Ubuntu. Sooo just looking for a little cross-compiling help. :/

HAHA I feel like a noob now but nevermind.
Found here: forum.xda-developers.com/showthread.php?t=1748297 ; I just needed this github.com/DooMLoRD/android_prebuilt_toolchains.git
Thanks to Arrrghhh for the "maek" script left in his reop. I will be experimenting with different configs and version patches....

That script is sweet! Kanged from Shabbypenguin .
Enjoy!!

No doubt! I am happy! Thanks again!! If I get anything worthwhile patched in I could send you pull-requests if you like.
I was hung up on that for a long time, seems like linaro-4.6.2 works though.

[Q] Multirom?

Could multirom be ported to OPO users?
Would be so awesome for 64gb version !
Cheers

You must ask Tassadar, multirom creator, who will confirm (or not) if hardware is compatible
IF it is, we will have to wait for a compatible kernel

Also interested in seeing a Multirom port.

Would be interested as well. So @Tasssadar, can you help here?
EDIT: Just did a quick read on the wiki... Looks like we should be able to port it ourselves. Maybe I'll look into it when I find some time. But everyone is invited to do so as well!
EDIT2: See here: https://github.com/Tasssadar/multirom/wiki/Porting-MultiROM

As in FAQ:
Will you port MultiROM to device X?
No, probably. I won't port MultiROM to any device I don't own, because it is very difficult to provide the level of support I want to provide if I can't test things myself, as proven by the Nexus 4 port. I'll probably keep buying Nexus devices and keep porting MultiROM to those myself, but I can't buy every single device - I'm still a student, all my existing devices were bought using some kind of money grant or donations from users.
But, you can port it yourself, the wiki should give you at least some idea how to do that: https://github.com/Tasssadar/multirom/wiki/Porting-MultiROM​tl;dr: get me the device or port and maintain it yourself.
I won't know how "hard" (what does that even mean?) it is to port MultiROM to X until I have the device in my hands, but it should be possible. I see you've already found the wiki, there's a bit of info about porting there. Kexec-hardboot patch will be the "hardest", since you need to know a bit about how linux boots on ARM devices. Or just blind guessing, that seems to work for some people too.

Tasssadar said:
As in FAQ:
tl;dr: get me the device or port and maintain it yourself.
I won't know how "hard" (what does that even mean?) it is to port MultiROM to X until I have the device in my hands, but it should be possible. I see you've already found the wiki, there's a bit of info about porting there. Kexec-hardboot patch will be the "hardest", since you need to know a bit about how linux boots on ARM devices. Or just blind guessing, that seems to work for some people too.
Click to expand...
Click to collapse
Thanks, luckily I know some things about this already. So shouldn't be that hard for me. Hardest thing will be to find time to actually do it. As this device don't have an sdcard, that part is already covered. I do however have to take a look at the ramdisk for that patch...

Tasssadar said:
tl;dr: get me the device or port and maintain it yourself.
I won't know how "hard" (what does that even mean?) it is to port MultiROM to X until I have the device in my hands, but it should be possible. I see you've already found the wiki, there's a bit of info about porting there. Kexec-hardboot patch will be the "hardest", since you need to know a bit about how linux boots on ARM devices. Or just blind guessing, that seems to work for some people too.
Click to expand...
Click to collapse
Well if I win one I'll give it to you. Its the least I could do for all the great work you do for the community!
Thanks Tasssadar!

lol, I was just about to post about this. From what I remember the Devs for each of the other kernels just have to add in the multirom code in to their kernel for multirom support. Pretty easy from what I heard. Otherwise I reached out to the dev for multirom today to see if this will be coming to OPO.

synergeticink said:
lol, I was just about to post about this. From what I remember the Devs for each of the other kernels just have to add in the multirom code in to their kernel for multirom support. Pretty easy from what I heard. Otherwise I reached out to the dev for multirom today to see if this will be coming to OPO.
Click to expand...
Click to collapse
I already did this in the posts above... He won't support it himself, but we can port it ourselves. Looks not that hard.
Sent from my One using XDA Premium 4 mobile app

I'd love to see MultiRom on the OnePlus One as well. If someone could port it, that would be amazing!

Well it would be simply great

I've almost finished MultiROM port to the OPO. Just a few framebuffer things to fix

KINGbabasula said:
I've almost finished MultiROM port to the OPO. Just a few framebuffer things to fix
Click to expand...
Click to collapse
Awesome! Can't wait to see instructions to do this.

KINGbabasula said:
I've almost finished MultiROM port to the OPO. Just a few framebuffer things to fix
Click to expand...
Click to collapse
Impressive !
If you got a working version, that "donate to me" button of yours will be pressed

KINGbabasula said:
I've almost finished MultiROM port to the OPO. Just a few framebuffer things to fix
Click to expand...
Click to collapse
Great! Thanks for your awesome help.

Ok, so MultiROM works, TWRP works, kexec works BUT the boot menu is not visible (it's working but it shows completely black) still framebuffer problems. I can set the main ROM from TWRP and it gets booted correctly. So the last thing to fix is just the boot menu. It's completely usuable anyway from the recovery

sorry for the noob questions, i am not "inside" the multirom project...
will the installed roms share the same data partition...so you can switch between roms keeping everything else is installed on device?

No, this is not possible atm (if it's the same as for N5)
But the main advantage of multirom is for me: testing ROMs without loosing your daily driver. If you like the new rom, install your stuff and swap it to primary

beren said:
sorry for the noob questions, i am not "inside" the multirom project...
will the installed roms share the same data partition...so you can switch between roms keeping everything else is installed on device?
Click to expand...
Click to collapse
I confirm the data partition cannot be shared
@KINGbabasula :
You should already tell the kernel dev to include the k-exec boot patch, so we won't have to wait ages to have a compatible Kernel
@ak is very responsive for features requests

bud77 said:
I confirm the data partition cannot be shared
@KINGbabasula :
You should already tell the kernel dev to include the k-exec boot patch, so we won't have to wait ages to have a compatible Kernel
@ak is very responsive for features requests
Click to expand...
Click to collapse
Sure. I tested mahdi and slim rom and they work perfectly sharing my kexec'd kernel. PA sadly still doesn't because they use cm11s kernel so I can't set shared kernel (in short it's impossible to use it until they merge kexec patch). Anyone who wants to merge it in their kernel it's here: https://github.com/KINGbabasula/and...mmit/3e93ccd23a37cc5fa3140fc935a43362a678de37 and to enable it add this in defconfig:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_PROC_DEVICETREE=y