Mainsail and Moonraker for Flashforge AD5M

[xblax]

Let's talk a bit about the options to get Mainsail and Moonraker working with the Flashforge 5M (Pro). I think we could consider the following options:

a) Install Mainsail+Moonraker on the Flashforge 5M after rooted into the existing image. As I understand the 128MB ram of the integrated ARM board are a bit limited to run Mainsail+Moonraker but maybe that's still worth trying out. Looks like some initial work to install missing components was already done here https://github.com/Stone-Time/Flashforge-Adventure-5M-Pro-Klipper-SSH

Either use the existing Klipper or install a clean rebuild. It looks like the printer comes with a more ore less stock Klipper 0.11, see https://github.com/FlashforgeOfficial/AD5M_Series_Klipper

b) Try to reverse engineer boot loader, run a different Linux image with Klipper etc. that is loaded from the USB Stick. I think that option takes too much effort.

c) Run Mainsail+Moonraker on a separate device, keep (stock) Klipper as is on the Flashforge. Moonraker connects to Klipper via a Unix Domain Socket that is forwarded via Openssh to another host.

d) Only have the Klipper MCU part running on the integrated controller, Run Clipper (Python part), Moonraker, Mainsail externally.

I would probably prefer a solution that is non-invasive and does not break the built-in printer interface. Not sure about Klippers capabilities, but maybe multiple clients can connect to Klippers API server in parallel: https://www.klipper3d.org/API_Server.html

[g992]

I'm testing an invasive method right now :D I'm not good at programming, and uds via ssh, I think I'd be better off re-soldering a couple resistors. You could try to do a method based on software modification, that would be cool!

[xblax]

That's a cool mod, but pretty invasive indeed :D I will look into something software based when I have the time for it.

Did you reflash the MCU or just kept the stock firmware?

[g992]

That's a cool mod, but pretty invasive indeed :D

I will look into something software based when I have the time for it.

Did you reflash the MCU or just kept the stock firmware?

I left the stock firmware on the main board, but due to damage to the transmitters I can’t communicate with the eboard, so I’ll make hardware and software changes to it (I’ll just rebuild the klipper)

[nitronov]

That's a cool mod, but pretty invasive indeed :D I will look into something software based when I have the time for it. Did you reflash the MCU or just kept the stock firmware?

I left the stock firmware on the main board, but due to damage to the transmitters I can’t communicate with the eboard, so I’ll make hardware and software changes to it (I’ll just rebuild the klipper)

Hello! Can you describe your instructions in more detail? It is not entirely clear what you are doing in step 3, no one in the profile chats on the klipper can make out your actions. Where did you connect the soldered wires in step 2 - to the external host card uart? If so, where did you connect the soldered wires in step 3?

[g992]

Hello! Can you describe your instructions in more detail? It is not entirely clear what you are doing in step 3, no one in the profile chats on the klipper can make out your actions. Where did you connect the soldered wires in step 2 - to the external host card uart? If so, where did you connect the soldered wires in step 3?

I don't quite understand what is not clear :(
I used regular usb-uart converters, as in the photo below, in photos 2 and 3 of the step I showed which pins to connect to the rx and tx converter I will redo my damaged head board in the near future and add photos to the guide

[nitronov]

Hello! Can you describe your instructions in more detail? It is not entirely clear what you are doing in step 3, no one in the profile chats on the klipper can make out your actions. Where did you connect the soldered wires in step 2 - to the external host card uart? If so, where did you connect the soldered wires in step 3?

I don't quite understand what is not clear :( I used regular usb-uart converters, as in the photo below, in photos 2 and 3 of the step I showed which pins to connect to the rx and tx converter I will redo my damaged head board in the near future and add photos to the guide

The problem is that I don't understand how to connect the uart to the board. Why did we solder the wires in step 3? What should I connect them to? In step 3, we are talking about connecting a Converter , that is, you need to connect 2 uart at once in steps 2 and 3? Or does it need to be done sequentially? My experience in printer modification is insufficient and I am grateful for the support and patience. I also want to invite you to our telegram chat on the printer https://t.me/FF_5M_5MPro I suggest we continue the conversation there. My nickname telegram is @armpix

[gpo123]

I think it is much easier to connect an external CPU to the ADM 5 via SOFTWARE. I must admit that I don't have an ADM 5 (yet) as I am waiting for the release and reviews of the FLSUN T1. Thanks to xblax I did a proof of concept in the meantime following his suggestion c) from above. Which means forwarding the Klipper socket on the ADM5 to an external machine. I did this by connecting my Klipper 3D-Printer-Server with a running Klippy-instance and a Raspberry PI Zero 2W running Moonraker/Fluidd. So far the connection works fine by running: socat "UNIX-LISTEN:/home/pi/ADM5_data/comms/klippy.sock,reuseaddr,fork" EXEC:'ssh user@PrinterServer-IP socat STDIO UNIX-CONNECT:/home/klipper/ADM_data/comms/klippy.sock' Unfortunately this solution relies on running socat on both machines. I don't know if this command exists on the ADM5. I did not succed by trying to forward the socket by using only SSH.

