That’s a neat idea, but niche…
Biggest hobbyist issue is that high speed signaling like PCIe, USB 3, and display protocols require specific attention to trace impedance, as well as a really good oscilloscope to verify and debug. Many of these can also require design documents that are expensive to license and/or require a non-disclosure agreement to view, so community knowledge is hyper-limited.
Cooling is also an issue, but it might not be too hard to bodge on the existing Framework cooler.
Like, I’ve made RPi CM4 carrier boards. I could make a board for this. But I’d have no idea if it worked.
I’d call this plausible but very difficult for a community undertaking.
–
Say we wanted to use an RPi CM4, just gonna rattle off some issues as they come to mind:
The default high speed I/O out of a CM4 is two HDMI, one gigabit ethernet, one USB 2.0, and one lane of PCIe. HDMI to eDP is not trivial, but maybe just… bodge one of those eBay converter modules to it for $20. Route the other HDMI out to a custom expansion module for a second display (existing HDMI module wouldn’t work because it converts DP, which isn’t present on a CM4). USB 3 controller can hang off the PCIe lane and be matched with a hub for multiple ports, easiest is just to make those the other three expansion slots, or two slots and the third is a barebones ethernet jack module. Or one PD-only port and two USB-only ports.
There are also MIPI CSI and DSI interfaces but the Framework has a USB webcam and an eDP display, so might as well ignore those. The Framework mainboard supports CSI cameras but they aren’t currently used I think.
Big problem here is handling power, keyboard, mouse, etc. You essentially need to re-implement the Framework’s Embedded Controller. The EC handles all the buttons and keys, it handles the trackpad, it handles turning power on in sequence and turning power back off when it’s safe to shut down. The Raspberry Pi platform doesn’t have any power management, so no sleep mode, and safe shut downs have to be overseen by external logic/control.
But it’s possible to bodge. A saving grace of using an RPi CM4 is that you can just give it five volts and flip its “on/off” switch, and its own power manager will handle everything on the board like sequencing and lower-voltage regulators and bootstrap. So the power duties of an EC can be simplified to power up, safe shut down, and battery emergency shutdown. Not great to use as a laptop, but not the worst either.
The USB-C ports would have to be simple USB-only jobs, but you could have them sink PD for the battery. Probably just output standard 5V/900mA or 5V/3A though.
Keyboard scanning is not really a problem for a modern microcontroller. Touchpad… Oh, Microsoft has good whitepapers for i2c touchpads. Not difficult, just time consuming. The Framework EC is open source, and that makes all this easier.
I wouldn’t know where to start to get the fingerprint sensor working (beyond plugging it in to USB) and would probably just ignore it. But a quick google says fprint might cover this on Linux, and I think the Framework’s sensor is supported.
Pull sound off the HDMI to eDP board…
Okay, I just looked over the Jetson Nano carrier board docs. There’s no way I could validate the USB 3.2 10 Gbps. That speed over a single RX/TX pair is serious engineering, not hobbyist grade stuff. Even if I followed the docs exactly, I couldn’t verify beyond “plug something in and hope it works.”
Man… this sounds hard but doable. Kind of interesting. Easy to make but hard to develop. But that means they’ll have a heck of a low-run markup to be viable. How desirable is it really if the Jetson module and the carrier board end up costing the same as a stock Mainboard?