Anycubic Kobra 2 Max. Workaround Feasibility Question

General Discussion
1

Basic Information:

Printer Model: [Anycubic Kobra 2 Max]
MCU / Printerboard: Allwinner R528
Host / SBC N/A
klippy.log N/A

Describe your issue:

Kobra 2 Max/Pro/Plus workaround feasibility for the R528 “app” & HIFI4 DSP problem

My question:
I see the the effort to reverse engineer the Kobra 2 Max/Pro/Plus motherboard seem to slowed considerably; apparently due to the cryptic APP and its use of the HIFI4 DSP as onboard klipper mcu.

I have a question for the Klipper gods as regards to the feasibility of an idea that would allow the stock mb to be used without reverse engineering the APP or the DSP. My idea is to use the stock motherboard as a “dumb” linux-process mcu that only runs Klipper to create a linux-process mcu that can be controlled by an external sbc (e.g. Rpi Zero 2 W) .

  1. Is such a thing feasible? Can a Klipper linux-process mcu be controlled by an external sbc?
  2. Can vanilla Klipper be installed on the Tina Linux OS that currently resides on the R528 (bypassing the “app” and the DSP)?
  3. Does Klipper “have to be” installed on Debian Linux?
  4. Anycubic has released its source code for the Kobra 3 (not the Kobra 2 Max/Pro/Plus) GitHub - ANYCUBIC-3D/Kobra3 which is a set of Linux-Kernal, Linux-Uboot and Klipper files that has sunxi and sun8i (which is what R528 is part of) compatible files within. Although I don’t know what flavor of Linux that is.

The whole idea is to bypass the mysterious “app” and the inaccessible DSP and just have the core of the R528 act as a regular mcu and have it controlled by an external Rpi without having to do any reverse engineering and without having to do a low-level port of Klipper.

I don’t mind experimenting on my Kobra 2 Max but I would need the answers to the above questions before I descend into this rabbit hole.

2

As far as I know. No. You would need to interface with the DSP I think? To be honest not many have talked a lot about it.

To install klipper you would still require to install a klipper.bin file I believe?

I assume this file would be compiled to the DSP I think? I’m not too sure but that’s what I think. I may be wrong but I don’t really know.

And nobody have tried to reverse engineer the DSP protocol.

To be honest doing that would be harder than just manufacturing your own 3D printer from used parts or something like that.

You would be better off replacing the board in that case.

Without the app the DSP wouldn’t work. It is responsible for talking to the DSP using rpmsg and initializing it or something similar to that.

The best you can do is to fool the printer with the MQTT protocol to send custom commands. That’s as much as you can do I think.

You would need a kernel expert Linux developer with an engineer who understands the DSP to even be able to reverse engineer a DSP.

And to get the SDK one would need a really expensive which no one can afford license you would also be needed to be a valid business. And there is no illegal version either because the code thing is server side based. Trust me I’ve already tried looking for that on Chinese forums.

Though that one DarkSimpson guy mention we could use gcc or something but that’s wayy wayy beyond my capabilities.

The Linux is based on Tina-Linux.

3

But I guess if you know electrical things and engineering you may be able to just remove the board entirely and screen and connect wires or using external board. Example can be found here Mainboard - Kobra2Pro Insights on how to replace the board.

4

Let us consider what the goal is and what is the path of least resistance/effort to achieve that goal.

  1. Would the “ideal” goal be to reverse engineer AC’s rewritten/compiled version of Klipper (i.e. the mysterious “app”) and how it communicates with inaccessable HiFi4 DSP which appears to act as the klipper “mcu” ? I’m not sure what are the Pros and Cons? In the past I have tried to re DSP code. It is an entirely different animal with an entirely different instruction set that is very esoteric and with a steep learning curve. This path is only for someone who wants to learn this stuff or for someone who already has the knowledge. How or why AC took this approach is beyond me but very cool none the less.

  2. Or would the goal be to get install Debian or Armbian and then install a regular Python based version of Klipper that we all know and love. But then what?

  3. Or would the goal be to add Klipper support for the Allwinner R528 as an mcu. That way a “traditional”/“normal” Klipper conversion can be done. Which may not be as far fetched as it may first appear because of something I discovered last night, which is:

    BigTreeTech CB1 Rpi board uses a Allwinner H616 to run Klipper on an Armbian Linux!

    Yes it’s true.

    I gets even better. BTT has instructions on how to get Uboot (a embedded Linux bootloader) installed via USB from a Windows machine! Yes it’s true. GitHub - bigtreetech/CB1: OS System image for CB1

If BTT was able to support for an Allwinner processor, well, I think it’s a good sign.

BUT (big BUT) what then? So, say we’re able to get the R528 to act like BTT’s CB1…what do you have? A Raspberry pi. (see #2 above). Being able to run a Klipper “host” on a R528 is NOT the goal. We want/need to be able to use the R528 as a dumb client “mcu”

HERE ARE THE QUESTIONS…*

  1. Does being able to run Klipper on a given processor (the Allwinner H616 in the BTT’s CB1) “automatically” mean it is, somehow, supported as a Klipper mcu? I can’t answer that. That is one for the Klipper gods. I posted that question on the discord, hoping Sineos would be able to answer. No answer yet.

  2. Now one can user a second instance of Klipper on the HOST Rpi to create a “virtual” or “secondary” mcu known as a “linux-process” ( RPi microcontroller - Klipper documentation ). If we were able to setup the R528 as a Rpi, can we set it up as strictly as a “linux-process” mcu ( Beaglebone - Klipper documentation ); can a Klipper HOST Rpi control that “linux-process” mcu as a dumb client mcu? In other words, Can an “external” Rpi running as a Klipper host use the “linux-process” secondary mcu running on a different Rpi?

We would need the answers to these two questions before proceeding. I’ve only been in this thing for about 48hrs, so I don’t know who knows what or who to ask.