[nitronov]

I think it is much easier to connect an external CPU to the ADM 5 via SOFTWARE. I must admit that I don't have an ADM 5 (yet) as I am waiting for the release and reviews of the FLSUN T1. Thanks to xblax I did a proof of concept in the meantime following his suggestion c) from above. Which means forwarding the Klipper socket on the ADM5 to an external machine. I did this by connecting my Klipper 3D-Printer-Server with a running Klippy-instance and a Raspberry PI Zero 2W running Moonraker/Fluidd. So far the connection works fine by running: socat "UNIX-LISTEN:/home/pi/ADM5_data/comms/klippy.sock,reuseaddr,fork" EXEC:'ssh user@PrinterServer-IP socat STDIO UNIX-CONNECT:/home/klipper/ADM_data/comms/klippy.sock' Unfortunately this solution relies on running socat on both machines. I don't know if this command exists on the ADM5. I did not succed by trying to forward the socket by using only SSH.

The standard host lacks many commands, I tried to raise socat a couple of months ago, nothing worked

[gpo123]

Thats a pity, so back to SSH then. Is openssh available on the machine or is it a crippled busybox / dropbear instance ?

[xblax]

SSH is not available on the machine at all, only telnet. But I yesterday set-up a cross compilation environment so everything that's missing can be installed if needed. They use Buildroot 2019.02 with a Linaro Toolchain for the embedded OS (can look up the exact versions when I'm at home).

I already compiled and installed Dropbear because I didn't want to waste the scarce ram for Openssh.

Actually I started focusing on option a) to have Moonraker on the machine. RAM is limited, but I think it will work. Had some troubles setting up the python venv for Moonraker, because their Python installation (3.7.11) isn't exactly standard. But I think I figured this out now and will continue exploring this in the next days.

Will be interesting be interesting to see how the stock printer application plays together with Moonraker, because they also connect to the Klipper API server via Unix Domain socket. If that makes problems they can just be cut off. But for a general purpose mod it would for course be nice to have full stock functionality in parallel with Moonraker+Mainsail.

[nitronov]

SSH is not available on the machine at all, only telnet. But I yesterday set-up a cross compilation environment so everything that's missing can be installed if needed. They use Buildroot 2019.02 with a Linaro Toolchain for the embedded OS (can look up the exact versions when I'm at home).

I already compiled and installed Dropbear because I didn't want to waste the scarce ram for Openssh.

Actually I started focusing on option a) to have Moonraker on the machine. RAM is limited, but I think it will work. Had some troubles setting up the python venv for Moonraker, because their Python installation (3.7.11) isn't exactly standard. But I think I figured this out now and will continue exploring this in the next days.

Will be interesting be interesting to see how the stock printer application plays together with Moonraker, because they also connect to the Klipper API server via Unix Domain socket. If that makes problems they can just be cut off. But for a general purpose mod it would for course be nice to have full stock functionality in parallel with Moonraker+Mainsail.

What if I use internal memory as a swap file?

[xblax]

What if I use internal memory as a swap file?

Yes maybe, but I think (and hope) that's not needed.

[gpo123]

@xblax: Wow, you are making great progress ! I am astonished about SSH not being on the machine. According to stonetime's repo some sort of SSH should be on the machine (at least with the latest firmware updates ?): https://github.com/Stone-Time/Flashforge-Adventure-5M-Pro-Klipper-SSH/blob/main/flashforge_init.sh

[gpo123]

Accidently during my fiddling with socat I connected two Moonraker instances to the same Klippy socket. That astonishingly without problems. What the Klippy socket did not like was the forwarding via OpenSSH (with my limited knowledge on this topic).

[xblax]

@gpo123 Stonetime's repo contains a cross-built openssh. But I think that's a statically linked build. I tried to match their build enviornment so that we can link against the installed libraries.

And yes, that's a weird choice that they have telnet and not ssh by default. Instead they choose to include things like postgresql (which I think is not used). They also have two different python installations. Python 3.7.2 from Buildroot sysimage and Python 3.7.11 which they installed in /opt along with all their printer application software and a bunch of libraries.

Their printer application is a Qt4 based touch application. So in theory someone could even develop a custom interface.

[gpo123]

Sounds great. Can you by chance provide some links to the toolchain you have used ? I am curious...

[nitronov]

@gpo123 Stonetime's repo contains a cross-built openssh. But I think that's a statically linked build. I tried to match their build enviornment so that we can link against the installed libraries.

And yes, that's a weird choice that they have telnet and not ssh by default. Instead they choose to include things like postgresql (which I think is not used). They also have two different python installations. Python 3.7.2 from Buildroot sysimage and Python 3.7.11 which they installed in /opt along with all their printer application software and a bunch of libraries.

Their printer application is a Qt4 based touch application. So in theory someone could even develop a custom interface.

Theoretically it is possible, but is it necessary? I'm more inclined to demolish the existing system and install normal Linux

[g992]

@gpo123 Stonetime's repo contains a cross-built openssh. But I think that's a statically linked build. I tried to match their build enviornment so that we can link against the installed libraries. And yes, that's a weird choice that they have telnet and not ssh by default. Instead they choose to include things like postgresql (which I think is not used). They also have two different python installations. Python 3.7.2 from Buildroot sysimage and Python 3.7.11 which they installed in /opt along with all their printer application software and a bunch of libraries. Their printer application is a Qt4 based touch application. So in theory someone could even develop a custom interface.

Theoretically it is possible, but is it necessary? I'm more inclined to demolish the existing system and install normal Linux

Normal linux requires >128mb RAM, T113-s3 is really weak cpu, i think @xblax idea about using uds over ssh win

[nitronov]

@gpo123 Stonetime's repo contains a cross-built openssh. But I think that's a statically linked build. I tried to match their build enviornment so that we can link against the installed libraries. And yes, that's a weird choice that they have telnet and not ssh by default. Instead they choose to include things like postgresql (which I think is not used). They also have two different python installations. Python 3.7.2 from Buildroot sysimage and Python 3.7.11 which they installed in /opt along with all their printer application software and a bunch of libraries. Their printer application is a Qt4 based touch application. So in theory someone could even develop a custom interface.

Theoretically it is possible, but is it necessary? I'm more inclined to demolish the existing system and install normal Linux

Normal linux requires >128mb RAM, T113-s3 is really weak cpu, i think @xblax idea about using uds over ssh win

More interesting is what FF wants to do in the new klipper repository. What will they provide to users?

[g992]

@gpo123 Stonetime's repo contains a cross-built openssh. But I think that's a statically linked build. I tried to match their build enviornment so that we can link against the installed libraries. And yes, that's a weird choice that they have telnet and not ssh by default. Instead they choose to include things like postgresql (which I think is not used). They also have two different python installations. Python 3.7.2 from Buildroot sysimage and Python 3.7.11 which they installed in /opt along with all their printer application software and a bunch of libraries. Their printer application is a Qt4 based touch application. So in theory someone could even develop a custom interface.

Theoretically it is possible, but is it necessary? I'm more inclined to demolish the existing system and install normal Linux

Normal linux requires >128mb RAM, T113-s3 is really weak cpu, i think @xblax idea about using uds over ssh win

More interesting is what FF wants to do in the new klipper repository. What will they provide to users?

