Continuing the discussion from RPi5 specs and review:
In some ways i think it is too early to discuss the pros and cons of ‘compute module’ vs ‘standard’ RPi, because we don’t have a ‘CM5’ announcement. And there may be some issues that we ‘should’ talk about, like WiFi and connecting to an external antenna.
Has anyone seen-noticed any announcement from Rpi Foundation re form factor of a CM5? I wouldn’t expect it to change. but I wouldn’t have expected the Ethernet-USB port swap either!
Revive this topic?
The last reply to this topic was 6 months ago. Your reply will bump the topic to the top of its list and notify anyone previously involved in the conversation.
Are you sure you want to continue this old conversation?
Yes, I think we need to consider this question for a ‘V6’ version. The question of whether a next Zynthian should use a standard Pi5 board or an as yet unannounced CM5.
No announcement. I heard that we can expect something by the end of 2024. But no news is good news as far as changing the CM interface. And there are quite a few non-RPi implementations, so it might be a de-facto standard even if RPi Foundation drops-changes it (again).
I believe wifi connections will remain iffy (assuming you agree that is the case now due to enclosing wifi antenna in a metal box), and that a Compute Module would allow us to connect to an external antenna (outside and attached to the box).
Friendliness towards Do It Yourself projects
I think we could make a more DIY board with a CM than RPi - we would be implementing the parts of the RPi that we need. And we could use the CM4IO board as an example. Perhaps use some through-hole parts, allow for choice on some chips, provide test points and access, etc.
Ability to change the compute module
This of course is the most important advantage - for Zynia Migrating ZynthianOS to RISC-V, project name Zynia it means we could swap the Pi CM to a RISC-V CM - and there are about a dozen other options available now, but all AFAIK Arm architecture. It would almost certainly make future RPi updates easier. And this is one of our goals on Zynia - to isolate more of the board-CPU characteristics and allow Zynthian to more easily run in different (Arm, RISC-V, PC?, etc) environments.
Multiple decisions
This doesn’t need to be the same decision for all implementations of the Zynthian ‘architecture’ - eg ZV6, Z-mini Zynthian mini , etc.
Although I mostly agree with @jofemodo that we “zapatero a tus zapatos” I can’t resist pointing out that the open space on the PCB where the CM goes could also have pads for a processor and memory etc. This might be be pure fantasy, and the space might not actually be open, but with extra layers??? I’m thinking a JH7110 chip or its descendant.
Yeah, and we still haven’t heard about CM5, but I think if Zynthian is running from an M2 NVME drive it is less important. If necessary it could be supported via the PCIE port.
I hope I’m not “jumping the gun” bringing this up now in the midst of Oram work - I feel it is a mix of inter-related trade-offs and needs to be discussed in advance of the actual CM5 announcement. We could do this now. In the meantime, I’m working on using a current RPi CM4IO board and CM4 for both Zynthian and Zynia.
I advocated for the use of CM in Z2 and (to a lesser extent) V5 but have since better understood the challenges. @tunagenes has discussed many here but one that is missing that I think may be the most important is… timing.
The Raspberry Pi Foundation release their “credit sized SBC” Raspbery Pi boards aimed at hobbiests and education much earlier than their compute modules which are aimed more at OEMs and business. There is often substantial time between these releases which historically seems to be about a year. That is a long time in computing with the next Rapberry Pi version often being release not much later. To use the CM we lose a year of improvements. And history has also shown that CM changes more substantially than the standard Pi which can make integration even longer.
I think the CM is a good solution for embedding in a long term stable device. Zynthian is not! It is an ever-evolving creature that pushes the limits of its SBC and craves to be fed as often and early as possible. I think moving to the CM would take a lot of effort away from core development. It requires some degree of specialism to design and build the parent board which loses a lot of the support we get from community efforts.
I was an advocate for CM but am reborn to appreciate the advantages that the standard SBC provides, despite initally appearing suboptimal. (If the CM had proven to be a stable format I may have a different opinion.)
Great discussion, a lot of things to consider, so here’s my point:
CM4
I’am a big fan but sadly, we’ve missed it. Mostly because of its shortage BTW.
It’s still hardly findable in some countries and quiet expensive if you go for 8Go + Wifi (85€ at Berrybase de)
It’s an “old” design now and a bunch of alternatives are on the market.
CM5
Wait and see IMHO because
Raspberry Pi 5
itself introduce many nice features (PCIe lane, multichannel I2S, new RP1 southbridge) wich are closely related to mainline kernel evolution (*).
It’s the base of choice for exploring all these novelties.
Keep it simple
@stojos Zynthian mini approach is very inspiring in the developper’s POV: cheap and easily hackable for experimenting
and backward compatible
This is software and hardware related:
(*) Kernel versions
Oram is on 6.1.62-v8+, RaspberryPi is working on 6.6 branch, Linus latest stable is 6.8.4 and current mainline is 6.9-rc3.
I think it’s good practice to keep at least Zynthian’s devel branch as close as possible from RasperryPi default Github branch (6.6.y) for working on the Pi 5 and also because it will benefit to
Porting Zynthian on other platforms
They are a bunch on the market, in different formats (SOM, “zéro” sized SBC, credit card SBC,…) with different CPU.
They mostly all can run a debian bookworm system with a recent kernel.
Example here for OrangePi boards: