Hey all!
As some have seen, I have started serious work on getting kexec on the Droid X2 for Android 2.3.4. Here's what I have working so far:
Code:
[B]procfs_rw.ko[/B] - Creates an empty slot in /proc/atags so we can place our atags in.
[B]LOADED AND ACCEPTED BY INSMOD![/B]
Code:
[B]kexec_load.ko[/B] - The main kernel module of Kexec.
[B]LOADED AND ACCEPTED BY INSMOD![/B]
Code:
[B]kexec-tools[/B] - The actual kexec binary. This is what loads the new kernel and executes it.
Code:
[B]Motorola DX2 Test Kernel[/B] - Nothing more than the stock DX2 kernel with native kexec and atag support, along with "-twitish" appended to the kernel version.
What works so far:
I have gotten the kernel to accept the proc_rw as well as the kexec_load modules.
The ATAGS (Some, maybe not all) have been found and load just fine.
What we need:
Patience
What can you possibly do to help?
Tomorrow I'm going to do a write-up on how I got my development environment set-up and post my git-hub links. If you have any experience with Linux and/or kexec, I encourage you to try it out and see what you can find. I can't notice everything.
Please be aware that I am NOT PROMISING I CAN GET KEXEC WORKING!!!!! I'm simply stating what I have done, and what I need.
I have a feeling we are close...very very close.
GitHub source to come soon.
Let's please try and keep this thread clean!
IF YOU WANT TO SAY "KEEP IT UP!" OR "GOOD JOB!" OR SOMETHING LIKE THAT, PLEASE JUST LIKE THIS POST!!!
Reserved For Tutorial on how to compile and stuff. (not today)
Reserved for (HOPEFULLY) Final Release.
Exciting! Keep up the great work. This could open lots of doors for our phone!
Reading Comprehension-FAIL!
Pr0f_Farnsw0rth said:
Exciting! Keep up the great work. This could open lots of doors for our phone!
Click to expand...
Click to collapse
twitish said:
Let's please try and keep this thread clean!
IF YOU WANT TO SAY "KEEP IT UP!" OR "GOOD JOB!" OR SOMETHING LIKE THAT, PLEASE JUST LIKE THIS POST!!!
Click to expand...
Click to collapse
PROGRESS REPORT FOR 09/27/12:
I have extracted the necessary cdt.bin from the phone and after talking with [mbm] (creator of sbf_flash) I was able to extract the ATAGS from it. The ATAGS are accepted by kexec, the new kernel is loaded into RAM, and then *poof* it freezes when kexec is actually executed. I'm going to try and see what I can find tomorrow by looking through the source of kexec. I think the problem lies in the kexec-tools, it seems to be looking at an incorrect memory block. (The one it is looking at doesn't exist on our device).
Still haven't heard back from Kholk, however, here's hoping that I wake up tomorrow with a PM from him.
ONE STEP CLOSER...
Again, unless you have something to say that pertains to the actual development of kexec, don't post. Just click "Thanks".
twitish said:
PROGRESS REPORT FOR 09/27/12:
I have extracted the necessary cdt.bin from the phone and after talking with [mbm] (creator of sbf_flash) I was able to extract the ATAGS from it. The ATAGS are accepted by kexec, the new kernel is loaded into RAM, and then *poof* it freezes when kexec is actually executed. I'm going to try and see what I can find tomorrow by looking through the source of kexec. I think the problem lies in the kexec-tools, it seems to be looking at an incorrect memory block. (The one it is looking at doesn't exist on our device).
Still haven't heard back from Kholk, however, here's hoping that I wake up tomorrow with a PM from him.
ONE STEP CLOSER...
Again, unless you have something to say that pertains to the actual development of kexec, don't post. Just click "Thanks".
Click to expand...
Click to collapse
definitely cant wait to get this up and running.. i will definitely help when git is posted and see what i can do
I hate to be the "negative nacy" here, but unfortunately for twitish and the rest of the X2 community.... this is nothing new. If any of you have been following the work that I've done on kexec mine does the exact same thing, if not getting a bit further. I'm not trying to seem like the a-hole here crashing the party, but we can't sit here and think that at this state this is 'developement." In fact, it's not even up to date to what I have going for it because: the ATAGs
I highly doubt (as in I know) that whatever you have going in the /proc/atags is incorrect and will not properly load kexec. I have the correct atags data that we need. If you're willing to help me work on it, I will be willing to hand it over. But keep in mind that this isn't exactly something I'm just going to hand over easily, as they've been slightly tweaked for what we need.
As for why it's freezing (besides the atags thing). It is a problem with the cpu_reset function not properly working with ARMv7 platforms for 2.6.32 and it's even worse for the Tegra 2. Needless the say, from what I can tell, the caches aren't being properly cleared to allow the cpu to reset into the proper location with out it freaking out.
If you would like anymore information, please PM me here and I will give you more details.
dragonzkiller said:
I hate to be the "negative nacy" here, but unfortunately for twitish and the rest of the X2 community.... this is nothing new. If any of you have been following the work that I've done on kexec mine does the exact same thing, if not getting a bit further. I'm not trying to seem like the a-hole here crashing the party, but we can't sit here and think that at this state this is 'developement." In fact, it's not even up to date to what I have going for it because: the ATAGs
I highly doubt (as in I know) that whatever you have going in the /proc/atags is incorrect and will not properly load kexec. I have the correct atags data that we need. If you're willing to help me work on it, I will be willing to hand it over. But keep in mind that this isn't exactly something I'm just going to hand over easily, as they've been slightly tweaked for what we need.
As for why it's freezing (besides the atags thing). It is a problem with the cpu_reset function not properly working with ARMv7 platforms for 2.6.32 and it's even worse for the Tegra 2. Needless the say, from what I can tell, the caches aren't being properly cleared to allow the cpu to reset into the proper location with out it freaking out.
If you would like anymore information, please PM me here and I will give you more details.
Click to expand...
Click to collapse
Sent a PM. I'll start looking into the kexec code.
I figured you had the correct ATAGs, I knew you had been in contact with kholk and probably got them. As for me, mine were simply extracted from the CDT because that would at least give me a starting point.
No worries about being a negative nancy! Lol. I'd rather have someone come in and tell me I'm doing something wrong than waste my time following something that doesn't work.
I'm looking forward to future collaboration dragonzkiller. Hopefully we can get this working.
Progress Report!!
Hey guys!!! How are you?? I'm great now. Life is back to normal!!! Anyways, Here's some good news!!!
So, I got Kexec to finally REBOOT THE PHONE!!! However, it doesn't load the new kernel. It may have been a bad kernel though, as I haven't touched any of this since about a month ago. So! A new one is compiling right now.
I don't think it is the new kernel though, it probably has to do with either the incorrect ATAGs I'm probably using. (Haven't talked to DZK yet, WILL DO!!!) Or it's something else that I don't know. HA!
Anyways, I'm back. I'm all in. And I'm TRYING MY HARDEST to get you guys kexec.
I'm sure at this point it is a really simple fix. (HOPEFULLY!)
Tl;dr
It loads the new kernel, loads the initrd, REBOOTS!!! (it froze before), then reboots back into the stock kernel.
NEW INFO:
Compiled the new kernel, no-go. Freezes again. Hopefully DZK's ATAGs are the trick.
Sounds great. What kind of set up do you have and what are the requirements for setting up a machine to try and work on a kexec for the mx2 myself.
Sent from my CM10 MX2
Lrs121 said:
Sounds great. What kind of set up do you have and what are the requirements for setting up a machine to try and work on a kexec for the mx2 myself.
Sent from my CM10 MX2
Click to expand...
Click to collapse
Any sort of computer that you have will work. I'm using an older desktop with Arch Linux on it.
You just have to be able to set-up a cross-compiler, be comfortable enough with the Linux Kernel and have the proper files necessary to boot the new kernel.
twitish said:
Any sort of computer that you have will work. I'm using an older desktop with Arch Linux on it.
You just have to be able to set-up a cross-compiler, be comfortable enough with the Linux Kernel and have the proper files necessary to boot the new kernel.
Click to expand...
Click to collapse
Perfect ill have to get my Linux systme up and running and get on it. Ill have some stuff to look up but ill be on track with it soon
Sent from my CM10 MX2
twitish said:
Hey guys!!! How are you?? I'm great now. Life is back to normal!!! Anyways, Here's some good news!!!
So, I got Kexec to finally REBOOT THE PHONE!!! However, it doesn't load the new kernel. It may have been a bad kernel though, as I haven't touched any of this since about a month ago. So! A new one is compiling right now.
I don't think it is the new kernel though, it probably has to do with either the incorrect ATAGs I'm probably using. (Haven't talked to DZK yet, WILL DO!!!) Or it's something else that I don't know. HA!
Anyways, I'm back. I'm all in. And I'm TRYING MY HARDEST to get you guys kexec.
I'm sure at this point it is a really simple fix. (HOPEFULLY!)
Tl;dr
It loads the new kernel, loads the initrd, REBOOTS!!! (it froze before), then reboots back into the stock kernel.
NEW INFO:
Compiled the new kernel, no-go. Freezes again. Hopefully DZK's ATAGs are the trick.
Click to expand...
Click to collapse
I would suggest seeing if it can load a different stock kernel so you rule out that its a problem with the kernel.
Sent from my Galaxy Nexus using xda app-developers app
redwingfaninnc said:
I would suggest seeing if it can load a different stock kernel so you rule out that its a problem with the kernel.
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
The kernel that I'm trying to load is a stock kernel. It's just I was trying out some stuff and it may have been one of my experiments.
Sent from my XT912 using xda app-developers app
You need to check /data/system/dropbox after the system "reboots." If at any point the phone showed the Motorola logo it was because of a kernel panic and not because of a kexec reboot. In that folder there should be gziped files about APAINC_CONSOLE. That contains the dmesg of what was happening when the panic occurred. Probably a bad pointer or a pointer to a NULL space in memory.
dragonzkiller said:
You need to check /data/system/dropbox after the system "reboots." If at any point the phone showed the Motorola logo it was because of a kernel panic and not because of a kexec reboot. In that folder there should be gziped files about APAINC_CONSOLE. That contains the dmesg of what was happening when the panic occurred. Probably a bad pointer or a pointer to a NULL space in memory.
Click to expand...
Click to collapse
Is it weird that I'm impressed by every post you make? It's weird, isn't it.
Sent from my MB870 using xda app-developers app
dragonzkiller said:
You need to check /data/system/dropbox after the system "reboots." If at any point the phone showed the Motorola logo it was because of a kernel panic and not because of a kexec reboot. In that folder there should be gziped files about APAINC_CONSOLE. That contains the dmesg of what was happening when the panic occurred. Probably a bad pointer or a pointer to a NULL space in memory.
Click to expand...
Click to collapse
Collaboration
Sent from my MB870 using xda app-developers app
definitely love reading collaboration between devs trying to fix a phone that was abandoned by a good phone company (other than not unlocking the bootloader on the droid x2)
dragonzkiller said:
You need to check /data/system/dropbox after the system "reboots." If at any point the phone showed the Motorola logo it was because of a kernel panic and not because of a kexec reboot. In that folder there should be gziped files about APAINC_CONSOLE. That contains the dmesg of what was happening when the panic occurred. Probably a bad pointer or a pointer to a NULL space in memory.
Click to expand...
Click to collapse
I checked it. And no, the Motorola logo did not show.
If anything, it might have just soft rebooted randomly. Knowing this phone that's not out of the question. Lol.
Related
This is more of a general suggestion to those making the TB GB roms and adding the kernel to them or thinking about it..
Since it would appear reading through the posts and trying out the kernel for myself, I have found that the current GB kernel just gives my phone fits and it appears that other's have the same issue. I know it works for some, wish mine did. But can we get or keep the GB Roms separate from the kernel for a bit?
My phone runs GB fine without the kernel, and it sounds like it runs fine for others as well, since the kernel appears to add issues, it makes it hard to try out Roms that have the kernel included.
Its just a suggestion and at least at some point down the road I (or we) could try the kernel(s) as it matures more. And for those that the kernel works on, they can use it..
Thanks!
If your talking about random reboots just let it throw a few, every time I change a GB kernel I get a few, then after that it's totally fine.
Me too. Mine usually reboots a few times right after I install and then just works.
Sent from my ADR6400L using XDA Premium App
I don't quite get what you're saying. Every rom has a kernel. It's basically what allows the software to communicate with the hardware. You can't take the kernel out of a rom or you don't have a complete functional operating system.
You need to remember that the leak was a test version, kind of like a cyanogenmod nightly. So things are going to be broken. They will fix them over time, especially as new leaks emerge.
In the meantime, if you are having problems, just go back to froyo for now. It's fast and fully functional. Gingerbread will be unleashed with ALL of it's greatness soon enough. Then we'll be anxiously awaiting ice cream sandwich
sent via rooted THUNDERBOLT with Tapatalk
sgtguthrie said:
I don't quite get what you're saying. Every rom has a kernel. It's basically what allows the software to communicate with the hardware. You can't take the kernel out of a rom or you don't have a complete functional operating system.
You need to remember that the leak was a test version, kind of like a cyanogenmod nightly. So things are going to be broken. They will fix them over time, especially as new leaks emerge.
In the meantime, if you are having problems, just go back to froyo for now. It's fast and fully functional. Gingerbread will be unleashed with ALL of it's greatness soon enough. Then we'll be anxiously awaiting ice cream sandwich
sent via rooted THUNDERBOLT with Tapatalk
Click to expand...
Click to collapse
He means including the modified kernel in the ROMs, and rather having users flash the modified version optionally. I think it is a valid point, and the kernel is something that is unrelated to the official release of Gingerbread. New kernels will come and the current ones are being worked on. What you may want to try is going into console and using speedtweak.sh to up the voltage if you are having reboot problems.
I know it gets hard to answer every question with a meaningless philosophical argument invalidating the question itself, but then again the forum has a minimum post count.
twistedumbrella said:
He means including the modified kernel in the ROMs, and rather having users flash the modified version optionally. I think it is a valid point, and the kernel is something that is unrelated to the official release of Gingerbread.
Click to expand...
Click to collapse
Exactly, I have no problem running the default kernel that comes with GB Gingerjane 1.2 Rom as their is another kernel to possibly fix camera issues and they are separate downloads. Once I load that kernel I start having all kinds of problems, I restore my backup and all is good. I have seen some posts that others run into a similar issue. I thought it would just be good to keep them separate right now if possible. Its possible that some of the other GB Roms would work too, but I have the same issue with those and they include the new kernel as well for camera fix. So I have assume (I know bad word) that the common issue with mine and possibly others just could be that kernel for whatever reason.
twistedumbrella said:
He means including the modified kernel in the ROMs, and rather having users flash the modified version optionally. I think it is a valid point, and the kernel is something that is unrelated to the official release of Gingerbread. New kernels will come and the current ones are being worked on. What you may want to try is going into console and using speedtweak.sh to up the voltage if you are having reboot problems.
I know it gets hard to answer every question with a meaningless philosophical argument invalidating the question itself, but then again the forum has a minimum post count.
Click to expand...
Click to collapse
"Meaningless philosophical argument"? I really don't see where you get that from, but whatever...
Also, a low post count doesn't mean you're a noob, just not as active at xda. This isn't the only forum site on the Internet.
I just saw something on twitter, jcase was posting the stock gb kernel in his thread, so there you go...
Edit: it's posted, happy flashing...
http://forum.xda-developers.com/showthread.php?t=1082001
Edit 2:
It's in the lightning rom thread too.
sent via rooted THUNDERBOLT with Tapatalk
sgtguthrie said:
I just saw something on twitter, jcase was posting the stock gb kernel in his thread, so there you go...
Edit: it's posted, happy flashing...
http://forum.xda-developers.com/showthread.php?t=1082001
Edit 2:
It's in the lightning rom thread too.
sent via rooted THUNDERBOLT with Tapatalk
Click to expand...
Click to collapse
Thanks.. that works too.
http://forum.xda-developers.com/showthread.php?t=1158951
That can probably be done with this phone since it uses the same chipset as the E3D and Sensation. Once I get mine next tuesday/wednesday ill see what I can do about getting this module to work.
If anyone takes a look at it, post anything you have tried. This could in theory at the very least allow an undervolt which would help offset the LTE power sucking.
Yeah see I wwas talking about this earlier. I think this will work. I PMed viperboy who actually wrote one of the bloatware scripts when we had temproot. Just waiting for a response AMD hope to get a jump start on this. Good idea starting this thread tho
Sent from my ADR6425LVW using Tapatalk
reverepats said:
Yeah see I wwas talking about this earlier. I think this will work. I PMed viperboy who actually wrote one of the bloatware scripts when we had temproot. Just waiting for a response AMD hope to get a jump start on this. Good idea starting this thread tho
Sent from my ADR6425LVW using Tapatalk
Click to expand...
Click to collapse
Coming from the bravoc which has almost zero development aside from 2fast at his site I am used to just thinking of things to try. I was able to port a couple dinc roms to it even though I was told it couldn't be done. I hope to be much more involved with development here since there are already more posts in this section than there were in a year at the site dedicated to the bravoc
con247 said:
Coming from the bravoc which has almost zero development aside from 2fast at his site I am used to just thinking of things to try. I was able to port a couple dinc roms to it even though I was told it couldn't be done. I hope to be much more involved with development here since there are already more posts in this section than there were in a year at the site dedicated to the bravoc
Click to expand...
Click to collapse
Yeah I.hear ya. I.haven't gotten much Involved myself buy then again I'm no dev LOL. But I k.ow my way around a bit. But I think the dev section is gonna he hoppin as well.
Sent from my ADR6425LVW using Tapatalk
It took a few days to get that inc port almost bugfree (usb pc transfer wouldn't work) but it was otherwise fine iirc. I hope that with support and other work to use as examples i can make some stuff for this device that isn't either a variation of AOSP or a sense port that has some serious drawbacks.
I am personally more interested in the possibility of underclocking and undervolting than OCing. Or maybe OCing and undervolting like I did with my droid x - can really help save some battery and allow the phone to sip less juice. This phone is so new I am getting ahead of myself, but hopefully in time we can get root/roms/OCing and undervolting apps to work on the Rezound.
I normally run my battery on performance mode on all my phones. I set it to normal, and with the equivalent usage I get 1/3 better battery life. I even leave all my antenna's on(except WiFi when I am away).
Just to let everyone know what I tried. I took the file for "unsupported phones" from the link's thread and changed the version number to match the rezound, which is -- 2.6.35.13-g20c5d1d -- . As you can see it was not just the ending part starting with the 'g' that needed to be changed as ours is 2.6.35.13 and the file was made for 2.6.35.10. But since a reboot resets everything I tried it by changing only the part starting with 'g' and it failed saying "Exec format error". So I then changed the entire version string to match ours and adb actually completed the task but the phone rebooted immediately and everything was wiped out again.
I did this before the kernel source was put up on the forums but since I dont have ANY knowledge of messing with kernels I am no help there, but hopefully this can help someone get this mod going for the Rezound.
we don't have perma root like the 3vo did so I don't think this will work until then. But this was a band aid until the kernel source was released so this won't even be necessary anymore.
con247 said:
we don't have perma root like the 3vo did so I don't think this will work until then. But this was a band aid until the kernel source was released so this won't even be necessary anymore.
Click to expand...
Click to collapse
The guy who made Setcpu made a script that allowed oc on the stock kernel on the 3D. It was before perm root. It was right after agrabren found the first exploit and a reboot would return the phone to stock. You temp rooted ran the script from adb and used Setcpu to oc.. Some of the smoothest kernel action the 3D had.. I'm sure same thing is potentially there, just need someone smart enough to do..
Sent from my PG86100 using xda premium
send me a link. Ill take a look at the script.
pstevep said:
The guy who made Setcpu made a script that allowed oc on the stock kernel on the 3D. It was before perm root. It was right after agrabren found the first exploit and a reboot would return the phone to stock. You temp rooted ran the script from adb and used Setcpu to oc.. Some of the smoothest kernel action the 3D had.. I'm sure same thing is potentially there, just need someone smart enough to do..
Sent from my PG86100 using xda premium
Click to expand...
Click to collapse
Yeah I rememba that man. I was just talking about that the other day. I also mentioned that maybe we can use that somehow but I wouldn't know where TP start. But we need a stable Temp Root first I think. Not degrading anyone's work either.
Sent from my ADR6425LVW using Tapatalk
con247 said:
send me a link. Ill take a look at the script.
Click to expand...
Click to collapse
It will take me a little time to find. I don't think I have the script on sd anymore and the thread is buried deep. I shall go look.
Edit: ironically easier than I thought to find. Here is the thread from the 3D forum.
http://forum.xda-developers.com/showthread.php?t=1158951
And I know for a fact this worked and worked well. I used for a while, well up until we were s-off..
Sent from my PG86100 using xda premium
sooooooo set cpu works with root....i made a profile for screen off. seems to be working.....
combatmedic870 said:
sooooooo set cpu works with root....i made a profile for screen off. seems to be working.....
Click to expand...
Click to collapse
Cool. I did find a tidbit that might (don't get your hopes up and basically pretend I didn't even say this) make root last longer. Obviously until I have my rezound for the next few days I can't even think about testing anything.
Then put it out there for us to test! Don't be selfish! lol
AtLemacks said:
Then put it out there for us to test! Don't be selfish! lol
Click to expand...
Click to collapse
I will once I get around to writing it. I am in class right now then I am driving 5 hours home. So maybe tomorrow afternoon Ill get a script working. Also, I may have figured out a way to disable elements of sense in an automated script(for those that don't like sense).
con247 said:
It took a few days to get that inc port almost bugfree (usb pc transfer wouldn't work) but it was otherwise fine iirc. I hope that with support and other work to use as examples i can make some stuff for this device that isn't either a variation of AOSP or a sense port that has some serious drawbacks.
Click to expand...
Click to collapse
Since I happened to venture to theses parts since our buddy plat ventured to this. I am a bit surprised to see you switched. How ever the module you are talking about in the op I am pretty sure you can't just hex edit the kernel version. As the kernel will be different for the device compared to that of the evo 3d. If it is anything like doing the g2 version for the htc merge that is. Where it had to be recompiled to work correctly.
I am sure one of the dev's familiar in here with building source code could get it done up. If it works after that I am unsure. Though con you ported the sense hd rom from the inc to the desire. That was the only one that you had ported. Followed by you followed samuel2706's guide and other info he gave you. Then you came to me to ask how I fixed the mms and verizon branding in the rom. In which I told you how to fix it but you put it off as you fixed it. As you are putting off in here.
THIS PAGE IS OUT OF DATE AND IS NO LONGER VALID
First off, I know that' I've been working on CWMR for the DX2 also. During this work though I found myself looking back at the CM7 source for hijacking and found myself getting a lot farther than I have in the past with the Motorola common hijack. CM7 is not booting yet, but this is the closest we've ever been. Special thanks to MoonShadow-NM, StringCheeseCR and balltongue for being my guinea pigs, mastafunk for helping get 2nd-init isssues worked out with our phone, and hashcode for helping me port the final steps of the hijack. I'm going to try to make this a lot shorter than my last one.
I had a few issues starting to port over the common hijack. These include (but not limited to):
no logwrapper usage
starting the hijack too late due to no logwrapper usage
unmounting things in use once hijacking (ties in with the top two)
starting ADB (still WIP)
getting the hijack to flash a new root directory
starting 2nd-init once the new root was flashed
Which Binary To Hijack (COMPLETED)
To resolve the first 3 issues was the first step. How would I call the common hijack while keeping the code from being completely modified? I first considered using mot_boot_mode as we have in the past. But this would require a lot of work trying to determine when it was already hijacked and when it wasn't. So I actually tried to hijack using logwrapper. I found that it was called around the touchpad setup service. This was called immediately after mot_boot_mode so it shouldn't have caused any more issues that mot_boot_mode was. After a few tests with that I found that I couldn't get things properly unmounted because too many things were set up and running by then. And because it was a service, others were starting up by then which it couldn't kill. It was getting worse and worse.
Then I remembered about another binary named "remountpds." I have played around with it in the past, but never actually used it in the hijack yet. I changed it intercept remountpds and after testing found that it was being called properly.
Starting ADB (COMPLETED)
Next step was to get ADB started. The hijack normally uses persist.service.adb.enable to get the system ready to run ADB. Normally I would use persist.service.adb.enable_NV_DISABLED (the prop I found that got adb working at boot) for the other hijacks. After trying the NV_DISABLED prop I found that it was not being set. After digging through the source that would set the props (setprop, etc.) I found that the maximum length that AOSP props can be is only 32 characters. Our prop is too long to be set with CM7's binaries. I decided to change the prop length to 40 but this only caused the binaries to crash and the hijack to not even go anywhere. This basically moved me backwards. Because of this I moved back to the old prop and reset the max prop length back to 32.
Later after I finally got the root directory flashed (next section) we almost got adb working. It recognizes that a device is connected, but won't actually get us into a shell.
UPDATE 2: I now have 2nd-init working by basically forcing all of the props that would start adbd (the service on the phone that allows us to connect through adb) to be 1. We now have a working ADB at boot with a CM7 system.
Flashing the New Root Directory (COMPLETED)
The moto common hijack basically works as our other hijacks do only with one major difference: it flashes a new root directory (like recovery does) and then moves everything to it's proper place. (With our current hijacks, we just do a lot of copy commands.) But whenever I tried to get it to flash my new zip, it would always fail and therefore everything beneath that in the code would fail also because of the dependency on what was inside the zip. After checking it out (with help from hashcode) I found that the hijack kept trying to flash the wrong zip name. And after numerous attempts at trying to get it to automate the name (through defines and such) I finally got it to find the correct zip to flash.
Firing 2nd-init (COMPLETED)
After the zip gets flashed it does everything it can to get the system back to as clean as a slate as it can. This is the killall script that we had been working with and tweaking to get working with our phones. BUT! Because of calling it earlier with remountpds and following the steps through the common hijack as they are supposed to be done, the standard kill all script worked and created a (essentially) clean slate for our system to restart itself.
The problem was that it wasn't calling 2nd-init and restarting the init process. After talking more to hashcode, we found that I had forgot to call tasket on 2nd-init and that the 2nd-init binary was dynamic and not static (dynamic means it looks for libraries to do it's instructions, static means they're all built in). As this was really late at night, I decided to start coding these changes and start a new build, but not test yet. Right now as I'm finishing this, I'm waiting on more logs to continue my efforts.
UPDATE: 2nd-init is now working and we are yet another step closer to getting CM7 working.
Getting /init Working (COMPLETED)
Now that we have 2nd-int working I'm now working on getting our new init binary that comes with CM7 to work with our init.rc. This is a challenge in itself but with the help of hashcode, I hope to have this working soon.
Our stock /init binary is programmed to work with certain users as it parses through the init.rc script. When it hits a user it doesn't know, it freaks out and stops the init process. My first thought was to go the way of the ATRIX and just rename all of the users to system but this posed another problem. Some of the services we are going to need are dependent on those Motorola users which our new init.rc has no clue about. Cue hashcode. He has helped me by pointing me to the D3 system core (aka init, adb, logcat, etc.) edits that's he's worked on. This includes changes to the /init binary that will include the motorola users needed to get our init.rc working. As I'm writing this, I'm currently building the source for it and haven't tested, but I assure you that this will help us get another step closer to CM7.
NOTE: Now before you go "That's for the D3, and we're the X2" remember that pretty much all of the code that we're compiling will work with any Android phone but certain changes are set up in our device configuration. Therefore although I'm taking the changes made to the D3, they will still work for us.
BIG UPDATE: We now have a working init binary that has the correct users so that it doesn't freak out when it tries to set permission up. This has let us to our first official bootloop of CM7. This is REALLY good news because that means that our init is trying to do what it's supposed to do and keep setting up our device and trying to actually start CM7. After looking at some of the logs, we had some issues dealing with the services trying to access the devices. I have since (hopefully) fixed the problem and am awaiting results as we speak.
UPDATE AGAIN: We have now started the boot animation! This means we're really close to getting it working!
Getting Into CM7 (WIP)
I have now managed to start the CM7 boot animation and I'm now currently trying to work out the problems with the installation of the apks.
After working some more with hashcode I found that there were audio decoders (take audio information and turn them into usable information) that weren't being loaded, but were being enabled. With his help i found two of these decoders that Motorola uses, but CM7 doesn't. So I disabled them and that's the first time we started getting places.
But then I learned that the dalvik-caches (the files on our phone that make it run faster) weren't being set up properly. Normally (in a lot of phones) the dalvik-caches are located in /data/dalvik-cache. This is not the case for CM7 as they are located in /cache/dalvik-cache. Once I got this set up we still were not able to get into the boot animation yet until looking at more logs. I found (silly me again) that the zygote process (basically the main system process) was trying to also load the framework (the base system files) that Motorola use. Since we obviously don't have those, it won't find them and it won't load. After fixing that, I sent it out for testing to MoonShadow-NM where he informed me (rather enthusiastically) that we were at the boot animation and made the video above.
Now the problem that I'm running into involves the permissions of those caches and having the other programs access those caches. This has been the hardest obstacle that I've had to face so far as I'm having problems figuring it out. Normally they are supposed to be owned by the system. This allows anything with system (or higher) privileges to access and use these caches for themselves. Normally when an apk is installed they have a user with App_## and belong to the system group. This why they can access the caches and use them. But my problem right now isn't the apps being able to access the caches, it's the installation of those apps.
There is a daemon (service) called installd that checks for newly installed apps and such and starts all of the work needed to get the caches set up and ready for application uses. This is where I'm currently stuck. The framework caches (as I mentioned above) are being created with root (the superuser) as their owner and not system. This means that the installd service (although being ran as root) can't have the processes it starts (which are being ran as system)
access these files and continue on. I'm currently trying to work this problem out.
Conclusion (aka "You Don't Have CM7 Yet Why Should We Bother?")
From a standard reader's perspective you have every reason to think that. From a dev's point of view we're the closest we've ever been to getting CM7 (and eventually AOSP, MIUI and CM9/ICS). CM7 is the first step to that. We're almost there. I haven't given up on getting this ported over and any readers shouldn't either. I'm not making any ETAs or predictions on any outcomes from all of this work, so please don't ask me. I hope you guys found this informative and continue to be supportive throughout this process.
For more information regarding development of CM7 or AOSP please join us on the Freenode IRC on the #x2-aosp channel using your favorite IRC client or at http://webchat.freenode.net. Please keep the conversation on topic as much as possible. We will get off topic sometimes, but when a dev says back on topic, please try to remain so. Or else I will lay down the fits of +v and +m. (If you know what that means, good. if not, don't worry about it.) There will be times that we are quiet, but when we talk we talk A LOT. So don't sign in, wait 5 minutes, then sign out. When we get somewhere, we'll let you slowly know.
Dragonzkiller don't worry about giving us a eta just knowing you guys are working on it is good enough. I have full faith that you guys will get it working at some point and I wanted to say thanks to all the dev's working on this and the continued support to make this phone better!
Thanks to the devs. These [REF] posts are informative and a good read. Knowing development is still going on is good, keep up the work; as previous poster said dont worry about ETA. I understand how these dev things go. Take time to debug and the rom will come in due time. But everything is sounding like a postive step toward us booting CM7
Wow, all I really have to say is thanks for spending so much time on this.
Thanks for the post. Knowing that dev on this phone isn't dead and that people are still trying to get this thing unlocked is amazing.
god i hope u guys can unlock the sexiness of AOSP onto this ****tily locked moto phone.
Oh we will be able to. 2nd init is working fine, depending what version you are using. It's our init.rc that is messed up atm or something related to it. The wording of everything might make you think otherwise but rest assured my rom is a working demonstration of it if you use it and test it via early usb enum and check /data/2nd-init for logs
Updated for new progress and issues.
Thanks for all of your guys' support.
Excellent news. Just patiently waiting!
Great news. Thanks for the update as well. Its wonderful to hear this info. We all owe you and the other helpers big time.
probably sent to from the middle of a lake in central Minnesota
motcher41 said:
Great news. Thanks for the update as well. Its wonderful to hear this info. We all owe you and the other helpers big time.
probably sent to from the middle of a lake in central Minnesota
Click to expand...
Click to collapse
Yes
These updates I'm loving...
And it really doesn't seem like anything is stalling like some thought
this is just the part that takes the most work lol...
Love it...thanks!
This is great news. Go Dragon Go!!!!
Sent from my DROID X2 using Tapatalk
Good to see my ideas last night got you thinking. Wish I knew how to compile a CM build myself to test my ideas lol.
Edit: In other news when we get CM porting done, MIUI will be a breeze. Atrix has a build already so I just need to take their base, add our radio and some other stuff. It will be a cake walk.
Edit2: When we get a booting CM (Even with tons of hardware bugs) I will be able to fix most of the bugs within a day or so. I helped fix a bunch on the D2G and also for getting MIUI to boot across the various devices. So Dragonz, take not and shoot me your first booting build so I can get all the hardware bugs sorted out and you can commit them to the overlay.
Well I just got my X2 today. I'm excited to see that there is still active development for this phone! Keep up the good work guys!
alias747 said:
Well I just got my X2 today. I'm excited to see that there is still active development for this phone! Keep up the good work guys!
Click to expand...
Click to collapse
Lol hope its off-contract...
Sent from my DROID X2 using xda premium
Jubomime said:
Lol hope its off-contract...
Sent from my DROID X2 using xda premium
Click to expand...
Click to collapse
yes sir or there goes more money into the pockets of the corporate communists..
Sent from my DROID X2 using xda premium
You guys are absolute champions.
Jubomime said:
Lol hope its off-contract...
Sent from my DROID X2 using xda premium
Click to expand...
Click to collapse
It's a work phone replacement for my OG Droid. It was out of my control... Don't get me on a rant...
You will like this phone. You got it at the right time too, as we see full aosp finally come to the x2.
Sent from my DROID X2 using xda premium
awesome job, dragonz, ace, masta, penguin, balltongue & the rest! you guys rock!
Sent from my DROID X2 using xda premium
All ICS kernel updates can go here. This is for Entropy, LipShitz, Task and any other who is actually working on the ICS kernel.
If you post here, it will be deleted on the spot so just fair warning...
First!
These are always my latest *unsupported* builds:
i9100 Touchwiz Based Roms: http://www.cheatersedge.org/android/i777/TWzImage.tar
AOSP Based Roms: http://www.cheatersedge.org/android/i777/AOKPzImage.tar
Red5 said:
If you post here, it will be deleted on the spot so just fair warning...
Click to expand...
Click to collapse
Come at me bro!
j/k..
Seriously guys.. No fooling around!
Fenny maybe I missed it but do you have a thread to discuss this tw kernel. So far so good. I had already converted OmegaRom 5.1 with everything and was just waiting on a kernel. So far so good. I am gonna look through my notes on how/where to fix the home haptic feedback but other than that all 4 buttons seem to working perfectly. I have sent a pm to the des of OmegaRom to see if they wanted it ported (help porting it to our phones) but i have heard back from them so far. Will continue playing with it with your kernel and test it out. I have run the OmegaRom for about three days already and have had any issues so testing with your kernel is now upon me. Thanks for your work on this. Rich
Fixed: All keys and home haptic working now, though home haptic seems lighter than the other keys.
Sent from my SGH-I777 using xda premium
Until things are cleaned up better, there aren't going to be threads. There's enough to be done and enough things are still not working right that new threads aren't justified yet.
https://github.com/Entropy512/initramfs_galaxys2_ics
https://github.com/Entropy512/kernel_galaxys2_ics
used to build the attached zImage. If you don't know what to do with a raw zImage, this isn't ready for you yet. Simple as that - there is a lot of things missing (like, don't set any profiles in SetCPU with reduced clock frequencies, bad things will happen) - I still haven't tested flashing zips in CWM. nandroid backup/restore seems to work but no guarantees.
You still need to disable Samsung Noise Reduction or use a hacked Phone.apk along with a hacked /system/usr/keylayout/sec_touchkey.kl (see Hellraiser on github) for it to work in a reasonable way. There's probably a large pile of **** still broken. Don't pester me with bug reports - there's a pile of stuff I KNOW I still need to address.
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Entropy, not stating a fact and you KNOW a heck a lot more than I so take this with a grain of salt. I have been playing with lots of different files on a ported/converted i9100 ICS Rom (Omega Rom 5.1) and used these for the usr files and have seen the screen wake issue. http://db.tt/DUe4afdh Maybe it has nothing to do with these though. I have changed many other things like csc folder, csc other files, many other things also. Also I am using the kernel posted by Fenny if that matters or is much different than yours a I have tested it out yet. I only replied here because one of the files I removed was the gpio file completely as other files inside seemed to have the same configurations. Maybe I am WAY off base here. If you want to try the Rom i converted already to see if anything helps let me know and I will send a link to you. Thanks for all your hard work.
Sent From My KickAss ATT SGS2 SPORTING my CobraRom
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Better off doing how its being done... if use another developers ... you just mirror same issues...if build yourself you know whats what.
Tap-Tap Talking
Entropy512 said:
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Click to expand...
Click to collapse
Isn't 4.0 a total new build from Sammy? Honestly.... from what I'm looking at...I don't see ginger GPIO being compatible..but should be if all they used was duct-tape and staples to parse another kernal together.I'm buying a laptop. You guys use sdk? Entropy..what program are you using for kernal popping? Give me area you want help....will do
Tap-Tap Talking
LipShitz said:
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
Click to expand...
Click to collapse
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Entropy512 said:
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Click to expand...
Click to collapse
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Fenny said:
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Click to expand...
Click to collapse
Ill make sure it stays at the top.
LipShitz said:
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Click to expand...
Click to collapse
I'll catch up on your PMs soon.
I think I've found the screen wake bug: I misread the #ifdefs in the Gingerbread kernel, and realized they unmap the HOME key GPIO.
There was no such unmapping in the ICS kernel - so the GPIO was left mapped to HOME but left floating, which explains both random wakes and spurious HOME presses. It's also why the patch I posted this morning caused guaranteed screen wakes on resume - GPX3(5) is the HOME GPIO and was set to pulldown by that patch - it's an active-low GPIO.
Attached is a test kernel zImage and two patches - if these solve screen wake for those experiencing it, I'll push the patches to github and probably release the first Daily Driver ICS tonight even though I still haven't fixed SetCPU hangs.
This kernel is for Touchwizz firmwares only - if it solves the problem for everyone I'll work with the CM9 maintainers on integrating the attached patches, which apply to the current state of my github repo.
Let me know when you get to test point. Shoot it over if you want.
I have started writing a new program that will enable you to do parcing of 2 total diff Kernals,full factory and custom ROMs., yank out APK's and cook me dinner. What It will prob be 2gig in size..will streamline it. But when done--- WE WILL RULE THE WORLD!.. yea ok.
Tap-Tap Talking
Here is a kernel I compiled to work with MIUIv4 for this weeks update 2.3.23:
http://www.mediafire.com/?5bm1l4t1bmbd8bm
All good... little laggy(prob CPU hang) 200-1200 CPU set? No wake issue yet. I'm on 1.5 hours.
Tap-Tap Talking
I restarted phone and stuck on startup logo(samsung bla bla bla) i need to hook it up to laptop and flash it. Will not go into cwm with power and both volume. Im on my infuse.
Sent from my SAMSUNG-SGH-I997 using Tapatalk
Sorry Double Post
https://wiki.ubuntu.com/Touch/Porting
Any Devs wanna start? I don't have the experience to even know where to begin
I hope someone does try, this could be really cool.
I can probably make this work, considering it's based of CyanogenMod 10.1. Now I just need to hope repo sync works with this, because it always breaks in the middle when I try to sync with paranoid 3.
I'm not at a computer right now, but I will let you know how it goes once I can get on one.
Sent from my NookColor using xda app-developers app
thejrcrafter2 said:
I can probably make this work, considering it's based of CyanogenMod 10.1. Now I just need to hope repo sync works with this, because it always breaks in the middle when I try to sync with paranoid 3.
I'm not at a computer right now, but I will let you know how it goes once I can get on one.
Sent from my NookColor using xda app-developers app
Click to expand...
Click to collapse
They have a switch to continue if failed in the middle.
Downloading repo now.
You guys probably know this...but just in case.
I installed this on my Nexus 7 yesterday. There are no apps, just screenshots of what the apps will be when they are ready. You can supposedly still make phone calls but that won't matter here. The UI was beautiful (I thought) but that is all they have done at this point.
Just saying, it is not even close to functioning as even a media device. I actually couldn't even get wireless up, although I think that is technically supposed to work. I never used it, but I would expect the NookBuntu to be way more functional at this point.
Not to rain on anyone's parade, porting new OS is a great way to learn new things, no matter your skill level. But don't expect much return on your investment at this point.
(Also, just because, make sure that there is a kernel and ramdisk and uboot and not a boot.img in whatever you build. The device tree should take care of that for you, but it didn't on AOSP for me, and I suffered as a result.)
mateorod said:
You guys probably know this...but just in case.
I installed this on my Nexus 7 yesterday. There are no apps, just screenshots of what the apps will be when they are ready. You can supposedly still make phone calls but that won't matter here. The UI was beautiful (I thought) but that is all they have done at this point.
Just saying, it is not even close to functioning as even a media device. I actually couldn't even get wireless up, although I think that is technically supposed to work. I never used it, but I would expect the NookBuntu to be way more functional at this point.
Not to rain on anyone's parade, porting new OS is a great way to learn new things, no matter your skill level. But don't expect much return on your investment at this point.
(Also, just because, make sure that there is a kernel and ramdisk and uboot and not a boot.img in whatever you build. The device tree should take care of that for you, but it didn't on AOSP for me, and I suffered as a result.)
Click to expand...
Click to collapse
What are the app extentions?
Gonna see what I can do to get it running anyway, since I have the entire repo.
moocow1452 said:
Gonna see what I can do to get it running anyway, since I have the entire repo.
Click to expand...
Click to collapse
That's awesome Moocow, let me know if you need any help testing.
I'm not terribly educated in the art of Android OS compiling, but if there's anything I can do to help, let me know.
tsukisan said:
That's awesome Moocow, let me know if you need any help testing.
I'm not terribly educated in the art of Android OS compiling, but if there's anything I can do to help, let me know.
Click to expand...
Click to collapse
And now I got to finish it, don't I? Get into XDA's Ubuntu Touch section, and start rooting around for porting tools, walkthroughs, and whatnot and we'll compare notes if one of us finds something the other doesn't.
I worked on building the phablet for the nook. I stopped because all reports were it works very badly with only 500 mb ram. Hashcode has ported it to the kindle fire and found he could only open a couple apps before it froze up. However, he did good work on porting and put the changes on github at https://github.com/KFire-Android . You can look for phablet branches on the otter branches. The kernel changes are also present in some of his repos. Look around those repos for good hints on getting started.The kindle fire is also an omap processor, albeit omap4, so it is close to ours. The changes should be similar.
Good luck.
drmarble said:
I worked on building the phablet for the nook. I stopped because all reports were it works very badly with only 500 mb ram. Hashcode has ported it to the kindle fire and found he could only open a couple apps before it froze up. However, he did good work on porting and put the changes on github at https://github.com/KFire-Android . You can look for phablet branches on the otter branches. The kernel changes are also present in some of his repos. Look around those repos for good hints on getting started.The kindle fire is also an omap processor, albeit omap4, so it is close to ours. The changes should be similar.
Good luck.
Click to expand...
Click to collapse
So the thing that's supposed to work better with lower grade hardware doesn't work better with lower grade hardware? Ain't that hysterical? :good:
It works somehow... on samsug 9003
voit said:
It works somehow... on samsug 9003
Click to expand...
Click to collapse
Well that's good. Right now, I'm trying to incorperate NookieDev source into the Manifest.xml to get it to properly build. It doesn't seem to be as easy as the fill in the blank I thought it was, but, progress is being made, I think.
Any progress on this?
Sent from my Nexus 4 using xda premium
Good news, I've gotten it to the point where I can brunch encore to try and make a new build.
Bad news, Brunch chokes up on mkimage, for reasons unknown to me. Seems like a problem for building an Android like image, but it escaped me thus far, and the irc on freenode is... of varying quality help to say the least.
Code:
make: *** No rule to make target `/home/user/Nook/out/host/linux-x86/bin/mkimage', needed by `/home/user/Nook/out/target/product/encore/ramdisk.ub'. Stop.
make: *** Waiting for unfinished jobs....
EDIT: Just figured out that I needed to patch the main.mk in build/core to specify a mkimage, now the compiler seems to be churning. Will update once something happens.
Well, it's something.
Anyway, have not had a chance to test this out on my own Nook yet, since it picked an excellent time to flake out on me. You do need to backup and completely wipe the device, assuming it even installs. (Did not work on just a Data/Cache wipe, anyway, and I need to recover my Nook after wiping emmc along with everything else, whoops.)
Anyway, it's like radioactive juice at this point, might kill your Nook, give it superpowers, or not really much of anything. YMMV.
https://docs.google.com/file/d/0B0iHVj8OqCAmMmhvMTY2d2cwbFk/edit
EDIT: It does install, but power on goes from Cyanoboot -> Backlight on -> Backlight off -> Device Off within a couple seconds, so more work is required. le sigh
EDIT2: Turns out that was because I only had the bootstrap on the device, no phablet-flash-preinstall that actually makes it work. :silly:
With both of them flashed, I get to Cyanoboot -> persistent black screen until I cut power. Common error, so I've heard and adb works, so there may be hope yet.
Ladies and Gentlemen, Children of All Ages. I give you Ubuntu Touch for the Nook Color!!
Conditionals:
1. I had to flash my homemade bootloader first (https://www.dropbox.com/s/q5g7mnadvkdmy8k/cm-10.1-20130511-UNOFFICIAL-encore.zip), then the Mobile World Congress Build of Ubuntu Touch. http://cdimage.ubuntu.com/ubuntu-touch-preview/quantal/mwc-demo/ (quantal-preinstalled-phablet-armhf.zip)
2. Rotation is mismatched, so that it cannot recognize that it's trying to use the portrait setup in landscape, should be an easy enough fix. Jossed, as this is the MWC build, it's not really built for tablets, and the Nook gets confused on how to display thing
3. The big one. TOUCH SCREEN IS BROKEN. Granted, it makes it more of a clock than anything useful, but Ubuntu has been built and runs on the Nook Color. Built a new bootstrap based on CM 10.1 RC2, works like a glove. Still not all that much more useful compared to a clock, but that's by design.
Super duper special thanks for the guys in the Ubuntu-Touch mailing list and irc.freenode.net #ubuntu-touch and #nookcolor, who I could not have done this without.
moocow1452 said:
Ladies and Gentlemen, Children of All Ages. I give you Ubuntu Touch for the Nook Color!!
Conditionals:
1. I had to flash my homemade bootloader first (https://www.dropbox.com/s/eaxcz91x7rm36tg/cm-10.1-20130508-UNOFFICIAL-encore.zip), then the Mobile World Congress Build of Ubuntu Touch. http://cdimage.ubuntu.com/ubuntu-touch-preview/quantal/mwc-demo/ (quantal-preinstalled-phablet-armhf.zip)
2. Rotation is mismatched, so that it cannot recognize that it's trying to use the portrait setup in landscape, should be an easy enough fix.
3. The big one. TOUCH SCREEN IS BROKEN. Granted, it makes it more of a clock than anything useful, but Ubuntu has been built and runs on the Nook Color.
So, what next?
Click to expand...
Click to collapse
Looks cool. What's next? fixing touchscreen and fix rotation.. the rotation bit, depending on what the issue is, might be fixed by a change to the kernel config or drivers-- see https://github.com/NookieDevs/andro...mmit/7894401f916eb90b08f113a0cedf4f4d12a1ed77 and https://github.com/NookieDevs/andro...mmit/297a7593c56a75691eb7a7ea4aabab4a052273c3
that's a kernel config flag sluo added. You can also play with the peripheral board file for more control... https://github.com/NookieDevs/andro...rch/arm/mach-omap2/board-encore-peripherals.c
Sweet Tiitties!
Sent from my NookColor using xda app-developers app
AgentCherryColla said:
Sweet Tiitties!
Sent from my NookColor using xda app-developers app
Click to expand...
Click to collapse
Indeed. Especially now that with the latest get of CM for Encore, I got touch screen working for the MWC demo. (Somehow) Turns out that rotation isn't so much the issue as is resolution, everything being too big to properly fit on the Nook Screen, and it looking more like a phone than anything, but it effing works like the half assed demo it's supposed to be.
https://www.dropbox.com/s/q5g7mnadvkdmy8k/cm-10.1-20130511-UNOFFICIAL-encore.zip
EDIT: Do any of you guys want me to do a write up or a Youtube video on how to patch and build your own version of encore for your Nook machine?