theguydanish / cm4_matx Goto Github PK

Would be nice to have a variant with 12 volt only power fed by 12V barrel plug and/or ATX12V 10-pin plug with an internal VRM to convert into 5 and 3.3.

@TheGuyDanish I know this is a wontfix for you from our original discussion on Geerling's 19, but I thought it's the kind of thing that should be an issue anyway - and maybe someone decides to raise a PR.

We should swap from PI7C9X2G404SL to PI7C9X2G606PR to give us two extra PCIe downstream ports - this would allow us to lose the MUX chip and also frees up a spare lane for USB3, Thunderbolt, a fourth PCIe slot or a second m.2 slot for a TPU or other minicard.

As I've mentioned a couple of times before, there are some parts of schematic and PCB design that I'm not quite confident with.

In the interest of moving this project forward, I'd like to request some assistance from anyone that has experience in designing schematics, specifically around powering ICs with different voltage. (1v, 3.3v, both analog and digital power)

I have requested, and received, a trove of design documents from Diodes Inc regarding this chip (That I am not publicly sharing due to concerns about disclosure). Including application notes, checklists, PCB design guides and a reference board design. I'd be happy to pass this onto anyone who would like to oversee getting the right power wired into this chip.

Alternatively, there is a chance I will be able to look at this around mid-December when I get back to Denmark and have a chance to chat with my father about it, as he's more qualified with these things.

On the Raspberry PI CM4 IO board, there is a jumper that affects the BOOT mode.
It is on Jumper 2 of the CM4 IO board:
Pin Function
1-2 nRPIBOOT If fitted forces USB booting, it is useful if the eMMC becomes corrupted.
3-4 EEPROM_nWP If fitted write protects the EEPROM on the CM4

It is vital when doing recovery of the eMMC on the CM4, or when installing the OS to it.

Please make sure there is a similar jumper on the CM4_MATX.

Output from 'update PCB from Schematic':

