Put a Raspberry Pi CM4 into an original iPad

Open up a 2010 iPad, remove its logic board, and fabricate a new board based around the Raspberry Pi CM4.

Public Chat
Similar projects worth following
The 2010 iPad is completely unsupported, and is almost useless. It will still run old apps, but almost all internet-connected apps are broken. Even browsing the web in Safari is difficult, since iOS 5 has out-of-date TLS CAs.

But still, it's a pretty good piece of hardware in many ways. If we were to replace the logic board, we could still use these parts:

* Case
* 25 watt-hour battery
* capacitive touchscreen digitizer
* 1024x768 LCD
* 2x wifi/bluetooth antennas
* mono speaker
* TRRS port
* microphone
* ambient light sensor
* four buttons (lock/unlock, volume up, volume down), one switch (rotation)
* The wifi/BT module
* 30-pin connector

In this project, I am building a replacement logic board around a Raspberry Pi CM4.

Apple sold millions of iPads the year they were introduced. These devices were capable of browsing the web, watching movies, and playing games, with up to 10 hours of battery life and an intuitive touchscreen display. Apple essentially defined what a tablet should look like, and competitors are still playing catch-up.

However, all the original iPads are many years out of date. While some apps still work, and some can be made to work by jailbreaking the device, due to a lack of software support by Apple, these tablets are unable to do many of the things they used to be capable of.

The hardware isn't terrible, though! The iPad has a nice touchscreen, an okay LCD, a beefy battery, and enough buttons and ports to make it still useful as a computing device.

With this project, I intend to make a logic board for the original iPad based around the Raspberry Pi CM4 or another similar SoM. This will allow people to upcycle their obsolete iPads into fully-functioning tablets, which should be able to run Linux and Android.

