Closed xblax closed 5 months ago
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!
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?
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)
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?
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
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
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.
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
Thats a pity, so back to SSH then. Is openssh available on the machine or is it a crippled busybox / dropbear instance ?
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.
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?
What if I use internal memory as a swap file?
Yes maybe, but I think (and hope) that's not needed.
@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
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).
@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.
Sounds great. Can you by chance provide some links to the toolchain you have used ? I am curious...
@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
@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
@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?
@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
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.
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
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.
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.
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
@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.
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
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.
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).
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.
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.
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
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.
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
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).
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
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.
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
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
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 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
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?
@xblax Do you speak Russian by any chance? (in places, the translation was "clipper", I have this happening when I use a translator)
@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
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
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.
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
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.
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?
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.
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