Freeplay CM4

[smoscar01]

Yeah, video is working with `core_freq=400` I put an snes rom in it and the video looks fine

Images are refreshing correctly. The resolution looks a bit small but probably due to forcing it to be 320x240

The audio output in emulationstation was actually set to HDMI, changing it to PCM didn't change anything. I get video out of omxplayer but no audio and the HDMI screen is still disconnected. Listing the audio cards through aplay shows this:

Code:

pi@retropie:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
  Subdevices: 4/4
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
card 1: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 4/4
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3

And omxplayer outputs the following:

Code:

pi@retropie:~/Freeplay/Freeplay-Support $ omxplayer audiotest.mp4 -o alsa
Video codec omx-h264 width 1280 height 720 profile 77 fps 29.970030
Audio codec aac channels 2 samplerate 44100 bitspersample 16
Subtitle count: 0, state: off, index: 1, delay: 0
V:PortSettingsChanged: 1280x720@29.97 interlace:0 deinterlace:0 anaglyph:0 par:1.00 display:0 layer:0 alpha:255 aspectMode:0
have a nice day ;)

[smoscar01]

I got sound coming out of it!!

I had to edit /usr/share/alsa/alsa.conf and change both `defaults.ctl.card` and `defaults.pcm.card` from 0 to 1

Moving on to joysticks. I don't remember exactly what I changed on my CM3 image to calibrate them and make them work (checking my old notes now) but I see the following error in dmesg.

Code:

[    3.618236] mk_arcade_joystick_rpi: Freeplay Button Driver
[    3.618267] mk_arcade_joystick_rpi: pad type requested : 4
[    3.618279] mk_arcade_joystick_rpi: pad type : 4

Right now I am unable to get L2, R2 and the joysticks to work

Note: I am using the L2R2 Dual Analog (4 ADC) Add-On Board for them

Quick edit: I only know those are errors because they're shown in red in the console
It worked after adding the correct mk_arcade_joystick.conf

[smoscar01]

I spoke too soon :|

I'm getting a different output in dmesg than before, this made me think everything had been detected correctly through I2C yesterday. But then I took a closer look at the dmesg output:

Code:

pi@retropie:~ $ dmesg | grep mk
[    3.634517] mk_arcade_joystick_rpi: loading out-of-tree module taints kernel.
[    3.636086] mk_arcade_joystick_rpi: Freeplay Button Driver
[    3.683198] mk_arcade_joystick_rpi: request_module i2c_bcm2835 returned 0
[    3.683220] mk_arcade_joystick_rpi: I2C bus 1 NOT opened (sleeping and retrying)
[    4.194358] mk_arcade_joystick_rpi: I2C bus 1 NOT opened (sleeping and retrying)
[    4.714363] mk_arcade_joystick_rpi: I2C bus 1 NOT opened (sleeping and retrying)
[    5.234362] mk_arcade_joystick_rpi: I2C bus 1 opened
[    5.234381] mk_arcade_joystick_rpi: I2C bus timeout set to 10 ms
[    5.234396] mk_arcade_joystick_rpi: Analog auto center disable
[    5.234568] mk_arcade_joystick_rpi: X1 assigned to I2C address 0x48
[    5.234701] mk_arcade_joystick_rpi: X1 chip not found
[    5.234921] mk_arcade_joystick_rpi: Y1 assigned to I2C address 0x4D
[    5.235037] mk_arcade_joystick_rpi: Y1 chip not found
[    5.235240] mk_arcade_joystick_rpi: X2 assigned to I2C address 0x4B
[    5.235352] mk_arcade_joystick_rpi: X2 chip not found
[    5.235554] mk_arcade_joystick_rpi: Y2 assigned to I2C address 0x4F
[    5.235681] mk_arcade_joystick_rpi: Y2 chip not found
[    5.235822] mk_arcade_joystick_rpi: pad type requested : 4
[    5.235842] mk_arcade_joystick_rpi: pad type : 4
[    5.235906] mk_arcade_joystick_rpi: GPIO configured for pad0

Is it possible the i2c module changed for the cm4? Since I'm getting `request_module i2c_bcm2835 returned 0` in the dmesg too.

PS: ...I am using the exact same config I had in modprobe.d/mk_arcade_joystick.conf for the CM3 image:

Code:

options mk_arcade_joystick_rpi map=4 hkmode=2 i2cbus=1 x1addr=72 y1addr=77 x2addr=75 y2addr=79 x1params=663,3431,16,300 y1params=629,3485,16,300 x2params=753,3477,16,300 y2params=657,3446,16,300 gpio=4,17,6,5,19,26,16,24,23,18,15,14,-20,42,43,-1,41,-1,-1,-1,-1

[Flavor]

You will want to use these commands/tools to track down the i2c stuff.

i2cdetect 0
I2cdetect 1
raspi-gpio get

You may need to figure out what pins on the CM4 are actually getting connected to the Freeplay i2c pins.

The i2c stuff in config.txt may need to change.

[smoscar01]

I had to install i2cdetect:

Code:

sudo apt install i2c-tools

Rebooted, and got the following:

Code:

pi@retropie:~ $ sudo i2cdetect 0
Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory
pi@retropie:~ $ sudo i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n] Y
    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
pi@retropie:~ $ raspi-gpio get

BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT pull=UP
GPIO 1: level=1 fsel=0 func=INPUT pull=UP
GPIO 2: level=1 fsel=0 func=INPUT pull=UP
GPIO 3: level=1 fsel=0 func=INPUT pull=UP
GPIO 4: level=1 fsel=0 func=INPUT pull=UP
GPIO 5: level=1 fsel=0 func=INPUT pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=1 fsel=0 func=INPUT pull=UP
GPIO 8: level=0 fsel=1 func=OUTPUT pull=UP
GPIO 9: level=0 fsel=4 alt=0 func=SPI0_MISO pull=DOWN
GPIO 10: level=0 fsel=4 alt=0 func=SPI0_MOSI pull=DOWN
GPIO 11: level=0 fsel=4 alt=0 func=SPI0_SCLK pull=DOWN
GPIO 12: level=0 fsel=4 alt=0 func=PWM0_0 pull=DOWN
GPIO 13: level=0 fsel=4 alt=0 func=PWM0_1 pull=DOWN
GPIO 14: level=1 fsel=0 func=INPUT pull=UP
GPIO 15: level=1 fsel=0 func=INPUT pull=UP
GPIO 16: level=1 fsel=0 func=INPUT pull=UP
GPIO 17: level=1 fsel=0 func=INPUT pull=UP
GPIO 18: level=1 fsel=0 func=INPUT pull=UP
GPIO 19: level=1 fsel=0 func=INPUT pull=UP
GPIO 20: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 21: level=1 fsel=1 func=OUTPUT pull=DOWN
GPIO 22: level=1 fsel=1 func=OUTPUT pull=DOWN
GPIO 23: level=1 fsel=0 func=INPUT pull=UP
GPIO 24: level=1 fsel=0 func=INPUT pull=UP
GPIO 25: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 26: level=1 fsel=0 func=INPUT pull=UP
GPIO 27: level=1 fsel=1 func=OUTPUT pull=DOWN
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=2 alt=5 func=RGMII_MDIO pull=UP
GPIO 29: level=0 fsel=2 alt=5 func=RGMII_MDC pull=DOWN
GPIO 30: level=1 fsel=7 alt=3 func=CTS0 pull=UP
GPIO 31: level=1 fsel=7 alt=3 func=RTS0 pull=NONE
GPIO 32: level=1 fsel=7 alt=3 func=TXD0 pull=NONE
GPIO 33: level=1 fsel=7 alt=3 func=RXD0 pull=UP
GPIO 34: level=0 fsel=7 alt=3 func=SD1_CLK pull=NONE
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD pull=UP
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0 pull=UP
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1 pull=UP
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2 pull=UP
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3 pull=UP
GPIO 40: level=1 fsel=0 func=INPUT pull=NONE
GPIO 41: level=1 fsel=0 func=INPUT pull=UP
GPIO 42: level=1 fsel=0 func=INPUT pull=UP
GPIO 43: level=1 fsel=0 func=INPUT pull=UP
GPIO 44: level=1 fsel=6 alt=2 func=SDA1 pull=UP
GPIO 45: level=1 fsel=6 alt=2 func=SCL1 pull=UP
BANK2 (GPIO 46 to 53):
GPIO 46: level=0 fsel=0 func=INPUT pull=UP
GPIO 47: level=0 fsel=0 func=INPUT pull=UP
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK pull=DOWN
GPIO 49: level=0 fsel=4 alt=0 func=SD0_CMD pull=DOWN
GPIO 50: level=0 fsel=4 alt=0 func=SD0_DAT0 pull=DOWN
GPIO 51: level=0 fsel=4 alt=0 func=SD0_DAT1 pull=DOWN
GPIO 52: level=0 fsel=4 alt=0 func=SD0_DAT2 pull=DOWN
GPIO 53: level=0 fsel=4 alt=0 func=SD0_DAT3 pull=DOWN

Verifying that I2C is enabled through raspi-config, rebooted but still didn't see any devices connected to the bus. What's interesting is that listing the buses only shows this:

Code:

pi@retropie:~ $ i2cdetect -l
i2c-1 i2c      fe804000.i2c                    I2C adapter
pi@retropie:~ $ ls -l /sys/class/i2c-adapter/
total 0
lrwxrwxrwx 1 root root 0 Jul 17 00:04 i2c-1 -> ../../devices/platform/soc/fe804000.i2c/i2c-1

Trying with the `i2c1-bcm2708` lists the bcm2708 but the pi still sees no devices connected to it:

Code:

pi@retropie:~ $ i2cdetect -l
i2c-1 i2c      bcm2835 (i2c@7e804000)          I2C adapter
pi@retropie:~ $ sudo i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n] Y
    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- 

Could the i2c1_baudrate be affecting it somehow?

[Flavor]

It could be baud rate, but it’s more likely that the CM4 is connected using different pins. We’d need to figure out what GPIO of the CM4 are connected to the Freeplay CM3 i2c pins.

I don’t have the documentation easily here available. Offhand, I feel like it was using 44 and 45 before (on CM3).

dtoverlay=i2c1,pins_44_45=1,combine=off
That’s what controls it, but the CM4 adapter board could be connecting different pins to those.

[smoscar01]

I believe they're the same, `raspi-gpio get` shows 44 is SDA1 AND 45 is SCL1. Here's what I see in the CM4 documentation:

2.9. I2C (SDA0 SCL0) This internal I2C bus is normally allocated to the CSI1 and DSI1, as these devices are controlled by the firmware. It can be used as a general I2C bus if the CSI1 ad DSI1 interfaces aren’t being used, or are being controlled by the firmware. For example libcamera runs on the ARM and doesn’t use the firmware, so in this case you may use CSI1 and this I2C bus. SDA0 is connected to GPIO44 on the BCM2711 and SCL0 is connected to GPIO45.

2.10. I2C (ID_SD ID_SC) This I2C bus is normally used for identifying HATs and controlling CSI0 and DSI0 devices. If the firmware isn’t using the I2C bus e.g. CSI0 and DSI0 aren’t being used then these pins may be used as GPIO 0 and GPIO 1 if required.

NOTE If these pins are used as GPIO pins, then to prevent the firmware from checking to see if there is a HAT EEPROM available, add  force_eeprom_read=0  and  disable_poe_fan=1  to the config.txt file.

Unsure about the Note by the end but could it mean we need to force that EEPROM read?

Edit: trying to verify if the board connects the pins correctly

[smoscar01]

Based off of an interface diagram from my board's manufacturer it seems like the GPIO44 and GPIO45 pins are not connected to the board.

I2C would only be possible using the other bus (GPIO0 and GPIO1)

Does the freeplay board expose these pins by any chance or am I out of luck here?

[Flavor]

I can’t look anything up at the moment, but what you would need to do is compare that against what the actual CM3 does. Then you would want to see where the CM3 would have had 44 and 45 and see what this new one has instead. There is also the opportunity to use software I to see, but it won’t be as fast. It might work fine though.

[Flavor]

raspi-gpio get
Will just show what you have set up in the config.txt file. So it’s not a great indication of what’s actually physically connected.