More out of curiosity than anything else do you think its possible to get the mnt reform working with a compute module 5 with fairly minimal work?
Don’t have a good level of understanding here to assess the complexity of such a task.
2 Likes
4 Likes
I dont even own a reform but imho a cm5 adapter would be great.
1 Like
I have a cm5 module it would be great to have a adapter
1 Like
1 vote from me for a CM5 adapter, enabling the use of the Radxa CM 5 in the Reform Classic.
Hi @minute
Any news or progress for a CM5 carrier board?
It would depend on the release of the V3.0 Classic motherboard (MNT Reform Motherboard 3.0 D-2 (!74) · Merge requests · Reform / reform · GitLab) wouldn’t it?
So far the interest in this has been very low (and also in the RPi CM4 before). Not 100% sure why that is. If a lot of people request this I’ll do it, but right now I’m not convinced about the benefit of doing it. Maybe you can change that!
2 Likes
Thanks @minute,
That is a shame. A CM4/5 carrier is a very flexible and cost effective upgrade path for the MNT Classic (or other Reforms?).
I already have the Classic and even though I was tempted to get the Next. It makes no sense when I can (theoretically) upgrade the MNT Classic to similar performance.
The Carrier CM5 would be the best option in terms of costs.
The official MNT Reform RCORE RK3588 Processor Module 16GB/128GB is €500 (~$1,000AUD) MNT Reform RCORE RK3588 Processor Module - MNT Research Shop.
Whilst a Radxa CM5 RK3588S2 16GB/128GB is about €160 (~300AUD) Radxa CM5 RK3588S2 8-Kern-CPU Radxa CM5 Lite RK3582 6-Kern-CPU-Compute-Modul, GPU, NPU, Single-Board-Computer - AliExpress 7
With the (future 
) CM5 carrier that would cost €150
(assuming similar pricing from the CM4 board MNT Reform CM4 Processor Module Adapter - MNT Research Shop)
Total ~ €310 (~$650AUD) + Cost of the V3.0 board?
The initial upgrade cost would be similar to the official MNT RK3588 module, but long term we can upgrade to newer CM5 modules with better CPU/GPU/FPGA etc in the future. Win - Win
1 Like
a CM5 carrier would be nice, though i understand that if the demand just isnt there it’s not quite worth the effort.
perhaps if it comes to fruition it might replace the rcm4? the pinouts are compatible, if my memory serves me right, and the extra pcie lane in the third connector could go straight to the nvme slot… or maybe the opposite, if routing allows it, to remove the mpcie to nvme adapter?
even though they are pin compatible, i however am NOT sure if component clearances allow for using a cm4 module on a cm5 carrier. maybe that requires one of those “interposer boards” that people use to protect the sockets like the Waveshare Interface Protection Adapter Board, but then having a single heatsink clearance becomes complicated… gah! maybe it’s too early for nixing the RCM4…
2 Likes
I would not assume that Radxa would support this exact pinout in a manner that facilitates upgrades down the road. Even Raspberry Pi changed the pinout of the actual CM5 from that of the CM4 slightly. Unless you have roadmap information you can trust, you should assume that only one board will ever be compatible with a SoM carrier like this given how quickly and erratically the SBC market moves.
3 Likes
It has come to my attention that i have been fooled by orange pi and their so-called cm5, and the actual RasPi CM5 features the same two 100-pin connectors as the CM4… with a few catches that mostly won’t affect the RCM4.
In terms of pinout changes, this is what’s been changed:
PIN# CM4 spec CM5 spec RCM4 Comment
16 SYNC_IN Fan_tach UART2_RX Note 1
19 Ethernet_nLED1 Fan_PWM (unused) Unused, so it's fine
76 Reserved VBAT (RTC) (unused) Unnecessary anyway...
92 RUN_PG PWR IMX_RESETn Functionally identical?
93 nRPIBOOT nRPIBOOT XSWITCH Note 2
94 Analog input 0 CC1 (unused) Unnecessary (USB-PD)
96 Analog input 1 CC2 (unused) Same as above
99 Global_EN PMIC_ENABLE TestPoint5 Externally identical
100 nEXTRST CAM_GPIO1 PI_nEXTRST Note 3
104 Reserved PCIE_DET_nWAKE (unused) PCIE-induced wakeup. See below.
106 Reserved PCIE_PWR_EN (unused) PCIE supports pwron/off
111 Composite out VBUS_EN (unused) Note 4
128 CAM0_D0_N USB3-0-RX_N (unused) |
130 CAM0_D0_P USB3-0-RX_P (unused) |
134 CAM0_D1_N USB3-0-DP (unused) |
136 CAM0_D1_P USB3-0-DM (unused) |
140 CAM0_C_N USB3-0-TX_N (unused) |
142 CAM0_C_P USB3-0-TX_P (unused) | Free Parking
157 DSI0_D0_N USB3-1-RX_N (unused) |
159 DSI0_D0_P USB3-1-RX_P (unused) |
163 DSI0_D1_N USB3-1-DP (unused) |
165 DSI0_D1_P USB3-1-DM (unused) |
169 DSI0_C_N USB3-1-TX_N (unused) |
171 DSI0_C_P USB3-1-TX_P (unused) |
Note1: This is going to be problematic. It would require a hardware workaround for A311D as it's shared with the SoC serial port (LINUX_Debug_RX). ouch.
Note2: Slightly different behavior according to cm5 forward guidance? "For a short time after power-up, if the PWR_button is low this pin will also be set low."
Note3: "Pulled up on Raspberry Pi Compute Module 5, but can be forced low to emulate a RESET signal." (effectively the same as it was for our purpose)
Note4: "The original Compute Module 4 VDAC_COMP pin is now a VBUS enable pin for the two USB 3 ports and is active high."
Strictly electrically speaking, the CM5 forward guidance would require sprinkling a few magic components that were once onboard the CM4. From the forward guidance:
- PCIE nWAKE: "Pull up to CM5_3v3 with an 8.2K resistor"
- "In addition to the above, the PCIe CLK signals are no longer capacitively coupled."
-- (note: this dont seem to have been required on nitrogen8m? i can't find any capacitors anywhere on those lanes...)
- Some track lengths are slightly different, but well within tolerance.
On top of all that DSI1 and CSI1 are now able to change purpose, so you can have two CSI/two DSI/ one DSI one CSI ports at will. As the RCM4 only bothers with DSI1/CSI1 anyway, not much should need to be changed.
Ironically, the A311D would be the only thing limiting a completely hassle-free upgrade. Kind of annoying since UART2 would be the main UART port of that SoC…
…Funnily enough this isnt a problem with the mars cm as it follows the raspi cm4 pinout a little more closely, go figure, lol. If only i could bring it up properly…
Other than that? This kinda looks like a drop-in upgrade!
2 Likes
This is a new RISC-V thing for CM4/5 form factor btw Banana Pi BPI-CM6 design with SpacemiT K1 8 core RISC-V chip | BananaPi Docs
I wonder how I could motivate more people to try their hand on RCM4 forks (in KiCAD). Maybe I could make a mod to support CM5 or this module and record it for YouTube or so…? Like, these modifications are limited enough that I think KiCAD hobbyists could do them, but my days are so cramped with work atm that I can’t justify delaying other things for sth like this, which is niche, but nevertheless interesting. I think it would be better as an evening or weekend thing for someone who has a normal, limited-hours job with some free time to spare.
2 Likes
I would like to take this on as a project as I do think support for these various CM4/5 modules offers a lot of potential for lower cost upgrade options across the MNT range.
As an electronics engineer by trade seems like a pretty doable mod as well. When I have some spare time maybe I will give it a go.
4 Likes
Hoho, K1! this is going to be either interesting or painful! vector extensions are nice, but mainlining is much behind the jh7110… not to mention the troubles wrt vendor distros. bianbu is so picky…
honestly i would not be surprised if cm5 boards could just be thrown on the rcm4 and work as well at they would always do.
fully taking advantage of the cm5 additions (like, perhaps, a usb3 to pcie adapter to keep the two new ports busy?) would require some tinkering with the design, but i believe basic functionality is already all there ready to work ootb. perhaps someone here with a cm5 could confirm? 