Support unmodified mainboard

[The-Synthax]

Stock mainboard can be supported by running Klipper, Mainsail, and Fluidd off of the original Mediatek MT7688 running a somewhat modified OpenWrt installation. This requires a good understanding of Linux. This could be done in one of three ways.
Method 1 [best method]) Create a USB installer that updates the kernel to the latest (older FlashForge kernel can't run Klipper) and installs KlipperWrt while disabling all of the FlashForge start scripts except the updater script, so that any update USB can revert the printer to stock. Flash the MCU and print away. (best method)

Method 2 [2nd best]) Connect to the MT7688 via serial UART and manually disable FlashForge's start scripts after updating to the latest firmware. Fix the OpenWrt installation and add KlipperWrt's distfeeds. Install KlipperWrt manually, then flash the MCU.

Method 3 [not recommended]) Gain SSH access via CrashForge, then manually install everything the same way as method 2. Harder to unbrick than method 2.

EDIT: nope. Not enough RAM, but we can get around needing to modify the mainboard by connecting the Pi via ethernet instead of serial.

[dJOS1475]

Howdy, I'd love to change my AD3 over to Klipper (I currently run it on my main printer SKR2 powered and heavily modified Mega Zero v1.0).

Method 1 would be ideal - how close are we to being able to do this?

[The-Synthax]

Howdy, I'd love to change my AD3 over to Klipper (I currently run it on my main printer SKR2 powered and heavily modified Mega Zero v1.0).

Method 1 would be ideal - how close are we to being able to do this?

Not terribly far off from the experimenting I did before deciding to just oust the MediaTek chip in favor of the Pi. I know it needs its init scripts changed so the boot process and networking works without starting the Finder binary. The STM32 can likely be flashed using the script in the original firmware's folder. Someone will need to look into how the original LCD GUI is working and get something like KlipperScreen working. The startup script checks for an update USB at boot time but I'm not sure if it does any checks. If so, however CrashForge is getting around those checks can be used to inject our own script to do all the initial setup. It'll likely be limited to a certain version window because updates to the firmware by FF could break the scripts and require a new version. Lastly, I'm unsure if the original CPU can handle Klipper, though I'm fairly confident it can, but there's no way OctoPi would run as it is far too heavy compared to Mainsail+Fluidd.

First someone will need to get it set up with UART and write a script that follows the steps they did to automate the process.

[dJOS1475]

Awesome, if you'd like me to test I'm happy to help out. I dont mind risking my unit as it's my "backup" printer and if it goes very badly wrong I'll just have to replace the main board with a Mellow Fly. 🤣

PS, I considered the Pi option but they are nearly impossible to buy atm.

[The-Synthax]

Awesome, if you'd like me to test I'm happy to help out. I dont mind risking my unit as it's my "backup" printer and if it goes very badly wrong I'll just have to replace the main board with a Mellow Fly. 🤣

I originally was just going to throw in a new board entirely but felt bad at wasting good TMC2209s 😋

[dJOS1475]

Yeah I hear you - the HW is great but the FW is very meh!

If I do keep the OEM main board, running pure Klipper (eg WRT) would be ideal - Im not a fan of octoprint as it's bloatware imo.

[dJOS1475]

PS. I was planning to make an adapter PCB board to allow the easy swap in of a RepRap Fly board - unfortunately I just havent had the time to map out the FlatFlex pinouts etc

[The-Synthax]

PS. I was planning to make an adapter PCB board to allow the easy swap in of a RepRap Fly board - unfortunately I just havent had the time to map out the FlatFlex pinouts etc

I've mostly mapped out the flex, but not entirely. I didn't spend enough time on it to figure out how the LED is connected, but now that I have it running Klipper it'd be easy enough to just enable things one-by-one and measure which pin has voltage. I think making some adapter boards and firmware mods for these printers would really breathe a lot of life into quite a few machines that would otherwise become e-waste.

[dJOS1475]

Agreed, mine just doesn’t get used ATM due to the horribly inaccurate bed leveling. I’m hoping Klipper will solve that issue as the “paper test” in Klipper has much more precise z axis control than the Flashforge firmware.

Btw I bought a PEI spring steel bed for it mine which would be awesome for printing ABS+ if I could get the bed mesh sorted.

https://a.aliexpress.com/_mM14t4W

[The-Synthax]

