Compute Module 4

[bzeiss]

Hi,

as CM4 is supposed to be (theoretically) be supported with the latest circle version, I thought I'd give some feedback with a few tests I have made:

Test 1:

• Board: official Raspberry PI I/O board
• Compute 4 model: CM4002008, Raspberry Pi Compute Module 4 2GB RAM, 8GB Flash
• MT32-Pi GPIO shield: self soldered chris-jh/mt32-pi-midi-hat v1.70 (I think). Confirmed working with a normal RPi4.

Test result:
Does not work at all. CM4002008 has onboard eMMC flash memory. I thought it would be straight forward to to put mt32-pi on the eMMC, but it turns out, the current circle version does not support eMMC. Unfortunately, it also doesn't seem to be possible to disable eMMC booting through the jumper and simply boot from the micro sd card. From what I have gathered, the sd card isn't wired at least on that version of the compute module. So as long as circle doesn't support eMMC, it's probably a good idea to avoid eMMC compute modules.

Test 2:

• Board: official Raspberry PI I/O board
• Compute 4 model: CM4002000, Raspberry Pi Compute Module 4 2GB RAM, Lite (without eMMC flash memory)
• MT32-Pi GPIO shield: self soldered chris-jh/mt32-pi-midi-hat v1.70 (I think). Confirmed working with a normal RPi4.

Test result:
mt32-pi starts to load, the oled of the mt32-pi-midi-hat starts to display text, but the device hangs on the "-> Init USB" test screen. When searching the circle wiki, I came across a pointer that suggested to add otg_mode=1 to the config.txt. I did that, but it didn't solve the problem. It seems to be that "#define USE_XHCI_INTERNAL" has to be enabled in sysconfig.h of circle in addition to the otg_mode=1 setting in the config.txt. I'm suspecting why this doesn't currently work with the provided binaries. I'm not sure if this setting can be safely enabled for operation with normal RPi4's as well.

I hope this feedback is helpful or interesting in some way.

The eMMC problem probably goes away with some upcoming circle release.

[dwhinham]

Hi there - thankyou for testing and providing this information, much appreciated.

I recently acquired a CM4 Lite (no eMMC) and there's an official I/O board on its way to me thanks to a generous donor, so I will be able to tackle this very soon. Like you say it's probably just some build options - if the same kernel can't be shared with the regular Pi 4, it won't be a problem to provide a CM4-specific build.

I expect to be able to come back to this within a couple of weeks.

Thanks again!

[dwhinham]

I now have the CM4 I/O board and was able to test it.

The kernel refused to boot fully simply because failure to initialize USB was considered fatal, which makes sense on a regular Raspberry Pi where USB ports are always present. However, obviously external USB controllers are optional on the CM4, so I simply allow it to fail now.

A test build is available here: https://github.com/dwhinham/mt32-pi/actions/runs/794051374
The same kernel as the regular Pi 4 can be used on the CM4.

Regarding USE_XHCI_INTERNAL - this is for when you want the Circle USB driver to use the internal USB 2.0 XHCI controller of the CM4 SoC instead of an external one connected via PCI Express (like the regular Pi 4 has with its VL805 chip).

This flag (and setting otg_mode=1) would enable the two USB 2.0 ports on the CM4 I/O board, but I'm not sure how useful that would be and whether I should bother going to the effort of setting up a special build just for that one use case. It would be better for a custom design based on the CM4 to add a USB 3.0 controller so that the user can enjoy USB 3.0 speeds, assuming there was a desperate need for USB at all in the first place.

In my testing I have used both VIA VL805 and Renesas uPD720201 based PCI Express cards in the CM4 I/O board with the kernel linked above, and USB MIDI and storage devices are working well.

[bzeiss]

That great. I'll test that build out tomorrow. I want to test out my newly built clumsymidi board anyway.

I fully agree with your thinking on the internal controller. It's probably not worth the bother for an entirely different build.

[bzeiss]

Success :-)

[dwhinham]

Excellent - thanks for confirming 🙂

I recognize those Thingiverse parts! Was thinking of adding them to my own board (which was very kindly donated!):