Hopefully by giving these venerable devices a new lease on life, we can keep some of them out of landfills.

  • Identifying the ambient light sensor

    Evan03/05/2024 at 05:39 0 comments

    I've long been ignoring the ambient light sensor flex cable that's part of the iPad's display assembly. This connects to a 24-pin board-to-board connector on the logic board, pictured on the right edge here:

    Only 7 of the 24 pins are used:

    • 3.0V
    • SCL and SDA for i2c
    • ALS_INT_L
    • COMP_RST_L
    • COMP_INT_L

    The other 17 pins are ground.

    (Fun fact: this connector, the AA03-S024VA1, is also what they used for the camera in the iPhone 3G, though with a different pin configuration. Maybe they had a lot of extras and decided to reuse it on the iPad. It's not like they were low on space in the iPad, so using a larger-than-necessary connector wouldn't be a big deal.)

    The last two pins are connected in the iPad schematics to "COMPASS_RST_L" and "COMPASS_INT_L", 

    I've been including this connector in all my prototype PCBs, and I also created a breakout board for it. This weekend, I wired up the breakout board to a Pi 4 (just power and I2C, none of the interrupt/reset pins) and got to work trying to figure out what ambient light sensor IC is used.

    What's i2c address 0x39?

    By wiring up the breakout board and connecting it to a Raspberry Pi, we can see that this cable only seems to have one device on it, at address 0x39: 

    meatmanek@pi4:~ $ i2cdetect -y 1
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:                         -- -- -- -- -- -- -- -- 
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    30: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- -- 
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    70: -- -- -- -- -- -- -- --    

    That's odd. I was expecting two devices: one for the compass, one for the ambient light sensor. Maybe it's a single IC?

    Searching the internet for "i2c address 0x39" brought me to which gives us a few options:

    Hmm. 3 of those could be ambient light sensors (APDS-9960, TSL2561, VEML6070), but also surely there are more devices out there that use this address.

    Not wanting to tear apart my iPad more than necessary, I took another look at iFixit's images of this flex cable: 



    Looks like there's just one IC and a decoupling capacitor.

    Here's what we know about this IC:

    • It's the ambient light sensor.
    • It's a 6-pin DFN footprint, but the size is hard to determine.
      • The top of the chip is clear, exposing the die. (Makes sense for a light sensor.)
      • We can see the 6 bonding wire pads.
    • It uses I2C.
    • It supports a power supply voltage of 3.0V

    (I guess the compass may have been removed before the iPad shipped?)

    Looking at the three options from

    The APDS-9960 does RGB and gesture detection, and doesn't look right:

    The APDS-9960 has a black plastic shroud, which our IC doesn't have. Also it has too many features to be an ambient light sensor.

    The VEML-6070 is a UV sensor, which doesn't make sense, and also it doesn't look right:

    The TSL2561 looks promising:

    The TSL2561 seems to be the right shape, not obviously the wrong color, and is the right kind of IC (Luminosity/Lux/Light sensor)

    To check if this is correct, I got the Adafruit python driver for this chip:

    meatmanek@pi4:~ $ python3 -m venv venv
    meatmanek@pi4:~ $ . venv/bin/activate
    (venv) meatmanek@pi4:~ $  pip3 install adafruit-circuitpython-tsl2561
    Successfully installed Adafruit-Blinka-8.34.0 Adafruit-Circuitpython-ConnectionManager-1.0.1 Adafruit-PlatformDetect-3.62.0 Adafruit-PureIO-1.1.11 RPi.GPIO-0.7.1 adafruit-circuitpython-busdevice-5.2.6 adafruit-circuitpython-requests-3.0.1 adafruit-circuitpython-tsl2561-3.3.18 adafruit-circuitpython-typing-1.10.2 pyftdi-0.55.0 pyserial-3.5 pyusb-1.2.1 rpi-ws281x-5.0...
    Read more »

  • Audio codec: ground-centered mode, BCLK, headset detection

    Evan01/21/2024 at 08:23 6 comments

    I haven't worked on the audio codec part of my board in a while (I don't think I ever tested it on rev1), but it's the last major section of my rev2 PCB that needs testing. A codec is a coder/decoder -- something that encodes and decodes a digital signal --- in this case, to/from analog, so it's an ADC and DAC. In PC terminology, this would be the sound card.

    The desired feature set is:

    • Stereo headphone output
    • Stereo speaker output
    • Stereo line output (through the 30-pin connector)
    • Headset microphone input (i.e. TRRS headphones that you'd use with a phone)
    • The iPad's built-in microphone
    • Headset detection (able to determine whether a pair of headphones is inserted into the jack, and ideally whether it includes a microphone or not)

    My original design used a TLV320AIC3104 codec from TI. This has a built-in headphone amplifier, headset detection, and enough other inputs+outputs to generally fit my needs. However, this codec has one problem that made it a poor choice: it doesn't have "ground-centered" outputs.

    Ground-centered outputs?

    Generally speaking, most ICs can't produce voltages lower than their negative supply voltage (which is usually GND) and their positive supply voltage. A lot of audio codecs will avoid negative voltages by centering their output voltage at some voltage between the power supply and ground. However, most headphones don't really like having a DC offset in the audio signal being pumped into them. Any DC offset will simply result in a steady flow of power through your headphones' speaker coils, which gets wasted as heat. It also means you get a loud pop sound from your headphones whenever your codec turns on its outputs or when you plug in your headphones.

    There are a few options to deal with this:

    The easiest is to just insert DC-blocking capacitors between the output of your codec and the jack. This forms (along with whatever device you plug into the jack) an RC or RLC circuit. This creates a trade-off between capacitor size and your bass response. For typical 32-ohm headphones, in order to have the cutoff frequency be above 50Hz, you'd need approximately 100 μF of capacitance per channel. If you want to get down to 20Hz, you'd need 250 μF. That much capacitance is going to take up a nontrivial amount of space (and height) on the board. The frequency response will change depending on the impedance of whatever you plug into it, making it hard to compensate for. 

    The next option is called "pseudo-differential" output. In this mode, you make the ground pin of your audio connector (the sleeve in your TRS connector) not actually match your circuit board's ground, but drive it with some voltage above ground. In the simplest form, this could just be some constant DC offset, and each channel can be driven above or below that offset. If you want to increase the maximum peak-to-peak voltage range, you can pull your ground pin low when your audio signal goes high, or pull your ground pin high when your audio signal goes low, same as how an H-bridge works. (This gets a little more complicated with stereo signals.)

    Pseudo-differential outputs should give you a nice flat frequency response, but sometimes they're infeasible. If you connect your audio ground (which your codec is trying to drive to, say, VCC/2) to your system ground (0V), you now have a short circuit. This isn't usually a problem with headphones, but if you were to e.g. plug your device into the aux jack of your car (which might connect the audio ground to the car's ground) while also charging your device from the car's USB port (which might connect the USB port ground to the car's ground), you'd end up with a short circuit.

    The nicest option is to have your signals be ground-centered -- that is, they have an average voltage of 0, and the signal goes both positive and negative. This is more complicated because you need some way to generate a negative voltage supply,...

    Read more »

  • It's a tablet! (Rev2 PCB testing)

    Evan12/30/2023 at 05:04 1 comment

    It works!

    I ordered the second revision of my PCB a few months back, and have been slowly working my way through testing and debugging the functionality. So far, the PCB hasn't required any modifications -- all the issues I've encountered have been soldering or software issues.

    A brief list of things I tested / debugged:

    • PCIe port (for the NVMe drive) worked without issue.
    • 5V boost converter mysteriously stopped working -- the 787k resistor turned into a 150k resistor?? Maybe I just placed the wrong resistor there in the first place, but I swear this was working before. (I use a 787k and 150k resistor as a feedback network for the MP3422GG boost converter.) Replacing the resistor fixed the issue.
    • Battery charger wasn't charging, until I discovered some passives were missing. Replacing them fixed the issue.
    • LCD backlight controller wasn't working, until I noticed that the inductor had a bad solder joint. Touching that up with a soldering iron fixed the issue.
    • The image on the LCD was corrupted -- at first, it was showing 3-ish copies of the screen vertically, like it was skipping all but every 3rd line. After messing with timings and frequencies for a while, I noticed that pressure on the board would change the severity of the problem (see youtube video below). At some point, the problem got significantly better, where the screen would be relatively stable vertically, but individual lines would be corrupted at some point. (Unfortunately, forgot to get a photo of this.) I noticed that it would improve when I cranked up the LVDS differential output voltage on the sn65dsi83 (CHA_LVDS_VOD_SWING in the datasheet). This indicated to me that there was an analog problem on the board. Hitting the sn65 and the LVDS connector with some flux and hot air solved the issue.
    • A while later, I noticed that my battery voltage was really low, and that it wasn't pulling any current from the USB power supply. After looking for any error codes or anything weird in the i2c registers of the battery charger IC, I bodged an LED and resistor onto the STAT pin of my charger IC, and that glowed solid. If there were a fault code, it would've blinked at 1Hz. Once again, flux and hot air solved the issue.
    • I tested the touchscreen - clean (none of the noise that plagued my earlier board revision; dunno why this is any better, as the only change I made to this part of the hardware was rounding the tracks to look pretty), but had a dead zone on the middle few Y lines. More flux and hot air fixed that.

    I'm beginning to think that my bismuth-based low temperature solder is a bad idea, especially since the 0.8mm PCB is so flexible.

    Anyway, with all those issues worked through, I decided to assemble the whole thing into tablet form (removing the battery wires I had soldered into place for testing purposes) and take a little victory lap.

    Next steps

    There's still a few more bits of hardware to test:

    • The soundcard (this is probably the next thing on the agenda)
    • SDIO communication with the battery
    • At some point I really need to see if I can talk to the ambient light sensor + compass; I've been wiring up that connector on every board rev and never done anything with it.
      • I think/hope the compass has an accelerometer as well, which would let me automatically change the screen orientation as I rotate the tablet. 

    There's also a bunch of stuff I'd like to do with the dock connector:

    • See if I can support USB peripherals through the "Camera connector" dongle
    • Support the iPad Keyboard Dock
    • Test component video output
    • I'd really like to get the iPad's own Wifi/BT radio working (this is actually mounted on the PCB that connects the logic board to the dock connector.)

    Also, Raspberry Pi OS's GUI is barely functional on a tablet:

    • You can pull up an on-screen keyboard through the menu, but it only supports letters, space, enter, and backspace? No numbers, symbols, modifier keys (it can type uppercase letters though), autocorrect, etc.
    • The on-screen keyboard...
    Read more »

  • NVMe, HDQ, SDIO, and curvy PCB traces

    Evan10/04/2023 at 07:15 4 comments

    I apologize for the long delay since the last update. I'm still here, making spurts of progress here and there.

    Since the last log, I've worked on a number of things:

    1. Figuring out why NVMe / PCIe wasn't working
    2. Successfully getting the Pi to talk to the battery pack through TI's HDQ protocol.
    3. Unsuccessfully attempting to get the Pi to talk to the iPad's Wifi chip through SDIO.
    4. Redesigning the PCB to fix some earlier issues.


    On my previous revision of the PCB, I had added a M.2 slot to allow for a 2230-sized NVMe SSD -- these are getting pretty cheap these days (around $15 for 128GB), and should be faster and more durable than eMMC.

    When I tested this slot by putting an SSD in it, I couldn't see anything with lspci, etc. I tried observing with my oscilloscope and didn't see anything happening, but PCIe is a little beyond the bandwidth of my scope.

    Fortunately, around this time, Arya Voronova was publishing her PCIe for Hackers series on Hackaday, and a line in this article caught my attention:

    As you might expect, RX on one end connects to TX on another end, and vice-versa – it’s just like UART, but spicy.

    Had I gotten TX and RX wrong? Sure enough, I had. The schematic symbol I used for the M.2 slot was labeled from the perspective of the card, not the host, so I had wired the host's TX line to the card's TX line. Don't trust random symbols — check the datasheet!

    I designed a little interposer board that fits in the M.2 slot, swaps TX and RX, and has another M.2 slot on top where you can put the SSD. This (and some reflow of a few bad solder joints, a perennial problem with this project) fixed the issue and got NVMe working perfectly.

    The interposer board is too big to fit inside the iPad case, but it let me verify the fix before ordering and assembling a whole new board revision.

    SWI? HDQ? 1-Wire?

    The iPad's battery connector has a pin named BATT_SWI_CONN_R, which is used for serial communication between the processor and the battery. From what I discovered in online research, Apple devices from this era all used TI battery controller chips which speak the HDQ protocol, a proprietary single-wire interface that only seems to show up on these TI battery controllers. For reasons, Apple decided to rename this "SWI" (presumably, "single-wire interface") rather than just calling it HDQ.

    I wanted to make sure I could get the Pi talking to the battery with just a trace wired between a GPIO pin and the battery's SWI pad. If I needed extra hardware to make this communication work, it would be nice to know before ordering a board revision.

    First things first, I wanted to double check that the battery actually spoke HDQ, so I flashed this Arduino sketch from mozzwald onto an Arduino Uno and hooked it up. This worked perfectly:

    iPhone 4G Battery Detected
    Device: bq27541
    Firmware: v1.25
    Hardware: 0xB5
    Remaining Capacity: 1166 mAH
    Full Charge Capacity: 6264 mAH
    Design Capacity: 6500 mAH
    Time to empty: N/A, not discharging
    Time to full: N/A, not charging
    State of Charge: 19%
    Battery Voltage: 3.73V (3730mV)
    Temperature: 24.00�C / 75.38�F / 2971 raw
    Charge Cycle Count: 146 times

    (Looks like the battery thinks it's full-charge capacity is 96% what it was when it was new. Pretty good for a 13-year-old battery!)

    Moving back to Pi land, I hooked up some jumper wires between a Pi 4 and the battery's ground / SWI contacts, and set about trying to get the Pi to speak HDQ.

    In the Linux kernel, there's a driver called bq27xxx_battery_hdq, which sounds perfect -- I want to talk to a BQ27541 over HDQ. However, it turns out that this uses the Linux kernel's 1wire subsystem. HDQ and 1wire aren't actually compatible -- they're close enough at the physical layer that TI made their OMAP processors capable of speaking either, and the Linux driver for this hardware can set it into HDQ mode. This isn't helpful for me, though, since the Pi doesn't use an OMAP processor.

    However, there's...

    Read more »

  • Debugging the power button

    Evan01/23/2023 at 00:27 1 comment

    Hey, I'm back with a simple one today. Between the holidays and general life stuff, I haven't found time to work on this project for a while. Motivation on hobby projects seems to ebb and flow. Hopefully it's starting to flow again.

    I saw a post on the Facebook group "Raspberry Pi and DIY Projects" where someone was using the MAX16150 IC to handle power on/off for their Pi, and it inspired me to try and get my MAX16150-based circuit working.

    One of the typical application circuits from page 16 of the MAX16150 datasheet, showing it controlling the enable pin on a power supply for a power-hungry device.

    The MAX16150 monitors a push button on its PB_IN pin. A short press of the button will either turn on the OUT pin, or if it's already on, send a brief low pulse on the INT pin. The MCU (the CM4 in my case) can detect this pulse and handle it gracefully, by e.g. starting a soft shutdown.

    If you press the power button for 8 seconds, the MAX16150 will deassert the OUT pin (pull it low), cutting power to the downstream device. This is consistent with the power button behavior of most computers, tablets, and phones.

    If the CLR pin goes low, the MAX16150 will deassert the OUT pin. This is used to give the MCU a way to shut off its own power, and also provides some power watchdog functionality -- if the power goes low for some reason, like a short circuit or a dead battery, the MAX16150 will shut off the power.

    I more or less followed the typical application circuit above in my own design:

    On my current revision of the PCB, the PWR_BUTTON_INT net connects to GPIO22 on the CM4, while PWR_CLR connects to the nEXTRST pin on the CM4.

    nEXTRST is meant to indicate that power is good on the CM4, so it can be used for driving the RST pin on EXTernal devices that need to be powered when the Pi is powered. I assumed this would mean it would go low when the Linux kernel halts.

    However, this approach has two problems:

    1. Turns out that nEXTRST is not pulled low when the kernel halts.
    2. nEXTRST stays low for around 200ms after 5V power is applied to the CM4.

    The second problem is more severe. After asserting the OUT pin, the MAX16150 will ignore the CLR pin for 2x its interrupt period (32ms on my version. Different versions exist, but they're less "add to your Digikey cart" and more "call the factory to custom order".) When that 64ms has elapsed, if CLR is still low, the MAX16150 deasserts OUT again, which cuts power to the downstream device.

    It turns out that this isn't an artificial delay on the nEXTRST pin - it actually just takes about 200ms for the CM4's 3.3V supply to start when 5V is applied.

    I had originally worked around this by cutting the CLR<->nEXTRST trace on the PCB and then connecting CLR to 5V with a resistor. I then connected an extra push button between CLR and ground, to give me a way to cut power. However, this meant the Pi had no way to turn off its own power, and I had to manually click that second button any time I did a shutdown, or it would sit there, halted, drawing a nontrivial amount of power.

    I've improved on this bodge in a way that I think is suitable to incorporate into my next PCB revision:

    • I cut the PCB trace near the CM4 connector to disconnect it from the CM4's nEXTRST pin.
    • I bridged it to a GPIO trace that I'm not currently using.
    • I changed the 5V<->INT resistor for a 10k, and added a 20k resistor to ground.

    This causes the INT pin to come up as soon as the 5V supply is good, but also keeps the voltage at a safe enough level for the GPIO pin, which is only 3.3V-tolerant.

    At bootup, the GPIO pin seems to have a weak pull-down resistor, so the INT pin ends up with around 3.0V on it instead of 3.3V, but this is high enough for the MAX16150 to treat it as high.

    With the following configuration in /boot/config.txt, I now have startup and shutdown behavior that works exactly as I intended.

    Read more »

  • Attempting to tune the touchscreen controller

    Evan10/21/2022 at 11:15 1 comment

    For reasons documented in a previous log entry, I am using the GT9110 touchscreen controller from Goodix. (Essentially, this is the only suitable touchscreen controller I could find in a footprint that I could actually use without spending hundreds of dollars per PCB revision.) In a later log entry, I got the GT9110 and Linux talking to each other.

    Goodix is quite a frustrating company to buy from as a hobbyist. In comparison to some chip manufacturers like TI, who publish loads of documentation about their chips on the internet, Goodix is very stingy with their documentation. As far as I can tell, there's no way for hobbyists to get the documentation except hoping to find a leaked datasheet posted online somewhere. When you do find a datasheet, it's not particularly helpful. Some guidance on how to tune your touch panel (rather than just a table of registers with ~5 words about each) would be nice.

    Goodix being extremely unhelpful to someone trying to design a board with their touchscreen controllers.

    Maybe I'll try reaching out to whatever AliExpress vendor I bought these chips from. I doubt they'll have the documentation, though.

    Trying to tune the touchscreen controller

    So I had the touchscreen detecting my touches, but it also detects phantom touches; mostly along a vertical line a quarter of the way in from the right side of the screen. 

    To recap how capacitive touchscreens work: The screens contain two layers of transparent traces, typically made of ITO, a transparent conductor. On one layer, you have traces going across the screen horizontally; in the other layer, traces go across the screen vertically. (This website has a pretty good graphic explaining this.) The touchscreen controller will send a signal to each "drive" trace (in my case, horizontal) and measure how much of this signal capacitively couples to each "receive" trace (vertical). When you bring your finger near the screen, some of the signal from the drive line will couple to your finger instead of the receive lines, which makes a measurable difference in coupling.

    I have a few hypotheses as to what might be happening:

    • That channel might have a bad connection on the board
    • The chip itself might have a fault on that channel
    • That channel might be receiving EMI from some nearby components, either on the PCB itself or in the touchscreen/LCD panel. Potentially this could be crosstalk between the transmit and this receive trace.)

    I got a hold of a programming guide for the GT911 (the little sibling to the GT9110 -- same family, but fewer channels. I bet it's the exact same silicon die inside.) This gives me information on the i2c register maps.

    (Aside: Apparently these chips support a mode called "HotKnot" in which two touchscreens can transfer data to each other!?!? What a bonkers feature.)

    These are the registers which seem relevant to tuning sensitivity:

    Address Name Notes
    0x8053 Screen_Touch_Level This seems to be the signal level threshold above which a touch begins to be reported. Higher numbers = less sensitive.
    0x8054 Screen_Leave_Level This seems to be the signal level threshold below which a touch stops being reported. Higher numbers = less sensitive.
    0x806b Pannel_Tx_Gain The lowest 3 bits set the DAC gain, where 0 produces the largest signal and 7 producest the smallest signal.
    0x806b Pannel_Rx_Gain The lowest 3 bits set the ADC gain. It seems like 7 is the most sensitive and 0 is the least sensitive.
    0x806d Pannel_Dump_Shift Setting the lowest 3 bits to N > 0 will cause the touch signals to be shifted by N bits left. This would be useful if I wanted even more receive gain than Pannel_Rx_Gain can give, but I want less.

    I'd like to be able to overwhelm any noise by cranking the Tx power up and decreasing the RX sensitivity. Unfortunately, the configuration I had started with was already using 0 for the ADC and DAC gain, so it was...

    Read more »

  • Trying my hand at driver development

    Evan10/18/2022 at 07:19 1 comment

    One issue which contributes to the backlight flicker is the undervoltage protection (UVLO) feature of the TPS61177A. This is configurable over i2c, but defaults to 3.5V, which is pretty high.

    In order to set this at startup, I decided to try and write a kernel driver for the TPS61177A. I partly followed and partly cargo-culted some stuff (mostly related to regmap) from the sn65dsi83 driver. (I've poked around in that driver in previous debugging sessions, which helps me understand its structure more than some other random i2c device driver.)

    The driver essentially just sets the 0xa2 register to the value 0x02, which corresponds to a UVLO voltage of 3.0V. (Ideally, they'd have options between 3.0 and 2.55, but alas...)

    After a few hours of struggle, I got this to configure the UVLO voltage over i2c, but I've run into a hardware-level problem with this approach: in order to save GPIO pins, I used the same GPIO for both the sn65dsi83's enable pin and the tps61177a:

    Screenshot of part of my schematic, showing that the enable pins for the LVDS bridge (sn65dsi83) and backlight driver (tps61177a) are shorted together.

    This means that the drivers for both chips are competing for control over the GPIO pin; this seems to cause the second driver to fail to load. (In this case, the sn65.)

    There's an easy workaround, for now: I can manually tell the tps61177a to save its configuration to EEPROM. Long-term, I'd like to reduce the number of manual steps that someone would have to take in order to get this board working, and that means either a driver like the one I've written, or some userspace solution like a startup script.

  • Backlight flickering investigation + device tree overlay for the battery charger.

    Evan10/16/2022 at 07:37 0 comments

    I've been investigating the backlight flickering that I showed in my previous log entry. My main hypothesis was that the long wires between my breakout board and my main PCB were adding too much inductance, causing increased ripple. I had moved an input decoupling capacitor to the breakout board, which helped some but didn't entirely solve the problem. Adding more capacitance on the input side didn't help much more.

    One thing I noticed is that the problem drops entirely when the tablet is connected to the charger. This made me suspect that maybe my battery is the problem.

    Looks like there isn't much difference between the VBAT measured at the battery terminals and VBAT measured on the breakout board (at least at speeds the Saleae can measure; it's possible that the breakout board sees switching transients.)

    But yikes, the battery is dipping ~400mV under load? That seems like a lot. Assuming that's happening while the board is drawing 2 to 4 amps, that's 100 to 200 milliohms of internal resistance on the battery. I dunno what the internal resistance of a LiPo battery is supposed to be, but this feels high. Perhaps my test battery is aged - internal resistance goes up with use + abuse. (I'm using a separate battery for testing; just a random 2000mAh cell I had lying around, because the iPad battery is glued to the back of the case and doesn't have wire leads, just spring terminals.)

    On the topic of battery health...

    I've heard one way to keep lithium ion/polymer batteries healthy is to limit the maximum charge voltage to something lower than 4.2V, like 4.0-4.1V. The battery charge IC I'm using (TI's bq25895) supports this functionality, so I've added a device tree overlay which sets this parameter. This also lets us read the battery voltage and charging current (but not discharge current?) easily in Linux:

    meatmanek@cm4:/sys/class/power_supply/bq25890-charger$ cat status 
    meatmanek@cm4:/sys/class/power_supply/bq25890-charger$ cat voltage_now 
    meatmanek@cm4:/sys/class/power_supply/bq25890-charger$ cat current_now 
    meatmanek@cm4:/sys/class/power_supply/bq25890-charger$ cat constant_charge_voltage_max 

    Hopefully this helps keep the 12-year-old iPad battery in good working condition.

  • Starting to look like a tablet

    Evan10/15/2022 at 07:10 0 comments

    I soldered my backlight controller IC onto a QFN breakout board and bodged some connections over to my PCB, so that I could view my LCD without having to provide an external backlight.

    The mess of wires here is mostly bodge connections from that QFN breakout to traces on the PCB -- battery power, i2c, PWM and enable pins, and the anode + cathode pins for the LCD backlight.

    This works, but has some issues: the backlight flickers a lot when the Pi is under load (or using wifi or something?) I think the backlight controller is hitting its under-voltage lockout. At first, I had left the large decoupling cap on the main PCB, but in this configuration the backlight would strobe for about a second on boot, then would shut off. Moving the capacitor to the breakout board helped, but the flicker remains. I may add more capacitance.

    I also think one of the LED strings isn't connected correctly, causing the "stagelight" appearance at the top of the screen.

    (The backlight in the iPad, like many other LCDs, is 6 strings of LEDs:

    Example schematic from the datasheet for the TPS61177A, the backlight controller I'm using.

    This keeps the voltage at something reasonable -- about 20V in the iPad -- and also means that a single LED failure doesn't cause the whole backlight to go out.)

    The video

    The touchscreen doesn't work quite right - it's detecting phantom touches. I've decreased the sensitivity, which helps slightly, but also makes it miss some real touches. This makes it pretty frustrating to use. (In the video, you can see me struggle to shut down the Pi using the shutdown menu while the touchscreen keeps trying to read MagPi.) The GT9110 chip I'm using has terrible publicly-available documentation, so tuning its configuration will be lots of trial and error.

    Even with all these problems, it's really beginning to feel like a tablet.

  • The LCD works!

    Evan10/07/2022 at 07:41 4 comments

    After finding and fixing a few silly mistakes, I finally got the LCD working:

    The iPad's LCD displaying glxgears, backlit by a makeshift backlight — the circuitry for driving the built-in backlight had a mistake that I haven't fixed yet, documented in this project log.

    The issues I discovered that I had to fix were:

    1. The registers for HFP, HBP, and Hsync pulse width are 8 bits on the sn65dsi83, but I was trying to set several of these to values above 255. This was causing them to wrap around, meaning my horizontal line frequency was different than I wanted. I had to adjust these values to be <=255.
    2. I recalled that someone had told me that 4 lanes of DSI doesn't seem to work with the sn65 (at least with the current version of the Linux driver). I had most recently been testing with 4 lanes, so I was getting no LVDS output. Switching to 3 lanes (and adjusting the desired LVDS clock speed downwards so that the DSI clock would be under 500MHz) got the sn65 producing LVDS signals that seemed to work.
    3. The LVDS connector on the other side of my board had come off. At some point I had tried swapping out the sn65 IC for a fresh one, thinking I might have burned out the LVDS outputs by shorting them to the inconveniently adjacent 1.8V supply pins. During this rework process, the solder on the LVDS connector must have gotten hot enough to melt (it is essentially right behind the sn65).

    I'm fortunate that the LCD doesn't seem to mind if I use a different timing configuration than is specified in its datasheet.

    Next steps:

    • Merge all my various git branches into one branch (the LCD, the touchscreen controller, the RTC, and the sound card)
    • Get PCBs made of the bodge board that I've designed which should let me connect the TPS61177A chip onto my board the right way around.
    • Try closing up the case.

    Once I do those things, this should be a functional tablet! Mostly. There's still the whole software thing to deal with. And I need to figure out how to either use the iPad's original wifi/BT chip or connect the CM4's antenna port to one of the iPad's own antennas. Also I'd like to test the NVMe slot. Oh, and I haven't tested the audio codec+speaker amplifier on this revision of the board, I think.

    But still! Tangible progress!

View all 28 project logs

Enjoy this project?



Hassla wrote 06/29/2022 at 13:47 point

Really nice your frequent updates currently.

  Are you sure? yes | no

Tom Cubie wrote 06/28/2022 at 02:43 point

This is Tom from Radxa, this project is very interesting and we can help to troubleshooting hardware issues and get everything working. You can join our discord

"Since the Radxa CM3 / RK3566 clearly has less software support than the Pi (I think as of the time of writing, you can't even get HDMI output, let alone LVDS"

I think this is the mainline kernel status, for the Rockchip 4.19 vendor kernel, we have everything working already.

  Are you sure? yes | no

Michael Shaub wrote 06/28/2022 at 00:27 point

this is awesome! Are you planning to make parts available on Tindie? I’ve been wondering why I kept my original iPad. Now I know!

  Are you sure? yes | no

Evan wrote 06/29/2022 at 18:42 point

Maybe! A lot of the parts are getting hard to find, and I dunno if I want to provide customer support 😆

  Are you sure? yes | no

jimmyplaysdrums wrote 06/27/2022 at 23:39 point

Very cool. Looking forward to seeing more!

  Are you sure? yes | no

Hassla wrote 06/20/2022 at 22:59 point

Awesome work, keep up the good work!

Hopefully you can revive your CM4.

  Are you sure? yes | no

Evan wrote 06/21/2022 at 19:21 point

Thanks for the words of encouragement! My replacement CM4 came in, and I'm working on getting it booting. Hopefully will have another project log soon. I bought the replacement PMIC chip from AliExpress, so it'll take a month or two to arrive.

  Are you sure? yes | no

Hassla wrote 01/26/2022 at 11:40 point


An absolute beauty of a board, hopefully all works as intended.

  Are you sure? yes | no

iamcanarin wrote 11/16/2021 at 15:15 point

This looks like a good solution for UPS :

  Are you sure? yes | no

iamcanarin wrote 11/08/2021 at 11:09 point

Hi, just want to say how awesome work you did so far. I also had an idea to fit Raspberry Pi into the old iPad. I was wondering since speakers are "dumb",  wouldn't it be enough to let us say use something like  PCM5101A from parts which are already tested to run iPad speakers, or am I missing something?

  Are you sure? yes | no

Evan wrote 11/10/2021 at 19:28 point

Yeah, that looks like it should work. Seems like that's using the PCM5101A codec + the [APA206](, which looks like a speaker amplifier. If I have trouble solving my [audio quality problem]( on the tlv320aic3206, I'll look around at different codecs. The PCM5102A seems to be the same part as the PCM5101A but with better audio quality specs.

One reason I went with the tlv320aic3206 is that it can drive 16 ohm headphones directly, whereas the PCM510x specifies a minimum load of 1kOhm on its LOL/LOR, so it may require an additional headphone driver circuit.

  Are you sure? yes | no

Hassla wrote 11/16/2021 at 18:52 point

The TLV320AIC3206 is really interesting, I wanted to use the PCM5100, TPA6133A2 and PCM1863, to subsides the CS4206 or the succesor CS4207, but these are not I2S. So the TLV320AIC3206 could probably used for my application with 2 or 3 Speaker and a Headphone out and input.

  Are you sure? yes | no

Hassla wrote 09/24/2021 at 15:50 point

Did you proceeed with working on this project? Or did you set it aside.

I have currently set it aside in favor of other projects, because the main chips, like the CM4 itself or the SN65DSI85, are simply not available. And of course during the design I fell down the rabbit hole with USBC and the thousand possibillity with DP/HDMI over USBC etc..


  Are you sure? yes | no

Evan wrote 09/24/2021 at 18:49 point

Yep, I'm still working on it. I picked up a few sn65dsi83's while they were still in stock, and have been trying to get it working since. Hopefully I don't destroy any of them.

I'm going to have at least one more board revision (to switch from my 40-pin prototyping layout to the CM4 connectors, and to fix some issues I've found), but so far the only new parts I'm going to need are passives, connectors, and a SMPS chip which seems to still be in stock.

You might try picking up a later iPad screen - I think they switched to eDP when they went to the retina screens, and it looks like the SN65DSI86IPAPRQ1 (MIPI to eDP) is still in stock at TI / Mouser / Arrow. I briefly looked into this because I was curious if I could upgrade this to a retina display. I think the later screens are a bit shorter in one dimension and a bit longer in another, but it might be possible to modify the mounting hardware to make it fit.

EDIT: oh right, you said you're hacking a Macbook. Maybe you want to use the RTD2660H if you can't find any other MIPI-LVDS bridge ICs?

  Are you sure? yes | no

Hassla wrote 09/26/2021 at 18:02 point

That's nice to hear!

Yeah the RTD2660H was my first Idea, like Joel Hill , used in his attempt to use a macbook and a RPi together.

Die SN65DSI85 was my first Idea, since it was already paired with the RPi from some guys in the RPi Forum. But I am going to look out for another MIPI to Dual LVDS.

But since i cant even get a CM4, I suppose i just wait for the World of Chips become normal again.

  Are you sure? yes | no

Evan wrote 12/01/2021 at 19:35 point

If you're not glued to the CM4, you might look at the recently released SOQuartz from Pine64[1] and the Radxa Rock3 CM3[2]. Both are based around the RK3566, are pin-compatible with the CM4, and can supposedly output LVDS signaling on the MIPI-DSI pins. The Radxa board has an extra 100-pin connector which breaks out some more IO. It's got USB3, HDMI, and eDP, so it might be perfect for messing around with USB C alternate modes.

The SOQuartz seems to be available on the Pine store, but I can't find the Radxa CM3 anywhere in stock. I'm going to pick up an SOQuartz and see how it goes.


  Are you sure? yes | no

Hassla wrote 12/02/2021 at 20:59 point

Yeah both of the alternative CMs are interesting, especially with LVDS and USB3 & SATA straight out of the box. Since the prject dont have any timelimit, I probably stick with the RPi. But I am still looking in the other two. oThanks for that.

  Are you sure? yes | no

Evan wrote 12/13/2021 at 06:49 point

I think the SOQuartz only breaks out 2 lanes of the combo LVDS/MIPI-DSI transmitter to the cm4 pins: page 15, top left. They break out all 4 lanes of the other MIPI-DSI transmitter, but that doesn't support LVDS according to the rk3566 datasheet.

I assume Pine64 did this to be as similar as possible to the CM4, which only has 2 lanes on DSI0, and 4 lanes on DSI1.

  Are you sure? yes | no

Evan wrote 12/13/2021 at 08:24 point

The Radxa CM3 has the remaining two lanes of LVDS broken out to the third board to board connector, and the wifi/2GB/16GB model is in stock at

I guess that may still not be enough for your display if you need dual LVDS.

  Are you sure? yes | no

Hassla wrote 08/22/2021 at 16:45 point

Just a comment to appreciate your project. I like it very much, since I am in the progress of trying to hack a Macbook A1286 i really enjoy your work. Keep it up!

  Are you sure? yes | no

Evan wrote 08/23/2021 at 06:24 point

Thanks! I bet there's a lot of similarity internally -- I think the iFixit teardowns of the iPad mentioned they used some similar parts in the iPad as on the contemporary Macbooks.

If you start writing up your project somewhere, let me know!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates