Info dump...

[nubecoder]

Hi, thanks for all of the effort put into this.
Your site and this repo helped to free my KLIPAD50s from outdated software.

1st, some of the 'unknown' binaries.

hid-flash:
The hid-flash binary found in the /root/ folder is indeed the STM32 HID Bootloader Flash Tool.
(Which is also the source of Klipper's lib/hidflash).
Using strings will output:

+-----------------------------------------------------------------------+
|         HID-Flash v2.2.1 - STM32 HID Bootloader Flash Tool            |
|     (c)      2018 - Bruno Freitas       http://www.brunofreitas.com   |
|     (c) 2018-2019 - Vassilis Serasidis  https://www.serasidis.gr      |
|   Customized for STM32duino ecosystem   https://www.stm32duino.com    |
+-----------------------------------------------------------------------+

Which aligns with:
https://github.com/Serasidis/STM32_HID_Bootloader/blob/master/cli/main.c#L77-L82
But it has been customized, the usage message was the giveaway:

Usage: hid-flash <bin_firmware_file> <comport> <delay (optional)>
For example:
./hid-flash /home/mks/klipper/out/klipper.bin ttyS0

And that aligns with MS1987's repo here:
https://github.com/MS1987/STM32_HID_Bootloader/blob/master/cli/main.c#L87
So, I believe this repo is the source: https://github.com/MS1987/STM32_HID_Bootloader/
(It also has the most changes of any public fork.)

I have not yet gotten around to testing hid-flash to see, but I'm hoping it can provide a means to updating the mcu without the need to use the SD card slot. 🤞

uart:
The uart binary found in the /root/ folder is a TFT screen firmware updater (used for QIDI 3d printers).

# strings uart | grep root
    /root/800_480.tft

Ref:
https://github.com/QIDITECH/QIDI_PLUS3/blob/main/main.cpp#L95

udp_server:
The udp_server binary found in the /root/ folder is a web server for managing the /root/www/dev_info.txt file.
It listens on port 8990 (port 8989 is also opened but doesn't seem to be used) and supports the following routes:
GET /printer/dev_name
This returns a json blob like:

{
    "result": {"dev_name": <NAME>}
}

`GET /printer/dev_name?name=<NAME>`
    This writes the provided name to the `/root/www/dev_info.txt` file.
    The `/root/www/dev_info.txt` file's original content is 'QIDI'.

I have no clue why this exists. I suspect it's Makerbase reusing OS images / builds and leaving leftovers behind.

Other Sovol / Makerbase modifications:
Sovol's power loss recover is more based on YUMI_PLR than it is klipper-plr. Although the former looks to be derived from the latter anyways.
But the PLR also includes modifications to KlipperScreen. I'm planning on compiling the necessary changes into patch files so they can be reapplied to KlipperScreen mainline.

Other:
And lastly, SOVOL_MKDEB...
Based on the hid-flash connection mentioned above as well as the default KLIPAD50 image Sovol provides' bash history showing:

# cat home/mks/.bash_history | grep MS1987
git config --global user.name "MS1987"
git remote add origin https://github.com/MS1987/KlipperScreen.git
git clone https://github.com/MS1987/KlipperScreen.git
git clone https://github.com/MS1987/KlipperScreen.git

This seems like as close to an official repo as we have for Sovol's Debian package based updates.

Images:
And now some images from this forum thread:
https://forum.sovol3d.com/t/mks-board-inside/3384

V1.0:

V1.1:

V1.0 & V1.2:

[nubecoder]

I almost forgot...
I had dug this up as well:
https://github.com/philmmanjaro/linux-bootsplash
It appears to be the patch files for armbian's bootsplash-packer:https://github.com/armbian/build/blob/master/packages/blobs/splash/bootsplash-packer

Specifically, the documentation patch and the binary patch it's self.

I've not yet ripped out the code and looked at it to see if it's possible to reverse the packing process or not.
Hopefully this could be used to extract the images from Sovol's bootsplash in order to create a plymouth theme.

[torte71]

Wow, nice investigation results!
And it would indeed be very nice, if it was possible to directly flash the board using hid-flash, as the SD-card option is extremely picky about the filesystem, partition- and sector-size. Not to forget the "always-use-a-different-firmware-name.bin" thing.
That almost drove me nuts.

[nubecoder]

Regarding klipper.bin mcu updates w/o opening the printer to get to the SD card slot...

(On my SV07_Plus)
I've tried an SD-WIFI.
It's slightly too large and blocks front panel.
The mcu board doesn't appear to provide enough power through the SD card slot alone.
I didn't bother checking with supplemental power, since it is too large.

As far as flashing via hid-flash... No luck so far.

mks-klipad50:MKS-KLIPAD50:# ./hid-flash firmware.bin ttyS0

+-----------------------------------------------------------------------+
|         HID-Flash v2.2.1 - STM32 HID Bootloader Flash Tool            |
|     (c)      2018 - Bruno Freitas       http://www.brunofreitas.com   |
|     (c) 2018-2019 - Vassilis Serasidis  https://www.serasidis.gr      |
|   Customized for STM32duino ecosystem   https://www.stm32duino.com    |
+-----------------------------------------------------------------------+

> Trying to open the [ttyS0]...
> Open the [ttyS0] successfully
> Sending <reset pages> command...
> Error, no ok receive, timeout and exit!!!
> Finish

&

mks-klipad50:MKS-KLIPAD50:# ./hid-flash firmware.bin ttyUSB0

+-----------------------------------------------------------------------+
|         HID-Flash v2.2.1 - STM32 HID Bootloader Flash Tool            |
|     (c)      2018 - Bruno Freitas       http://www.brunofreitas.com   |
|     (c) 2018-2019 - Vassilis Serasidis  https://www.serasidis.gr      |
|   Customized for STM32duino ecosystem   https://www.stm32duino.com    |
+-----------------------------------------------------------------------+

> Trying to open the [ttyUSB0]...
> Open the [ttyUSB0] successfully
> Sending <reset pages> command...
rcv 2 data:(�
rcv 2 data:C�
rcv 2 data:�
rcv 2 data:,�
rcv 2 data:!|
rcv 2 data:P�
rcv 2 data:,
rcv 2 data:�l
rcv 2 data:�,
> Error, no ok receive, timeout and exit!!!
> Finish

No options for baud rate or anything appears to be offered / available.

And it may be the case that the hid-flash binary is a leftover from some other printer / board and that Sovol hasn't installed that bootloader.
If that is true, then we would need to first flash the bootloader with an ST-Link (or similar).
And if that's the case, I'd rather be looking at katapult as, I believe, that's more commonly used in the community.
At least the ST-Link V2 (clone) is pretty cheap.

And as an absolute fallback, I have an SD card extender (sd -> sd, 25cm), but don't have a clue yet as to where I would choose to mount it.

[torte71]

I had the "normal" users in mind, as problems getting the printer flashed are quite common in the FB groups.
If it doesn't work without extra hardware, then it's no option for this case though.
So let's just hope, that there won't be too many klipper updates which require flashing the printer board. 😄

[nubecoder]

Yeah, absolutely, for 'normal' users, I'd think the best option for future MCU firmware.bin updates would be the SD card extender (sd -> sd, 25cm).
Open up the printer once, install the extension, and then it's easy access to the SD card from then on.

And for those who are more adventurous, katapult is probably the [best] solution.
... The SV08 folks 'get' to flash katapult to 2 different control boards (MCU & toolhead).

[nubecoder]

Alternate / updated version of Makerbase's automount service, buried in the SV08 source:
https://github.com/Sovol3d/SV08/tree/main/home/sovol/usbmount
Note that it references /home/sovol rather than /home/mks.
And it kinda looks like some of the functions from auto-fresh have made it into usbmount.

And there's certainly some overlap with the SV08 sources.
The patch folder includes some KlipperScreen changes, including a plr.py which is almost identical to the one in cluded in Sovol's KLIPAD50 image.
There's a plr.sh and a plr-old.sh, etc.
There's a good bit of variance between the plr*.sh files and what's in the KLIPAD50 image and TBH, I've not fully grokked what those scripts are doing other than saving state and a bunch of sed replacing, etc. during recovery.

[torte71]

Finally I found the time to include your additions.
I was busy preparing the integration of MKS-Klipad50 into mainline Armbian. With the release being scheduled for Feb. 20th and updated nightly images expected for next thursday, I had not much "air" for other things.
I'd like to keep this "issue" open, as it contains much more details than I included directly on the pages, and as an open issue, it will be easier to find.
Thanks again for your contributions.

[nubecoder]

Hey, thanks for the update, I'm happy to have been able to contribute something.
You've done really great work here, literally bringing new life to the mks-klipad50. ❤

There's still a long list of things I'd like to do, but sadly, my time is often limited, so no promises.

• Reverse the armbian-bootslapsh and create a plymouth theme from it.

• Get the KlipperScreen patches for enabling/disabling the screen beep and power loss recovery into a repo.

  • The power loss recovery script is a very manual process (which I failed at in my limited testing) w/o the KlipperScreen patches.
  • (I've successfully added the screen beep, but have not attempted the power loss recovery.)

• Build, flash and verify Katapult.

  • The requirement for additional hardware is a deterrent, but verifying and documenting options isn't a bad thing.