[bzeiss]

Hey Dale, have you happened to have played around with the latest circle release 44/44.1 yet? It seems that it supports the emmc compute module without an sd card slot. I have one of those emmc compute modules around and could test it.

[dwhinham]

Hi Benjamin,

Yes, my local dev branch is synced with 44.1 and coincidentally I received an eMMC-flavoured CM4 yesterday, so I'll get round to testing this shortly.

It shouldn't need any effort to support as it's just a Circle build flag, but I'll need to fiddle around with my build matrix in GitHub Actions to produce eMMC kernels. Watch this space :)

[joeytroy]

@dwhinham any luck getting this to work? I am using the ZWO ASIAIR Plus and it looks like that is the board they installed in the unit. I am currently running Raspain Buster 32bit Core

astro@openastro:~ $ lspci
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20)
01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)

The issue I am having is not all the ports are working

astro@openastro:~ $ dmesg
[    6.346375] usbcore: registered new interface driver r8152
[    6.346477] usbcore: registered new interface driver lan78xx
[    6.346555] usbcore: registered new interface driver smsc95xx
[    6.348178] xhci_hcd 0000:01:00.0: xHCI Host Controller
[    6.348231] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[   16.348301] xhci_hcd 0000:01:00.0: can't setup: -110
[   16.348346] xhci_hcd 0000:01:00.0: USB bus 1 deregistered
[   16.348402] xhci_hcd 0000:01:00.0: init 0000:01:00.0 fail, -110
[   16.348454] xhci_hcd: probe of 0000:01:00.0 failed with error -110
[   16.374367] xhci-hcd fe9c0000.xhci: xHCI Host Controller
[   16.374417] xhci-hcd fe9c0000.xhci: new USB bus registered, assigned bus number 1
[   16.376114] xhci-hcd fe9c0000.xhci: hcc params 0x0220fe65 hci version 0x110 quirks 0x0000000000010010
[   16.376225] xhci-hcd fe9c0000.xhci: irq 61, io mem 0xfe9c0000
[   16.376856] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[   16.376897] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.376933] usb usb1: Product: xHCI Host Controller
[   16.376963] usb usb1: Manufacturer: Linux 5.10.103-v7l+ xhci-hcd
[   16.376994] usb usb1: SerialNumber: fe9c0000.xhci
[   16.377691] hub 1-0:1.0: USB hub found
[   16.377790] hub 1-0:1.0: 1 port detected
[   16.378321] xhci-hcd fe9c0000.xhci: xHCI Host Controller
[   16.378365] xhci-hcd fe9c0000.xhci: new USB bus registered, assigned bus number 2
[   16.378409] xhci-hcd fe9c0000.xhci: Host supports USB 3.0 SuperSpeed
[   16.378583] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   16.378899] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10
[   16.378938] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.378974] usb usb2: Product: xHCI Host Controller
[   16.379003] usb usb2: Manufacturer: Linux 5.10.103-v7l+ xhci-hcd
[   16.379034] usb usb2: SerialNumber: fe9c0000.xhci
[   16.379706] hub 2-0:1.0: USB hub found
[   16.379790] hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
[   16.380564] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[   16.380909] dwc_otg: FIQ enabled
[   16.380923] dwc_otg: NAK holdoff enabled
[   16.380938] dwc_otg: FIQ split-transaction FSM enabled
[   16.380955] Module dwc_common_port init
[   16.381430] usbcore: registered new interface driver uas
[   16.381575] usbcore: registered new interface driver usb-storage

I did add otg_mode=1 into the config.txt and it seems to at least show the uPD720201 but again all the ports are not working. Here are some images of the custom board that they are using with the RPI 4 Compute. It has (2) USB2 / (2) USB3 / Network / 4x12v power ports. The system is used for Astrophotography.

[joeytroy]

I was able to resolve the issue by writing a custom Kernel https://github.com/open-astro/linux. The big thing was updating the config open-astro/linux@a40a0d1 and also copying over the renesas_usb_fw.mem firmware open-astro/linux@da5c9f1. More details are in the readme.