it`s just license agreement, klipper license require to publish klipper sources if u use it in commercial

[xblax]

Sounds great. Can you by chance provide some links to the toolchain you have used ? I am curious...

Should be this one that I used and they also used to build the system initially: https://releases.linaro.org/components/toolchain/binaries/7.4-2019.02/arm-linux-gnueabi/ This here probably works as well: https://releases.linaro.org/components/toolchain/binaries/7.5-2019.12/arm-linux-gnueabi/

Newer tool-chains probably don't work unless we do static builds, because we cannot user newer glibc than 2.25 from the stock linux.

[xblax]

Short update, before anyone else runs into the same issues like I did: Python builds that are included in the system image are not usable to run Moonraker.

Buildroot System Python 3.7.2: That was compiled without of optional libraries like zlib. But zlib is required for at least pip. We can't install Moonraker dependencies. Flashforge /opt Python 3.7.11: They compile python without _ctypes support, so that also doesn't work.

Good news: I managed to cross-compile up-to-date Python 3.11.7 for the printer. This was much easier than expected.

Next difficulty will be to install Moonraker python requirements. The dependencies contain native code which must be compiled for the target, therefore they must also be cross-built. This should be possible using https://github.com/benfogle/crossenv

[g992]

Hi @xblax! Are there any successes? if testing is needed, maybe I can help? I was able to successfully launch a printer running a clipper with strong hardware modifications and not strong software modifications. I think I can run experiments on T113-S3 without the risk of breaking something.

[xblax]

Yes, I manged to complete proof of concept yesterday. I have Moonraker on the device and can connect with Mainsail from it! I didn't do a test print yet or anything complex. Just tried homing, movement, gcode loading, extruder and bed heat up. How well it runs is still to be determined, but I'm optimistic. It appears that Moonraker and the Stock Flashforge App can run in parallel.

I also noticed that it's not a good idea to try run Moonraker externally and just forward the Unix Socket, because it expects direct access to shared folders with Klipper (i.e. for gcode access) and Moonraker also pulls useful information from the machine like load data (RAM, CPU Usage etc.).

Next step will be to put more though in how to make a mod that others can install without breaking their printers ... I plan to do an automated installer using the stock update mechanism (copy Zip archive on USB Stick). I will share something for testing to some users once I have a first test installer. Then some can help beta testing and tuning the configurations.

I'm also currently leaning towards replacing stock Klipper as well and make the stock application connect to the custom Klipper instead, but I don't want to touch the MCU firmware. Custom Klipper will give a bit more freedom with the configuration and save some RAM, when both Klipper+Moonraker use the same python build.

[g992]

Be careful with upgrading firmware, im bricked my extruder boardwhen try to load builded klipper. I think its need more than klipper, maybe bootloader or smth. I asked a klipper forum, but no answers at this moment. https://github.com/g992/flashforge-ad5m-5mpro-research/issues/8

[xblax]

@g992 Yes, I don't want to flash MCU firmware. Only have the python part (klippy) and printer config separated from what is pre-installed, So that it's very easy to back to 100% stock software even if Klipper config was changed.

Did you try to flash the stock firmware to unbrick the MCU? The flash tools and stock builds are are all included in their update packages. Do you want to make the hardware mod work long-term or rather try out the software mod.

[g992]

the main problem is that the old mcu firmware is not compatible with the new clipper :( I made the printer work, but I had to solder the controller on the printhead

[xblax]

I'm not sure if there are big benefits running newer Klipper at moment, Klipper 0.12 doesn't seem to add that much features. I'd rather stay with Klipper 0.11~ for now that is compatible with stock MCU firmware.

[jlodew0]

the t113-S3 could be upgraded with the S4 (256MB version - same die, so pin compatible). https://nl.aliexpress.com/w/wholesale-t113%2525252ds4.html?spm=a2g0o.productlist.search.0 Allwinner kernel available here: https://github.com/Tina-Linux/linux-5.4 I only did embedded projects with u-boot in the past. Seems like only awboot and xboot are working atm acording to this page: https://linux-sunxi.org/T113-s3

p.s. using an external host like rpi instead of the onboard soc would render the display useless as well as the webcam on the pro machines.

p.s. 2 does anyone knows how many and what type of load cells are used on the bed for leveling? And how about klipper support because I can only find some topics about some users writing stuff for load cells in klipper. If you want to make a firmware for the mcu you might want to overcome that part + some custom things implemented as well. I didn't went trough the config file yet, but it wouldn't surprise me that isn't all standard klipper stuff in there.

I'm afraid that since FF is yet another chinese company that they don't care a lot about licensing. So opening up everything as required with the gpl license is probably not going to happen. However, I hope to be proven wrong. their current github repo seems to be setup just to comply to gpl (and even those requirements aren't fully met)

They have a good machine hardware wise and price wise, it beats the bambu products by a large margin. If they would only see that opening up the machine's source code would increase their sales by a huge factor (that's what I would expect, at least by the more advanced maker/thinker community).

[g992]

I’m not sure that the upgrade to 256MB of RAM will be available to all users, as it requires soldering skills + skills in working with embedded Linux. Regarding the table level cells, judging by the klipper there are 3 of them and apparently there is an additional controller that processes them, since the clipper receives the “probe” signal from one pin. with an external controller it works the same way, I was able to get a height map. Regarding the display: I plan to replace it with a 4.3-inch display with hdmi, but these are just plans. As an experiment, I want to replace almost all the electronics of this printer.

[xblax]

I don't think that the 128MB of RAM are a deal-breaker. We just have to be a bit resourceful with what we install, but Klipper+Moonraker+Mainsail/Fluid should just run fine. I'm definitely not going to solder another SOC on the board, the amount of work required for that is just not worth it. Processing power also seems to be enough.

What I'm currently working on is a change root environment based on Buildroot 2023.02 that basically runs everything but the stock printer app. In the chroot environment we can have a custom klipper (klipppy), moonraker and a webserver to provide mainsail & fluidd (probably busybox-httpd). Basically a custom linux in linux. Dropbear with root access will also run in the chroot, so we don't even have to edit the root password. I've started a git project for this, but that's not yet public.

I everything goes as planned, the mod installs just an Init script and a self-contained folder on the /data partition with the mod system. Going back to stock functionality is than as easy as just deleting one folder or the Init script.

[g992]

Guys says that mellow have pi lite board on t113-s3, that can run klipper + mooonraker + web interface. Some docs here: https://mellow.klipper.cn/#/introduction/downloadimg Maybe it can help

[xblax]

So I managed to do print a test Benchy with Moonraker, Klipper, Mainsail running on the machine yesterday. This worked quite well. The Ram is sufficient, CPU Usage never went above 20%. The difficulty is how to set up everything properly.

The Stock app does not really like it to not be in control of Klipper. I think it's better to disable it while using Moonraker, otherwise this can lead to unexpected issues. I think the best for Klipper Mod mode would be to just copy the Wifi settings from the stock app and enable DHCP for Ethernet - for Filament loading etc. we then need Klipper Macros.

I also tried running slightly newer Klipper than 0.11, but that didn't work well with the MCU firmware. I think they need to be reflashed for newer Klipper.

[g992]

Nice! I think the upgrade to 0.12 is not so important, since it turned out to be more difficult to assemble the firmware on the N32 than we thought. I think the stable operation of the 0.11 version is enough we have a community of owners who want to install a moonraker, could you share the basic steps? at least not through the update files, but through the terminal

[xblax]

Yes ... hope I have soon something that I can share. The problem is that build instructions are too complicated to write them down in a tutorial or something like that. I started to script most things, fortunately.

The whole thing works in a chroot environment, which is cross-build with buildroot. There are a lot of step involved in building all dependencies, unfortunately.

I will try to get it in a state that it can install and run (maybe manual startup via telnet at first).

[nitronov]

Yes ... hope I have soon something that I can share. The problem is that build instructions are too complicated to write them down in a tutorial or something like that. I started to script most things, fortunately.

The whole thing works in a chroot environment, which is cross-build with buildroot. There are a lot of step involved in building all dependencies, unfortunately.

I will try to get it in a state that it can install and run (maybe manual startup via telnet at first).

As an option to record a video, I think anyone can figure it out, and if not, then they won’t need it

[xblax]

As an option to record a video, I think anyone can figure it out, and if not, then they won’t need it

That would have to be a multiple hour session :D It's easier for me to share something prebuilt for testing and then make the git repos with build scripts public, eventually.

Currently I'm having a problem with the MCUs. Klipper cannot connect after Linux startup. Only if the Flashforge software starts with their Klipper, then I kill that, and then my Klipper can connect. I don't think it's a change to Klipper they did, I looked at https://github.com/FlashforgeOfficial/AD5M_Series_Klipper - that is basically vanilla Klipper.

There must be some initialization missing. Do we have to power on the MCUs maybe? @g992 Any Idea - you looked at the MCUs more than I did.

[nitronov]

As an option to record a video, I think anyone can figure it out, and if not, then they won’t need it

That would have to be a multiple hour session :D It's easier for me to share something prebuilt for testing and then make the git repos with build scripts public, eventually.

Currently I'm having a problem with the MCUs. Klipper cannot connect after Linux startup. Only if the Flashforge software starts with their Klipper, then I kill that, and then my Klipper can connect. I don't think it's a change to Klipper they did, I looked at https://github.com/FlashforgeOfficial/AD5M_Series_Klipper - that is basically vanilla Klipper.

There must be some initialization missing. Do we have to power on the MCUs maybe? @g992 Any Idea - you looked at the MCUs more than I did.

Half of the system is launched through the installed proprietary Flashforge software, the same display is not registered in the configuration settings, apparently it is also launched through native software

[g992]

As an option to record a video, I think anyone can figure it out, and if not, then they won’t need it

That would have to be a multiple hour session :D It's easier for me to share something prebuilt for testing and then make the git repos with build scripts public, eventually.

Currently I'm having a problem with the MCUs. Klipper cannot connect after Linux startup. Only if the Flashforge software starts with their Klipper, then I kill that, and then my Klipper can connect. I don't think it's a change to Klipper they did, I looked at https://github.com/FlashforgeOfficial/AD5M_Series_Klipper - that is basically vanilla Klipper.

There must be some initialization missing. Do we have to power on the MCUs maybe? @g992 Any Idea - you looked at the MCUs more than I did.

hmm, how ff software starting up? (I found many strange functionals like pin enabling (?)) if FF software starts from init.d, maybe edit start script to kill software after 10s from launch? :D I killed the motherboard, so I can safely explore it. I will deal with this in the coming days, perhaps it will be necessary to add a simple script to enable the MCU

[xblax]

Half of the system is launched through the installed proprietary Flashforge software, the same display is not registered in the configuration settings, apparently it is also launched through native software

Yes, some things are ... but display is available at /dev/fb0 - I didn't figure out the framebuffer format and how to display images at it. But installer just writes framebuffer images to /dev/fb0

hmm, how ff software starting up? (I found many strange functionals like pin enabling (?)) if FF software starts from init.d, maybe edit start script to kill software after 10s from launch? :D

Did you disassemble the software or where did you find it? Maybe that would help me.

I don't want to start flashforge software. I want to hijack system init before flashforge software launches and continue in chroot environment.

[g992]

I don't want to start flashforge software. I want to hijack system init before flashforge software launches and continue in chroot environment.

I disassembled it, but I didn't figure it out much , I found a lot of tracks that control something and come from T113, as well as update files depend on the system gpios (try running NationsCommand on RP) I will investigate them, write in this topic what I find

[nitronov]

Half of the system is launched through the installed proprietary Flashforge software, the same display is not registered in the configuration settings, apparently it is also launched through native software

Yes, some things are ... but display is available at /dev/fb0 - I didn't figure out the framebuffer format and how to display images at it. But installer just writes framebuffer images to /dev/fb0

hmm, how ff software starting up? (I found many strange functionals like pin enabling (?)) if FF software starts from init.d, maybe edit start script to kill software after 10s from launch? :D

Did you disassemble the software or where did you find it? Maybe that would help me.

I don't want to start flashforge software. I want to hijack system init before flashforge software launches and continue in chroot environment.

I'm now experimenting with loading a different loader. All that remains is to find out the address of the cell where the u-boot is installed. Any ideas on how to find out the address?

[g992]

@xblax Do you speak Russian by any chance? (in places, the translation was "clipper", I have this happening when I use a translator)

[xblax]

@g992 No, not at all :D

Here I have the GPIO state before Flashforge software starts. But this output is unchanged after Flashforge software start. I will try to use gpiomon.

ADM5 ~ # gpioinfo gpiochip0
gpiochip0 - 224 lines:
    line   0:      unnamed       unused   input  active-high 
    line   1:      unnamed       unused   input  active-high 
    line   2:      unnamed       unused   input  active-high 
    line   3:      unnamed       unused   input  active-high 
    line   4:      unnamed       unused   input  active-high 
    line   5:      unnamed       unused   input  active-high 
    line   6:      unnamed       unused   input  active-high 
    line   7:      unnamed       unused   input  active-high 
    line   8:      unnamed       unused   input  active-high 
    line   9:      unnamed       unused   input  active-high 
    line  10:      unnamed       unused   input  active-high 
    line  11:      unnamed       unused   input  active-high 
    line  12:      unnamed       unused   input  active-high 
    line  13:      unnamed       unused   input  active-high 
    line  14:      unnamed       unused   input  active-high 
    line  15:      unnamed       unused   input  active-high 
    line  16:      unnamed       unused   input  active-high 
    line  17:      unnamed       unused   input  active-high 
    line  18:      unnamed       unused   input  active-high 
    line  19:      unnamed       unused   input  active-high 
    line  20:      unnamed       unused   input  active-high 
    line  21:      unnamed       unused   input  active-high 
    line  22:      unnamed       unused   input  active-high 
    line  23:      unnamed       unused   input  active-high 
    line  24:      unnamed       unused   input  active-high 
    line  25:      unnamed       unused   input  active-high 
    line  26:      unnamed       unused   input  active-high 
    line  27:      unnamed       unused   input  active-high 
    line  28:      unnamed       unused   input  active-high 
    line  29:      unnamed       unused   input  active-high 
    line  30:      unnamed       unused   input  active-high 
    line  31:      unnamed       unused   input  active-high 
    line  32:      unnamed       unused   input  active-high 
    line  33:      unnamed       kernel   input  active-high [used]
    line  34:      unnamed       unused   input  active-high 
    line  35:      unnamed  "usb1-vbus"  output  active-high [used]
    line  36:      unnamed       unused  output  active-high 
    line  37:      unnamed       unused  output  active-high 
    line  38:      unnamed       kernel   input  active-high [used]
    line  39:      unnamed       kernel   input  active-high [used]
    line  40:      unnamed       unused   input  active-high 
    line  41:      unnamed       unused   input  active-high 
    line  42:      unnamed       unused   input  active-high 
    line  43:      unnamed       unused   input  active-high 
    line  44:      unnamed       unused   input  active-high 
    line  45:      unnamed       unused   input  active-high 
    line  46:      unnamed       unused   input  active-high 
    line  47:      unnamed       unused   input  active-high 
    line  48:      unnamed       unused   input  active-high 
    line  49:      unnamed       unused   input  active-high 
    line  50:      unnamed       unused   input  active-high 
    line  51:      unnamed       unused   input  active-high 
    line  52:      unnamed       unused   input  active-high 
    line  53:      unnamed       unused   input  active-high 
    line  54:      unnamed       unused   input  active-high 
    line  55:      unnamed       unused   input  active-high 
    line  56:      unnamed       unused   input  active-high 
    line  57:      unnamed       unused   input  active-high 
    line  58:      unnamed       unused   input  active-high 
    line  59:      unnamed       unused   input  active-high 
    line  60:      unnamed       unused   input  active-high 
    line  61:      unnamed       unused   input  active-high 
    line  62:      unnamed       unused   input  active-high 
    line  63:      unnamed       unused   input  active-high 
    line  64:      unnamed       unused   input  active-high 
    line  65:      unnamed       unused   input  active-high 
    line  66:      unnamed       kernel   input  active-high [used]
    line  67:      unnamed       kernel   input  active-high [used]
    line  68:      unnamed       kernel   input  active-high [used]
    line  69:      unnamed       kernel   input  active-high [used]
    line  70:      unnamed       kernel   input  active-high [used]
    line  71:      unnamed       kernel   input  active-high [used]
    line  72:      unnamed       unused   input  active-high 
    line  73:      unnamed       unused   input  active-high 
    line  74:      unnamed       unused   input  active-high 
    line  75:      unnamed       unused   input  active-high 
    line  76:      unnamed       unused   input  active-high 
    line  77:      unnamed       unused   input  active-high 
    line  78:      unnamed       unused   input  active-high 
    line  79:      unnamed       unused   input  active-high 
    line  80:      unnamed       unused   input  active-high 
    line  81:      unnamed       unused   input  active-high 
    line  82:      unnamed       unused   input  active-high 
    line  83:      unnamed       unused   input  active-high 
    line  84:      unnamed       unused   input  active-high 
    line  85:      unnamed       unused   input  active-high 
    line  86:      unnamed       unused   input  active-high 
    line  87:      unnamed       unused   input  active-high 
    line  88:      unnamed       unused   input  active-high 
    line  89:      unnamed       unused   input  active-high 
    line  90:      unnamed       unused   input  active-high 
    line  91:      unnamed       unused   input  active-high 
    line  92:      unnamed       unused   input  active-high 
    line  93:      unnamed       unused   input  active-high 
    line  94:      unnamed       unused   input  active-high 
    line  95:      unnamed       unused   input  active-high 
    line  96:      unnamed       unused   input  active-high 
    line  97:      unnamed       unused   input  active-high 
    line  98:      unnamed       unused   input  active-high 
    line  99:      unnamed       unused   input  active-high 
    line 100:      unnamed       unused   input  active-high 
    line 101:      unnamed       unused   input  active-high 
    line 102:      unnamed       unused   input  active-high 
    line 103:      unnamed       unused   input  active-high 
    line 104:      unnamed       unused   input  active-high 
    line 105:      unnamed       unused   input  active-high 
    line 106:      unnamed       kernel   input  active-high [used]
    line 107:      unnamed       kernel   input  active-high [used]
    line 108:      unnamed       kernel   input  active-high [used]
    line 109:      unnamed       kernel   input  active-high [used]
    line 110:      unnamed       unused   input  active-high 
    line 111:      unnamed       unused   input  active-high 
    line 112:      unnamed       unused   input  active-high 
    line 113:      unnamed       unused   input  active-high 
    line 114:      unnamed       unused   input  active-high 
    line 115:      unnamed       unused   input  active-high 
    line 116:      unnamed       unused   input  active-high 
    line 117:      unnamed       unused   input  active-high 
    line 118:      unnamed       unused   input  active-high 
    line 119:      unnamed       unused   input  active-high 
    line 120:      unnamed       unused   input  active-high 
    line 121:      unnamed       unused   input  active-high 
    line 122:      unnamed       unused   input  active-high 
    line 123:      unnamed       unused   input  active-high 
    line 124:      unnamed       unused   input  active-high 
    line 125:      unnamed       unused   input  active-high 
    line 126:      unnamed       unused   input  active-high 
    line 127:      unnamed       unused   input  active-high 
    line 128:      unnamed       kernel   input  active-high [used]
    line 129:      unnamed       kernel   input  active-high [used]
    line 130:      unnamed       kernel   input  active-high [used]
    line 131:      unnamed       kernel   input  active-high [used]
    line 132:      unnamed       kernel   input  active-high [used]
    line 133:      unnamed       kernel   input  active-high [used]
    line 134:      unnamed       kernel   input  active-high [used]
    line 135:      unnamed       kernel   input  active-high [used]
    line 136:      unnamed       kernel   input  active-high [used]
    line 137:      unnamed       kernel   input  active-high [used]
    line 138:      unnamed       kernel   input  active-high [used]
    line 139:      unnamed       unused   input  active-high 
    line 140:      unnamed       unused   input  active-high 
    line 141:      unnamed    "phy-rst"  output  active-high [used]
    line 142:      unnamed       unused   input  active-high 
    line 143:      unnamed       unused   input  active-high 
    line 144:      unnamed       unused   input  active-high 
    line 145:      unnamed       unused   input  active-high 
    line 146:      unnamed       unused   input  active-high 
    line 147:      unnamed       unused   input  active-high 
    line 148:      unnamed       unused   input  active-high 
    line 149:      unnamed       unused   input  active-high 
    line 150:      unnamed       unused   input  active-high 
    line 151:      unnamed       unused   input  active-high 
    line 152:      unnamed       unused   input  active-high 
    line 153:      unnamed       unused   input  active-high 
    line 154:      unnamed       unused   input  active-high 
    line 155:      unnamed       unused   input  active-high 
    line 156:      unnamed       unused   input  active-high 
    line 157:      unnamed       unused   input  active-high 
    line 158:      unnamed       unused   input  active-high 
    line 159:      unnamed       unused   input  active-high 
    line 160:      unnamed       kernel   input  active-high [used]
    line 161:      unnamed       kernel   input  active-high [used]
    line 162:      unnamed       kernel   input  active-high [used]
    line 163:      unnamed       kernel   input  active-high [used]
    line 164:      unnamed       kernel   input  active-high [used]
    line 165:      unnamed       kernel   input  active-high [used]
    line 166:      unnamed       unused   input  active-high 
    line 167:      unnamed       unused   input  active-high 
    line 168:      unnamed       unused   input  active-high 
    line 169:      unnamed       unused   input  active-high 
    line 170:      unnamed       unused   input  active-high 
    line 171:      unnamed       unused   input  active-high 
    line 172:      unnamed       unused   input  active-high 
    line 173:      unnamed       unused   input  active-high 
    line 174:      unnamed       unused   input  active-high 
    line 175:      unnamed       unused   input  active-high 
    line 176:      unnamed       unused   input  active-high 
    line 177:      unnamed       unused   input  active-high 
    line 178:      unnamed       unused   input  active-high 
    line 179:      unnamed       unused   input  active-high 
    line 180:      unnamed       unused   input  active-high 
    line 181:      unnamed       unused   input  active-high 
    line 182:      unnamed       unused   input  active-high 
    line 183:      unnamed       unused   input  active-high 
    line 184:      unnamed       unused   input  active-high 
    line 185:      unnamed       unused   input  active-high 
    line 186:      unnamed       unused   input  active-high 
    line 187:      unnamed       unused   input  active-high 
    line 188:      unnamed       unused   input  active-high 
    line 189:      unnamed       unused   input  active-high 
    line 190:      unnamed       unused   input  active-high 
    line 191:      unnamed       unused   input  active-high 
    line 192:      unnamed       unused   input  active-high 
    line 193:      unnamed       unused   input  active-high 
    line 194:      unnamed       unused   input  active-high 
    line 195:      unnamed       unused   input  active-high 
    line 196:      unnamed       kernel   input  active-high [used]
    line 197:      unnamed       kernel   input  active-high [used]
    line 198:      unnamed       kernel   input  active-high [used]
    line 199:      unnamed       kernel   input  active-high [used]
    line 200:      unnamed       kernel   input  active-high [used]
    line 201:      unnamed       kernel   input  active-high [used]
    line 202:      unnamed       unused   input  active-high 
    line 203:      unnamed       unused   input  active-high 
    line 204:      unnamed       unused   input  active-high 
    line 205:      unnamed       unused   input  active-high 
    line 206:      unnamed       unused   input  active-high 
    line 207:      unnamed       unused   input  active-high 
    line 208:      unnamed       unused   input  active-high 
    line 209:      unnamed       unused   input  active-high 
    line 210:      unnamed       unused   input  active-high 
    line 211:      unnamed       unused   input  active-high 
    line 212:      unnamed       unused   input  active-high 
    line 213:      unnamed       unused   input  active-high 
    line 214:      unnamed       unused   input  active-high 
    line 215:      unnamed       unused   input  active-high 
    line 216:      unnamed       unused   input  active-high 
    line 217:      unnamed       unused   input  active-high 
    line 218:      unnamed       unused   input  active-high 
    line 219:      unnamed       unused   input  active-high 
    line 220:      unnamed       unused   input  active-high 
    line 221:      unnamed       unused   input  active-high 
    line 222:      unnamed       unused   input  active-high 
    line 223:      unnamed       unused   input  active-high

[g992]

hmm, any errors in moonrakers logs? and usd alive when system starts? maybe ff software creating uds (?) or maybe it starts klipper? i didnt remember klipper at init.d

[xblax]

hmm, any errors in moonrakers logs? and usd alive when system starts? maybe ff software creating uds (?) or maybe it starts klipper? i didnt remember klipper at init.d

No, Klipper was the issue, could not connect to eboard-MCU. Yes, normally FF-software starts Klipper, but I don't start FF-software for the mod.

But it's working now, cannot reproduce it. No GPIOs needed. Don't know what happended earlier, maybe MCU shut down for some reason.

[g992]

I got the same bug (klipper doesn’t see the main controller, but my uart is hardwired to raspberry) and... it went away after 2-3 reboots! and now I can’t reproduce it either! I don’t know where it comes from, and how FF fights it, maybe there is a gpio for rebooting the controller, I need to check it

[xblax]

Also got the bug again yesterday. Only way to resolve it was to boot into stock mode, FF-Application didn't have problems, then reboot into Mod mode. Maybe the MCU must be enabled once after cold boot.

I also don't really know yet what some of the GPIO Pins and Sensors in the Klipper config do.

[xblax]

Ok so I started to look at a bit at the "firmwareExe" from Flashforge. The pattern seems to be, that after power up, the software must run or otherwise the eboard-MCU is not available. The main-MCU is ready all the time without additional initialization.

First I had a look at the output on console. Logs saved at /mnt/data/logFiles/firmwareExe.log don't help much. MCU initialization happens earlier. But if we launch it on the console, we see some serial initialization is taking place:

Serial: serial fd: 14
Serial: serial ready recv:  , count: 0
Serial: serial ready recv: Ready.
 , count: 8
Serial: serial ready end: 1
Serial: serial ACK send: A , count: 1
Serial: serial ACK recv: 6 , count: 1

The sequence is a bit different every time, sometimes it's quite a bit longer with more commands exchanged. I looked into the binary with Ghidra and found the relevant part. There are two functions bootSerialMainMcu and bootSerialMainEboardMcu. The one for the main MCU is never called, that matches obervations that it doesn't need initialization. Maybe they used it during development. But bootSerialMainEboardMcu is called directly from main().

Here are the code snippets from Ghidra: https://gist.github.com/xblax/2287bc83f399d2144952cd345518cf78

I assume that MCU boots in program or debug mode and must be told to start the actual program first. I guess this could be reverse engineered, but do we maybe have a datasheet that explains this?

[xblax]

That unsolved problem didn't let me rest so I had to reverse engineer that code ... seems they have written a custom bootloader. I had checked STM and Nations Bootloader descriptions, but that didn't look like what was sent.

What the Eboard-MCU does after start, is to periodically send:

Ready.
Ready.
Ready.
Ready.
...

That is detected by the initialization code and with command 'A' (0x41) the boot loader starts the application. This command is acknowledged by the bootloader with byte 0x06 (Ascii ACK). I have updated the Gist with C-Code to do that initialization: https://gist.github.com/xblax/2287bc83f399d2144952cd345518cf78

Now I can start Klipper, Moonraker etc. after boot 😎 Will try to get something ready for testing for you soon.