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.
Related
Alright.
Seriously, whats the deal with the Rogers Dream and the normal Dream? I dont get the difference. Please explain some in detail.
The only thing I've been reading for a while is the DRE2100 or something compared to the normal thing.
seriously. What is rooting?
I have a Rogers Dream and I really want to know where to start playing around with it.
Its sad however that I have to look for threads with "Rogers" tagged on it.
previously, I had an HTC Kaiser, and I played around/flashed it a LOT. and I moved on to a Rogers Dream, I've had it for quite a while, just didn't know where to start.
Thanks
Theres a few minor differences between the 2. The main one is the frequency it runs on. But to get you started understanding everything this is what you need to look at.
http://forum.xda-developers.com/showthread.php?t=519523
Alright. I am so. tired of looking up stuff. I'm not going to do anything yet.
I barely get anything.
What is root for?
what is it used for?
I have used Ubuntu and Fedora a couple of times but, seriously, root was just a command really.
After I root. then what?
Also. I was wondering. can Rogers ever be converted into the DREAM100/DREAM110?. i dont know, just wondering. If that was possible, It would make things very simple for people like me.
I believe that dream100/110 are boards so they could never be converted.
Root is basicly in windows terms- the admin, getting root allows you su like the sudo command in linux. Having root allows you to flash custom roms, nandroid backup, themes, allow deeper hardware access, full privs to the kernel processes of the system, allowing apps to sd, allow you to wipe or activate gps from sms, dentonate nuclear warheads, so on and so on
Have I answer the ? Sufficently enough yet
Oh and root on linux is the same thing and not just a command
da pavinator said:
Alright. I am so. tired of looking up stuff. I'm not going to do anything yet.
I barely get anything.
What is root for?
what is it used for?
I have used Ubuntu and Fedora a couple of times but, seriously, root was just a command really.
After I root. then what?
Also. I was wondering. can Rogers ever be converted into the DREAM100/DREAM110?. i dont know, just wondering. If that was possible, It would make things very simple for people like me.
Click to expand...
Click to collapse
Since you're a lazy noob (at least to the G1), check the link in my sig that will answer most of your preliminary questions. Also look in the development forum's stickies, as there is A LOT of information for noobs about rooting (how to do it, and what it's good for, etc.) and flashing SPL, Recovery, and ROMs.
^That noob thread should be stickied. lol
So now, I am following instructions.
and I am a bit confused.
I am right now setting up my pc for rooting
http://developer.android.com/guide/developing/device.html
It says
Setting up a Device for Development said:
Step 1.) Declare your application as "debuggable" in your Android Manifest.
In Eclipse, you can do this from the Application tab when viewing the Manifest (on the right side, set Debuggable to true). Otherwise, in the AndroidManifest.xml file, add android:debuggable="true" to the <application> element.
Click to expand...
Click to collapse
What exactly does this mean?
Which application.
I have learned that AndroidManifest.xml is used for every application
I have the AndroidSDK on my computer, and I have also installed the usb driver
And when I searched in there, boy I got lots of results for "AndroidManifest.xml"
A little help?
Thanks a lot.
EDIT-
See, while here, I just had a simple question
http://forum.xda-developers.com/showthread.php?p=4280573#post4280573
HyeProfile said:
Rooting the Rogers Dream
3.Install the proper drivers for your device, and make sure you can mount the microSD card and access it from your computer
Click to expand...
Click to collapse
Does this mean, being able to access the MicroSD card straight from you computer with an adapter/card reader? or though the phone?
I can access it from the phone btw
Follow the simple root link in my signature. Takes you to a thread specific to root on a Roger's dream along with a crowd of other canucks executing the same procedure.
A 1gig swap, way way overkill and completely useless to have anywhere near that much
I have decided not to delay any longer getting these files to the dev community here. I expect these may be removed from Megaupload by Motorola very quickly so grab them while you can!
This is a dump of the complete system directory for a recent GRH55 2.3 Gingerbread development build for the Atrix dated 1/21/2011.
I extracted it from the CG60 SMG file which was split from the SBF file using SBF Recalc 1.2.9.1 and then opened as a disc image in WinHex 15.5 Specialist version.
We will also post an archive of the raw CGs which include a number of other partitions that may be of interest as well as the boot files that were packaged separately with the SBF.
Please be very careful when trying to use any of these files on your stock consumer phone. The system includes many debug features and binaries etc. for development that are not found in stock builds and are of little use to end users and in some cases decidedly unwanted on your phone.
Hopefully the developers here will quickly set to work finding out what is most useful and safe for end users and everyone can enjoy the fruits of their labor.
Have fun and remember that there is no custom recovery yet for these phones nor an SBF file to restore with. You are completely unable to recover your phone at this stage if anything goes wrong that prevents it from booting normally!
The reason we are not going to post the SBF file itself is twofold.
First, they are proprietary Motorola files and we have received C&D orders from Motorola in the past and don't wish to have that happen again here.
Second, these engineering builds are strictly for unsecured development devices and will brick a consumer device if you tried to flash it.
We obviously do not want to see anyone brick their phone especially at this early stage when their is no recourse or means of recovery.
USE AT YOUR OWN RISK! Nobody is responsible for what you do to your phone except you!
http://www.megaupload.com/?d=Y232E9J0
very interesting, thanks for the post and info. hope a developer can make uses of this
Not that I will know what to do with these files at all, but I am going to keep a copy just in case someone needs to re-upload the files once Moto takes them down.
cellzealot said:
I have decided not to delay any longer getting these files to the dev community here. I expect these may be removed from Megaupload by Motorola very quickly so grab them while you can!
This is a dump of the complete system directory for a recent GRH55 2.3 Gingerbread development build for the Atrix dated 1/21/2011.
I extracted it from the CG60 SMG file which was split from the SBF file using SBF Recalc 1.2.9.1 and then opened as a disc image in WinHex 15.5 Specialist version.
We will also post an archive of the raw CGs which include a number of other partitions that may be of interest as well as the boot files that were packaged separately with the SBF.
Please be very careful when trying to use any of these files on your stock consumer phone. The system includes many debug features and binaries etc. for development that are not found in stock builds and are of little use to end users and in some cases decidedly unwanted on your phone.
Hopefully the developers here will quickly set to work finding out what is most useful and safe for end users and everyone can enjoy the fruits of their labor.
Have fun and remember that there is no custom recovery yet for these phones nor an SBF file to restore with. You are completely unable to recover your phone at this stage if anything goes wrong that prevents it from booting normally!
The reason we are not going to post the SBF file itself is twofold.
First, they are proprietary Motorola files and we have received C&D orders from Motorola in the past and don't wish to have that happen again here.
Second, these engineering builds are strictly for unsecured development devices and will brick a consumer device if you tried to flash it.
We obviously do not want to see anyone brick their phone especially at this early stage when their is no recourse or means of recovery.
USE AT YOUR OWN RISK! Nobody is responsible for what you do to your phone except you!
http://www.megaupload.com/?d=Y232E9J0
Click to expand...
Click to collapse
thanks for sharing
cellzealot said:
I have decided not to delay any longer getting these files to the dev community here. I expect these may be removed from Megaupload by Motorola very quickly so grab them while you can!
This is a dump of the complete system directory for a recent GRH55 2.3 Gingerbread development build for the Atrix dated 1/21/2011.
I extracted it from the CG60 SMG file which was split from the SBF file using SBF Recalc 1.2.9.1 and then opened as a disc image in WinHex 15.5 Specialist version.
We will also post an archive of the raw CGs which include a number of other partitions that may be of interest as well as the boot files that were packaged separately with the SBF.
Please be very careful when trying to use any of these files on your stock consumer phone. The system includes many debug features and binaries etc. for development that are not found in stock builds and are of little use to end users and in some cases decidedly unwanted on your phone.
Hopefully the developers here will quickly set to work finding out what is most useful and safe for end users and everyone can enjoy the fruits of their labor.
Have fun and remember that there is no custom recovery yet for these phones nor an SBF file to restore with. You are completely unable to recover your phone at this stage if anything goes wrong that prevents it from booting normally!
The reason we are not going to post the SBF file itself is twofold.
First, they are proprietary Motorola files and we have received C&D orders from Motorola in the past and don't wish to have that happen again here.
Second, these engineering builds are strictly for unsecured development devices and will brick a consumer device if you tried to flash it.
We obviously do not want to see anyone brick their phone especially at this early stage when their is no recourse or means of recovery.
USE AT YOUR OWN RISK! Nobody is responsible for what you do to your phone except you!
http://www.megaupload.com/?d=Y232E9J0
Click to expand...
Click to collapse
I have no Idea also what to do with these files but just incase someone else need them I downloaded them, You never know.
Hopefully something with the modem firmware can be pulled from this to turn on HSUPA.
Do you guys have access to an engineering spl ?
Sent from my MB860 using XDA App
humancyborg said:
Do you guys have access to an engineering spl ?
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
That is something that applies to HTC with a Nand lock from my understanding.
We don't have a complete picture of the boot process on this device but Motorola does things differently than HTC and on our OMAP/Qualcomm chipset devices there is no SPL involved in the bootchain.
hey i have a tester atrix from motorola. How would i go about installing this on that?
hassanjanjua2002 said:
hey i have a tester atrix from motorola. How would i go about installing this on that?
Click to expand...
Click to collapse
You would need the full sbf file and a program named rsdlite.
The test model I have is on 4.0.2340.MB860.Attt.en.us which trying to update to 4.0.2350 but keeps failing. With the ! screen showing up mid install. Is there any sbf file or update.zip that i can use at the moment because I don't know how to update it regularly. For either this ginderbread or any version thats newer than mine...
hassanjanjua2002 said:
The test model I have is on 4.0.2340.MB860.Attt.en.us which trying to update to 4.0.2350 but keeps failing. With the ! screen showing up mid install. Is there any sbf file or update.zip that i can use at the moment because I don't know how to update it regularly. For either this ginderbread or any version thats newer than mine...
Click to expand...
Click to collapse
You can not update that phone, you will be stuck on your version because your phone is not able to pass the hash checks in the update.zip. your hope lies in a released sbf file.
hassanjanjua2002 said:
The test model I have is on 4.0.2340.MB860.Attt.en.us which trying to update to 4.0.2350 but keeps failing. With the ! screen showing up mid install. Is there any sbf file or update.zip that i can use at the moment because I don't know how to update it regularly. For either this ginderbread or any version thats newer than mine...
Click to expand...
Click to collapse
do you have a sbf for your phone ? if so please upload so that i can split it and use to compare with other sbf from other dev unit build
Ok thanks for the responses. How do i grab the sbf from my phone? From android sdk?
hassanjanjua2002 said:
Ok thanks for the responses. How do i grab the sbf from my phone? From android sdk?
Click to expand...
Click to collapse
You don't grab it from your phone at all. An SBF file is a proprietary firmware file from Motorola that is flashed with a service ware utility called RSD Lite.
These files are only available to the public via leaks from unofficial sources.
Having a development test phone in this case is a difficult problem unless you have access to internal files for engineering devices.
On another note, I am very surprised that devs are not all over this dump pulling out the framework and libs and apks for use on consumer phones.
There is plenty here that should be able to be safely used.
I am sure that will change once recovery methods have been achieved.
cellzealot said:
On another note, I am very surprised that devs are not all over this dump pulling out the framework and libs and apks for use on consumer phones.
Click to expand...
Click to collapse
Well, what should we be pulling out? Transplanting 2.3 libs and frameworks into 2.2 isn't a good idea, and if it's just a stock MotoBLUR build for 2.3, then nothing's truly different besides it being Gingerbread. Correct me if I'm wrong, but unless there's something wildly new in this build, it's just another version of what we have?
(I'm newer to Android development, but I know multiple languages (Java, C, C++, Obj-C, etc) and have been hacking/dev'ing for the iPhone since 1.0. Just thought I'd state that so I don't like like a huge idiot if this is extremely useful haha)
Smith7018 said:
Well, what should we be pulling out? Transplanting 2.3 libs and frameworks into 2.2 isn't a good idea, and if it's just a stock MotoBLUR build for 2.3, then nothing's truly different besides it being Gingerbread. Correct me if I'm wrong, but unless there's something wildly new in this build, it's just another version of what we have?
(I'm newer to Android development, but I know multiple languages (Java, C, C++, Obj-C, etc) and have been hacking/dev'ing for the iPhone since 1.0. Just thought I'd state that so I don't like like a huge idiot if this is extremely useful haha)
Click to expand...
Click to collapse
It actually looks like stock android.
Smith7018 said:
Well, what should we be pulling out? Transplanting 2.3 libs and frameworks into 2.2 isn't a good idea, and if it's just a stock MotoBLUR build for 2.3, then nothing's truly different besides it being Gingerbread. Correct me if I'm wrong, but unless there's something wildly new in this build, it's just another version of what we have?
(I'm newer to Android development, but I know multiple languages (Java, C, C++, Obj-C, etc) and have been hacking/dev'ing for the iPhone since 1.0. Just thought I'd state that so I don't like like a huge idiot if this is extremely useful haha)
Click to expand...
Click to collapse
Yaotl said:
It actually looks like stock android.
Click to expand...
Click to collapse
you've been pwned sir.
Yup...this is a completely Blurless build and we have one like it for the Droid X as well.
I should caution that some primary functionality appears to be stripped out from the DX build regarding hardware sensors and some other things that are missing entirely.
It's fascinating because it is in many ways what everyone has been whining for since the DX came out with the locked bootloader. It is pure AOSP with virtually no amendments to the libs and very limited or no proprietary Motorola drivers.
There is no WebTop in this build and many other feature again appear to be missing entirely.
So, a very interesting challenge to the developers here to take this mythical beast and turn it into a useable build for consumer hardware by re adding the desired components and shoehorning them back into this build.
Pretty unique opportunity I would say!
Just knowing this file could potentially become a workable 2.3 build for my Atrix makes me VERY excited.
HOPE
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.
Lets see if we can get
- Locked bootloader
- Custom rom security issues
and maybe other security related problems in one development thread and how we make apps to get around this
I take the lead for now, since i started testing custom roms (JellyBean) right now.
and the DRM check at bootup is important to get around, otherwise we end up, having to restore a v10 image again and again, too often.
i suspect that it can be done using a bind folder. but lets see where this takes us.
just update with other issues seen.
Dexter_nlb said:
Lets see if we can get
- Locked bootloader
- Custom rom security issues
and maybe other security related problems in one development thread and how we make apps to get around this
I take the lead for now, since i started testing custom roms (JellyBean) right now.
and the DRM check at bootup is important to get around, otherwise we end up, having to restore a v10 image again and again, too often.
i suspect that it can be done using a bind folder. but lets see where this takes us.
just update with other issues seen.
Click to expand...
Click to collapse
Sounds little bit like Chinese for me but hope you can get a break through and goodluck for all who trying to make it for us an even great phone
ok, i have had my jellybean semi running and oneX rom running, both not very functional, as most hardware did not work well.
the lgdrmserver kept crashing on me as well, but probably less important.
the solution i made was the early boot used the original libraries from /lib from and vendor/lib , so i simply mapped the 2 files in /lib with a symlink to the /system/drm folder and ran the wallpaper binary and it worked fine.
secondly changed a vold binary to be a little script, that
1: bind'd new libraries for drm in drm2 folder (mount -obind drm2 drm) so the new booting os would get related files.
2: start vold
and the workaround seemed to do just fine for the drm security check.
IF it fails during regular boot if you unintentionally copied over the files, do not worry. booting into safe mode (keep VOL UP pressed and press power) you can connect with a shell and bypass the check, and fix your failure and reboot.
Hi
Is DRM checking forced from kernel?
Can we live without it?
no, its called from init.d
Dexter_nlb said:
Lets see if we can get
- Locked bootloader
- Custom rom security issues
and maybe other security related problems in one development thread and how we make apps to get around this
I take the lead for now, since i started testing custom roms (JellyBean) right now.
and the DRM check at bootup is important to get around, otherwise we end up, having to restore a v10 image again and again, too often.
i suspect that it can be done using a bind folder. but lets see where this takes us.
just update with other issues seen.
Click to expand...
Click to collapse
It is allways exciting to see people like you fellow.
Curious, courageous, openminded, wise and most of all doing all without expecting anything.
Success on your way..:good:
Dexter_nlb, You're a hero :good:
When will be released some beta?
since we have root, shouldnt init.d be accessable and easily modifyable?
The Troll said:
since we have root, shouldnt init.d be accessable and easily modifyable?
Click to expand...
Click to collapse
its part of the boot.img (ramdisk), so not really, but the 2nd-init makes it possible to make a new ramdisk and start it. but its only ramdisk, not the kernel, which remains static.
downgrade mode?
sorry, im a htc user thinking of buying this phone.. *since s3 isn't tegra, not thd games and one x kinda sucks with the lack of sd card and stuff..*
but htc has a dorwngrade mode.. 2 exposed connectors close to the camera.. short circuit them to access downgrade mode.. and then flashable though linux..
if im right, that should give u open access to bootloader..
evo 3d cdma used this method to get s-off.. as in bootloader unlocked and accessable with all write restrictions removed on all partitions..
oh forgot to meantion, this can brick ur device.. actually downgrade mode itself is a bricking method.. so i'd be careful *assuming this method is true for gs as well*
The Troll said:
downgrade mode?
sorry, im a htc user thinking of buying this phone.. *since s3 isn't tegra, not thd games and one x kinda sucks with the lack of sd card and stuff..*
but htc has a dorwngrade mode.. 2 exposed connectors close to the camera.. short circuit them to access downgrade mode.. and then flashable though linux..
if im right, that should give u open access to bootloader..
evo 3d cdma used this method to get s-off.. as in bootloader unlocked and accessable with all write restrictions removed on all partitions..
oh forgot to meantion, this can brick ur device.. actually downgrade mode itself is a bricking method.. so i'd be careful *assuming this method is true for gs as well*
Click to expand...
Click to collapse
nah, we haven't nothing to lose... someone should try it
The Troll said:
but htc has a dorwngrade mode.. 2 exposed connectors close to the camera.. short circuit them to access downgrade mode.. and then flashable though linux..
if im right, that should give u open access to bootloader..
evo 3d cdma used this method to get s-off.. as in bootloader unlocked and accessable with all write restrictions removed on all partitions..
Click to expand...
Click to collapse
i believe you reference a different hardware platform not Nvidia based. o4x is nvidia tegra3 and different from omap and other platforms security wise.
can you link to the tegra fuse , you reference here? (fuse is a connector which will break the firmware open and full access granted, but can also cause firmware to not load, since fuse is broken)
reas0n said:
nah, we haven't nothing to lose... someone should try it
Click to expand...
Click to collapse
flash image GUI..
someone rooted should try that first..
also, unlimited.io <--- website.. for details of the downgrade mode trick..
http://forum.xda-developers.com/showthread.php?t=1547695
http://forum.xda-developers.com/showthread.php?t=1491107
http://forum.xda-developers.com/showthread.php?t=1563342
http://forum.xda-developers.com/showthread.php?t=1627917
the basic idea of this is 2 connectors close to the camera.. short circuit them to switch the phone to downgrade mode *QHSUSB_DLOAD*.. bricking the device and mounting all partitions as read and writable.. then using linux to find the right partition to flash/dump the hboot *the bootloader*
at the end, if it uses fastboot/adb, i dun think this will be too different from the evo 3d..
try it.. but dont say i didnt warn you..
im not sure its a fuse, its more of a reset?
also, i dont exactly have the phone *yet* so i cant tell..
but for the 3d, its exposed.. 2 holes in the back under the cover, next to the camera..
http://unlimited.io/juopunutbear-public-beta-0-1/instructions/evo-3d-cdma-shooter/
or you can find a schematic of the phone itself..
if you dont mind me asking, whats the reason for the lack of devs?
this is an excellent phone..
is it the extreme security?
iphone got a jailbreak too :/
ok, this is a QUALCOMM solution, not for our tegra3 based platform
Dexter_nlb said:
ok, this is a QUALCOMM solution, not for our tegra3 based platform
Click to expand...
Click to collapse
how did one x get the kernels running?
**edit.. nvm.. htcdev.. forgot..
Hope you guys can pass by all that anoyeingsecurity. Would like to buy that phone but without real controll over the hardware aand custom rom community i would seariously reconsider buying it...
Dexter, the One X solution is for Tegra3 devices. The QUALCOMM-Device is called HTC One XL. So if the chipset is nearly the same, there must be a solution? If I could code anything, I would. But I cannot
Hilmy said:
Hope you guys can pass by all that anoyeingsecurity. Would like to buy that phone but without real controll over the hardware aand custom rom community i would seariously reconsider buying it...
Click to expand...
Click to collapse
Instead of trying to bypass, people should be asking LG for an unlock mechanism. I've been talking to them about this for over half a year, and today they still feel there is no demand for it (unlock tools)
Show of hands: How many people here have actually e-mailed LG asking for an unlock procedure, for this or any other of the current locked generation?
aremcee said:
Instead of trying to bypass, people should be asking LG for an unlock mechanism. I've been talking to them about this for over half a year, and today they still feel there is no demand for it (unlock tools)
Show of hands: How many people here have actually e-mailed LG asking for an unlock procedure, for this or any other of the current locked generation?
Click to expand...
Click to collapse
do you have the mail address we can use? then we can engage a mailrobot to send them 10000s of mails regarding the unlocker, and maybe they will follow asus and motorola/google on this one.
Dexter_nlb said:
do you have the mail address we can use? then we can engage a mailrobot to send them 10000s of mails regarding the unlocker, and maybe they will follow asus and motorola/google on this one.
Click to expand...
Click to collapse
I'd rather not forewarn them by asking for a contact for this
My personal opinion: a mailrobot would be a bad idea, they'd just filter it out. Actual users, with actual devices (serial numbers in the message and all that) would carry much more weight than just generic "gimme". From experience... petitions don't work, either, unless they hit visible news outlets;
My suggestion would be to hit a support contact, consistently (instead of dispersing the message to random contacts); most companies will escalate any issue given enough occurrences of it. On the other hand, I can't find contacts besides the country-specific ones at http://www.lg.com/global/supports/service-sites.jsp ...
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