Error: Cannot add C65 (no footprint assigned).
Error: Cannot add C45 (no footprint assigned).
Error: Cannot add C35 (no footprint assigned).
Error: Cannot add C36 (no footprint assigned).
Error: Cannot add C44 (no footprint assigned).
Error: Cannot add C37 (no footprint assigned).
Error: Cannot add C38 (no footprint assigned).
Error: Cannot add C43 (no footprint assigned).
Error: Cannot add C40 (no footprint assigned).
Error: Cannot add C42 (no footprint assigned).
Error: Cannot add C41 (no footprint assigned).
Error: Cannot add C50 (no footprint assigned).
Error: Cannot add C33 (no footprint assigned).
Error: Cannot add R3 (no footprint assigned).
Error: Cannot add C46 (no footprint assigned).
Error: Cannot add J22 (no footprint assigned).
Error: Cannot add C32 (no footprint assigned).
Error: Cannot add J23 (no footprint assigned).
Error: Cannot add C31 (no footprint assigned).
Error: Cannot add C47 (no footprint assigned).
Error: Cannot add C30 (no footprint assigned).
Error: Cannot add C29 (no footprint assigned).
Error: Cannot add C48 (no footprint assigned).
Error: Cannot add R1 (no footprint assigned).
Error: Cannot add R28 (no footprint assigned).
Error: Cannot add C27 (no footprint assigned).
Error: Cannot add R4 (no footprint assigned).
Error: Cannot add C56 (no footprint assigned).
Error: Cannot add C26 (no footprint assigned).
Error: Cannot add R6 (no footprint assigned).
Error: Cannot add C49 (no footprint assigned).
Error: Cannot add C25 (no footprint assigned).
Error: Cannot add R8 (no footprint assigned).
Error: Cannot add R9 (no footprint assigned).
Error: Cannot add C24 (no footprint assigned).
Error: Cannot add R10 (no footprint assigned).
Error: Cannot add C8 (no footprint assigned).
Error: Cannot add Y1 (no footprint assigned).
Error: Cannot add C23 (no footprint assigned).
Error: Cannot add R12 (no footprint assigned).
Error: Cannot add C68 (no footprint assigned).
Error: Cannot add R13 (no footprint assigned).
Error: Cannot add C22 (no footprint assigned).
Error: Cannot add R14 (no footprint assigned).
Error: Cannot add R15 (no footprint assigned).
Error: Cannot add C21 (no footprint assigned).
Error: Cannot add C67 (no footprint assigned).
Error: Cannot add R17 (no footprint assigned).
Error: Cannot add C20 (no footprint assigned).
Error: Cannot add C54 (no footprint assigned).
Error: Cannot add C57 (no footprint assigned).
Error: Cannot add C7 (no footprint assigned).
Error: Cannot add R19 (no footprint assigned).
Error: Cannot add C19 (no footprint assigned).
Error: Cannot add R20 (no footprint assigned).
Error: Cannot add C66 (no footprint assigned).
Error: Cannot add R21 (no footprint assigned).
Error: Cannot add C18 (no footprint assigned).
Error: Cannot add R22 (no footprint assigned).
Error: Cannot add R23 (no footprint assigned).
Error: Cannot add C53 (no footprint assigned).
Error: Cannot add R24 (no footprint assigned).
Error: Cannot add R11 (no footprint assigned).
Error: Cannot add R25 (no footprint assigned).
Error: Cannot add C16 (no footprint assigned).
Error: Cannot add R26 (no footprint assigned).
Error: Cannot add C17 (no footprint assigned).
Error: Cannot add C52 (no footprint assigned).
Error: Cannot add C14 (no footprint assigned).
Error: Cannot add R29 (no footprint assigned).
Error: Cannot add R27 (no footprint assigned).
Error: Cannot add C64 (no footprint assigned).
Error: Cannot add C15 (no footprint assigned).
Error: Cannot add C28 (no footprint assigned).
Error: Cannot add C51 (no footprint assigned).
Error: Cannot add R2 (no footprint assigned).
Error: Cannot add J21 (no footprint assigned).
Error: Cannot add C63 (no footprint assigned).
Error: Cannot add C12 (no footprint assigned).
Error: Cannot add R16 (no footprint assigned).
Error: Cannot add C11 (no footprint assigned).
Error: Cannot add C62 (no footprint assigned).
Error: Cannot add C10 (no footprint assigned).
Error: Cannot add U2 (no footprint assigned).
Error: Cannot add C9 (no footprint assigned).
Error: Cannot add C61 (no footprint assigned).
Error: Cannot add C34 (no footprint assigned).
Error: Cannot add R18 (no footprint assigned).
Error: Cannot add C13 (no footprint assigned).
Error: Cannot add C60 (no footprint assigned).
Error: Cannot add C6 (no footprint assigned).
Error: Cannot add C5 (no footprint assigned).
Error: Cannot add C59 (no footprint assigned).
Error: Cannot add C4 (no footprint assigned).
Error: Cannot add C55 (no footprint assigned).
Error: Cannot add C3 (no footprint assigned).
Error: Cannot add C58 (no footprint assigned).
Error: Cannot add C2 (no footprint assigned).
Error: Cannot add C1 (no footprint assigned).

I dont mean to toss some logs into a fire but perhaps considering the pi is known for efficiency. We adapt the new trend of atx12vo power supplies. They tend to be cheaper and more efficient naturally since they only dish out one voltage. Im not saying drop the normal atx only but maybe a variant board on the repo that could be kept in line with the main board with the exception of the power circuits.

If thats seen as not needed or wont do please close this or comment your thoughts so others know.

GPIO_VREF is used on sheets (1,) 2 and 6 but never defined.

Screenshots from CM4_IO:

YES i am perfectly aware of the ATX formfactor and the ATX-PSU coming with it. But i was thinking about all the other possibilities of powering a board: onboard MicroPSU or even only PoE.

I am currently diving into IEEE 802.3bt on PoE++ / 4PPoE which could give up to 70 effective Watt.

