This is certainly going to be the largest and most challenging project I’ve ever worked on, but I’m going to begin designing a Carrier board for the Raspberry Pi CM4, I’m hoping it will be a drop-in replacement. Currently, the biggest challenge for me is having the capability for DP Alt Mode, Thunderbolt just will not happen.
A random question, would a PineBook Pro work better? They seem to have more IO. Not sure if that’s a better starting point.
if you can source a thunderbolt 3 chip, you can connect it to the pcie3x1 lane… if you dont use it for the ssd.
This sounds like an awesome project.
Good luck
Any updates on this?
I stumbled on the Pinebook Pro’s wiki:
https://wiki.pine64.org/wiki/Pinebook_Pro
Might be interesting to put a RockPi instead the Framework.
Any update on this?
Also, what about a CM4 expansion bay module?
A CM4 expansion bay module could be basically a second computer inside a Framework 16.
It might not even need to use the PCIe or full power capabilities of the expansion bay, just DisplayPort (for the internal display), USB (for communication between the mainboard and expansion module), and 5v 2.5a (enough to power the CM4 without needing voltage conversion from the 20v line).
Some software implementation could be setup to send the keyboard/trackpad inputs over the expansion bay USB to the CM4. USB tethering could share the mainboard’s WiFi connection over that USB connection (the 480 Mbps of USB 2.0 is good enough for the average internet connection IMO). And some hotkey could enable quickly switching the mux and keyboard/trackpad between the mainboard and CM4 module.
This is probably the module that I would be most likely to buy (currently am just getting a shell, which this could slot into). Having a full second computer (even a CM4) inside my laptop that I can switch to seems very cool and useful IMO.
It’s been on my backburner, but it might not be possible with CM4 for a surprising reason: The CM4 can’t boot directly to NVMe drives if they are behind a PCIe switch. This badly limits the ability of a carrier board to have stuff like add-in-card WLAN and USB 3.0.
Explanation about halfway down this blog post from Jeff Geerling: NVMe SSD boot with the Raspberry Pi 5 | Jeff Geerling
Tl;dr: the CM4’s limited bootloader space does not have logic to traverse a PCI Express device tree, so NVMe boot only works on a directly-attached drive. This is not yet fixed on Pi 5 but may be; no answer yet.
Personally I’m still intrigued enough to poke at it, and you could still have the OS on NVMe as long as you started your boot from eMMC or an SD card, but that makes it a much more tweaking-required sort of end-user experience. But the first thing I want to solve, personally, is adapting a Pi video output to eDP, since that’s what’s needed to run the FrameWork screen.
While it could be cool to use NVMe, I think SD card would be okay. (I’ve personally always used SD cards with raspberry pi computers)
One thing I’ve noticed with the Framework developer community is that developers want to go for the most advanced, capable, difficult, complex, and expensive version of what they’re developing. That’s not necessarily a bad thing, but I personally would prefer cheaper versions of stuff.
My ideal CM4 board likely wouldn’t even tap the PCIe capabilities of either the CM4 or the expansion bay. It would just connect to the USB 2.0 and Display capabilities of the expansion bay/mainboard for the keyboard/trackpad/display (and ideally internet connection sharing) capabilities and have an SD card slot for an SD card. It would also be nice to have rear facing GPIO and USB ports on the expansion card for external connections.
I think someone already developed a FW13 compatible DP to eDP adapter. Something based on that could be used.
Although through the expansion bay I think it might just use regular DP (and convert to eDP on the mainboard).
The Raspberry Pi does not have any sort of DisplayPort. It has HDMI, MIPI-DSI (which is barely documented and only officially supported for the official Raspberry Pi screen), and MIPI-DPI (which uses all the GPIO pins).
As near as I can tell, nobody makes HDMI-to-DP converters (just the other way around). There are a bare few chips that do DSI or DPI to DP conversion, but they don’t have much public documentation or sourcing, and they’re all really tiny BGA packages, so it’s far from easy.
Compared to that, PCI Express is actually fairly easy. The mining craze made simple 1-to-4-lane gen 2 PCIe switches cheap as chips, and you can just shove the signal over a USB 3.0 cable if you’re feeling lazy.
I see a couple cable with built in HDMI-to-DP converts on Amazon such as this. Presumably whatever chip is used in that could be used.
What about the SN65DSI86 chip? That claims to be for MIPI-DSI to eDP and I see some threads about it on raspberrypi.com.
Ooo, I hadn’t seen that one. The search results don’t look like it’s been “solved,” but it does already have a Linux kernel driver, and that’s huge. I had been looking at a Toshiba DPI chip previously.
If you do move forward with it I will probably buy one.
Hmm, perhaps sourcing USB4 controllers may be useful for redirecting the PCIe capabilities for the CM5, if you end up using that in your carrier board when it comes out
I tried a quick lifehack for the DP issue: can you just use a DisplayLink adapter connected by USB 3.0?
Answer: No. Outside of Windows, DisplayLink is a bit janky. Outside of x86 systems, DisplayLink is incredibly janky. “Break every software update” level janky on ARM.
Should the Pi 5 come out in CM5 form, would there be solutions to the NVMe issue?
Just checking in here to see if this is still being developed?
Is the project still ongoing?
Our team is ready to start producing this motherboard based on CM4 or CM5.
For the EDP section, we have found a solution and are currently testing it.
Since both CM4 and CM5 cannot boot from the PCIe bridge backend, we may use a USB 3.0 to NVMe solution to strike a balance between the slower SD card and the very fast NVMe.
Are you hosting the files somewhere, or is this a proprietary product?