rk3308B Sovol SV06 Ace Klipper using mks skipr as a starting point

[shepper]

Hi,

 

I'm new to the forums and am looking into replacing OEM Klipper firmware on a Sovol SV06 Ace,

The main board  looks very similar to the MKS Skipr with the following notable differences:

rk3308 B

emmc soldered on

No SD card.

Wifi/Bluetooth added - Original boards used realtek and the latest version uses Broadcom.

 

OEM wifi is hit or miss on connecting and hopefull will be improved with Trixie based Armbian.

Sovol has mostly complied with the GPL and source/configuration files are on github. IIRC the kernel version was 5.1x

 

I'm a long time Linux user (Slackware 8.1), have contributed OpenWRT builds and have built custom Linux kernels.

 

I think I've mapped out the install:

flash the appropriate ambian image to a formated USB2.0 drive - Ideally with wifi ssid/wpa key

ssh sovol@ip login sovol/sovol.  su, suspect the root passwd will be makerbase.

plug in usb, id drive in dmesg and mount

dd if /dev/usb* of=/devmmcblk*

Unmount drive and hopefully boot and access over wifi ssh.

Install/configure Kipper/Mainsail...

 

I have a recovery path that I have tested using rkdeveloptool/upgrade_tool and the original Sovol firmware.

 

I've perused the armbian github pages looking the MKS Skipr build but have not found it yet.

I'm willing to build a tailored (stripped if worthwhile) kernel.

I'd appreciate any comments about broadcom wifi access and if newer kernels and newer wpa supplicant builds improve access enough to make it worthwhile.

Comments on the overall plan.

Pointers 

[Torte]

Zitat

I've perused the armbian github pages looking the MKS Skipr build but have not found it yet.

According to https://github.com/redrathnure/armbian-mkspi?tab=readme-ov-file#technical-details the mks-skipr is just an mks-pi with an additional mks-robin-nano attached via uart.
That should be the reason, why there aren't separate mks-skipr images, only images for mks-pi.

 

Btw, the images for mks-pi and mks-klipad50 both use the same kernel. After replacing the corresponding .dtb file with the one from your original image, these images should behave identical.

 

Zitat

plug in usb, id drive in dmesg and mount

dd if /dev/usb* of=/devmmcblk*

Your approach of dd'ing the image from a usb-drive directly to the system that is currently running, sounds as dangerous as replacing a car engine while it's running.

 

You said, that you've successfully used rkdeveloptool for a recovery.
If that means, that you have flashed a *full* image to the emmc this way, then I would use this approach to directly flash the desired armbian image to that emmc (without using any other usb drive).

 

Or try to intercept u-boot from the original image to boot from an usb-drive (as I wrote here). Then you could 'dd' an image stored on that usb-drive to the emmc - but neither the source or the destination filesystem should be mounted/in use during that process.