Nevertheless: i would really appreciate compatibility for a PoE HAT for not so power gussling usecases.

This is something cribbed straight out of Supermicro's playbook, but I think we should absolutely borrow it.

The design as current exposes two USB 2.0 headers. I propose we only expose one header and expose the other as a USB type A socket.

The reason is, there are many USB devices that would make sense to use internally in a Pi based PC which are only available with A connectors and not header blocks:

1. USB-SATA adapters. Many people use these, as they connect a standard 2.5" ssd to a USB socket. With an internal USB port, one could be mounted in a normal drive cage and still used as a Pi's boot drive - handy, since NVMe boot support is not available.

2. USB flash drive. See above, except cheaper. A USB flash drive could hold the pi's bootloader only, for booting to NVMe. Allows easy use of NVMe with the Pi CM4 lite, potentially allowing the eMMC interface to be used for something more useful. (We're exposing that as a header block too, right?)

3. USB-Floppy disk drive interface. Something like this - https://www.ebay.co.uk/itm/264239344659 - Which allows an internal 3.5" drive to be mounted for retrogaming fun. But, it needs a USB-A, not a header.

As an alternative to this proposal, I'd also accept headers-only, as long as they were two physically separate four-pin headers, and not the common two-port 9-pin header block. That would allow something like a single port version of this to be made to allow both internal or external type connectors to be used in any combination: https://www.ebay.co.uk/itm/383805792699

I recently worked a lot with the Raspberry Pi Zero and i really liked the existence of test pads for debugging. Would be great to see some (labeled) pads for testing supply voltages, the I2C bus etc. on this PCB too.

As was seen in #15, the nightly builds of KiCad have some issues with save compatibility between operating systems. A great way to avoid this is to use stable versions of the software. (I'm gonna take the fall for that one.) And we should make an effort to move CM4_MATX towards using a stable version.

Given we already have a bit of a base to work from, it would be nice to be able to somehow export the current work into a format that will then be readable by stable, but I doubt that will be the case. I've started a local rebuild of the project and I'm currently gathering all the schematics and footprints required to get it going.

My first challenge is that the CM4IO board, from where the actual Compute Module 4 schematic and footprint was taken, uses KiCad Nightly as well. Meaning that the resources taken from there are incompatible with stable.

While these are issues that could be worked around, it would take some time to figure out.

I'm looking into this as a priority so we don't have people wasting time building schematics or designs that cannot be directly transferred to the project.

According to the launch blog for the CM4, by holding the SOC in a reset state, the SDIO interface can be used to access the eMMC on a full fat CM4 for programming. Outside of that case it can also be used to add an eMMC module to a CM4 Lite, as an SD I/O interface in the classic sense for external hardware (GPS, modems, etc), or.. as an SD card socket.

The CM4 Carrier hard limits all of that to JUST being used as a storage medium by using a uSD socket. We should expose it as pins, and allow the end user to attach an eMMC module, a full size OR micro SD slot via a simple passive shim, or use the SDIO functionality for another device - OR, connect it to another computer to access the eMMC.

Should be 0402 size, 0.1µF, and on both lanes at the same position (inside the trace, not to ground).

Has heat sink mounting been discussed for this board?

I've looked around and not found much offered specifically for the CM4, but I have made contact with Alpha Nova Tech and requested some help fitting one of their products to a CM4 for another project. Right now it's looking like M2.5 shoulder bolts and press-fit PEM style threaded inserts, with an off the shelf heat sink, custom drilled for the CM4 will be the most economical solution.

Would appreciate any insight others have here, and of course will share what I learn if that's helpful.

Wouldn't it be better to integrate a USB-based RTC into the motherboard design, as opposed to a GPIO-based one, to save pins?

Something like this perhaps: https://easyeda.com/rodyne/USB_RTC-dfce249ec7af4d7380d69c51a7e2cfec

USB (at least theoretically) supports up to 127 concurrently connected devices. Therefore, whenever integrating any functionality on the motherboard that can be implemented over either USB or GPIO, USB should be the preferred way to go, right?

