-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Root Porting ClockWorkMod to the Kyocera Rise
- Thread starter cooldudezach
- Start date
-
- Tags
- kyocera rise
Use opera mobile classic
smartmanvartan
Android Expert
Here was my last post as a contributor and the attached picture should motivate you guys...
Thing is unless it looks within the fw itself and not on the phone you will brick your rise.Momentarily it may but when turning your phone off embedded will still kick in overwriting anything not done by Kyocera themselves simultaneously booting you to a black screen with no way to recover.Lmfao good luck though
TechDad378
Well-Known Member
I have a question...
I have been reading through this thread for a while and tested a few things with cwm. I am able to install it on the phone but it reboots back to the logo. When o do this there is no recovery app installed no matter how many times I reboot. When that happens I am able to reinstall the stock recovery. It seems the offset may be the cause of my problem. Can someone help me identify my phone's offset for the recovery block? I need a method to verify my offset against someone else's offset. This will help me determine if the recovery block offset is the cause of my problem. Thanks in advance!
I have been reading through this thread for a while and tested a few things with cwm. I am able to install it on the phone but it reboots back to the logo. When o do this there is no recovery app installed no matter how many times I reboot. When that happens I am able to reinstall the stock recovery. It seems the offset may be the cause of my problem. Can someone help me identify my phone's offset for the recovery block? I need a method to verify my offset against someone else's offset. This will help me determine if the recovery block offset is the cause of my problem. Thanks in advance!
smartmanvartan
Android Expert
The stock recovery... you where able to flash it back to its partition? and now you can boot into stock recovery? You have the Kyocera rise?
TechDad378
Well-Known Member
Yes you are correct. It is stock recovery and I am using a rise. I think the problem is the offset or may be the size of the cwm version. Once I verify the offset I could test the size difference.
smartmanvartan
Android Expert
I think if you mount your stock recovery.img with adb you can get some more info.... I haven't had this device in a long time, whats the total partition size for the recovery? 16mb? But there is more to it... there is a secondary protection in the device... On my rise(C5156 for Public Mobile) I had fastboot and was able to boot into CWM recovery with "fastboot boot c:\<imagename>.img"... but even then, the recovery would reboot about 30 seconds after... I think it resembles what Myformiscrack was saying... how would you go about replicating the offset?
TechDad378
Well-Known Member
There is a boardconfig file for the recovery where you can change the offset. There is a check which is ran when the device starts. This checks the integrity of the boot. If the offset is set correctly this may resolve the problem.
I know JB+ versions have a feature called MF_Check which bypasses the ics integrity check.
I know JB+ versions have a feature called MF_Check which bypasses the ics integrity check.
smartmanvartan
Android Expert
yes but I have made a stock recovery that didn't work... the only thing i changed was ro.debugable = 1 so that adb could be used while in recovery... then i repacked it and even the stock recovery unpacked and repacked would not load after being flashed... it's a signature in the packing process for sure...
TechDad378
Well-Known Member
Where did you change the ro.debuggable? Did you use windows or Linux machine?
I unpacked and repacked in windows which did not work to well
When I unpacked and repacked in linux the recovery worked fine.
It seems somethings work on one os better than the other. I have access to both Oses for that exact reason.
Now taken into consideration what you said, I did not change ro.debuggable. I believe you made the change in default.prop when you unpacked it, correct? If so I will attempt this later today, in order to see the results.
I unpacked and repacked in windows which did not work to well
When I unpacked and repacked in linux the recovery worked fine.
It seems somethings work on one os better than the other. I have access to both Oses for that exact reason.
Now taken into consideration what you said, I did not change ro.debuggable. I believe you made the change in default.prop when you unpacked it, correct? If so I will attempt this later today, in order to see the results.
smartmanvartan
Android Expert
Yes I use ubuntu and abootimg was the command I used to unpack. I use ark to unpack the initrd.img and the proper command to pack ramdisk initrd.img after making my changes and abootimg to repack everything. The bootimg.cfg file sets the size of the image so you can replicate the exact size as the original...
TechDad378
Well-Known Member
One thing I realized the linux commands make a big difference.
I got the stock recovery version working yet the same steps with CWM does not work. When CWM is on the phone, it just reboots to logo.
I was able to determine a few things with the bootloader.
It seems the boot loader is locked by a key on the vendors server. It can be unlocked with the key.
VM would not have this key since Kyocera provides updates for the phone. The command "fastboot + bootloader-offset" should produce a password prompt for the bootloader.
Now getting fast boot to work first for the Rise is tough. This will be done with the correct fastboot set-up and Rise drivers. Then we need a hardware key combo which starts a download mode. Once that is done finding the bootloader offset is next.
Now the bootloader key is questionable. Some say the keys are tied into the phone imeid number. Dailing "*#60#" produces the id. I don't think there is a key for each phone. I think there is a generic key for all the devices considering the price of the device. Having (ex xx amount of keys for xx amount of phones) needs to be maintained somewhere. More phones made, more keys, means larger databases and higher costs to maintain. Which would drive the cost up of the phone. My point is cheap phone, means less maintenance, or one key for all devices.
Just a few thoughts I had towards Porting CWM.
I got the stock recovery version working yet the same steps with CWM does not work. When CWM is on the phone, it just reboots to logo.
I was able to determine a few things with the bootloader.
It seems the boot loader is locked by a key on the vendors server. It can be unlocked with the key.
VM would not have this key since Kyocera provides updates for the phone. The command "fastboot + bootloader-offset" should produce a password prompt for the bootloader.
Now getting fast boot to work first for the Rise is tough. This will be done with the correct fastboot set-up and Rise drivers. Then we need a hardware key combo which starts a download mode. Once that is done finding the bootloader offset is next.
Now the bootloader key is questionable. Some say the keys are tied into the phone imeid number. Dailing "*#60#" produces the id. I don't think there is a key for each phone. I think there is a generic key for all the devices considering the price of the device. Having (ex xx amount of keys for xx amount of phones) needs to be maintained somewhere. More phones made, more keys, means larger databases and higher costs to maintain. Which would drive the cost up of the phone. My point is cheap phone, means less maintenance, or one key for all devices.
Just a few thoughts I had towards Porting CWM.
smartmanvartan
Android Expert
well on the c5156 had a advantage on the c5155 and c5170. It could be rebooted into fastboot using this. But has anyone looked into the c5133? in any case, I hoard data on my hard drives and still have a full adb backup of my c5156 somewhere... maybe it could be analyzed and turned into away for you guys to get into fastboot... OH snap! I still have an active link to it.. C5156... I still have hope for you guys...
EDIT: remember partitions are different between both rises and the hydro...
EDIT: remember partitions are different between both rises and the hydro...
TechDad378
Well-Known Member
The app is sort of useful. To a point. This app sends commands to the phone triggering certain events. Now the problem I noticed with apps like this Reboot Menu, they don't give the desired results.
The apps are generally used to accomplish the task as quickly as possible and to be universally accessible to majority android devices. With that in mind, speed versus integrity is tough. Users rather have something run fast than take long while checks are done.
With the correct usb drivers and adb set-up this can be accomplished by typing...
1. adb reboot
2. adb reboot recovery
3. adb reboot bootloader
4. adb reboot download
5. But shutdown works well with manual shutdown even better with shutdown and battery pull.
I am posting this because, I realize I got better results when using the methods I provided. This may help Someone else get some more results.
The apps are generally used to accomplish the task as quickly as possible and to be universally accessible to majority android devices. With that in mind, speed versus integrity is tough. Users rather have something run fast than take long while checks are done.
With the correct usb drivers and adb set-up this can be accomplished by typing...
1. adb reboot
2. adb reboot recovery
3. adb reboot bootloader
4. adb reboot download
5. But shutdown works well with manual shutdown even better with shutdown and battery pull.
I am posting this because, I realize I got better results when using the methods I provided. This may help Someone else get some more results.
smartmanvartan
Android Expert
Actually no...on the c5156 the "adb reboot bootloader" command did not work...it would just reboot the phone...Dane with the "adb reboot download"command...but for some reason that app worked...
TechDad378
Well-Known Member
Yes it does not work with C5155 either by default.
I had to tweak the usb driver for it to work properly.
That's why it makes a big difference for the Rise. It seems the default drivers they provide don't allow access to certain things.
But even with the default drivers the pc allows the commands but the when rebooting the pc does not recognize the device until it is fully booted.
Which leads me to believe the default.prop file with the line added...
- persistant.usb.adb.debugable=1 or a variant of that property may resolve the problem when booting.
That is something I am going to test but need CWM first.
I had to tweak the usb driver for it to work properly.
That's why it makes a big difference for the Rise. It seems the default drivers they provide don't allow access to certain things.
But even with the default drivers the pc allows the commands but the when rebooting the pc does not recognize the device until it is fully booted.
Which leads me to believe the default.prop file with the line added...
- persistant.usb.adb.debugable=1 or a variant of that property may resolve the problem when booting.
That is something I am going to test but need CWM first.
smartmanvartan
Android Expert
The default drivers are actually not available for the c5156...I had to use the universal one in pdanet...
TechDad378
Well-Known Member
What happens is with the default drivers from Kyocera they do not pick up the Kyocera Modem.
I found that Pda.net v4.126 picked up the modem. The problem was the drivers from Pda did not work with other devices to well. This cause me to see there is a solution to the pc recognizing the device.
When you plug the device in you will see only charging and storage generally work.
I added some line of code to the google usb driver and the problem was solved.
The new adb for versions of android 4.2+ were very tricky to get working.
But there is hope for the phone.
I found that Pda.net v4.126 picked up the modem. The problem was the drivers from Pda did not work with other devices to well. This cause me to see there is a solution to the pc recognizing the device.
When you plug the device in you will see only charging and storage generally work.
I added some line of code to the google usb driver and the problem was solved.
The new adb for versions of android 4.2+ were very tricky to get working.
But there is hope for the phone.
smartmanvartan
Android Expert
So if you have fastboot with your new drivers, why can't you check your offset? wanna post a link to your modified drivers? I'll poke my head in regularly if your motivated to do this and maybe even pick up a c5156 again for deving... I have one but it needs a new motherboard...
TechDad378
Well-Known Member
I will post a link to the drivers when I get a chance.
The drivers work on windows.
The drivers work on windows.
TechDad378
Well-Known Member
I have been running some tests with the drivers I add before posting. Never really tested them since I generally only use charge only.
The drives work except when you select mass storage and disconnect or switch modes, the mass storage notifications stays on until you reboot the device.
I need to determine where this is staying locked in the device from the regular event of just disappearing from notifications.
The drives work except when you select mass storage and disconnect or switch modes, the mass storage notifications stays on until you reboot the device.
I need to determine where this is staying locked in the device from the regular event of just disappearing from notifications.
TechDad378
Well-Known Member
Here is something else I realized about CWM. I had been using the builder page from the site. Though the regular recovery created by the site worked the cwm version did not.
This takes me to my next thought. The buldier app creates cwm and it shows successful. Yet when I read the log pages, it seems the CWM version needs to be manually created on a linux machine.
I will attempt to build a version of CWM from all the information I have gathered.
The bootloader is locked and I am almost sure we won't get it unlocked by the vendor Kyocera. The reason it is locked is to reduce unwanted results from corrupting files. This way the boot loader will automatically reverse any critical error.
This is way when some have tried to install cwm then reboot it would reboot twice. The first boot attempts the cwm install since it fails it is rebooted again into the file system.
This clears the system from critical errors and fixes them.
This is how the file system is set-up.
Now I noticed when other devices are in root with an unlocked boot loader the command line shows root@android: our device does not say that so it seems this may be a possible solution. The /root folder on the device is empty. I think if we can find the correct system link to create "ln -s" this may bypass the bootloader all together. Possible the correct lines of code added to the init file. Since the init file runs right when the system starts.
Just a few thoughts to add to this, hopefully we can all combine our thoughts to resolve this. This would be resolved if it was a very popular device. But this is still an excellent device to learn android!!!
This takes me to my next thought. The buldier app creates cwm and it shows successful. Yet when I read the log pages, it seems the CWM version needs to be manually created on a linux machine.
I will attempt to build a version of CWM from all the information I have gathered.
The bootloader is locked and I am almost sure we won't get it unlocked by the vendor Kyocera. The reason it is locked is to reduce unwanted results from corrupting files. This way the boot loader will automatically reverse any critical error.
This is way when some have tried to install cwm then reboot it would reboot twice. The first boot attempts the cwm install since it fails it is rebooted again into the file system.
This clears the system from critical errors and fixes them.
This is how the file system is set-up.
Now I noticed when other devices are in root with an unlocked boot loader the command line shows root@android: our device does not say that so it seems this may be a possible solution. The /root folder on the device is empty. I think if we can find the correct system link to create "ln -s" this may bypass the bootloader all together. Possible the correct lines of code added to the init file. Since the init file runs right when the system starts.
Just a few thoughts to add to this, hopefully we can all combine our thoughts to resolve this. This would be resolved if it was a very popular device. But this is still an excellent device to learn android!!!
DMedina559
Android Enthusiast
What if we bring Google into this? I'm pretty sure Kyocera has violated some Android agreements to be on their devices. Google could probably force Kyocera to release a Bootloader unlock method...
Just a thought.
Just a thought.