Open up a 2010 iPad, remove its logic board, and fabricate a new board based around the Raspberry Pi CM4.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
Since the last time I had a board made, I've discovered several revisions that I needed to make:
- The 5V boost of the bq25895 cuts out long enough to shut off the Pi when you connect USB power.
- I needed extra lanes of DSI going from the CM4 to the SN65DSI83 chip in order for all the clock rates to fall within the ranges allowed by the SN65 and the iPad's display.
- The footprints for my touchscreen FFCs were backwards
I took this opportunity to design a version of the board where I actually used the CM4 instead of having separate 40-pin connector / FFC for DSI / USB port on the board. I threw an M.2 slot on there for NVMe support, as well.
When I was nearly finished with that design, I learned about the Radxa CM3, which is the same form factor as the Raspberry Pi CM4 but has a third board-to-board connector providing several features that would be quite convenient for this application:
In addition, the Rockchip RK3566 that the Radxa CM3 is built around actually seems to have the ability to sleep, which is especially important on a tablet. On the CM4, I'll have to suspend to disk or just shut down or something.
I think if I the Radxa CM3 had existed when I started this project, I might've chosen it over the Pi CM4, as it should require a lot less glue circuitry to make it work in this application. (I had originally considered the Pine64 SOPine and the Nvidia Jetson Nano, but I think I excluded these because the SO-DIMM connectors that they require wouldn't fit between the case and the screen.) As a bonus, the RK3566 is less tall than the BCM2711, which may buy me a little vertical room, depending on the other components on the CM3.
I've also designed a version of my board based around the Radxa CM3. Once I figured out the position and orientation of the third connector on the CM3, this wasn't too bad -- it has far fewer components than the CM4 version of the board. It's essentially just connectors, the touchscreen controller, a buck-boost converter for the NVMe slot, and some audio switches.
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'm planning to hedge my bets and have both boards made.
Thanks to the help of some folks on the Raspberry Pi forums, I've got the sn65dsi83 driver loading, and the Pi generating enough DSI signal for the SN65DSI83 to be able to generate a test pattern (it uses the DSI clock to generate the LVDS clock)
Hopefully I can get those black lines to go away.
For the past few days, I've been trying to get the sn65ds83 driver (recently added to linux) running and talking to my board. It has been a (re-)learning experience trying to get this device tree overlay to cooperate.
Following my own advice from the last time I touched device trees, I used udevadm monitor and dmesg -w to watch for kernel/udev messages while loading my overlay with sudo dtoverlay pipad_screen. This gave me this helpful error message:
[ 178.309859] sn65dsi83: probe of 1-002d failed with error -2
From what I can tell from looking at the kernel source, this implies that the sn65dsi83_probe function was returning -2. Unfortunately, the sn65dsi83_probe function can return errors from several different places. Fortunately, there's a kernel feature called ftrace that can trace every function call that happens within the kernel. The easiest way to use it is to use the trace-cmd command, which you can install on Raspberry Pi OS with apt install trace-cmd. You record with trace-cmd record -p function_graph (with various options for filtering), then view the results with trace-cmd report.
Supposedly, you can trace everything by just running trace-cmd record -p function_graph with no filter options, but when I tried this, I had a lot of dropped events and didn't see the sn65dsi83_probe function in the results.
After learning some things about ftrace (by manually constructing a list of functions to filter on with the -l flag), I discovered that ftrace can only trace functions in kernel modules that are loaded before ftrace starts. Normally, the ti-sn65dsi83 module is loaded automatically when I run dtoverlay pipad_screen, but that prevents ftrace from seeing it.
If I manually modprobe ti-sn65dsi83 before running trace-cmd record -p function_graph -F dtoverlay pipad_screen, I get no dropped events, and the trace for the sn65dsi83_probe function was there in the output of trace-cmd report:
sn65dsi83_probe() { devm_kmalloc() { __kmalloc_track_caller() { kmalloc_slab(); should_failslab(); } devres_add() { _raw_spin_lock_irqsave() { preempt_count_add(); } _raw_spin_unlock_irqrestore() { preempt_count_sub(); } } } of_device_get_match_data() { of_match_node() { _raw_spin_lock_irqsave() { preempt_count_add(); } __of_match_node.part.0() { __of_device_is_compatible() { __of_find_property(); of_prop_next_string(); } __of_device_is_compatible() { __of_find_property(); of_prop_next_string(); of_prop_next_string(); } } _raw_spin_unlock_irqrestore() { preempt_count_sub(); } } } devm_gpiod_get() { ... } }
This implies that sn65dsi83_probe was returning immediately after the call to devm_gpiod_get finished. Oh, right, I never put the enable GPIO pin for the sn65dsi83 in my dts file. I figured the property would be called enable because that's the string being passed to devm_gpiod_get, but nope. From looking at documentation for other bridges, I inferred that it's enable-gpios.
Adding enable-gpios = <&gpio 5 0>; to my device tree and trying again, this time I get from dmesg -w:
[ 95.093834] sn65dsi83: probe of 1-002d failed with error -22
Looking at my report, this time I see:
sn65dsi83_probe() { devm_kmalloc() { ... } of_device_get_match_data() { ... } devm_gpiod_get() { ... } of_graph_get_endpoint_by_regs() { ... } of_property_count_elems_of_size() { ... } of_graph_get_remote_port_parent() { ... } of_node_put(); }
Looks like it's failing just after of_graph_get_remote_port_parent and of_node_put. These aren't called directly from sn65dsi83_probe, but by sn65dsi83_parse_dt. Because sn65dsi83_parse_dt is defined as a static function, it can't be traced by ftrace, and everything it calls appears directly beneath sn65dsi83_probe.
I think I'm being caught by this code:
ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
ctx->host_node = of_graph_get_remote_port_parent(endpoint);
of_node_put(endpoint);
if (ctx->dsi_lanes...
Read more »
Based on my guess of how complicated testing the different components will be, I decided to test the LCD backlight controller next.
For this part of my PCB, I basically built the example circuit from the datasheet of the TPS61176. This chip is essentially a DC-DC boost converter and 6 constant-current/PWM sinks. You control it by providing a PWM signal on its PWM/EN input. It decodes this signal and then runs its own PWM on each IFB# pin.
Not wanting to risk frying my iPad's display, I wanted to first test with my own string of LEDs. However, I'm a dummy and I neglected to put any test points on this part of my PCB, and because both ends of the trace end up at fine-pitch footprints, I opted to scrape away some solder mask and solder some magnet wire directly to some traces.
I dead-bug soldered a few LEDs together to make my test string, and connected them to the common anode and one of the cathode lines, which works great:
The TPS61176 will increase the anode voltage until your LEDs start actually drawing current, so it basically supports strings of LEDs with arbitrary forward voltage, within its voltage range.
After double-checking that I hadn't flipped the pinout for the display, I decided to connect the actual LCD panel. Powered it up and ....nothing. Black. The anode voltage was 3.6V (so, not boosted at all). My hypothesis is that it's detecting an open circuit on all the LED strings, so it disabled the boost converter. Some basic testing confirms:
The anode voltage jumps (higher than my Saleae Logic 8 can measure), and then falls back down. I wonder how high that voltage is going? Is it higher than the 18V required to drive the backlight on the LTN097XL01-A01 panel in my iPad?
I soldered a few more wires onto my board: one at the MODE/FAULT pin, and one at the OVP pin (which is connected to a voltage divider with 143k / 1M, which divides the anode voltage by 8). Rerunning the test gives me:
1.5V at the OVP pin. There's my problem! Turns out the reference voltage for the OVP pin is 1.5V, and with the 1/8 division, I'm only getting 12V max. I need to adjust the ratio on my voltage divider.
After swapping the 143k resistor for an 82k resistor, the backlight works!
I assembled the front of my board yesterday (dealing with 0402 components is tedious. I really should just pay JLCPCB to solder on most of the passives for me.) Today, I wanted to quickly test the power supply to make sure I hadn't broken anything yesterday.
I attached a battery (I managed to find another LiPo battery buried in a drawer), checked output voltage (5.1V ☑️), wired up the raspberry pi (which booted.) Everything seems to work as well as it did two days ago. However, I tested a few things that I hadn't tested before, and discovered a few unfortunate things:
When I plugged in the USB charge cable, the red LED on the Raspberry Pi shut off. However, the Pi didn't actually shut down - I think the input voltage dropped just enough that the Pi turned off the LED. (The USB charger I'm testing with only puts out about 4.5V.)
However, when I unplugged the USB cable, the Pi did actually shut off. Turns out, it takes about 38ms for the bq25895 to start the boost converter after VBUS drops to 0, so my 5V output drops to about 0.2V below Vbat, so about 3.6V in this case. (probably being fed entirely through the external Schottky diode.)
From this trace of the various voltage rails, we can see that PMID (the 5v output of the bq25895) and 5V @ pi (the pi's 5v rail, connected by wire to PMID - I just wanted to make sure there wasn't too much voltage drop on the wire) drop down to about 3.6V. This is low enough that the Pi shuts down its 3.3V rail.
Because of this issue and the risk of USB voltage being passed directly to the Pi if the bq25895 negotiates a higher voltage, I think I'm going to have to add a separate boost converter like the SuperPower-RPi project does. (I based my bq25895 schematic heavily off of theirs.)
Thanks a ton to Seth K from the SuperPower discord for his input on this.
So I finally finished designing v0.0.1 of my PCB, and had them made by JLCPCB. This prototype has:
Instead of having the two 100-pin connectors for the CM4 like the final board will have, this version of the PCB is designed sort of like a Pi HAT, with a 40-pin header on the bottom. It also receives the video signal through a 15-pin ribbon cable, and has an extra USB micro B connector wired to the battery controller. This design allows for safer testing: I can connect only the pins that are needed to test one feature at a time.
I've assembled only the bottom of the board so far (the battery controller and the DSI-to-LVDS converter), and have been working on testing the battery controller.
My battery controller is adapted from Pi-Charger.sch from the SuperPower-RPi project, which is essentially the example schematic for the bq25895 battery controller from TI. In the SuperPower board, they use a separate boost converter to go from battery voltage up to 5V, but on my board I decided to use the bq25895's built-in boost converter, which can provide 3.1A at 5V if you add an extra diode. This approach has risks, and I will revisit this decision.
First thing I did to test it was give it 3.6V on the battery+ and ground connectors, hoping to see 5 volts output, but no dice. After scanning through the i2c registers, I eventually noticed that it was complaining about the thermistor being missing. After adding a 10k resistor... still no dice. Turns out I needed to pull the OTG pin high. Good thing I broke that out to a test pad!
I futzed around for a while with various approximations of the iPad's battery (3x NiMH AA's in series; some old, fairly degraded 18650s out of a battery pack from a broken bike light). These all had too much internal resistance to supply the ~15 watt spikes required to boot the RPi 4, and would trigger the bq25895's undervoltage shutoff. Eventually, I gained enough confidence in the board to test with the iPad's actual battery. This worked great!
It seems like the iPad battery is in pretty good condition - at least, it's been holding a charge, and still has very low internal resistance. I measured maybe 50mV of voltage droop when booting the Pi 4.
Up next is probably testing the LED backlight driver, then after that I can test the LVDS controller. I may or may not be able to test the touchscreen controller: the FFC connectors are backwards. 🤦♂️
Since my last log, I connected the other ends of the magnet wires to female header pins so that I can attach to my RPi 4. I really, really would recommend against trying to do it this way. I'm either gonna spend the board space and use 0.1" headers next time, or go for something easy to solder like an FFC so I can make a matching breakout board.
In the mean time, I've tested the board a bit, and have been working on making it work under Linux.
For basic testing, I used command line tools for I2C (i2cdetect, i2cset, i2cget from the i2c-tools package. From this, I was able to confirm that the codec powers up successfully, I can speak to it over i2c, and that jack detection works. (This codec can tell the difference between a TRS stereo headset and a TRRS stereo/mic headset, based on the resistance between the different pins.)
I still have no idea whether I can actually make sounds with this thing, though. To get sound, I need to:
I could probably script all that, using python or bash or something, but since in the end I want to make this work as a fully-supported alsa/pulseaudio/whatever output, I started learning how to do this Properly™. The basic approach is to make sure the kernel has a module available for the codec, then write a "device tree overlay" describing the board.
The Linux kernel source already have a driver for the TLV320AIC3104, but they aren't included by default in Raspberry Pi OS. After cloning, configuring to enable the tlv320aic3x driver, and rebuilding the kernel, I have the snd_soc_tlv320aic3x module available.
Next, I need a device tree overlay for my board. This will tell the kernel what hardware I've attached to the computer, and if all goes well, the kernel should load and instantiate the appropriate drivers.
The Raspberry Pi website has a decent page about device trees, overlays, and parameters. The kernel documentation also has some useful pages about it: Linux and the Device Tree. It's also helpful to I cargo-culted my first version of my overlay, compiled it, put it in /boot/overlays, added it to config.txt, and rebooted, and... how do I know if it worked? After playing around and searching for things, I was able to find a couple useful debugging tips:
sudo vcdbg log msg
# in one terminal: dmesg -w # in a second terminal: sudo udevadm monitor # in a third terminal: sudo dtoverlay pipad
You'll find devicetree-related messages in dmesg often have the prefix "OF:", which I think refers to OpenFirmware, where the device tree concept was originally created.
Unfortunately, this doesn't shorten the iteration cycle -- every time your overlay fails to properly apply, you need to reboot to get back to a clean state. (It looks like you should be able to remove an overlay with dtoverlay -r, but this doesn't work if your overlay doesn't apply cleanly.)
After iterations, I've settled on this .dts file:
/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835";
fragment@0 {
target = <&gpio>;
__overlay__ {
aic3104_reset: aic3104_reset {
brcm,pins = <17 27>;
brcm,function = <1 1>;
brcm,pull = <1 1>;
};
};
};
fragment@1 {
target-path = "/";
__overlay__ {
vcc30: fixedregulator@1 {
compatible = "regulator-fixed";
regulator-name = "fixed-supply";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
gpio = <&gpio 22 1>;
startup-delay-us = <70000>;
...
Read more »
My most recent JLCPCB order arrived today, which contained:
I also included a stencil for the soundcard.
I soldered the breakout board for the AXK770147G with the drag soldering technique, which I definitely need to practice. I needed to do a lot of cleanup with solder wick, plus I seem to have destroyed some of the solder mask. After some basic continuity checking, everything seems okay (though now that I'm looking again, it seems like I may have a bridge between two pins on the bottom right.
Unfortunately, it seems like I designed it upside-down. (It still pretty much works as a breakout, but I had intended for the double row of header pins to be on the top, not the bottom. Double check the orientation of critical connectors before routing! This isn't a big deal for this board (I mostly ordered this as a way to test continuity to pins on the 30-pin dock connector, and this board still works for that purpose, even if several of the pins are only accessible from the back.)
I also soldered the I2S board. (It's an odd shape because it's supposed to wrap around the touchscreen controller board.)
This went pretty smoothly, all things considered! This was my first time working with solder paste, stencils, and hot air. With the stencil ensuring that I had a reasonable amount of paste on each pad, I found the paste very forgiving. Squeegee some paste through the stencil, use tweezers to carefully place each part (nudging as necessary), and then gradually heat with the hot air station. Repeat for the back.
I caught a mistake with this I2S board pretty soon after I submitted the JLCPCB order -- I had laid it out with 0402 footprints for the 220uF capacitors, which you cannot get in such a small footprint. I've updated my board layout for 1206 footprints. I may end up adjusting the board so I can have JLCPCB assemble most of it for me -- put all the passives on one side, so I'm only doing the larger ICs. Before I reorder this board, I want to test it. In the mean time, I ordered the highest-capacity 0402 caps you can get on Digikey (22uF). This will mean I have terrible bass response, but I should still be able to test basic functionality.
(I'm tempted to redo this board with a codec with ground-centered "capless" headphone outputs. These ICs provide their own negative voltage rail with a charge pump, and can drive the headphone output to negative voltages. This avoids the need for bypass capacitors, and provides even better bass.)
For some reason, I had decided to use 1mm-pitch header holes on this board. I guess I was hoping if I got the board right, I could leave it as is and use small wires to connect to other boards.
Most forms of hookup wire I have on hand have insulation that is larger than 1mm diameter, so I ended up going with enameled magnet wire. Magnet wire takes forever to strip.
I think in the future, for small-pitch headers, I might go for 1.27mm. The standard rainbow "Dupont" jumper wires that you can find for cheap with 0.1" male or female pins on either end seem to be 1.27mm-pitch ribbon cable, so it would be much easier to solder some ribbon cables in place. Either way, if I do header pins this small again, I'll buy actual header pins and get a breakout board to 2.54mm headers manufactured. Maybe I should just buy some generic FFCs and breakout boards?
Looks like the connectors are in the right place / orientation, at least!
Still to do on the soundcard:
While I wait for my audio board and breakout boards to show up, I started working on the video output side of things.
The Raspberry Pi CM4 has four ways to output video:
I need to convert these into three different formats (in order of priority):
I'm not sure why Apple went with DisplayPort internally. I guess Macbook Pros of that era already had Mini DisplayPort ports. HDMI is roughly as complicated as DisplayPort, though, and would have simplified their HDMI dongle without adding much complication to their VGA dongle, in my opinion.
Here are the various options for converter ICs I found:
DisplayPort | LVDS | |
---|---|---|
HDMI x2 | STDP2600 (0.8mm BGA - doable?) | TFP401 (HTQFP) -> SN65LVDS93 (TSSOP) ADV7613 (0.8mm BGA) RTD2668 (massive QFP) |
MIPI DSI x2 | SN65DSI86 (tiny BGA) SN65DSI86-Q1 (HTQFP) PS8640 (tiny BGA) TC358766X (tiny BGA) ANX7805 (tiny BGA) | SN65DSI83 (tiny BGA) SN65DSI83-Q1 (HTQFP) |
DPI x1 (Parallel RGB) | ANX9807 (0.8mm BGA) STDP4028 (0.8mm BGA) | SN65LVDS93 (TSSOP) |
I think the SN65DSI86-Q1 and SN65DSI83-Q1 are my best bets:
It's not nearly done yet, but I've started making progress on the board for both LVDS and DisplayPort (as of right now, I've mostly wired up the SN65DSI83-Q1 but haven't finished the LED backlight driver nor started on the DisplayPort side of things.)
In my first project log, I had designed a PCB for interfacing with the touchscreen digitizer, based around Atmel's mXT2952, which was the only device I managed to find that had:
Unfortunately, the mXT2952 is a tiny 5mm x 10mm 162-pin BGA, with 0.5mm pitch. This is a tiny, tiny package, and they made it extremely dense -- many BGA chips have a few rows of pins, some blank spaces, then a few more rows of pins. To fit a trace between two pads, you need 3 mil traces and 3 or 3.5-mil spaces. To fit a via between four pads, you need vias that are less than 0.25mm diameter / 0.15mm drill. While there are some PCB manufacturers online that claim to have these specs, the cheapest I was able to find was about $150 according to their online quote form (others seemed to be $300 and up). When I engaged with the cheap one, they told me they couldn't actually do 0.15mm drill holes.
So I sat on this problem for a while, thinking maybe I'd eventually bite the bullet and spend several hundred dollars on a more expensive manufacturer.
The other night, I searched the web again for "capacitive touchscreen IC", and saw some results for the Goodix GT911 and GT9271. The latter is used in the Pinetab, and it's one of the first touchscreen controllers I considered. However, the GT9271 only has 32 drive / 20 sense pins - not enough for the iPad's touchscreen, and the GT911 has even fewer.
Long ago, I had tried looking on the Goodix webpage about their touchscreen controllers, which indicates that they have controllers that should work for even larger displays. This page has zero links or product numbers on it, however.
I searched around to see if I could find a full listing of all the ICs in the gt9xx family, and searched for every part number I found. Eventually I stumbled on the GT9110 and GT9113 (which seem to be nearly pin-compatible). Both of these have datasheets available online (not from goodix.com, of course), were available for purchase on AliExpress, and have a reasonable 0.4mm-pitch 88-pin QFN package.
I've created a new PCB design based around the GT9113 (should work for the GT9110 also - some of the broken-out pins become NC on the 9110).
As always, if you have any feedback, please let me know!
Create an account to leave a comment. Already have an account? Log In.
This looks like a good solution for UPS : https://www.omzlo.com/articles/pivoyager-the-smart-ups-for-the-raspberry-pi
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 https://www.waveshare.com/wiki/Pico-Audio parts which are already tested to run iPad speakers, or am I missing something?
Yeah, that looks like it should work. Seems like that's using the PCM5101A codec + the [APA206](https://octopart.com/apa2068kai-trg-anpec-87202072?r=sp), which looks like a speaker amplifier. If I have trouble solving my [audio quality problem](https://github.com/EvanKrall/pipad/issues/12#issuecomment-962888071) 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.
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.
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..
Cheers
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? https://learn.adafruit.com/hdmi-uberguide/rtd2660-hdmi-vga-ntsc-pal-driver-board
That's nice to hear!
Yeah the RTD2660H was my first Idea, like Joel Hill http://joel.hillspawn.com/apple_pi/2019/09/02/display.html , 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.
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.
1. https://wiki.pine64.org/wiki/SOQuartz
2. https://wiki.radxa.com/Rock3/CM3
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.
I think the SOQuartz only breaks out 2 lanes of the combo LVDS/MIPI-DSI transmitter to the cm4 pins: https://files.pine64.org/doc/quartz64/SOQuartz_SOM_schematic_v1.1_20210816.pdf 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.
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 https://shop.allnetchina.cn/collections/frontpage/products/rock3-computing-module
I guess that may still not be enough for your display if you need dual LVDS.
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!
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!
Become a member to follow this project and never miss any updates
@log13
An absolute beauty of a board, hopefully all works as intended.