See screenshot:

Has there been any discussion about ATX style power control? E.g. press the power button once and the OS shuts down, and then powers off. Hold down the button to override the OS shutdown.

Here are a few references to some pi-related stuff that might be of use:

soft power off
This device tree overlay can be used to map a GPIO to key 116 (power key):
https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt

pi specific discussion here:
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=115394

You can then use a custom udev rule to map this to "power-switch" tag. Systemd then gets ahold of the event and can initiate the shutdown, and finally take the action configured in logind.conf according to its HandlePowerKey setting, which defaults to "poweroff".

turning off ps
After the OS has shut down, you want to signal to the ATX power supply that it can turn off. Here's a discussion about a pi-specific overlay that maps a GPIO pin such that it changes state once the OS has halted the CPU:
https://www.raspberrypi.org/forums/viewtopic.php?t=201483

Lots of ways to implement this, but I'll stop there - maybe this has already been thought about? (Apologies if I missed it!)

Considered a best practice by some.

I agree with Jim G here on the library best-practice. I have been able to clone others' projects more successfully when they had the Project Library included with the project source.

When having multiple editors working in KiCad, with a shared workspace (i.e. Github), having a 'Project Library' for symbols & footprints is common. This practice also places these parts under version control (Github) and they "live with the project" as time goes by, leading to easier recovery of old projects.

@TheGuyDanish perhaps you could make the library management conditions part of your CONTRIBUTING doc, i.e. one of these two workflows (or your own)?

Workflow Idea 1 (always use Project Library)

• when placing a symbol or referencing a footprint, only reference the CM4_MATX Project Libraries, and migrate components from standard libraries to the project within the working session.

Workflow Idea 2 (use standard libraries, and 'freeze' components to the project library on release):

• Standard symbols and footprints can come from standard libraries, but if adding a new custom part, it must be in CM4_MATX libraries.
• When moving to tag a release in Github (a major milestone on the project perhaps?) symbols and footprints are copied from the standard locations to the Project Library versions. There may be some Python scripts to automate some of this, or perhaps the 'Edit Symbol Library Links' and 'Assign Footprints' menu options within eeschema (I've done search/replace copy/paste for these fields on a medium sized, 500 component, project. It takes some time.)

You could (over time, and as you see fit to do so) add other best practices, for example:

• SCH files must pass ERC before sending in a pull request. (or exception is noted in the pull request comments)
• PCB files must pass DRC before sending in a pull request. (or exception is noted in the pull request comments)
• Files must be named as (whatever file-naming standard) i.e. CM4_<component_name> (Looks as this has been done well so far)
• Subsheet files should be in the same directory as the .pro and toplevel .sch file. (unless you want some contributors work coming in subdirectories...)
• etc.

These things become more important as you move past 4-5 contributors, so choose and implement at your discretion.

These type of practices are used often in distributed software development work, (except the software-team dev practices are: builds must be passing compilation with no errors before checking in a file, files have to follow naming standards, source code requires comments per function, etc.)

Originally posted by @ddkaiser in #15 (comment)

So in order to provide the high res 4-lane CSI, the i2c pins are needed. The i2s interface is also needed for sound capture from HDMI. By counterpoint, the CM4 exposes ADC interfaces on the SOM connector that are not exposed through the standard pi 40 pin. It also doesn't expose the 12V rail we have access to through the ATX PSU.

Additionally, the 40-pin IDC connector is not "external grade" hardware.

Since many hats already won't work with the hardware above missing, I propose making a "different" 40-pin connector exposed internally which is not pin-compatible with the standard Pi header, then breaking that out onto the I/O shield with a 37 pin D-Sub connector on a ribbon cable. - Inspired by the Be Inc Geekport.

We have a ton of passive components (resistors, caps, etc) and as the board makes progress towards being more feature-complete, we need to start considering which parts we want to use for manufacturing.

For the first portion of this task, I believe just getting a footprint assigned would be a good start. (Deciding what size parts we're going to use for specific items. 0603, 0805, etc) Once all passive parts have been assigned a footprint, we can look into more specifically which parts can be used for manufacturing once we get closer to such a stage.

Hi, did you verify the uatx board yet? I might want to steal that :)

not sure what reference you used, but the holes dont line up with
https://doc.xdevs.com/doc/_PC_HW/Form_factors/matxspe1.2.pdf page 12

I'm kind of in favour of copyleft, since nice to get bug fixes from any company who makes money off this - but permissive is more likely to encourage somebody to actually make it.

Copyright assignment, or collaborative licence model? Contributors.md?

Or do you just want to CC0 (Public Domain) this?

But you should probably add a licence, anyway. :)