Agreed, mine just doesn’t get used ATM due to the horribly inaccurate bed leveling. I’m hoping Klipper will solve that issue as the “paper test” in Klipper has much more precise z axis control than the Flashforge firmware.

Btw I bought a PEI spring steel bed for it mine which would be awesome for printing ABS+ if I could get the bed mesh sorted.

https://a.aliexpress.com/_mM14t4W

Yeah, without a probe it's still not as good as I'd like it, but maybe that's just me. My theory is that it's somewhat due to backlash, but I believe Klipper's manual leveling "bounces" between moves to prevent inaccuracies caused by backlash. I got mine pretty good and then edited the mesh by hand doing a few first layer tests until it was nearly perfect across the entire bed.

(excuse the ugly base plate, I rescued this printer from eBay in pretty bad/rusty condition)

[dJOS1475]

Wow, that’s massively better than what I’ve been getting out of mine!

[Borillion]

Sorry to bump this if its necro/abandoned. I have one of these that I was able to get SSH access into using a reverse shell, by pulling and modding the scripts off of a usb firmware update.

I assume I have to start by pulling the device tree and kernel configuration off after updating to the newest firmware.

Not too familiar with building openwrt willing to give it a good try but will need someone to discuss the process with.

When printing it seems to write to some /sys/kernel/ pinctrl devices. So far i'm just poking dangerously and playing with strace/ptrace and the qtlib qui.

[Tasshack]

I have got a Arçelik PT1000 last week thinking that it is another rebrand of the Adventurer 3 but suprisingly enough it has some differences like a newer revision of the main board and a different heat plate (looks like Adventurer 4 bed but smaller).
Most importantly it has OpenWRT 18.06.4 installed with the 4.14.131 kernel and i cannot install the official firmware because of that (They have used hucl to compile the main exetuable instead of uclibc).
I can share the whole disk image in exchange of a disk image from the official model so i can install the flashforge software and you can try to install the KlipperWRT on 4.14.131 kernel.

[The-Synthax]

I have got a Arçelik PT1000 last week thinking that it is another rebrand of the Adventurer 3 but suprisingly enough it has some differences like a newer revision of the main board and a different heat plate (looks like Adventurer 4 bed but smaller). Most importantly it has OpenWRT 18.06.4 installed with the 4.14.131 kernel and i cannot install the official firmware because of that. I can share the whole disk image in exchange of a disk image from the official model so i can install the flashforge software and you can try to install the KlipperWRT on 4.14.131 kernel.

Can you share a high resolution clear photo of the mainboard? If the hardware isn't supported by FF's firmware it won't work even if you get it to install. It probably won't install Adventurer firmware because their update mechanism either works differently or checks the update USB before applying it. If you can get Crashforge to run on it, it should be quite easy to force install the Adventurer firmware. Why do you want Flashforge's firmware anyway, does it have features the stock firmware doesn't?

[Tasshack]

If the hardware isn't supported by FF's firmware it won't work even if you get it to install.

I don't think hardware is not supported, it is just the kernel.

If you can get Crashforge to run on it, it should be quite easy to force install the Adventurer firmware.

OpenWRT dropped support for uclibc and because of that Flashforge engineers used different toolchain for compiling the main executable on my device. I can force install it but the main executable wont run because the c library is different on my machine because of the kernel difference

Why do you want Flashforge's firmware anyway, does it have features the stock firmware doesn't?

My firmware does not support new nozzle which means i stuck with pla also it does not have 9 point calibration. Device does not have a camera therefore my firmware does not have stream capabilities even i buy the official camera and plug it myself.
And most importantly my device requires its own branded filament and checks the used/remainin filament through rfid.

Can you share a high resolution clear photo of the mainboard?

I wil open the case and the the photos when i am available later today.

[Tasshack]

On my device
finder-rush-mips: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked, interpreter /lib/ld-musl-mipsel-sf.so.1, not stripped

On the official firmware
finder-rush-mips: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked, interpreter /lib/ld-uClibc.so.0, not stripped

[The-Synthax]

Probably doesn't have a camera to free up the USB header for the RFID reader. If you want to flash a different kernel, your best bet is to either use a SOIC clip on the NOR flash on the Mediatek board, or flash it by accessing U-boot's boot menu via serial, if the boot menu is enabled on the bootloader they are using. I'd recommend using serial if you can.

[Tasshack]

Probably doesn't have a camera to free up the USB header for the RFID reader.

Actually camera header is empty and rfid is connected to the STM32(GD32) on the board. It does not have a camera to just cut the cost of the machine like on the Adventurer 3 Lite.

If you want to flash a different kernel, your best bet is to either use a SOIC clip on the NOR flash on the Mediatek board, or flash it by accessing U-boot's boot menu via serial, if the boot menu is enabled on the bootloader they are using. I'd recommend using serial if you can.

I know how to flash but i don't have the rootfs for the older kernel so i am looking for people who are willing to share a system image.

[Tasshack]

@VioSynthax there are the board pictures that you asked for. I am not sure all adventurers are built this way but there are a lot of cable management involved on mine, so i cannot get the board out easily. You find the rfid socket next to the serial port.

This the heatbed of my device, it looks very much like on the Adventurer 4 but it has 20x20 version of this design.

This is actual glass, not metal like on the original Adventurer models.

[hw-lunemann]

Hey I'm back! Sorry for not getting back to this or updating on my progress.
I have long given up on getting klipper to run on the embedded mediatek board and haven't really worked on it anymore either. It simply doesn't have enough ram to make it fit. That would definitely been nice though but even if it did fit, the CPU is also very slow and could have supported tectnoically slow printing speeds.

Good news is that I started work on figuring out how to flash the STM32 without connecting a Pi or soldering, and I'm happy to report that I have been successful! This method doesn't need anything but a computer and an USB stick. The only problem is that I have modified the OS on the printer significantly along the way and the "stock" backup I had from earlier this year isn't exactly stock either. So it would be tremendously helpful if one of you guys could share a stock dump of the 8gb eMMC that contains the OS so I can make this reproducible for anyone.

root@FlashForge:~# stm32flash /dev/ttyS1
stm32flash 0.4

http://stm32flash.googlecode.com/

Interface serial_posix: 57600 8E1
Version      : 0x10
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0414 (High-density)
- RAM        : 64KiB  (512b reserved by bootloader)
- Flash      : 512KiB (sector size: 2x2048)
- Option RAM : 16b
- System RAM : 2KiB

This all might seem somewhat useless as you currently need to solder to the mainboard anyways to connect the Klipper host and the MCU. However, I believe that I've also figured out how to solderlessly connect an external Klipper host to the mainboard while also retaining full control of the mediatek SoC's preinstalled operating system, screen and touchscreen.
This part still needs some testing but if it works well enough we could potentially utilize the screen for basic info. Though that would require a custom solution much more basic than something like KlipperScreen. Reverting back to stock or just the stock MCU firmware/host combo would also be possible without any hardmods this way. It doesn't even require us to flash a custom bootloader!

I will share more when I've run some tests. :)

[hw-lunemann]

On another note, this sort of approach probably works on any adventurer printer up to and including the Adventurer 5M Pro. I can't test any of them though since I only have the adv 3.

[The-Synthax]

CPU is just barely fast enough for Klipper, it's the same MediaTek MT7688AN as Creality WiFi Box which manages to run Klipper at an okay enough speed. This printer was never going to be capable of terribly fast printing anyway due to the extruder issues. RAM is almost certainly an issue, but it may be possible to strip down OpenWRT even further and just barely fit Klipper in. Not the best solution though, even if it works. It could definitely handle Marlin on unmodified hardware, with the MediaTek board hosting a web interface and powering the display and touch interface.

As for doing Klipper without soldering, I agree that it is almost certainly possible, though I am worried about latency and reliability with the approach I was considering. We should be able to simply echo the debug port UART and MCU UART to one another as a sort of bridge, so we can just plug a Pi directly into the debug port and it will transparently repeat all serial traffic to the MCU, and all MCU responses back to the Pi. May even be possible to use the screen for info and basic control as well, with the Pi handling the heavy lifting.

Adventurer 4 should be similar. I don't know about the specs of 5, it may have enough RAM for native Klipper, if anyone knows the CPU model used in the 5M Pro, that should tell us enough to know for certain (if the SoC has built-in RAM like Adventurer 4's does)

[hw-lunemann]

Looks like we came to the same conclusions!
I ended up settling on forwarding the MCU UART over the network when I realized that latency isn't really an issue. I've just got that running and am going to test it tomorrow.
This does require ethernet though, WiFi issues would be inevitable.

[brendann993]

If I'm reading this right, is the two ideas for solderless Klipper to create the debug port to MCU UART bridge on the existing board (probably as part of a modified upgrade script?) and then run Klipper on the raspberry PI connected to the debug port?
Or in the case of @hw-lunemann way, being similar but doing the bridge over ethernet rather than the debug port.

[hw-lunemann]

@brendann993 Correct! I have been printing with my setup for a few days now and forwarding the firmware and host communication over the network hasn't failed a single time. It's outstandingly reliable for me. I've also overhauled the config that's found in this repository to fix a few outstanding issues and to make improvements. Stay tuned!

[The-Synthax]

If I'm reading this right, is the two ideas for solderless Klipper to create the debug port to MCU UART bridge on the existing board (probably as part of a modified upgrade script?) and then run Klipper on the raspberry PI connected to the debug port? Or in the case of @hw-lunemann way, being similar but doing the bridge over ethernet rather than the debug port.

There are a few options. The printer can be upgraded with a Pi to boost processing power by either installing it internally, connected to the debug serial interface, or the UART between the microcontroller and the main processor can be forwarded over ethernet to the Pi for an external install. The third option is to forego the Pi and only use the existing hardware, but we currently don't know if there's enough RAM for Klipper and enough processing power for input shaper and pressure advance even if there is enough RAM. If it does work, it will be a very tight fit.

Also, I've seen the progress @hw-lunemann has made on configuration and tuning, the machine is printing even better than I could have hoped 😁

[The-Synthax]

Time for a quick update. There's not enough RAM for Klipper. The fact that it uses Python and compiles some C modules at runtime is just too much for the 64MB we have to work with. Good news though! Klipper is pretty much tuned, I've designed an internal Pi mount for a Zero 2 W, and I have an Orca Slicer profile that works really well with the models and filaments I've tried so far. I also made a simple little spacer for increasing the extruder tension, which paired with the torque boost we can get by increasing motor current really uncorks this printer. I've been printing at 0.2mm layer height and getting good quality prints at about 7.5mm³/s flow rate, 4000mm/s² print acceleration and travel speeds of up to 900mm/s with 5000mm/s² accel. (I slowed down to 750mm/s to improve noise quality)

In other news, the project will be re-released this week with v2 of the install guide! I'll upload some demo videos of what kind of speeds and quality you can expect with a stock machine, and begin work on some physical upgrades to boost performance even further (This thing is FAST! the extruder and hotend hold it back massively. Direct drive conversion, anyone?) Before I go too far into the speed rabbit-hole though, I'd like to flesh out the installation methods and work on feature support.

Given that this Issue is about unmodified mainboards, I'll explain a little bit about the plan for that install method. The good news is, it's possible! And, we have a plan for making it happen. The bad news is that it won't be making the cut for v2 of the guide. My 2023 was insanely busy. I moved to a new continent, and for a few months there I didn't even own an Adventurer 3 anymore. Now that I'm back though, I feel that it's time to get the project into other people's hands and get some real testing under way. v3 of the guide will have at least 2 different install methods, and should include full feature parity with the stock firmware. Currently the piezo buzzer, filament runout sensor, screen, USB port, and camera aren't working as those are all handled by the original Linux system onboard the Adventurer 3. @threadproc and I are working on a solution that will allow us to use those features by forwarding the necessary data from the onboard computer to the Pi, even on a bone-stock machine. you won't have to disassemble the machine or even open the bottom panel. Just insert the USB installer, plug your Pi into the ethernet port, and you have a Klipperized Adventurer 3 (or MonoPrice Voxel, or Arçelik PT1000, or ...)

[The-Synthax]

Probably doesn't have a camera to free up the USB header for the RFID reader.

Actually camera header is empty and rfid is connected to the STM32(GD32) on the board. It does not have a camera to just cut the cost of the machine like on the Adventurer 3 Lite.

If you want to flash a different kernel, your best bet is to either use a SOIC clip on the NOR flash on the Mediatek board, or flash it by accessing U-boot's boot menu via serial, if the boot menu is enabled on the bootloader they are using. I'd recommend using serial if you can.

I know how to flash but i don't have the rootfs for the older kernel so i am looking for people who are willing to share a system image.

Now that I own an Adventurer 3 again, I was able to make a dump of the eMMC. Do you still need it?