Related
Hey Guys,
Not sure if you still use this or not but I'm trying to get a hold of the himem patch and I cant find it anywhere!
I need the actual patch, not the boot.img with the patch included.
It's so we can try something on the liquid E, if anyone has it I'd love to get my hands on it.
Thanks for your help!!!
What patch are you talking about?
himem patch for the nexus...
I need this because my phone has 2 revs 1 with 256MB ram and the other for 512MB, our froyo only supports 313MB or so... and we would love to have the whole thing lol
It was integrated with the boot.img I saw it everywhere when doing a search but it's only integrated in the boot.img..
Cyanogen was asked about this and he said he no longer has it but I'm wondering if anyone else has it stand alone and not in the boot.img
Alright, so I'm just doing a lot of searching and I MIGHT have found something useful. We'll see though
http://www.spinics.net/lists/arm-kernel/msg94488.html
http://android.modaco.com/content/g...-online-kitchen-optional-root-insecure-himem/
Superboot Boot Image with himem
* This option installs a Superboot boot image that installs the SU and Superuser binaries for root access. This boot image is also insecure and therefore also provides adb remount permissions. This boot image also includes himem support!
http://www.nexusonephoneworld.com/firmware-update-for-nexus-one-ere36b-256.html
http://android.modaco.com/content/g...modaco-com/302503/ere36b-rom-leaked-repacked/
I thought OP was talking about something something else... something we wouldn't be able to help him with...
SeEsAw12 said:
I thought OP was talking about something something else... something we wouldn't be able to help him with...
Click to expand...
Click to collapse
He very well could be, lol, as I don't know much about this. I just did some deep research and tried to find what I thought he was looking for.
I did find some old old ROMs that had it, but I had no idea what file to look for or where it would be located (folder wise) so I couldn't search them myself.
Well, I know it was added to cyanogenmod around or a bit before feb 2nd, so I'm combing through the commits. Around and before that day, there are extensive memory structure, access, error, etc changes. I still haven't found it, but...
Is it impossible to synchronize to the latest source, or are there too many drivers that are not portable?
Hah, I guess it's a bit ironic I ask that when it's been my goal to port some of the Liquid E drivers to the N1.
I'll at least try to hunt down the original author, I remember highmem being credited to someone somewhere.
Edit: It appears it was fixed in kernel .32 but persists in .29. It seems things get a bit fuzzy here, archived articles being vague and all, as I'm no longer sure if highmem patching means that there was a .29 modification or they just went with .32.
Edit2: http://www.nexusoneforum.net/forum/nexus-one-general-discussion/748-we-need-update-2.html There was a setting for highmem on arm processors in .32, but not in .29. There never was a "patch," I don't think.
EDIT: Try this: http://www.androidspin.com/download.../&file=cm502_highmem_kernel_update_v1.6.1.zip - Himem 1.6.1 kernel update - CM 5.0.2? OR http://www.androidspin.com/download.../&file=cm5b4_highmem_kernel_update_v1.5.1.zip - Himem 1.51 kernel update
Please try the edited links first. I believe they are what you are looking for, what I wrote after this could be just useless to you.
I am not sure if this is what you are looking for but check the files on here.
http://files.androidspin.com/downloads.php?dir=enomther/RESOURCE/
I think I know the patch you are talking about but I don't think it is listed there but there may be something similar there.
Also I remember it being on the Modaco forums but I don't see it there anymore, well not where it used to be, since now it is just integrated.
But check the link none the less.
Wow thanks for all the replies guys!
It is pretty much what I am looking for however it seems to be all the boot.img files for the kernel and I need the source for the "patch"
This sucks cause I'm stuck with 30% of my ram missing on my device!
Anyways thanks for your help!
I'll keep looking
Welcome to Eternity Project!
So... as most of you know I'm working on the Atrix solution from TOO MUCH time.
With the collaboration of people on #moto-atrix I've stated that FUSES on Tegra2 are really OTP, so there isn't any way to CRACK the BL, but we can still BYPASS it.
So... what is it?:
kexec is a "fastreboot" that won't pass through the Moto Bootloader, so with it it's possible to use custom kernels and, with some other development, custom Android systems like CM7 and many others.
Where's the poop?
Okay, that's it: I've successfully compiled and ran kexec on the Atrix 4G, so that kexec works, but it needs a kernel that can boot with kexec. On x86 we can build a relocatable kernel so no problems... but not on ARM and obviously not on Tegra.
The thing that is missing is exactly... _the address of the boot params_!
And now?
I'm only searching for help for completing the project and make a kernel that is bootable from my god-it-is-really-working-kexec. Any devs around?
Downloads:
- Kexec pack V0.01: DOWNLOAD
Kexec pack contains:
- ATAGS for MB860 (ATRIX_atags.tar)
- ATAGS hack module (eternity_procfs.tar)
- kexec module (eternity_kexec.tar)
- kexec tools/binaries (kexec-tools.tar)
- Kernel....that doesn't work. (eternity_kexec_kernel.tar)
So, what does work and what does not?
- ATAGS hacky hack: WORKING
- kexec module: WORKING
- kexec tools/binaries WORKING
- Kernel ToDo
How to run it:
0. FLASH AT&T 1.2.6 SBF PRIOR DOING ANYTHING
1. Extract all the archives
2. Insert the procfs_rw.ko module
3. cat atags > /proc/atags
4. Insert the kexec module
5. Run kexec for loading the kernel and jumping to it.
6. Boot! :|
P.S.: I won't release detailed how-tos because at this state I only need a DEVELOPER that can help me to build the kernel.
Thanks to:
- PAulyHoffman (special thanks!)
- unknown
- Sogarth
- the2dcour
- cranch
- eval-
- and many, many others....!
Awesome, i can verify that this kexec is working and will continue testing until we succeed.
random boot animation I made for eternity project
http://diamantephoto.com/bootanimation_red.zip
Also: 1.2.6 without losing /data, in case you were wondering exactly why I made this
http://forum.xda-developers.com/showthread.php?t=1073439
kexec pack updated. now kexec-tools is included
@kholk: Hai;
so basically this is a port of the unix kexec to run on tegra based devices?
From my understanding the android system uses a boot image that has the ramdisk and kernel combined together and they are dependent on each other... so won't overwriting the kernel at runtime give you us some issues since the core initialization of the system is ran from the ramdisk???
wouldn't be a better idea to tackle this issue too? but then again the only reason we can't flash boot images is because of the bootloader but ofcourse this is definitely a step forward for the tegra users.
now about the kernel, theoretically if we build an aosp tegra kernel from http://android.git.kernel.org/?p=kernel/tegra.git;a=summary shouldn't it work?
I can try building us a kernel if that would work
PS: people let's keep this dev ONLY if you want us to get some progress we need able to read through the thread without useless posts.
edit: also found this https://opensource.motorola.com/sf/frs/do/listReleases/projects.atrix/frs.olympus I'm sure having the source for the kernel we are currently running is also helpful
I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was
Ratchet556 said:
I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was
Click to expand...
Click to collapse
When a kernel that works will be deployed I'll personally port it to Bell Atrix. This will take only some seconds.
kholk, perhaps we can ask a defy developer (or any of the phones that have kexec working) to help us build the kernel.
it's too bad da_g isn't around, he did a custom kernel but wasn't able to boot it.
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?
lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
thebeardedchild said:
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?
Click to expand...
Click to collapse
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.
Jotokun said:
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.
Click to expand...
Click to collapse
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Boot time will be about twice as long. Other then that, everything will run about the same
Yes thank you very much for that explanation... though I do also have the question about stability. By replacing the current kernel in memory with the new modified kernel the phone state may get confused as you mentioned... could this cause instability as a whole or increase risk of kernel panics? Or once everything is loaded and complete does it stabilize with the modified kernel?
Again sorry for the questions. This topic intrigues me and I love learning how stuff works.
thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Only difference would be that it might take slightly longer to boot up. Once the phone is finished booting, there's no difference in terms of performance because by that point the Motorola kernel isnt running, or even loaded.
thebeardedchild said:
Haha yeah I'm checking every like 2 seconds now. What exactly do we wait for then? Someone to just create the custom kernel, and then of course wait for some Custom ROMs to be created? I hope we get CM7!
Click to expand...
Click to collapse
Kexec isn't fully operational yet, still need to find boot params. Then custom kernel.
How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?
Ratchet556 said:
How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?
Click to expand...
Click to collapse
I imagine some of the preliminary stuff may need to be pushed with ADB but devs are always nice and give us very clear guides. And I'm sure either a dev or active member could easily create a batch script.
Even though I'm comfortable with ADB I always make scripts for myself because I regularly wipe me phone and whatnot. Because it's so engaging some people might want to wait until a few normal community members test this out so we can see if there are any glaring challenges with the instructions. Just remember to back things up, read instructions clearly and I'm sure we'll all be fine. We've got SBFs and all that good stuff to cover our asses too.
Would it be possible to bring fastboot off the htc to this? Then we won't have to worry about boot time at all. Even if it did double the boot time...
Sent from my MB860 using XDA App
PixoNova said:
This bypasses the bootloader
Swyped from my Motorola Atrix 4g using XDA Premium App
Click to expand...
Click to collapse
Correct this method has nothing to do with unlocking the bootloader and previous attempts at that proved it maybe impossible.
Granted, it has been a while since I've built CM, and never ported it to a new device, but figure this might give some smarter people a head start or at least provide a place for others to collaborate.
I've not gotten very far past the initial vendor setup per http://wiki.cyanogenmod.org/w/Doc:_porting_intro.
A lot of the work is based off the similar ASUS TF700T, https://github.com/CyanogenMod/android_device_asus_tf700t.
I've not messed with the kernel at all at this point, https://github.com/ouya/ouya_1_1-kernel.
I've uploaded everything so far to github, https://github.com/vinny75/android_device_ouya_ouya_1_1
Packages included with official build:
OUYA Framework, Launcher, and Store
Code:
app\OUYAKeyboard.apk
app\OUYALauncher.apk
app\OUYAOOBE.apk
app\OUYAWallpaper.apk
app\ouya-framework.apk
note: some media files I haven't list
CWiid for Android: http://cvpcs.org/projects/android/cwiid4android and https://github.com/cvpcs/android_external_cwiid[.
Code:
bin\wminput
lib\libcwiid.so
etc\acc_led
etc\acc_ptr
etc\buttons
etc\gamepad
etc\ir_ptr
etc\neverball
etc\nunchuk_acc_ptr
etc\nunchuk_stick2btn
Sixpair for PS3 controllers http://www.blog.kaiserapps.com/2012/10/setting-up-sixaxis-controller-android.html.
Code:
/bin/ps3service
/bin/sixpair
I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Sent from my Nexus 7 using xda premium
mybook4 said:
I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Click to expand...
Click to collapse
Thanks, appreciate the help, hopefully, we'll have a working build soonish
If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!
Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"
mybook4 said:
Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"
Click to expand...
Click to collapse
I started out with Method 1 then moved over files and settings from the ASUS TF700T.
professorpoptart said:
If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!
Click to expand...
Click to collapse
Yes, building the new device tree has been... uhm... educational... and I am still learning. If I don't make any headway on 10.1, I might drop back to 10 - at least most of the legwork will be done.
Ok, so I'm in the middle of a build
Have a vendor tree on my git and I forked Vinny75's device tree, modified it some
Also a kernel tree up there, which is required for my device tree (prefer to build the kernel myself =) I've booted a custom-built kernel on it already, so that shouldn't be an issue)
I'm nervous to flash this though. I did a bit of searching but couldn't come up with a way to get back into recovery should this thing not boot. You guys know of anything?
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium
mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Yea, that's what I'm seeing.
So here's my 'solution'
Since we have fastboot, we can boot a boot.img without having to worry about flashing it.
I've successfully booted my cm boot.img, with ro.secure=0 and ro.adb.secure=0, I can adb reboot it when it fails miserably to boot
Quick and dirty script to unsecure a boot.img:
http://pastie.org/8033076
It assume that unpackbootimg and mkbootimg are in your path, you can get them here: http://invisiblek.org/mkbootfs_tools.zip
Getting closer...
THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?
dibblebill said:
THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?
Click to expand...
Click to collapse
Yeah, I think that is the same solution posted earlier:
mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Click to expand...
Click to collapse
THis might be another option too:
tylerwhall said:
I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.
Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.
I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.
Click to expand...
Click to collapse
Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium
mybook4 said:
Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium
Click to expand...
Click to collapse
ah he makes it sound like it puts you in USB recovery mode fo you could ADB in to push an update.
Just wanted to say I'm totally stoked on this guys! Can't wait to see what you do with this. Wish I could help, but I'm really not a developer.
i agree with rebel! but when you guys have it readyish ill test flash it and tell you what happens!!
So, OUYA isn't really as interested in being an open console as they suggest.
I'm keeping a track of how many requests we get relating custom firmware, and from what I'm seeing the user base is not as interested in custom firmware as you might think, which is echoed by this thread (we've shipped 60,000+ units, and less than 10 people have commented in the last month in this thread about getting access to recovery mode).
That doesn't mean that we're shooting the idea down, you need to keep in mind that in terms of priorities this is way down the list as you'd expect from any feature where it's being requested by less than one tenth of one percent of the user-base.
I'm sure @Wajeemba is familiar with CM requests that a very small minority of the user-base are very passionate about, so hopefully you can understand why we're not rushing to work on this.
Click to expand...
Click to collapse
Go to this thread and let them know we want support:
http://forums.ouya.tv/discussion/1380/recovery-mode
That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...
sonofskywalker3 said:
That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...
Click to expand...
Click to collapse
I'd check with invisiblek about how to avoid bricking the OUYA. Apparently his is bricked. It's stuck in nvflash mode. I think it was a kernel written with a bad init.rc that did it. not sure though.
Sent from my Nexus 7 using xda premium
Let me first say, despite what the title of this thread may lead some to believe, I am NOT a noob. I am very familiar with Android, rooting, recovery, Linux, CLI, etc. Excluding recent months, I've been a very active member of the XDA community providing support for the Amazon Kindle Fire and variants for quite some time, and as such, I have amassed a great deal of knowledge regarding Android and modification. Unfortunately, all of this knowledge is limited to wi-fi only devices and I have yet to have any experience with wireless (used prepaid phones for years).
My carrier is Cricket Wireless, and I know being a CDMA variant, that I can only install ROMs made for CDMA variant phones, but are there any CDMA based ROMs for this device? (at first glance, I didn't see any) If so, upon installing a new ROM, would it still be possible to use the same carrier? I know that may seem like a stupid question, but as mentioned before, my experience with wireless carriers is minimal, at best.
Also, I have seen the one-click unlock/root tool available for this device, which is great, but experience has shown me that without first educating yourself about the device being modified, putting faith in such tools' safety/effectiveness is never the best policy. I've read the guides and tutorials posted in the general section (without spending too much time searching through the entire forum), but they are very basic and do not touch much on the fundamentals of what I understand to be exclusive to HTC based phones such as S-Off, RUUs, Sense,etc., and I would much rather use a more reliable command line method (Linux preferably) than putting my trust in a tool in which I can't even view the source code.
And while I'm not a huge fan of XDA's dilapidated search function and will avoid it whenever possible, I am not in the least bit averse to reading provided I don't have to spend all day looking for the right information. I'm sure there are users that provide support for this device (much like myself with the Kindle Fire) that have a "laundry list" of bookmarked links for guides/tutorials/postings etc. for HTC device specific knowledge that can spare me the grueling task of wasting my time through endless, and sometimes pointless searching, only to find I am more confused/frustrated than when I first started. If there are such users willing to share links and the like to make the transition faster for me, I would be very appreciative.
TIA
For the time being there are no CDMA ROMs here, I can say that.
As to the guides, there are some on here. The only one that i can provide you is a kernel building one. It pretty much works for most devices.
Kernel building guide by nikhil
Im also gonna attach a txt file of my FB conversation/walkthrough of building aokp from source.
I hope you find this helpfull. If you ever have any questions you can go ahead and ask me over Facebook, and i will try to assist :3
Еdit: Questions like this make me feel good about humans. Glad to see that there are civilized individuals out there. Have a great time doing what you like (coding) and maybe visit our forums with a Desire C and lend us a hand :3
There is a lot to be done.
I have never Re-searched into the different variables of phones as i assume i have always used the GSM version of every phone, i am unaware of the difference of a CDMA Version and a GSM version of a phone, so what is the difference? and would it just be the RIL that needs to be changed for a ROM to work on the CDMA version of a phone?
me4488 said:
For the time being there are no CDMA ROMs here, I can say that.
As to the guides, there are some on here. The only one that i can provide you is a kernel building one. It pretty much works for most devices.
Kernel building guide by nikhil
Im also gonna attach a txt file of my FB conversation/walkthrough of building aokp from source.
I hope you find this helpfull. If you ever have any questions you can go ahead and ask me over Facebook, and i will try to assist :3
Click to expand...
Click to collapse
Thank you for your quick response. I was hoping to get rid of the stock Sense ROM and move to a CM based JB or even ICS if needed but it looks like that will have to wait for now. I must say, I am actually quite surprised there isn't any CDMA support in these forums. Is it due to lack of developer support here or is there a lot more involved to get a working CDMA ROM?
me4488 said:
Еdit: Questions like this make me feel good about humans. Glad to see that there are civilized individuals out there. Have a great time doing what you like (coding) and maybe visit our forums with a Desire C and lend us a hand :3
There is a lot to be done.
Click to expand...
Click to collapse
Believe me, I've paid my dues in this community (XDA) and I know all too well how frustrating the all too frequent ambiguous questions can be. I'm always willing to help where and when I can, but I was also hoping there were like-minded individuals willing to do the same for me so I can get up to speed as fast as possible.
penguin449 said:
I have never Re-searched into the different variables of phones as i assume i have always used the GSM version of every phone, i am unaware of the difference of a CDMA Version and a GSM version of a phone, so what is the difference? and would it just be the RIL that needs to be changed for a ROM to work on the CDMA version of a phone?
Click to expand...
Click to collapse
A CDMA phone, has a CDMA chip (radio) that stores information such as the carrier, MEID, phone number, network account information, what towers to connect to, etc. Whereas on GSM phones this is all stored on a removable SIM card. The CDMA is not removable and is intended to be (though not necessarily the case) permanently configured for that particular phone/user and that particular carrier.
That being said, this should theoretically be no "major" consequence in getting a ROM built that would work on a CDMA based device.
i see, so are you able to root/flash the same recoveries as us? or are they different for CDMA phones? i could try changing some stuff around with a ROM to make it work with a CDMA device but it will take a lot of testing because i have nothing done this before! the ratio of GSM:CDMA in this community is possibly 100000:1 so nobody has bothered to look into this as it is not needed. however me and Nick may work together to bring you this as he is a kernel developer and i am a ROM developer.
penguin449 said:
i see, so are you able to root/flash the same recoveries as us? or are they different for CDMAonhones? i could try changing some stuff around with a ROM to make it work with a CDMA device but it will take a lot of testing because i have nothing done this before! the ratio of GSM:CDMA in this community is possibly 100000:1 so nobody has bothered to look into this as it is not needed. however me and Nick may work together to bring you this as he is a kernel developer and i am a ROM developer.
Click to expand...
Click to collapse
After a bit of research, I've found that there is a CDMA to GSM patch made by a fellow Recognized Contributor that, as expected, allows certain CDMA ROMs to run on GSM phones. I can't see why the same couldn't be done the other way around. I've sent a PM to him already and I'm just waiting on a response. Considering the fact that there are so few of us CDMA users, I'm sure a patch would be the way to go rather than building a ROM from scratch. But, if nothing else, I'd just build my own based on an available source.
As for the root/recovery, I'm still looking into it...
soupmagnet said:
After a bit of research, I've found that there is a CDMA to GSM patch made by a fellow Recognized Contributor that, as expected, allows certain CDMA ROMs to run on GSM phones. I can't see why the same couldn't be done the other way around. I've sent a PM to him already and I'm just waiting on a response. Considering the fact that there are so few of us CDMA users, I'm sure a patch would be the way to go rather than building a ROM from scratch. But, if nothing else, I'd just build my own based on an available source.
As for the root/recovery, I'm still looking into it...
Click to expand...
Click to collapse
i have the most experience in building PAC from source, however i can offer you this as i wouldn't mind re-building it for CDMA (If i know how to) I too saw the patch and wondered how it would work however i think that when building this will need be inluded rather then GSM.
Code:
PRODUCT_COPY_FILES += \
vendor/cm/prebuilt/common/etc/apns-conf-cdma.xml:system/etc/apns-conf.xml
However i may be wrong in my naivete thinking that is all there is to the variations of GSM and CDMA Roms
If you could explain me how CDMA kernels differ from GSM ones, i could make one for the 2-3 people that need it :3
Go ahead and ask/share. We are open for ideas.
I assume it's just the RIL that needs to be changed, prehaps the kernel will only need to be changed from GSM to CDMA in the same way as a ROM, however i don't know anything about kernels, tonight i'll repo sync and try build a CDMA Rom, prehaps we could then extract a patch from it? Pico has no CDMA version so there is no hope of guidence from our older Brother /:
This is the response that was given to me...
In fact it's possible - BUT you might only have 3G maximum speed. If your device is an GSM device I guess there won't be any CDMA/4G baseband drivers available - which means you'll have to play with 3G max.
The most stuff can be done in the roms build.prop file. The best way is to comapare your file to a cdma build.prop file and edit/insert/remove the related entries.
In some cases you need the ril libs too. Those are only available in a cdma rom for your device. And as there's no cdma rom available this can be difficult.
Is the device/bootloader unlocked? In that case you might build cdma libs from source - depends on rom.
Click to expand...
Click to collapse
Luckily, HTC released the source for the Cricket Wireless Desire C and it should be as simple as compiling and pulling the necessary files.
http://dl4.htc.com/RomCode/Source_and_Binaries/golfc-ics-3.0.16-3d39477.zip
And I can't imagine why it would even make a difference, but here's the Cricket Wireless/Radio Shack Desire C source as well...
http://dl4.htc.com/RomCode/Source_and_Binaries/golfc-ics-3.0.16-3d39477.zip
soupmagnet said:
This is the response that was given to me...
Luckily, HTC released the source for the Cricket Wireless Desire C and it should be as simple as compiling and pulling the necessary files.
http://dl4.htc.com/RomCode/Source_and_Binaries/golfc-ics-3.0.16-3d39477.zip
And I can't imagine why it would even make a difference, but here's the Cricket Wireless/Radio Shack Desire C source as well...
http://dl4.htc.com/RomCode/Source_and_Binaries/golfc-ics-3.0.16-3d39477.zip
Click to expand...
Click to collapse
Well @me4488 you up for the challenge? I could try changing GSM to CDMA in build prop for @soupmagnet if you would like to test that way? if that doesn't work we may have to source build a CDMA Rom for you!
penguin449 said:
Well @me4488 you up for the challenge? I could try changing GSM to CDMA in build prop for @soupmagnet if you would like to test that way? if that doesn't work we may have to source build a CDMA Rom for you!
Click to expand...
Click to collapse
Let me get unlocked, rooted and recovery installed and I'll see what can be done. I might try to pull RIL libs from an original Desire ROM (assuming there is a CDMA version somewhere). Aside from CPUs, NANDs, cameras, etc., manufacturers generally don't like to stray too far from the hardware configurations between device variants.
Edit: BTW what are the udev rules for this device? Are there different rules for fastboot adb hboot and recovery ?
soupmagnet said:
Let me get unlocked, rooted and recovery installed and I'll see what can be done. I might try to pull RIL libs from an original Desire ROM (assuming there is a CDMA version somewhere). Aside from CPUs, NANDs, cameras, etc., manufacturers generally don't like to stray too far from the hardware configurations between device variants.
Edit: BTW what are the udev rules for this device? Are there different rules for fastboot adb hboot and recovery ?
Click to expand...
Click to collapse
Watch out for the recovery. The one person that flashed a custom one had his fail because we don't have a CDMA recovery.
At least that's what he said.
And i would gladly build you a kernel when i get the time.
I don't think there are a lot of udev rules that can differ from the kindle. But don't listen to me, as I am still a rookie.
me4488 said:
Watch out for the recovery. The one person that flashed a custom one had his fail because we don't have a CDMA recovery.
At least that's what he said.
And i would gladly build you a kernel when i get the time.
I don't think there are a lot of udev rules that can differ from the kindle. But don't listen to me, as I am still a rookie.
Click to expand...
Click to collapse
That's absolutely ridiculous. Recoveries like TWRP and CWM sit on a relatively small partition with minimal hardware support. Display, touchscreen, USB, battery, memory and storage are, generally speaking, all that gets initialized. Drivers for WiFi, Bluetooth, CDMA, etc., would likely take up more space than is available on the partition. I could be wrong, but if experience has shown me anything at all, it is you should rarely take what random XDA users says at face value. I'm sure if we take a look at the source code for whatever recovery is being used, well find that it's probably just a simple case of user inexperience playing a part.
Can someone post a partition layout so I can compare it with mine?
soupmagnet said:
That's absolutely ridiculous. Recoveries like TWRP and CWM sit on a relatively small partition with minimal hardware support. Display, touchscreen, USB, battery, memory and storage are, generally speaking, all that gets initialized. Drivers for WiFi, Bluetooth, CDMA, etc., would likely take up more space than is available on the partition. I could be wrong, but if experience has shown me anything at all, it is you should rarely take what random XDA users says at face value. I'm sure if we take a look at the source code for whatever recovery is being used, well find that it's probably just a simple case of user inexperience playing a part.
Can someone post a partition layout so I can compare it with mine?
Click to expand...
Click to collapse
I haven't partitioned my SD card or anything like that at all tbh :L i just flashed the recovery, as far as a CDMA Rom goes, i've got the CDMA in permissions and in the build.prop but not sure if the RIL correctly configured to CDMA and i am unsure of how to Check, however if you want to test i'll upload it and send you the link although we may have to wait for a CDMA kernel before we can do anything!
penguin449 said:
I haven't partitioned my SD card or anything like that at all tbh :L i just flashed the recovery, as far as a CDMA Rom goes, i've got the CDMA in permissions and in the build.prop but not sure if the RIL correctly configured to CDMA and i am unsure of how to Check, however if you want to test i'll upload it and send you the link although we may have to wait for a CDMA kernel before we can do anything!
Click to expand...
Click to collapse
I'll try it out when I can, but I have to figure out this recovery issue first. I was able to obtain root, but not with the "superboot". The superboot method gave me the same problems others here were having and it would never install Superuser.apk or the 'su' binary. However, I wrote a small script using Bin4ry's exploit and it worked flawlessly. I have root now, but I'm having trouble identifying each of the partitions.
Having root, I was able to make backups of each of the partitions listed under "/proc/emmc", and I attempted to 'dd' the TWRP recovery.img to the "recovery" partition, but the device would still always boot to the stock recovery. When I tried to install recovery via fastboot, I got the same "This build is for development purposes only" message as before and the stock recovery is gone. So apparently, the partition (mmcblk0p21) listed as recovery under "/proc/emmc", is either not the actual recovery partition, or I'm missing something.
Since you have recovery installed, does it have 'parted' included in the build? Do you know how to print a partition table? If so, would you mind posting one?
If you could explain how you do it, i could gladly give it a shot when i can (vacations up ahead dunno when i will be back)
me4488 said:
If you could explain how you do it, i could gladly give it a shot when i can (vacations up ahead dunno when i will be back)
Click to expand...
Click to collapse
Assuming the version of recovery you are running has 'parted' included, enter the following at your command prompt:
Code:
[COLOR=DimGray]$[/COLOR] adb shell
[COLOR=DimGray]~ #[/COLOR] parted /dev/block/mmcblk0
[COLOR=DimGray](parted)[/COLOR] print
If for some reason 'parted' isn't included in your version of recovery, you can temporarily install it for one session (since recovery is loaded into memory to run, nothing gets written to the actual recovery ramdisk and rebooting will erase any changes made):
1) Download 'parted': http://d-h.st/h81
2) Boot into recovery
3) Enter the following commands:
Code:
[COLOR=DimGray]$ [/COLOR]adb push /path/to/parted /sbin/parted
[COLOR=DimGray]$ [/COLOR]adb shell
[COLOR=DimGray]~ #[/COLOR] chown 0.0 /sbin/parted
[COLOR=DimGray]~ #[/COLOR] chmod 755 /sbin/parted
Ah that is pretty helpful, it should be implemented into the recovery source, if you don't mind me asking where is the main source which includes his function?
russell664 said:
Ah that is pretty helpful, it should be implemented into the recovery source, if you don't mind me asking where is the main source which includes his function?
Click to expand...
Click to collapse
I'm pretty sure it just needs to be added during the build. With the Kindle Fire, early versions of TWRP didn't include the 'parted' binary and it was added intermittently in subsequent versions. It wasn't until the developer was constantly bombarded with requests that it became a permanent addition.
I don't have much (any) experience building recoveries but I would think it'd be as simple as unpacking the ramdisk and just adding it to the filesystem.
Just what the title says. I'm not familiar with optimizing governors, so if someone with more experience has a different set of parameters that'd be better, feel free to drop recommendations. This uses the following settings (copied from elsewhere on XDA):
Governor: ondemand
up_threshold 70
sampling_rate 50000
sampling_down_factor 2
down_differential 15
freq_step 50
Performance seems quite a bit smoother than stock, especially when opening Google Assistant. Battery life has been in the vicinity of 20-25 hours.
Download: https://androidfilehost.com/?fid=673791459329059808
Installation:
Unlock bootloader and enable ADB if you haven't yet
adb reboot bootloader
fastboot flash boot boot.img
Not all heroes wear capes. I'm glad someone with the knowhow finally did it. I'm gonna try it here in just a few minutes. Been dying to get back that 4 core, 998 mhz since 2.0.
---
Edit: Alright, booted up perfectly fine, no issues. And I am already noticing its much quicker than before. Excellent job man, thanks a lot for this. My watch has been feeling so sluggish since 2.0 and this is just what it needed.
Omg huge thanks man!!! Finally
this working on Lg watch R ? 1.5 or 2.0 ?
odmetnik said:
this working on Lg watch R ? 1.5 or 2.0 ?
Click to expand...
Click to collapse
This is for the Urbane. It's plausible that it'd work on the GWR, but I don't have one to test on and won't make any guarantees. If you flash it on a GWR, make sure you're ready to flash it back to stock in case it doesn't work.
This is for the most recent 2.0 build, which is mentioned in the title. You can check your build in settings > system> about > build number. If you're on a different build, then this will most likely not work and you'll need to flash the factory boot.img in order for your watch to boot again.
Is there a noticeable decrease in battery performance? in comparison to the standard AW 2.0?
Awesome, working great, even more battery time than before.
Thanks bro!!!
HI,
My computer does not want to get along with the watch. I can not detect it. What could be the reason ? Debugging via USB have turned on in the clock.
https://ibb.co/mvPfB6 - i have this messege from ABD
PROBLEM SOLVED
mod is very goog.
Hi guys,
What's the stock CPU setup? I thought it was quad core at 1.2GHz.
Does anybody have the stock boot.img in case want to undo the mod?
ceanth said:
Hi guys,
What's the stock CPU setup? I thought it was quad core at 1.2GHz.
Does anybody have the stock boot.img in case want to undo the mod?
Click to expand...
Click to collapse
The stock setup is one core enabled at 788MHz. Most (maybe all?) watches with the SD400 did this to improve battery life.
You can get the stock boot.img from unzipping the full factory image here: https://androidfilehost.com/?fid=673368273298983957
Corrupt file
Bro.. Its say the file. img corrupt when i drag in windows
Any help?
This gave my watch new life... it's actually usable again! Thank you.
Sorry , i have a doubt. I read the entire "how to.." and still dont know, is necesary root access or twrp or is just fine with the bootloader unlocked (oem unlock)?
Psico.ext said:
Sorry , i have a doubt. I read the entire "how to.." and still dont know, is necesary root access or twrp or is just fine with the bootloader unlocked (oem unlock)?
Click to expand...
Click to collapse
You just need the bootloader unlocked.
Help me!!!!!!!
Hi everyone,
I have lg urbane watch with same build number. After I flash boot.img mod 4 cores, My watch can boot and suddenly shutdown.
I flash stock image but i have problem. My watch will suddenly shutdown if i discharge. Any one can help me. I try flash stock 1.5 but my watch can't return as normal.
:crying::crying::crying::crying:
Sorry for my bad English.
many thanks.
Adiprana1106 said:
Bro.. Its say the file. img corrupt when i drag in windows
Any help?
Click to expand...
Click to collapse
I've been stuck on this for about half an hour. I discovered that I didn't leave a space after typing "fastboot flash boot_"
So basically:
1. Type "fastboot flash boot" followed by spacekey ("fastboot flash boot_")
2. Drag boot.img before hitting enter
3. Enter
If I reset (factory reset) the watch, do I need to flash the boot image again, or does it persist?
surface13 said:
If I reset (factory reset) the watch, do I need to flash the boot image again, or does it persist?
Click to expand...
Click to collapse
I'd like to know this as well. Also, is there any way to double check to make sure this boot.img and 4 cores are in function?
Thanks
Matt174e said:
I'd like to know this as well. Also, is there any way to double check to make sure this boot.img and 4 cores are in function?
Thanks
Click to expand...
Click to collapse
My watch is overheated and consumed about 20% of charge in the first 30 mins (maybe for all the updates, app sync etc)
now i leave resting for a while. Anyone experienced this battery drain ?
REQUEST: 2 core 778MHz and 4core 778MHz
Hi thank you a lot for your work.
I flashed this, and effectively the watch became much more responsive, but after a while it started to feel significantly hotter , and from time to time the watch starts to reboot, sometimes multiple times rebooting, and becoming almost unusable, and it needs to be docked to even turn on.
Could it be that the watch's old battery is not able to deliver enough energy for the processors?
Could it be a problem with optimizing governors? No Idea. Maybe you could build a 2 core 778 / 998MHz or a 4 core 778MHz for me to test on my watch?
Phobophobia said:
Just what the title says. I'm not familiar with optimizing governors, so if someone with more experience has a different set of parameters that'd be better, feel free to drop recommendations. This uses the following settings (copied from elsewhere on XDA):
Governor: ondemand
up_threshold 70
sampling_rate 50000
sampling_down_factor 2
down_differential 15
freq_step 50
Performance seems quite a bit smoother than stock, especially when opening Google Assistant. Battery life has been in the vicinity of 20-25 hours.
Download: https://androidfilehost.com/?fid=673791459329059808
Installation:
Unlock bootloader and enable ADB if you haven't yet
adb reboot bootloader
fastboot flash boot boot.img
Click to expand...
Click to collapse