A hacker's journey: freeing a phone from the ground up, third part
Written by Paul Kocialkowski no commentsWith all that soldering successfully performed on my LG Optimus Black (P970), I was finally able to load my own code and actually see the results, on UART.
Building and running
X-LoaderI first tried to build the X-Loader source code that was released by LG and, after addressing some relocation issues, got it to finally print something on serial! The first step was to get X-Loader to run on the device, to a point where it could load and run U-Boot. I had at disposal the version released by LG, which is not exactly the most recent one out there, and found various other versions on the Internet. Overall, I was told that X-Loader development is a bit of a mess: it was initiated by TI for OMAP devices, but there is no clear notion of upstream for it, just different branches that work on different OMAP devices. The closest thing I could find was the X-Loader project on Gitorious, which was an initiative to gather all the various X-Loader trees into one, as I was told. That felt like the right path to follow, so I decided to use it as a base for development for the Optimus Black (P970) codename sniper's X-Loader port. Most things worked nicely by importing code from the LG release, even RAM initialization was rather painless and worked straight away. Soon enough, I was at a point where my concern was loading and running the next stage bootloader: U-Boot.
Loading the next stage
The Optimus Black (P970)'s internal storage is eMMC. There is a partition for X-Loader and one for U-Boot too. As I wanted to keep the devices in an usable state (a working shell on a kernel that actually works can turn out to be an important resource when working close to hardware), I decided to avoid flashing the internal memory. And flashing requires the current system to work, so that would only have worked once. Not really a possibility. Of course, I would still need to be able to boot from internal memory for production, once everything is known to work. Internal storage is connected to the OMAP3's MMC2 controller while the external sdcard is connected to MMC1. The current X-Loader code would only deal with MMC1, so I decided to give booting from internal memory a shot. After all, there was already a bootloader in there (LK) and my X-Loader code should have been able to boot it as well. Given that the bootrom has to be able to boot directly from MMC2 (it is the first boot option), everything is wired according to the TRM: that is, using the appropriate TWL5030 regulators. Thanks to that, the code in X-Loader was able to use the eMMC without any change and it would soon load and run the preinstalled LK.
Booting from the external sdcard
Real trouble began when I started looking into getting X-Loader to read from MMC1 (the external sdcard). Modifying X-Loader so that it would also allow booting from MMC1 wasn't enough to do the trick. As it turned out, MMC1 is powered by an external PMIC, the LP8720: one of its LDOs is dedicated to powering MMC1 (3.0V_MMC). Looking at the schematics, it appeared that the LP8720 is contacted through I2C3. Thankfully, it had good enough documentation available (in addition to the reference code from LG), so it was really easy to figure out how it works. X-Loader's I2C code wasn't designed to allow changing the bus either, so I had to implement that too. With the bus switched to I2C3, I should have been able to communicate with the device. Except that it didn't work. I spent a crazy amount of time looking at the TRM, making sure that every necessary clock was enabled, every needed pin muxed properly, but it didn't do. The controller would only return the same error. Nevertheless, it worked perfectly on the preinstalled Android version and other buses were working normally too. It just didn't seem to make sense and after a week or so, this got me very frustrated.
Frustration and investigation
Spare boardAt some point, I even wrote an I2C probe function from scratch based on what the TRM recommends, with no better result than the original code. Looking at it more closely, it seemed that the controller wasn't getting any NACK. I was able to reproduce the same behavior by disabling input on another I2C bus, or by muxing the pins to GPIO. Still, it didn't make sense that it happened all the time on I2C3, so I asked on the TI E2E community forums but didn't really get a clue there. Since I had another working device at disposal, I decided to tear its board off, keep only the USB connector, load my code and look with a probe at what was actually going on on the bus. Lacking proper hardware, I used my buspirate as a logic analyzer but it didn't really work out, neither did my Arduino Uno. It was also particularly hard as I had to probe on two very tiny resistors to get I2C3's SCL and SDA lines. I decided to head back to LabX, where I knew that people would have a clue about how to do this properly. It turned out that nouveau developer Martin Peres was around at that time and kindly offered to bring his own digital oscilloscope. That was really a life saver! After a short while, we were able to probe the SCL and SDA lines and see things actually going on in there. A few times, we were even able to catch a full trace with SDA and SCL simultaneously. Martin knew the I2C protocol well, so we were able to decode the transaction, only to find out that everything was going on just fine. NACK was there and I just couldn't understand why the controller wasn't getting it.
I2C3 trace
GPIO to the rescue!
Probing the spare boardIn the meantime, while I was discussing the issue with fellow developer GNUtoo, he suggested that I mux the pins to GPIO to see what reads. The device with UART attached did show 1 for GPIO read on I2C1 SDA and SCL lines but showed 1 on SDA and 0 on SCL on I2C3. It was as if the SCL line wasn't pulled high as it should have been. I could not actually measure the tension there, as opening up the case would tear off my UART setup. On the spare board, it was clear that SCL was pulled high by reading the voltage, so the 0 GPIO read did seem like the I2C controller on the OMAP wasn't reading the values properly. It still worked normally on Android though, so this was clearly not a hardware problem. That's when I decided to take an extra step: checking that the spare board actually read 0 like the board with UART did. Since the spare board didn't have UART, I needed some other way to read back the values. The most straightforward solution was to use the same I2C3 pins, read the boolean value, then configure the GPIO to output and write back the opposite of the read value (so that I would clearly see the difference).
Sub-board connectedAnd it turned out that reading those values with my voltmeter indicated that the spare board was reading a logical 1 on I2C3 SCL. Thus, my two devices were behaving in two different ways. Moreover, it was likely that I2C3 had been working correctly on the spare board since the very beginning. Now what is the difference between those boards? The most obvious thing is that one is loaded with all the sub PCBs while the other one had only the USB connector attached, which would allow me to probe the I2C3 resistors. Regarding the I2C3 bus, there were indeed a handful of slave devices attached to it on a sub-board that I removed, so I plugged the sub-board back and read the GPIO values again. It then indicated 1 for SDA and 0 for SCL! So the differences between both setups were apparently caused by that sub-board, and something in there was bringing SCL to 0. The slave devices were mostly sensors and looking at the schematics revealed that they were using dedicated regulators. After a quick check, it appeared that 1.8V_MOTION_VIO and 3.0V_MOTION were possibly not enabled. Those are LDOs from the TWL5030, so I just thought I would give a shot at powering them up. Right after that change, the GPIO read on the UART-enabled devices turned to 1 for SCL! Another build to switch the muxing back to the I2C controller and I could finally probe the LP8720 regulator correctly!
This post is part of a series of articles about freeing the LG Optimus Black (P970):