Does someone got it done ?
What function/feature do you want/need to make mainline worth the risk?
As far as I can tell, with the pressure sensor no longer used in recent firmware the only thing not compatible with mainline is the display. Upgrade to a HDMI screen and use KIAUH to change repositories and you should be golden.
And, in case not, you can rollback to the previous firmware.
i just want it to work, printer.cfg be visible, moonraker does not crash, remove obico junk etc
printer.cfg is right where it belongs. You have to follow the [include] statements to get everything.
Pro tip: The klippy.log has the ENTIRE configuration written to is every time there is a firmware restart. Use Klipper Advanced Log Inspector if you don’t want to scroll the whole log.
You should be able to uninstall Obico with KIAUH. Uninstall everything in KIAUH of you want. Change repositories and reinstall only the pieces you want.
If uninstall/reinstall doesn’t satisfy you get a spare EMMC module and experiment.
I don’t have a Zero board to test with but the images below will likely boot on the board.
I’d recommend you have the USB <> EMMC dongle. On the Klipad (SV07) the bootloader is configured to boot EMMC first not the SD card. I assume the Zero is similar. You have to update the bootloader if you want to run off a SD card.
OR
One of the SV08 methods has a hack to modify the EMMC image and boot from SD. Might work on the Zero. The SV08 is also based on the same H616 chip.
I have upgraded the eMMC to a 32GB version by downloading the image from the sovol wiki and flashing it to the new eMMC board using the usb to eMMC adapter and it worked flawlessly, I first backed up all my configs too to make sure any modifications I had could be copied over. So far the only thing I kept was the webcam config changes suggested in another thread.
You could also take the eMMC out and use the adapter to clone the data for back-up and then do the klipper main line upgrades.
One thing to note is that you most likely would want to find a way to preserve the eddy sensor code, since that looks like it’s a Sovol specific bit of code that is required for optimal use.
I’ve seen posts at https://klipper.discourse.group claiming they are running a Zero toolhead on different printers with mainline klipper AND Kalico + eddyNG.
I don’t have personal experience so proceed at your own risk.
Just trying this out now. It does seem that the default sovol zero config uses the normal probe_eddy_current implementation and that in order to use eddy-ng the toolhead needs a firmware update.
I’m going to try that out now on the toolhead I’ve got installed on my ender 3 v2.
following this guide to flash the toolhead with mainline (or kalico or klippain) worked for me.
For the record, to get eddy-ng working:
[probe_eddy_ng eddy]
sensor_type = ldc1612
i2c_mcu = toolhead
x_offset = -19.8
y_offset = -0.75
i2c_software_scl_pin = PB10
i2c_software_sda_pin = PB11
that’s assuming the mcu for the toolhead is called toolhead otherwise change to the appropriate value.
I’m not sure why it needs those pin values like that, the STM32F103 that’s on the toolhead board should be able to use i2c_bus: i2c2 but it doesn’t work with eddy-ng. At least not on my setup.
The above does work, however, and I’m able to home the printer now.
Edit to add (6 October 2025):
So I’ve been looking to re-create some of the START_PRINT macro on my ender 3 and I now know that if you need to run the eddy probe with mainline klipper and not eddy-ng, then you’ll need to copy the ~/klipper/klippy/extras/probe_eddy_current.py file as it is not the standard version that comes with klipper. It defines a few extra gcode commands including RUN_PROBE_VIR_CONTACT which I believe is responsible for Z_OFFSET.
I’ve not tried to use this version yet
Glad to have found this, I have a pair of Zeros so I want to move one to mainline Klipper and see if the change is worth it. Both are using BTT HDMI 5 inch touchscreens already so I don’t need to worry about the stock screen.
Kilpper mainline won’t seem much different than Sovol’s fork. There have been non-trivial changes in the motion planner resulting in better positional accuracy with minimal increases in CPU load.
BUT you’ll be unlikely to see a noticeable improvement in printed models.
What mainline does is future proof your printer allowing you to quickly adopt any new features the Klipper team comes up with. The other big advantage is direct support from the actual developer team at https://klipper.discourse.group
I have not tried this yet myself but I like it.
“mainline” means different things to different people; there are at least 3 other projects in addition to lexfrei’s that all achieve slightly different things. Some even involve replacing the mainboard with a generic one. I haven’t decided which one to employ myself yet, as they all have different tradeoffs… It is inevitable though, and I will post my thought process when I finally get around to it!
I will note that most require the 32GB eMMC upgrade, not because of capacity, but because nobody realized until lexfrei that sovol underclocked the 8GB modules below klipper’s defaults so they would work.
Now that lexfrei figured that out, I would think any of the options could continue to the slow, small, stock eMMC.
Being able to use the original emmc is helpful because it is hard to find the 32 gb in stock anywhere.
What is needed is a method to attach a “real” SBC host to the MCU half of the Sovol mainboard. Then decommission the H616 host. The MCU side is all standard hardware that could work flawlessly if a connection to another host was possible.
As in using another board/unit which does all the processing & such? I was wondering just the other day if that was feasible/possible.
The board is 2 functional units. Power supply is shared but the only connection is 1 USB data pair. It may require cutting board traces or lifting pins at the MCU.
I wish I had a board to play with,
I’m somewhat new to these ideas but I’m thinking the H616 with twice as many faster cores and 4x the ram is a better Klipper host than what’s on my Creality K1. On the K1 there’s been some success by disabling Klippy and Moonraker and using socat to bridge the MCUs over USB to a secondary Klipper host such as an RPi4 with USB OTG. Here’s a link to notes on this:
And a link to the project:
I’m still gathering info and have not done much yet but I’d like to get my SV07, Zero and K1 on open source software as each has issues and is unlikely to receive further updates. I’m thinking with the stock hardware the SV07 could benefit from Kalico’s MPC instead of PID for the hotend. Differing X & Y acceleration limits might help and a different UI for the Klipad’s touchscreen might be nice. MPC for the Zero might be a bigger win as I have been using it for a lot of tiny prints in higher temp filaments. For the K1 I’ve ordered a Cartographer eddy probe which is supported under Simple AF which I hope will help me get its bed mesh flatter, similar to what I’ve managed on the Sovols and Simple AF may fix some of the K1’s flakiness for things like timing errors, display freezes and the slow stuttering camera.
I may try putting Kalico on all my printers with their stock Klipper host CPUs, K1 first than the SV07 and finally the Zero. Might also do the vanilla Armbian for the Sovols after learning more about potential gains and pitfalls. One or more of my printers might benefit from a higher powered SBC but SBC performance to price ratios have faltered and I need more convincing to take that further step.
I can’t imagine salvaging the mcu side of the zero’s mainboard to be very easy. On the host side, the zero is basically a BTT CB1, which implies a cleaner division of labor with a Mantra control board, presumably one of those would run the Zero but I haven’t looked into mechanical fitment etc.
It may be advantageous to replace the mainboard to handle more peripherals (more USB cameras, toolheads, fans with tachs, I2C sensors, end stops, controlled or addressable illumination, therms, etc). its not necessary though - this can be achieved with expanders.
Similarly, it may be convenient to replace the mainboard with something popular to support mainline, but it certainly is not necessary with all the groundwork laid by the existing github projects.