Paul Kocialkowski's coding blog

Free software, programming and stuff

A hacker's journey: freeing a phone from the ground up, fourth part

Written by Paul Kocialkowski 5 comments

That whole I2C issue took me close to two months to resolve. As I recall, probing finally worked on my last day of summer vacation. I was so happy to finally have figured the issue out, that over the next week or so, I cleaned-up the X-Loader code and got it to a state where it could load LK (the only working second-stage bootloader binary I had at disposal) from the external sdcard.

U-Boot

A few months went by, I started working on other things, like Allwinner devices, on my ever-shrinking amount of spare time. At some point, I decided I needed to get back to it and properly port U-Boot. Of course, we're talking about upstream U-Boot here, as I'm not a big fan of either fighting with the code LG released (that is old, poorly written and contains a lot of dead code) or adapting versions of U-Boot code coming from TI. Working with upstream has countless advantages, among which I see an opportunity to get familiar with the current state of the U-Boot code as well as going through the process of having my code reviewed by peers, which is always a very enriching experience. It ensures that code is written the right way, fits well in the overall design and doesn't break something else. The temptation of doing easy and nasty changes to suit our case better is big when working on our own personal fork of such a big project and that's exactly what I wanted to avoid. Finally, having the phone in my pocked supported by upstream is pretty cool, right?

As I first dig into the U-Boot code, it struck me that an increasing number of devices are using the U-Boot SPL as a first stage loader. The U-Boot SPL is a minimalistic build of U-Boot that only contains the minimal amount of code to be able to chainload the usual and complete U-Boot binary. There is SPL support for the OMAP3, so I thought I might as well give it a try, since X-Loader is an old copy of deprecated U-Boot code anyways. It didn't take me long to get it to run, with the usual base address correction due to the fact that I'm using peripheral booting. I will most certainly drop X-Loader and go with U-Boot and the U-Boot SPL for the future.

Current status and overlook of the future

U-Boot running
U-Boot running
To this day, I have submitted a handful of patches upstream to add support for various features that I need for the P970 (named sniper in the code) and most of those were accepted already. The rest of it is available on my personal git repository for the Optimus Black (P970) codename sniper's U-Boot port. I am still working on getting board support ready with a certain amount of features, like fastboot support (including eMMC flashing) and being able to get the SPL to boot U-Boot from the external sdcard on demand, to allow failsafe U-Boot development without having to unsolder a resistor.
A few others things are needed in order to be able to load and run kernels painlessly: currently, booting Linux is working but a few features appear to be broken.

The next steps in this journey are the following: getting board support ready and accepted in upstream U-Boot and then starting the Replicant port. It shouldn't be too much work to get Replicant running on the device, so I'm confident it will come around. Of course, I will properly document the device on the Replicant wiki at some point in the near future. I am also hoping to talk about this device at FOSDEM this year, among other exciting new things that I've been doing recently.

And once upstream U-Boot support is merged, why stop there? I could just as well try and get some Linux support for it upstream: that could be an interesting and challenging task, despite not being crucial for software freedom. And of course, once everything is properly documented, everyone is welcome to join in and help!

Finally, during all this, I've come to learn about a few other mainstream OMAP GP devices (that I will also document at some point), such as the first generation Kindle Fire from Amazon, which is really likely to become my next target for Replicant after the Optimus Black. Thanks to the great work already achieved by developer Hashcode, there is already an U-Boot port available, and instructions on how to get UART from the device are also available!

Conclusion

Overall, I'm definitely very happy with the way this whole experience went. It most certainly brought me a lot regarding how low-level initialization and bootloaders work and hopefully offered me a chance to make a real difference for those of us who care about having free bootloaders running on the devices in our pockets, in addition to a free system. The odds also seem to be in our favor when it comes to modem isolation, so the whole device is pretty close to being “as good as it gets” today. To be fair, everything is not exactly great about it: graphics acceleration and 3D will still be proprietary, the GPS protocol is still unknown and the video decoding unit (DSP) as well as Wi-Fi and bluetooth require loaded proprietary firmwares.

As a final word, I'd like to thank whoever decided to go with the GP version of the OMAP3630 at LG. Heck, that decision brought me the hell of a ride!



This post is part of a series of articles about freeing the LG Optimus Black (P970):

5 comments

#1  - Christopher Waid said :

This is awesome news. If "modem isolation" involves privacy and security aspects as I'm pretty sure it does then it sounds like the only pretty-critical component missing from a free software standpoint is the wifi. Even as it stands it sounds like it could potentially be a very privacy-friendly messaging device (even if not a cell phone as with a cell phone they *always* know where you are as opposed to with a messaging device you can potentially gain some level of control over it if that is in fact possible with modem isolation via turning on/off the modem) if the user ends up having the level of control over it that I think may be achievable. I'd love to see a cellular messaging device where the modem doesn't have access to the rest of the device such that you know big brother can't see whats going on (even if they can tell whats being transmitted if not encrypted once it gets to the modem).

#2  - Paul Kocialkowski said :

@Christopher Waid :
> If "modem isolation" involves privacy and security aspects as I'm pretty sure it does

You can read more about how modem isolation relates to privacy and security aspects at: https://www.replicant.us/freedom-privacy-security-issues.php.

> then it sounds like the only pretty-critical component missing from a free software standpoint is the wifi.

Privacy/security and free software are two separate issues that are fundamentally different, even though we believe free software is a requirement for reliable privacy/security. Regarding free software support, as I mentioned, the GPS still doesn't have free userspace drivers (and requires a proprietary loaded firmware), Wi-Fi and bluetooth require proprietary loaded firmwares (but the system-side drivers are all free software) and of course, graphics don't have free userspace drivers. Video decoding will also not working without proprietary loaded firmwares (drivers are free, too).

> Even as it stands it sounds like it could potentially be a very privacy-friendly messaging device (even if not a cell phone as with a cell phone they *always* know where you are as opposed to with a messaging device you can potentially gain some level of control over it if that is in fact possible with modem isolation via turning on/off the modem) if the user ends up having the level of control over it that I think may be achievable. I'd love to see a cellular messaging device where the modem doesn't have access to the rest of the device such that you know big brother can't see whats going on (even if they can tell whats being transmitted if not encrypted once it gets to the modem).

This is still a phone and while there is no evidence pointing that the modem can access any other component of the device directly, it can still be tracked everytime it's on. I am unsure there will be a way to switch the device off reliably (it looks like it could be the case but I have to conduct further investigation). Normally, switching it to airplane mode should guarantee that the phone is not transmitting anything, but I would understand that people have doubts believing that.

#3  - skierpage said :

Great work!

#4  - pablog said :

Great work, very inspiring!

#5  - capcj said :

Man, you are awesome! Great work, you inspire all of us in the field!

Thank you!

Comments are closed.

Rss feed of the article's comments

Fatal error : type : 8192 message : Function utf8_decode() is deprecated file : /core/lib/class.plx.utils.php line : 843 See https://www.php.net/manual/en/errorfunc.constants.php about type of error ============================================================ Drop this plugin now for running PluXml and report to its author !!