It has been quite some time since I’ve talked about the RAZR-HD which was so generously donated by the community at DroidRZR.com. So I should do a quick recap of where we’re at with development:
Obviously we have a functioning Safestrap (which still needs a few tweaks to enable stock ROMs). But, development for the RAZR-HD/M/AHD has been VERY sluggish on our end. And I can totally understand if there are grumblings out in the community regarding our progress:
1. It’s not always that easy to pick up an entirely new platform and get rolling on it. And I think we’re suffering a bit due to the MANY MANY changes in the QCOM devices. Everything from RIL, to wifi, to the libs operate in different ways than on the OMAP phones we’ve been supporting. So development just takes longer.
2. There has been some really good development for these phones. One of the Atrix devs (E. Pinter) has done some GREAT work getting the XT925/XT926 (and potentially the M barring some bugfixes) up and running on CM10.1. Unfortunately, the direction he took was to do the updates the way it’s intended: via the kernel and using AOSP drivers. So this kind of development doesn’t work on the locked Verizon phones. :/
3. Currently, I’m working on getting kexec up and running for the QCOM phones in a similar way that the OMAP phones has kexec as an option. You can see this work here:
Kexec-Tools: https://github.com/razrqcom-dev-team/kexec-tools/commits/master
Kexec-Modules (for use on the stock kernel): https://github.com/razrqcom-dev-team/android_kernel_motorola_msm8960-common/commits/jellybean-stock-kexecmodules
What’s been done? Using the development edition phone as a testing device: I pulled the atag info given to the kernel via the bootloader, as well as the device-tree, and I’m using a custom kernel to troubleshoot the kexec process. I’ve also had to customize the kexec tools to use a different method of loading / starting the kexec process. Turns out the newer 3.0.31 kernel has new security features which are fixed some of the holes that were used to setup the kexec syscalls as was done on the OMAP phones.
Right now, I’m to a point where part of the kexec process goes on w/o any real indication of what’s happening. In the past, developers like [mbm] and Kholk setup a vibrate to see where this process crashes. However, those are still not working on the QCOMs.
So I took apart the phone and search for UART pads to get serial output up and running. Here again, I was unsuccessful in my search over 3 nights of probing nearly every point on the motherboard I could find.
Couple of snapshots of parts of the RAZR-HD motherboard:
Next steps:
#1 Priority: Fix kexec and get a usable kernel out to the public. This would fully leverage all of the great development that exists right now for the locked devices.
#2 If for some reason it doesn’t look like kexec is going to be an option, then we’ll revisit building CM10.1 using the existing portions of software that we have much like we do on the other Moto’s.
Sorry it’s taking such a long time to get rolling. :/