As mentioned in #1, we can quite easily implement an RTC into our design (which I believe would be a genuinely nice and useful feature). I'm breaking it out into a new issue to increase visibility.

On-board RTC is present in the CM4IO board and could easily be lifted if we want to integrate it.


Originally posted by @TheGuyDanish in #1 (comment)

I noticed the following when I tried importing the KiCAD project in FreeCAD, using the KiCadStepUp addmon.

Apparently, in addition to the default library location in $KISYS3DMOD, this project has been configured to assume hard-coded locations of 3D images of some of the components in the default Windows installatoin folder of the SamacSys ibrary Loader.

If you type the following command:

cat CM4_MATX.kicad_pcb | grep -i samac

That results in this output:

    (model "C:\\SamacSys_PCB_Library\\KiCad\\SamacSys_Parts.3dshapes\\72309-8014BLF.stp"
    (model "C:\\SamacSys_PCB_Library\\KiCad\\SamacSys_Parts.3dshapes\\PI7C9X2G404SLBFDE.stp"
    (model "C:\\SamacSys_PCB_Library\\KiCad\\SamacSys_Parts.3dshapes\\USB2517-JZX.stp"
    (model "C:\\SamacSys_PCB_Library\\KiCad\\SamacSys_Parts.3dshapes\\39-28-1243.stp"
    (model "C:\\SamacSys_PCB_Library\\KiCad\\SamacSys_Parts.3dshapes\\SS-52100-002.stp"
    (model "C:\\SamacSys_PCB_Library\\KiCad\\SamacSys_Parts.3dshapes\\10104110-0001LF.stp"
    (model "C:\\SamacSys_PCB_Library\\KiCad\\SamacSys_Parts.3dshapes\\10018783-11200TLF.stp"

Obviously, this will only succeed in when you're running KiCAD in Windows, and even then only if the SamacSys ibrary was indeed installed in that folder.

Now ideally, we would want to include any 3dshapes that are not provided in the standard KiCAD llibrary, and refer to them through a closs-platform project-relative path. Unfortunately, there's the license of these 3D models to consider. The ones from SamacSys are apparently "free as in beer" (not sure what the exact terms are in the fine print), but that doesn't necessarily allow us to distribute them with these sources

For an optimal render that will look close to the actually envisioned end product, we need 3D models of the components that will go into the design.

Any ideas on how to tackle this?

This isn't really an issue, but I was hoping to get some input because I am interested in doing something similar as a hobby project.

Just in general, how hard is it to build a board around the CM4? I would assume that if you stay within the default functionality it is relatively simple, but adding things like a PSU, DAC, or chips on the PCIE bus greatly increase the complexity.

What would you say are the hardest parts of designing this board? Any specific major issues you faced?
Have you gotten to the point of manufacturing any tests PCBs? Have you been picking components specifically thinking about manufacturing?
Is there anyway for you to test things before manufacturing a PCB? I assume simulation of this with many black box chips would be extremely hard. Is the only option lots of schematic review to hopefully catch bugs?

Sorry for the barrage of questions, I am just hoping to learn more about the challenges of this sort of process.
Thanks for your time.

The STEP file RJMG2012119A0NR.stp is kind of odd. Footprint and device do not match (through holes do not align with pins).

Perhaps some inspiration for ideas or things that may be unseen. But take a look at this. Delete this if you simply dont care or use this issue as a discussion about it. http://linuxgizmos.com/carrier-board-extends-raspberry-pi-compute-module-4-with-pcie-sata/

Wouldn't it be preferable (and equally flexible) to use open-ended PCIe x1 slots instead of full-blown PCIe x16 slots that would be wired up as x1 slots?

It would make it clear that these are indeed just x1 interfaces, and there would also be a lot less solder points and PCB real estate required, so perhaps it would simplify the board design a bit as well?

The one challenge here might be that such slots could be difficult to source, at least judging from this Reddit discussion, although it's 3 years old, and availability may have improved since then.

One of the things the pi really lacks is good audio in and output. The Pi 4 model B got an audio jack, the IO Board none. But what about a microphone jack, 2.1 sound (or even 5.1). There are some HATs out there doing this by I2S, SPDIF or an HDMI Audio Grabber IC.

Some examples:
SUPTRONICS ST6000 or X6000K-7.1CH Expansion Board they seem to be the same,
Amplifier HATs by HifiBerry,
HiFiBerry Digi (digital audio interfaces),
Wolfson Audio Card

All these solutions are quite expensive but certainly worth considering for a Desktop PC.

This empty space can be utilised to add further features, such as:

• SATA
• M.2
• Front USB 2.0 header
• Onboard audio device

As an improvement on #12, perhaps we can export the KiCad designs to Blender and render a near-realistic image of what the board would be expected to ultimately look like.

There appear to be multiple projects on GitHub that aim to facilitate just that, including one that was featured on Hackaday here: https://hackaday.io/project/175077-remoticon-kicad-to-blender-pcb-renders

The results look pretty impressive.

If we could manage this for this project as well, it would attract a lot of interest and publicity, including (hopefully) more knowledgeable volunteers willing to help us with the hardware design.

I'll look into those projects to see how feasible this would be. Seems like a fun challenge, and something that even I, lacking hardware development skills, can take a stab at. 🙂

Just to make the README page a tiny bit more accessible / quickly identifiable—it would be nice to capture the PDF as an image, and place it on the project's README near the top, linked to the PDF itself, with a note underneath stating the image may be slightly out of date, and to click on the link to the PDF to see the latest design.

See my Turing Pi Cluster README for an example of how it works (in case you're not familiar with embedding repo images in a README or positioning/aligning them).

Over time we can update the image... and eventually maybe slap a picture of the board itself on it, once it comes to fruition! I will try to help in whatever way I can to make this board a reality, as after a bunch of NAS testing, I'm kinda jealous of all those boring old PC cases being able to mount tons of hard drives without a giant rat's nest of cabling mess.

I'm willing to do this, and will in a bit if nobody else picks this up, but right now I'm putting the kiddos to bed :)

Although it's considered a legacy interface, I'd very much like to see a parallel port on the backplate of this motherboard, for various (retro) tinkering purposes. One that supports bit-banging, a low-level feature that USB to parallel port adapters don't offer.

Perhaps you could implement this fairly easily by integrating the pi-parport HAT design at https://github.com/worlickwerx/pi-parport into your motherboard design?

I'm not sure if this would take up any pins that are already required to offer other types of integrated I/O that you plan to implement, but if not, this would be really nice to have.

What if you did one pci slot and then ISA? That would make this more of a retro hybrid kind of like the commander x16. You could use old ISA cards then too.

A fan powered by a 4-pin fan connector would be quite useful to actively cool the compute module.

Hi,

I suggest using Display Port out instead of HDMI.
Display Port out is much more flexible because it adds a power supply to the output.
One can then get adapters that convert it to all sorts of different outputs: DVI, HDMI, VGA etc.

Seems overkill on first glance – but the CM4 might get very toasty on heavy loads. Maybe place a thermistor somewhere near the maximum heat spot under the CM4 to control that circuitry.