Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For anyone interested in this kind of thing, I am designing a board to hold two Raspberry Pi CM4 modules connected to a gigabit switch with 3 extra RJ45 jacks.

My hope is to make a somewhat minimal board for CM4 clustering. Eventually I will make a version with 4 CM4s and a single RJ45 jack, but I started with two CM4s and three jacks so I could test the ethernet switch independently of a CM4. And it turns out this board has some interesting uses too. I will break out both PCIe ports for the CM4s, so this board could have two intel wifi adapters plus three ethernet ports. It seems like that would make it a useful general purpose network thing. For example you could put a long range parabolic antenna on one wifi adapter and an omni antenna on the other and make it into a remote network access point (like a Ubiquiti Nanobeam connected to an AP). It should support VLANs etc as I will connect to the management interface on the switch via SPI or I2C.

However it is one of many projects I am working on, so I can't give a firm completion date. Microchip tells me they will ship me the ICs I need in a month, so it would be nice to have layout done by then. But we'll see.

Fork or star it on github to follow along. https://github.com/tlalexander/rpi-cm4-switch-board

Also if you have other thoughts about the design please share!




Don't forget to check the errata for that switch and apply the recommended workarounds. That fixed some link stability issues I witnessed on boards with KSZ9567.


Ah great tip thank you!


All the best!

The comments on that Banana Pi board point that the SoC doesn't have any network specific features i.e. HW NAT, WiFi offloading and so it would be bad for a router.

That seems like a reasonable criticism and if so it could apply to RPi CM4 as well, AFAIK they don't have network specific accelerators. Are you planning to address this with some additional co-processors?

If you end-up adding network specific accelerators, Please do work with OpenWrt team as lack of HW accelerator support (WiFi offloading) unlike proprietary firmware is a major pain point.


> The comments on that Banana Pi board point that the SoC doesn't have any network specific features i.e. HW NAT, WiFi offloading and so it would be bad for a router.

Does this really matter? It only has 1Gbps Ethernet, so shouldnt software NAT be fine? I have a significantly less powerful router with no hardware acceleration, and its never been an issue to get maximum speed, though my connection is only 100Mbit (over-provisioned to be about 20% faster).


I've seen the lack of HW NAT impacting performance of Wireless Network over Wired on some aftermarket firmwares for routers, OpenWrt does a decent job of software offloading but as with any SW acceleration the price is paid by the CPU.

Even with OpenWrt there are forks which can make use of HW NAT and give proprietary firmware level performance but are closed source!


Ah interesting. I don't see mention of NAT or address translation at all in the datasheet for the switch I am using. Since the original plan was just to mate CM4s with a switch I hadn't considered any additional network hardware.

This seems like a Rev2 thing. I could get the basic system up and running without additional complexity. But I really like the idea of forks of my work so once I've proven the basic layout I'd be happy to collaborate with the community on improvements.

Do you have any more information on that type of hardware or suggestions on how to learn more? Maybe I should get on the OpenWRT mailing list and introduce myself.


I'm going to be making a video about how I turned an Asus PN50 into an AP using Linux NAT but tbh the performance is pretty bad (but good enough for my home office)... It's also possible I'm configuring it wrongly. The general principles should be the same as RPi and even the net configuration is likely to be identical.

Rpis are notorious for just dying though. You may want to consider something more robust. Don't know if it's SSD corruption or what.


My understanding is that the issues with pi's dying is related to SD cards. But the Raspberry Pi Compute Module 4 (CM4) uses industrial eMMC memory which should have a much better lifetime.


Thanks for the confirmation! Apologies, I meant SD, not SSD. I didn't know cm4 was better! Good to know


> Maybe I should get on the OpenWRT mailing list and introduce myself.

I agree. OpenWrt's HW NAT support seems to be limited to mt7621 (i.e. At least upstream version).

Unless the SoC is purpose built for network computation I don't think they feature HW NAT, But open-source drivers for the SoC's which has HW acceleration is a bigger problem.

I think aiming for a good SW offloading is a more reasonable goal to start with, Which OpenWrt seems to be doing with MIPS based CPUs.


Interesting. The mt7621 is significantly more advanced than the basic switch chip I am using so far. I will continue with my current design and still try to reach out to the OpenWrt community for comment.


I’m not currently in the market for this but I must say: Very cool project. Godspeed!


Thanks for the kind words!


The CM3s and CM4s are so hard to find. The regular pis are still available, albeit at a higher price. Given that the CMs were intended for industrial/commercial integration, it seems like they would have a priority. They are mostly the same components.


Well the big issue with the CM4 is that there are 32 possible variants. As far as I can tell, a couple CM4 variants tend to be in stock at least in the USA last I checked. Only seeing one variant in stock right now at PiShop but it's there:

https://www.pishop.us/product/raspberry-pi-compute-module-4-...

The thing about industrial customers is that they are willing to buy whatever variant is available now for testing, spend a year doing design and integration, and then switch to the correct module for final system tests. I'm doing this with a project at work right now.

I could speculate that some hobbyist customers who might buy a raspberry pi would just as soon buy something else if they're just trying to learn electronics. So I would think commercial customers would be more resilient to delays than the hobby customers (as long as one or two variants are in stock to test).

And releasing 32 different variants of a new design during a global chip shortage seems reason enough for delays.

Frustrating though!


The CM4 network chip has hardware timestamp support, it'd be great if you could ensure that this is available through the interface.

I'm actively looking for a CM4 board that will support hardware timestamp so that I can use a CM4 to build a NTP + PTP master.


Interesting. You mean support the use of the SYNC_IN and SYNC_OUT pins? I could break those out. Looks like they are still working on support, but I could break out the pins. https://github.com/raspberrypi/linux/issues/4151




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: