Worklog Retro Lite CM5

[StonedEdge]

Hi guys,

I thought I'd start a new worklog to share progress updates on the Retro Lite CM5! (however slow they may be!).

I've decided that I want to re-design the Retro Lite PCB from the ground up to support the up and coming RK3588s compute module. With the new release of the Radxa CM5 coming this year, I would like to be able to upgrade my emulation handheld to be able to play GC/PS2 games at full speed, which obviously the Raspberry Pi CM4 cannot do with its poor GPU and lack of CPU cores. At the same time, there were a few flaws with the original design that didn't make a whole lot of sense/left a lot on the table, so I am hoping to at least improve the electronics side of things where I can!

I've ran some tests with the Orange Pi 5 (uses the same RK3588s SOC) and I've been able to get some great performance out of AetherSX2 under Linux with the Open GL ES 3.2 backend and mali blob panfrost drivers. Here it is running God of War at around 7-8W of total power at 2x resolution with minimal dropped frames in Arch Linux. Unfortunately the RK3588s doesn't support Vulkan drivers at the moment but I still think performance is good enough to create a great gaming handheld under Linux.

There's a lot of changes that need to be done to the new carrier board to integrate the CM5 module, but I'm hard at work trying to make improvements here and there. Some noteable changes between the CM4 & CM5 include & improved features/goals for the project include:

• Third mezzanine connector - this mezzanine breaks out a lot of stuff. I really am only interested in the DP/USB 3.0 lanes
• Stackup - I've changed my PCB to a 6 layer instead of a 4 layer that is signal - ground - power - signal - ground - signal instead of signal - power - gnd - signal. This way I should have more breathing room to route all of the high speed buses and reference planes . I did try on 4 layer but it was quite difficult
• PCIE 2.0 support - Unfortunately the CM5 does not have WiFi integrated onto the main SBC module, so I've opted to use an AX210 WiFi card which can support BT 5.3 and WiFi 6 from Intel. I've tested this already and it works fantastic with Linux with not much configuration needed. Getting it to fit was a bit of a pain but I think it can just squeeze in next to the fan! I'll need to source some decent antennas too!
• USB 3.0 - available from the SoC itself and will allow for USB 3.0 speeds out of Type-C
• Power - upgrade my 5v regulator to one that can support 15W of power (TPS61235) since the peak power draw of the CM5 is around 12W (3W overhead for other peripherals such as screen backlight, audio & controller)
• Controller - potentially porting the controller code from the ATMEGA32u4 to the RP2040 after my new knowledge gained from the docking project
• Audio - WM8960 i2s audio amplifier with headphone jack support
• DisplayPort - these are available from the SoC itself and now will make for easy video out of Type-C
• DisplayPort/USB 3.0 mux switch - this chip is to switch the DP/USB 3.0 lines where required and also handle the flip/orientation of the USB-C cable in case it is inserted upside down. I'm using the TUSB546 for this in GPIO mode, connected to the USB-PD controller
• Software - I still plan on using RetroPie, however this will be manually installed on top of a CM5 compiled linux kernel and device tree blob for Armbian to support my hardware. We will boot directly into EmulationStation when the console is turned on as there is likely to be no touch screen support I lied, there is now a touchscreen!
• Frontend - EmulationStation
• HDMI - still plan on keeping the HDMI mini port intact and available, as the RK3588s supports one HDMI TX channel
• Code porting - I need to port over my code from RPi to the CM5. This should be relatively straightforward as I've already found some GPIO libraries that work well, however the hardest part will probably be finding a GPU API like dispmanx that can support writing to the display for battery SoC and other info. I'm not sure exactly how I will solve this issue yet but I'll probably focus on it last
• USB OTG support - 5V out will be supported from the USB-C port to power external peripherals via the TPS65987D, which was lacking in my prior build which was really frustrating. This chip has built in MOSFETs and handles all of the power path switching internally, so its a pretty small footprint solution. It can either be controlled over i2c or can run standalone using a binary program stored on an SPI flash module. This also communicates to the display port mux in GPIO mode or I2C mode to let that muxer know that it needs to flip the signals. It also tells it whether we are in sink, source or DFP/UFP mode
• MIPI 5.5" support (720p resolution display) - integrating a MIPI 5.5" screen to mimic the real Switch Lite dimensions has been a goal of mine for a while (I honestly was a bit disappointed with the poor resolution for streaming games via moonlight) and I think I've figured out how to get it working. Unfortunately reverse engineering the switch lite panel is not something I would even know where to begin with so that isn't an option, but I've found a display that has a linux kernel driver based on the ILI9881C. This would also allow me to use regular switch lite screen protectors so I dont need to paint/buy expensive custom glass sizes
• Replacing the SD card slot with a proper spring loaded connector so it can be removed easily to swap out SD cards
• Keep compatibility with with my Retro Lite CM4 dock
• Gyro support/analog triggers (not sure if I will integrate these to be honest but, nice to haves!)

I have a test board that's currently on the way from JLCPCB (see below) to test the MIPI display (super basic 4 layer impedance controlled board). Touch screen integration would be nice, but I cannot find a symmetrical capactive bezel pre-glued to a 5.5" screen anywhere, so I will most likely not use touch. I don't really like Android anyway for gaming handhelds and EmulationStation doesn't support touch anyway (but it is nice for DS/3DS emulation).

I haven't really made a massive amount of solid progress yet to be honest, but slowly going to chip away at it for fun! But I'll be sure to keep everyone updated when I move forward. Let me know if you have any cool features you can think of!

Thanks for reading!

Check out the GitHub link below for all the details, code and CAD files:

GitHub - StonedEdge/Retro-Lite-CM5: An upgrade to the Retro Lite CM4 handheld, which uses the RK3588s compute module from Radxa.

An upgrade to the Retro Lite CM4 handheld, which uses the RK3588s compute module from Radxa. - GitHub - StonedEdge/Retro-Lite-CM5: An upgrade to the Retro Lite CM4 handheld, which uses the RK3588s...

github.com

 

[Adan]

This is wizardry. For the triggers maybe you could have a hall sensor and a tact switch at the end of the travel. I think that’s how DualShock controllers do it.

 

[StonedEdge]

This is wizardry. For the triggers maybe you could have a hall sensor and a tact switch at the end of the travel. I think that’s how DualShock controllers do it.

That may work (similar to a GC controller?), otherwise I am thinking of using some dual tact buttons similar to how it's done in portables. I think that would suffice too! There's nothing worse than using the LR as a half press and the LT triggers for a full press...

 

[CLAUDIO]

Hi guys,

I thought I'd start a new worklog to share progress updates on the Retro Lite CM5! (however slow they may be!).

I've decided that I want to re-design the Retro Lite PCB from the ground up to support the up and coming RK3588s compute module. With the new release of the Radxa CM5 coming this year, I would like to be able to upgrade my emulation handheld to be able to play GC/PS2 games at full speed, which obviously the Raspberry Pi CM4 cannot do with its poor GPU and lack of CPU cores. At the same time, there were a few flaws with the original design that didn't make a whole lot of sense/left a lot on the table, so I am hoping to at least improve the electronics side of things where I can!

I've ran some tests with the Orange Pi 5 (uses the same RK3588s SOC) and I've been able to get some great performance out of AetherSX2 under Linux with the Open GL ES 3.2 backend and mali blob panfrost drivers. Here it is running God of War at around 7-8W of total power at 2x resolution with minimal dropped frames in Arch Linux. Unfortunately the RK3588s doesn't support Vulkan drivers at the moment but I still think performance is good enough to create a great gaming handheld under Linux.

View attachment 28516

There's a lot of changes that need to be done to the new carrier board in order to integrate the CM5 module, but I'm hard at work trying to make improvements here and there. Some noteable changes between the CM4 & CM5 include & improved features/goals for the project include:

• Third mezzanine connector - this mezzanine breaks out a lot of stuff. I really am only interested in the DP/USB 3.0 lanes
• Stackup - I've changed my PCB to a 6 layer instead of a 4 layer that is signal - ground - power - signal - ground - signal instead of signal - power - gnd - signal. This way I should have more breathing room to route all of the high speed buses and reference planes . I did try on 4 layer but it was quite difficult
• PCIE 2.0 support - Unfortunately the CM5 does not have WiFi integrated onto the main SBC module, so I've opted to use an AX210 WiFi card which can support BT 5.3 and WiFi 6 from Intel. I've tested this already and it works fantastic with Linux with not much configuration needed. Getting it to fit was a bit of a pain but I think it can just squeeze in next to the fan! I'll need to source some decent antennas too!
• USB 3.0 - available from the SoC itself and will allow for USB 3.0 speeds out of Type-C
• Power - upgrade my 5v regulator to one that can support 15W of power (TPS61235) since the peak power draw of the CM5 is around 12W
• Controller - potentially porting the controller code from the ATMEGA32u4 to the RP2040 after my new knowledge gained from the docking project later on
• Audio - same WM8960 i2s audio amplifier with headphone jack support
• DisplayPort - these are available from the SoC itself and now will make for easy video out of Type-C
• DisplayPort/USB 3.0 mux switch - this chip is to switch the DP/USB 3.0 lines where required and also handle the flip/orientation of the USB-C cable in case it is inserted upside down. I'm using the TUSB546 for this in GPIO mode, connected to the USB-PD controller
• Software - I still plan on using RetroPie, however this will be manually installed on top of a CM5 compiled linux kernel and device tree blob for Armbian to support my hardware. We will boot directly into EmulationStation when the console is turned on as there is likely to be no touch screen support
• Frontend - EmulationStation of course
• HDMI - still plan on keeping the HDMI mini port intact and available, as the RK3588s supports one HDMI TX channel
• Code porting - I need to port over my code from RPi to the CM5. This should be relatively straightforward as I've already found some GPIO libraries that work well, however the hardest part will probably be finding a GPU API like dispmanx that can support writing to the display for battery SoC and other info. I'm not sure exactly how I will solve this issue yet!
• USB OTG support - 5V out will be supported from the USB-C port to power external peripherals via the TPS65987D, which was lacking in my prior build which was really frustrating. This chip has built in MOSFETs and handles all of the power path switching internally, so its a pretty small footprint solution. It can either be controlled over i2c or can run standalone using a binary program stored on an SPI flash module. This also communicates to the display port mux in GPIO mode or I2C mode to let that muxer know that it needs to flip the signals. It also tells it whether we are in sink, source or DFP/UFP mode
• MIPI 5.5" support (720p resolution display) - integrating a MIPI 5.5" screen to mimic the real Switch Lite dimensions has been a goal of mine for a while (I honestly was a bit disappointed with the poor resolution for streaming games via moonlight) and I think I've figured out how to get it working. Unfortunately reverse engineering the switch lite panel is not something I would even know where to begin with so that isn't an option, but I've found a display that has a linux kernel driver based on the ILI9881C. This would also allow me to use regular switch lite screen protectors so I dont need to paint/buy expensive custom glass sizes
• Replacing the SD card slot with a proper spring loaded connector so it can be removed easily to swap out SD cards
• Keep compatibility with with my Retro Lite CM4 dock
• Gyro support/analog triggers (not sure if I will integrate these to be honest but, nice to haves!)

I have a test board that's currently on the way from JLCPCB (see below) to test the MIPI display (super basic 4 layer impedance controlled board). Touch screen integration would be nice, but I cannot find a symmetrical capactive bezel pre-glued to a 5.5" screen anywhere, so I will most likely not use touch. I don't really like Android anyway for gaming handhelds and EmulationStation doesn't support touch unfortunately



View attachment 28517

View attachment 28515
View attachment 28518

I haven't really made a massive amount of solid progress yet to be honest, but slowly going to chip away at it for fun! But I'll be sure to keep everyone updated when I move forward. Let me know if you have any cool features you can think of!

Thanks for reading!

View attachment 28529

Amazing!

 

[StonedEdge]

My 5.5" MIPI display arrived and I'm looking forward to getting it working soon. The bezel was actually symmetrical which is great news - this finally means I can have a fully touch integrated display now and a fully laminated display without messing around trying to do it myself with LOCA gel and other messy bits. The driver boards also arrived so I just need to wait to get the components to populate the boards - mainly its just a backlight and some connectors which route the screen data lines to the correct pins on the Orange Pi 5 for testing. I also managed to set up RetroPie last night pretty easily - there's a couple of tricks I needed to do to get the Mali blob drivers working (which perform better than Panfrost at the moment for gaming purpose) for PS2 in Wayland/X11 but I think I've figured that out now. PanVk drivers are being worked on but it may take years for those to develop (more likely to get a proprietary Vulkan blob before that) but for now the performance is good enough

Old display (5") - 800 x 480p vs. new display (5.5") - 720 x 1080p! I need to draw this up in CAD however from first glance it seems to fit vertically however the buttons are probably too close to the bezel horizontally, so I am thinking of making the handheld just a bit wider (this will be needed anyway to fit the screen internally). I think it looks far better and will be better for streaming/more modern games

Now with touch! Using the GT911 touch driver over I2C - this shouldn't be too difficult to get working

Custom driver board PCBs - rev 1

Some more GoW testing - 2x resolution however 1.5x seems to be the max for a stable frame rate

 

[StonedEdge]

Currently working on the CAD! I've made the whole case slightly wider to accommodate the bigger screen, moved all the necessary parts around and have switched to 0.8mm PCBs instead of 1.6mm so I can maintain the same thickness, as the new capacitive touch panel is actually 1.1mm thick instead of the previous method I used which used 0.7mm glass. I also finally put in an SD card slot that is spring loaded. I've also added in an AX210 WiFi card which is connected over PCIe. It was a tight fit but I've just made work, but I still am searching for some antennas to use. Open to recommendations if anyone has any suggestions! I also plan to replace the FFC connectors with ZIF style flip lock connectors instead of the sliding lock ones which I find in general are just more fiddly.

I also realized that the Orange Pi 5 I am using for testing does not break out all of the required I2S bus for digital audio, so I've hacked in my own solution for testing (the bus is actually taken by the onboard DAC and they don't break out any of the other I2S buses available on the GPIO pins). I plan on continuing to use the WM8690 as there is a linux kernel driver available for it and I've already got it working on the previous handheld (I also think the sound is plenty loud enough).

I2C5_SDA/UART1_RX/GPIO1_B7_J = I2S N/A
I2C5_SCL/UART1_TX/GPIO1_B6_J = I2S N/A
UART0_TX_M2/GPIO4_A3_J = I2S N/A
UART0_RX_M2/GPIO4_A4_J = I2S N/A
SPI4_MOSI/UART3_TX/GPIO1_C1_J = I2S N/A
SPI4_MISO/UART3_RX/GPIO1_C0_J = I2S N/A
GPIO2_D4_P = I2S N/A
SPI4_CS1/GPIO1_C4_J = I2S N/A
PWM1/GPIO1_A3_J = I2S N/A
PWM15_IR/GPIO1_C6 = I2S0_LRCLK
SPI4_CLK/GPIO1_C2_J = I2S0_MCLK
I2C1_SDA/UART4_RX/GPIO1_D3_J = I2S0_SDI1
I2C1_SCL/UART4_TX/GPIO1_D2_J = I2S0_SD03/I2S0_SDI2
CAN1_RX_M1/GPIO4_B2_J = I2S1_SDO1_M0
CAN1_TX_M1/GPIO4_B3_J = I2S1_SDO2_M0
CAN2_RX/GPI00_D4_J = I2S1_SDO2_M1
CAN2_TX/GPIO0_D5_J = I2S1_SD03_M1
UART2_TX_M0/JTAG_TCK_M2 = I2S1_MCLK_M1
UART2_RX_M0/JTAG_TMS_M2 = I2S1_SCLK_M1

I should have more updates in the coming weeks hopefully of a working display & audio solution as all the parts are almost here for the driver board. After that, it's time to start porting the Retro Lite CM4 code to the RK3588s & continuing to work on the main carrier board design, which I suspect will take a couple more months to finalize. I'll probably order them from JLCPCB and make them by hand to start before I do any turnkey assembly

 

[StonedEdge]

Still a fair way to go but I am getting there. I've populated my test driver board for the Orange Pi 5 and got the backlight working. Next step is to get the MIPI drivers integrated into the Armbian device tree blob and do some testing. I should be able to have that done by this week.

The TPS65987D is a really nice chip to use and has its own GUI tool you can use to generate a binary to flash via SPI. I think for Wii portables it's definitely overkill but for what I want to do I think it's a really nice addition. I am going to use a Raspberry Pi Pico to flash the module as it seems really easy to set up and get working (RP2040 pulls through yet again).
https://github.com/stacksmashing/pico-serprog

All of the registers are easily accessible and editable from the GUI tool. I'm going to run the PD controller in GPIO mode, which is predominately used for toggling the high speed mux orientation/flip mode, USB3/DP active modes, etc. There is also some other neat GPIOs functionality, such as identifying which PDO contract has been negotiated. I've put some debug LEDs on the board to show the user what mode we're in. There's a priority mode register byte you can alter which also allows the user to select whether the controller prioritizes watts, volts or current during the PD contract negotiation. Pretty neat stuff.

The PCB is coming along nicely! I've got about 100 air wires left to go, then it will be running a DRC check and checking for any schematic errors before placing my order. I've made a lot of changes vs. the CM4 board and a lot of the pinout is not even electrically compatible with the CM4 which has required me to essentially make a new board entirely from scratch! So much for a drop-in replacement...

The OS will now be stored on an eMMC module (I picked one of these up for $15 on AliExpress) and the games/Retro Lite CM5 firmware will be stored on the SD card. Unlike the CM4, the RK3588s has the ability to use both an eMMC and an SD card. This just makes things a bit more modular if I want to port the games across to another handheld or potentially dual boot into Linux and Android. They're really cheap!

 

[StonedEdge]

Not a huge update for everyone but a couple of new CAD shots after integrating the new PCBs. It doesn't look like much has changed yet but I'm still working on the following changes:

• Integrating original switch lite buttons to reduce costs. This includes trigger and shoulder buttons. Yeah this didn't happen
• Integrating the original volume/power flex PCB as the switch lite uses. This is just another off-the-shelf part that makes the whole assembly less of a pain
• Finalizing the final PCB design (the carrier board is now done, yippee!) - included an RTC module & 1225 coin cell for keeping track of time. This was a feature that was lacking in the CM4 and meant I couldn't integrate some features into my dock without it (such as tracking how often games are played, duration played, etc).
• Controller board redesigns - now includes an IMU module for 6-axis gyro (mainly for game streaming in games like Zelda TOTK or FPS games). This connects to the ATMEGA32u4 over I2C. Now it uses an RP2040, far cheaper and better! In general I re-did these boards from scratch and still am changing the shape of them
• Search for a slightly wider battery but slightly thinner (so as to not press on the display)
• Dual tact buttons - now integrated into the rear triggers. Thankfully I had enough IO for all of the digital buttons (nothing left now!). Fake it till ya make it (no analog unfortunately)
• eMMC module now integrated. I routed these using 50 ohm single ended traces and made sure they had decent spacing. The clock speed only goes up to 200MHz so I dont think it'll be overly critical but we'll find out soon This also didn't happen - Radxa now offer pre-soldered eMMC modules, which in my opinion is a downgrade.
• Better fan? I am looking for something bigger and less noisy but haven't found much yet (45x45x5mm is still quite large but I might be able to make it work with a redesign of the heatsink). As you can see it doesn't currently fit as it is but it is in my opinion a needed upgrade due to the noise of the old one

The MIPI driver integration is giving me a few headaches at the moment as well, but hopefully, I'll have a photo of it being driven in the coming days. Checking the Ilitek driver code, the DSI initialization is not matching for the panel I am using, so currently tweaking that atm.

There is also no CM5 STEP file available at the moment so I borrowed the CM3 footprint from Radxa & ensured that the 3rd connector lines up accurately.

That's all for now but making some good progress! I really like the look of the new display.

 

[StonedEdge]

I have my MIPI display working over the DSI bus with the Orange Pi 5 for testing. The driver is already in the Linux kernel (ILI9881C) so all it requires was edits in the structure for the display timings and initialization commands, then recompiling the kernel I used. I also printed a test housing to see how my measurements stacked up and to my surprise, it fit first try. I think it looks pretty good, definitely better than the old one. Hopefully with a black machined case it will be less noticeable.

Next steps is to get it working on the CM5 board and then focus on getting audio drivers working. Then it’s over to porting the CM4 code to the CM5.

@Wesk also kindly provided me with a scan of the switch lite fan, which I plan on integrating into this build (provided it fits)! Thanks man.

 

[OpenCompute]

Great stuff, and the Retrolite CM4 is an amazing project as well!

I am also interested in building my own handhelds, and I have one question regarding the upcoming Radxa CM5 module (and sbcs in general). Does the CM5 support quick sleep/wake-up from low power like modern battery operated devices?

For some reason, Sleep mode has been off the radar for a lot of sbcs, if not most (Especially on the raspberry pi forums, where every engineer seems to say that having mobile like sleep is something very difficult to implement). Yet, any cheap mobile device is able to do it.

What are your thoughts here, and how do you suggest we can work around this limitation? Thanks!

 

[StonedEdge]

Great stuff, and the Retrolite CM4 is an amazing project as well!

I am also interested in building my own handhelds, and I have one question regarding the upcoming Radxa CM5 module (and sbcs in general). Does the CM5 support quick sleep/wake-up from low power like modern battery operated devices?

For some reason, Sleep mode has been off the radar for a lot of sbcs, if not most (Especially on the raspberry pi forums, where every engineer seems to say that having mobile like sleep is something very difficult to implement). Yet, any cheap mobile device is able to do it.

What are your thoughts here, and how do you suggest we can work around this limitation? Thanks!

Thanks very much! I don't think the BCM2711 or any other Pi SoCs support sleep/wake commands - it needs to support it in hardware and I don't think any of the Broadcom SoCs did.

There is a method though for the RK3588 (and sleep mode did work well on the RK3399 as well). I don't think its a true hibernation mode as it doesn't dump RAM to flash, but it's far better than what the Pi has available to it and should allow for a sleep mode function via GPIO toggle.

&rockchip_suspend {
    compatible = "rockchip,pm-rk3588";
    status = "okay";
    rockchip,sleep-debug-en = <1>;
    rockchip,sleep-mode-config = <
        (0
        | RKPM_SLP_ARMOFF_DDRPD
        )
    >;
    rockchip,wakeup-config = <
        (0
        | RKPM_GPIO_WKUP_EN
        | RKPM_USB_WKUP_EN
        )
    >;
};

I will come back to you once I have tested it out!
I'm currently focusing on assembling the new CM5 test PCBs for the controller IMU & MIPI display for now and then I will connect a button to see if we can sleep/wake the SoC.

 

[Nold]

damn man, how did somebody say.. "you really leveled up your game" man. looks absolutely insane!

 

[OpenCompute]

Thanks very much! I don't think the BCM2711 or any other Pi SoCs support sleep/wake commands - it needs to support it in hardware and I don't think any of the Broadcom SoCs did.

There is a method though for the RK3588 (and sleep mode did work well on the RK3399 as well). I don't think its a true hibernation mode as it doesn't dump RAM to flash, but it's far better than what the Pi has available to it and should allow for a sleep mode function via GPIO toggle.

&rockchip_suspend {
    compatible = "rockchip,pm-rk3588";
    status = "okay";
    rockchip,sleep-debug-en = <1>;
    rockchip,sleep-mode-config = <
        (0
        | RKPM_SLP_ARMOFF_DDRPD
        )
    >;
    rockchip,wakeup-config = <
        (0
        | RKPM_GPIO_WKUP_EN
        | RKPM_USB_WKUP_EN
        )
    >;
};

I will come back to you once I have tested it out!
I'm currently focusing on assembling the new CM5 test PCBs for the controller IMU & MIPI display for now and then I will connect a button to see if we can sleep/wake the SoC.

Thanks for the updates! Looking forward to how this unfolds and wish you luck to complete this smoothly and swiftly!

 

[StonedEdge]

A brief update:

I2S audio HAT now is playing sound via Alsamixer so can confirm this one works with the CM5 too.
Using the stock kernel driver, an overlay, pins 3/5 for I2C, pins 19/23/24 for SCLK/LRCK/SDO - I2S now works! Hell yeah.

For those interested, here is the required device tree overlay you'll need:

/dts-v1/;
/plugin/;

/ {
    metadata {
        title ="Enable WM8960 HAT on I2S-1 bus on Rock 5A";
        compatible = "radxa,cm5-io";
        category = "misc";
        description = "Enable WM8960 HAT on I2S-1 bus on Rock 5A";
    };

    fragment@0 {
        target = <&i2s0_8ch>;
        __overlay__ {
            status = "disabled";
        };
    };

    fragment@1 {
        target = <&i2s1_8ch>;
        __overlay__ {
            status = "okay";
            rockchip,i2s-tx-route = <1 0 2 3>;
            rockchip,i2s-rx-route = <0 1 2 3>;
            pinctrl-names = "default";
            pinctrl-0 = <&i2s1m0_sclk
                &i2s1m0_lrck
                &i2s1m0_sdi0
                &i2s1m0_sdo1>;
        };
    };

    fragment@2 {
        target = <&i2c7>;
        __overlay__ {
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&i2c7m2_xfer>;
            #address-cells = <1>;
            #size-cells = <0>;

            wm8960: wm8960@1a {
                compatible = "wlf,wm8960";
                reg = <0x1a>;
                #sound-dai-cells = <0>;
                AVDD-supply = <&vcc5v0_sys>;
                DVDD-supply = <&vcc_3v3_s3>;
            };
        };
    };

    fragment@3 {
        target-path="/";
        __overlay__ {
            wm8960_mclk: wm8960-mclk {
                compatible = "fixed-clock";
                #clock-cells = <0>;
                clock-frequency = <24000000>;
            };
        };
    };

    fragment@4 {
        target-path = "/";
        __overlay__ {
            wm8960_sound: wm8960-sound {
                status = "okay";
                compatible = "simple-audio-card";
                simple-audio-card,format = "i2s";
                simple-audio-card,name = "wm8960-soundcard";
                simple-audio-card,mclk-fs = <256>;
                simple-audio-card,widgets =
                    "Microphone", "Mic Jack",
                    "Line", "Line In",
                    "Line", "Line Out",
                    "Speaker", "Speaker",
                    "Headphone", "Headphone Jack";
                simple-audio-card,routing =
                    "Headphone Jack", "HP_L",
                    "Headphone Jack", "HP_R",
                    "Speaker", "SPK_LP",
                    "Speaker", "SPK_LN",
                    "LINPUT1", "Mic Jack",
                    "LINPUT3", "Mic Jack",
                    "RINPUT1", "Mic Jack",
                    "RINPUT2", "Mic Jack";
                sac_cpu: simple-audio-card,cpu {
                    sound-dai = <&i2s1_8ch>;
                };
                sac_codec: simple-audio-card,codec {
                    sound-dai = <&wm8960>;
                    clocks = <&wm8960_mclk>;
                    clock-names = "mclk";
                };
            };
        };
    };

    __overrides__ {
        alsaname = <&wm8960_sound>,"simple-audio-card,name";
        compatible = <&wm8960>,"compatible";
        master = <0>,"=2!3";
    };
};

I am now working on the USB-C power management & dual role port shenanigans.
I decided to make a test PCB this time, as I don't want to order an expensive large 6 layer 0.8mm PCB and have it not work first go. Slow and steady.

It is coming along and hope to finish it off this weekend before placing an order on Sunday Excited to finally get DisplayPort out of USB-C in a project, as well as dual role port functionality.

Moving back to the DSI topic, I am geting a vblank kernel panic error with the default ilitek,ili9881c panel driver.
I also discovered this on the Orange Pi 5, so I think I just need to use a different driver that I have confirmed worked last time (panel-innolux-afj101-ba2131.c instead of the default one).

I'll make another post once I have DSI working with the CM5 IO board.
Also, the CM5 now has onboard eMMC, which I plan to flash with a bare bones version of Armbian for testing for now. eMMC no longer is on the carrier board since Radxa made a new revision since X1.2 (I now have X2.0 & they have another X2.1 in the works).

The nice thing about the CM5 is that you can have both eMMC and SD storage, unlike the CM4 which only has one or the other available to it. Bonus!

For now, focus is on testing the USB-C PD/DRP and once thats done, finalizing the CM5 IO board before I place an order

Oh, and the new controller PCBs came in with the MPU-6050 module. I also integrated official switch lite speakers this time with little JST connectors. Thanks to @YveltalGriffin for finding the right part (screwed up and had to make some bodges on the I2C lines, oop)

 

[GinKage]

Player 2 joined the game!

I've been helping with the project only a little bit so far, but now I'm fully on-board.

I'm not as well-versed in hardware design, so my focus will be on the side of Linux/Armbian bring-up, device tree changes, drivers and other software shenanigans.

For example, we now have DSI working, see the attached patch for the stock ili9981c driver that made it work.

 

[StonedEdge]

Touch now works with the GT911 IC.

Looking forward to trying out some DS emulation with touch! The sensitivity is a little bit poor at the moment though, so we hopefully can make it a bit more touch sensitive to user input. Please ignore the audio popping, that was just me playing around with alsamixer.


Here’s a look of the old screen next to the new one:

 

[Stitches]

Damn, I might have to get me one of these to play Pokemon Ranger on

 

[Nold]

Damn nice work guys, hope you put some of there files/changes on github or bring it upstream

 

[StonedEdge]

Brief update - v1.0 of the test PCB is now finalized and I have an order in my cart with JLCPCB for their assembly services for this 6 layer board.

Some of the parts they don't have in stock, so I am going to ask them if they can source them separately and place them (since the parts are in their library but not currently in stock, there might be some possibility they can still solder them for me). Otherwise, I may just have to do those few missing parts myself by hand.

Here's how the test board turned out The price was relatively reasonable, around $220 for 5 6 layer 0.8mm PCBs with their 06081H-2216 6 layer impedance stackup for 2 fully assembled boards (minus a few missing parts).

The main purpose of the board is to accept in USB 3.0/2.0 and DisplayPort from the carrier board and spit them out the other end via the DRP port at the bottom. U1 is the TPS65987D and is used to do all of the switching shenanigans for the power paths for sinking and sourcing power, either from the charger or the 5V regulator on the board & negotiating a PD contract (I put some LEDs on the board there to identify which voltage PDOs are succesfully negotiated from the charger). The board also will be used to test how much more efficient powering from battery will be vs. the 5V regulator - capable of 3.5A output. If we can make some power saves there, all the better - I'm quite keen to hook it all up & see how much more power it draws vs. a CM4 - will update once I get the boards in hand

GinKage is working hard on the controller at the moment and we are still figuring out the best way to implement our gyro controls - I will let him update when the time is right!

 

[StonedEdge]