[Feature Request]: Add DTB Support for Built-in Wi-Fi on MKS KliPad

[ils15]

Dear Developer,
We kindly request the addition of Device Tree Blob (DTB) support to enable the built-in Wi-Fi functionality for the MKS KliPad. This enhancement would greatly improve the user experience and connectivity options for the device.
Proposed Changes
DTB Modification: Update the existing DTB file to include necessary configurations for the built-in Wi-Fi module.
Wi-Fi Driver Integration: Ensure proper integration of the Wi-Fi driver with the DTB configurations.
Automatic Wi-Fi Detection: Implement automatic detection of the built-in Wi-Fi hardware on boot.
Benefits
Simplified Setup: Users won't need to rely on external Wi-Fi adapters.
Improved Reliability: Built-in Wi-Fi support should offer more stable connectivity.
Enhanced User Experience: Streamlined out-of-the-box Wi-Fi functionality.
Technical Considerations
Identify the specific Wi-Fi chip used in the MKS KliPad.
Ensure compatibility with the existing Klipper firmware.
Consider power management implications for the built-in Wi-Fi module.
We believe this feature would significantly enhance the MKS KliPad's functionality and appeal to users. Thank you for considering this request.

https://torte71.github.io/InsideSovolKlipperScreen/rk3328-roc-cc_dts.html

EDIT: can you see this?

https://torte71.github.io/InsideSovolKlipperScreen/sovol_mods.html

[redrathnure]

Hello @ils15 ,
I am not sure can do this without having hardware for testing.

[ils15]

IF you want, i can colaborate and test with you

[redrathnure]

I may give you a hints about declaring a new boards. If your product is based on mkspi it should be not too hard. However, for me personally, I see no reason to invest my time in a product that I will not use or have no any other benefits from it, sorry.

[ils15]

I may give you a hints about declaring a new boards. If your product is based on mkspi it should be not too hard. However, for me personally, I see no reason to invest my time in a product that I will not use or have no any other benefits from it, sorry.

ok, but can i compile by myself and send a PR with new (not too new) product?
i saw someone make similar with another printer model i guess

about klippad
just need to add wifi internal module dtb i guess

[redrathnure]

Sure, you can. Actually there are few options here, depend how deeply you would dive (and how match time to spend:) ). Unfortunately I cannot say something concrete about klippad because I have no idea about it.

So, about options:

1. You may replace a dts/dtb file to your version. If your boards do not need any special kernel modules or other closed source components, it should work. Basically you extract dtb from working image/machine, rename it and put to the mkspi image, boot and check main functionality.
   pros: fast and easy, you may prove compatibility in 5-10 minutes. cons: it will work only if you do not need any special/closed software (e.g. see MSK Pi - Cannot make Screen Working #36 as non successful example). And of course, it is not persistence solution. You would need to redo these steps with each update.
   IMO it has sense only as preparation step, just to estimate your hardware.

2. You may add kernel overlay for your board. Means some customization on top of mkspi.dts. This option has sense if option 1 works and amount of changes are minimal.

3. You may introduce a new board, like it was done for mkspi. More work, most likely you would need to dive to schematic, dts syntax and may be some kernel patches. Of course it means that your have access to needed information (board schematic and specific sources/patches if there are any). It may take time, however you would get a images adjusted exactly to your machine. And even preinstall required soft. And you may contribute these changes back to Armbian repo (be contributor, getting images from their site etc)

This process is very depends of your goals and having access to required documentation and patches.

[ils15]

its a mks pi with a display (maybe a mks ts35) and built in wifi

[redrathnure]

Looks similar to #12

[torte71]

I think using overlay DTBs is a good approach and I already planned to give it a go.
(With the kernel being locked in prior images, it was just a one-time task to manually replace the DTB with the "sovolish" one, but now, as kernel-updates are possible and working, a more permanent solution is required. As a quick workaround, I use a dpkg hook that just copies over that special dtb whenever a dtb-package install/remove is detected.)
But before I open another can of worms with the dtb stuff, I want to get the rest of the system-/klipper-installation done (like resolving conflicts between networkd and NetworkManager).
"I'll be back." 😄

[redrathnure]

like resolving conflicts between networkd and NetworkManager

@torte71 Please check readme. There are (almost) no conflicts between them at least till you use networkd for CAN interface only.

[ils15]

I think using overlay DTBs is a good approach and I already planned to give it a go. (With the kernel being locked in prior images, it was just a one-time task to manually replace the DTB with the "sovolish" one, but now, as kernel-updates are possible and working, a more permanent solution is required. As a quick workaround, I use a dpkg hook that just copies over that special dtb whenever a dtb-package install/remove is detected.) But before I open another can of worms with the dtb stuff, I want to get the rest of the system-/klipper-installation done (like resolving conflicts between networkd and NetworkManager). "I'll be back." 😄

you need to patch supercapacitor module too
because this capacitor kill some mks personalized boards and a sovol workaround works great

[torte71]

@redrathnure NetworkManager and networkd enabled at the same time led to a long boot delay here (NetworkManager-wait-online.service blocked systemd-networkd-wait-online.service, until it timed out after ~2 minutes).
I think I got around this by using systemctl disable systemd-networkd.service and changing "renderer: networkd" to "renderer: NetworkManager" in "/etc/netplan/10-dhcp-all-interfaces.yaml" (or simply using "Network"->"Reset to defaults" in armbian-config once NetworkManager is installed).
Networkd will still be started as a dependency (e.g. timesyncd also depends on it), but now it doesn't cause a boot delay.
I can't say anything about CAN, as is doesn't exist on the Klipad50, but with timesyncd (and its dependency on networkd) working, I assume that this will work with CAN-bus as well.

[redrathnure]

@torte71 Wait a second, if you have no can why do you need to mess with NetworkD at all?

And @ils15 what this supercapacitor for?

[torte71]

Networkd is installed in the community releases from https://github.com/armbian/community/releases , which I wanted to use as the base for the Klipad50 replacement image.
But maybe your images would be a better choice - I'll try that tomorrow.

About the capacitor: I haven't seen any documentation for it. There is a makerbase service in the original image, which mentions a "supper"(sic) capacitor. It should shutdown the system if signaled by a gpio, but they have commented out the command for reading the gpio, so it actually does nothing but syncing the filesystem every 2 seconds: https://torte71.github.io/InsideSovolKlipperScreen/makerbase-soft-shutdown-files.html#rootsoft_shutdownsh
Looks like it's unfinished and not actually used for something. And I am curious as well, what patches and issues there are with it.

[redrathnure]

Networkd is installed in the community releases from https://github.com/armbian/community/releases

Looks like yet another "improvement" from Debian...

But maybe your images would be a better choice - I'll try that tomorrow.

Armbian conmunity and my images should be almost identical. Difference may be in preinstalled Kernel headers, but the kernel and OS should be the same.

About the capacitor: ....

Funny, I thought you guys talking about hardware capacitor :)

[torte71]

Armbian conmunity and my images should be almost identical. Difference may be in preinstalled Kernel headers, but the kernel and OS should be the same.

I've now compared your latest image 1.0.1-25.2.0-trunk with the community release 25.2.0-trunk.293 (trunk.298 does not contain mkspi for whatever reason).

The community image turned out to be more "bare-bone" than your image. Your image is ~500M bigger and comes with more preinstalled packages (NetworkManager, vim, mc, aptitude, ...).

Your image handles handles networking better:

• wifi setup in the firstlogin script works perfectly (with dtb file replaced before booting)
• no delay at boot from networkd vs. NetworkManager conflict

Whereas the community image

• just comes with networkd and requires the aforementioned steps to get it working together with NetworkManager
• asks for using wifi in the firstlogin script, but then simply continues without showing the setup dialog

So your images are more comfortable to set up. If you plan to continue offering releases in the future (even though your changes made it into mainline Armbian), then I'll recommend using your images as a base.

Funny, I thought you guys talking about hardware capacitor :)

Yes, it's the big brown package in the upper left corner of the photo which @ils15 posted here.
I don't know for sure, what the capacitor is actually used for, but I found that script mentioning a super capacitor, so I think they belong together and were once meant to achieve a proper shutdown when the power is simply cut.
Let's wait for @ils15 reply, what patch he is referring to in this reply to avoid wild speculations.

[nubecoder]

Hello all and thanks for all of the effort you've put into this already. 👍
My KLIPAD50s are now freed from Sovol's outdated software because of your work!

I don't think it's wild speculation to say that, based on the information available, @ils15 is likely referring to EMMC corruption, where Sovol's 2 second sync loop helps to prevent it when the OS isn't properly shutdown.

And FWIW, I've tested all 3 buttons on the board, none of them appear to effect either the enabled gpio85 or the rk805 input device...

Again, thanks for this! From the sounds of it, the MKS-KLIPAD50 will be getting a proper DTB / overlay fairly soon. ❤️

[edit]
ps - I believe the screen on the MKS-KLIPAD50 is basically a MKS IPS50.

[ils15]

I saw the script....

I think it installs a service in the systemd manager to detect system shutdown events. When the system begins shutting down, the service intercepts the process and sends a command (echo 0) to discharge the supercapacitor by toggling its control pin. After this step, the system shutdown continues as usual.

However, this method has limitations. For example, if the printer is powered off using the physical switch or during a power outage, the script cannot execute, leaving the supercapacitor charged.

MKS had previously advised users to wait around 5 seconds after turning off the system before flipping the physical power switch on the printer. This delay ensures the system fully powers down, preventing issues like eMMC corruption or board dead.

It seems likely that the supercapacitor was included to mitigate problems arising from sudden power-offs. By holding the board powered for a few seconds after the physical switch is flipped, it helps prevent data corruption. This feature may also address the issue where some users experienced their printer failing to turn back on after abrupt shutdowns.

In summary, the supercapacitor acts as a safeguard to provide a smoother shutdown process and enhance system reliability, particularly in scenarios where power is cut off unexpectedly.

Mks send this to all manufactures I guess, but some of the cannot implement property
Sovol still have a bootloop problem. But nothing with dead Motherboard I guess

[ils15]

I friend of mine talked about a solution he bad implemented. He push pwm tô 100% in capacitor pin tô prevent it. I think can be a solution too

[torte71]

What is "the script" you are referring to?
It would be great if you could post it, then I can mention it in the HowTo and include it in the final image.

[ils15]

Your makerbase-soft-shutdown.service inside repo

[nubecoder]

I'll see what I can find out about gpio100 and this supper capacitor.
I've got a multimeter hooked up to this KLIPAD50 here, which has not seen power in a good 30+ minutes, and this thing is sitting here with a steady 4.5v.
Once I can get a multimeter hooked up to a KLIPAD50 which is online, etc...
I'll see if enabling and setting gpio100 to low does anything to this supper capacitor 🤣...

[torte71]

I am unsure, if this script has any real effect, apart from the syncing (what may in fact reduce problems, if the power is just cut instead of shutting down first).
I could not measure any difference at the capacitor's voltage, no matter what I wrote to gpio100 (tested 0, 1, 255 and 65535). But that doesn't mean that there aren't any effects, or maybe it behaves differently on other board revisions (mine is rev. 1.2).

My new (klipperized) image will have this service included. If it didn't cause trouble in the original image, then it probably won't hurt in the recent one. And if one dislikes it, it can be removed with "dpkg -r makerbase-soft-shutdown-service".

Btw., that script does not intercept a shutdown. It is simply started at boot time, at that time it writes a "0" to gpio100 (once) and then constantly syncs the filesystem.
In the original Klipad50 image I could not detect any non-standard commands hooked into the shutdown process, and in the armbian-update.deb I didn't find anything like that as well. I could have overlooked something, but I rather think, that there is just nothing intercepting the shutdown.

[torte71]

@redrathnure

Status feedback on including the Klipad50 dtb into the Armbian build system:

I've rewritten the decompiled DTB from the Klipad50 board that it now uses symbolic names and references instead of constants and phandles, so it's better comparable to your and other dts files.

See here for the main differences: torte71@5351004
(The forgotten constants have been replaced in a later commit :))

Though I am not sure yet, if a dtb-overlay is the best option.
With a designated image for the klipad50, the firstboot script can already configure and use wifi to set timezone and locales automatically (the board has no ethernet).

[redrathnure]

Sounds like good news! A few points from my side:

1. I would not recommend to rename mkspi related patches/files. This may be a problem if you decide to open PR with your changes. I would advice to create a new files instead. You always may use IDE diff functionality to compare with mkspi related files.
2. In our case dtb-overlay has only one benefit - no need to support a new board and publish related images.
   2.1. In theory you may enable overlay before first run, but this is manual work (and looks like workaround)
   2.2. (If I understand correctly) overlays were introduced to disable/enable some specific device. Introducing a new board using overlays looks like a misusing of this mechanism
   2.3. In case of new boards (with board config, patches etc) you would also build and publish images. May be a bit more work, however looks better in long term. Plus you may have "fine tuning", e.g. preinstall packages, drivers or some other soft.
   2.4. In case of new board you may open PR to official Armbian repo. In this case more peoples may benefit from your research, so I would say it's a good idea. However there are few points to keep in mind: a) probably you would need to test a new images from time to time and b) seems "default Armbian image configuration" is not always the best for us (e.g. we newer use Gnome Desktop or full set of distros).

BTW, side question: have you managed to make screen work? Looks like SKIPR Mini board has very similar configuration.

[torte71]

1. I would not recommend to rename mkspi related patches/files. This may be a problem if you decide to open PR with your changes. I would advice to create a new files instead. You always may use IDE diff functionality to compare with mkspi related files.

I am not sure, what you mean exactly.
I've copied your mkspi.csc to "./config/boards/klipad50.csc" and your board_mkspi directory to "./patch/u-boot/u-boot-rockchip64/board_klipad50", so these are actually copies.
And in a following commit, I've replaced the dts contents with that for the klipad. I don't see, where I've renamed something. But of course I could leave out the first commit which contains your unmodified files and upload the modified klipad dts directly as the first commit.
Just guessing, what your point is...

2. In our case dtb-overlay has only one benefit - no need to support a new board and publish related images.
   2.1. In theory you may enable overlay before first run, but this is manual work (and looks like workaround)
   2.2. (If I understand correctly) overlays were introduced to disable/enable some specific device. Introducing a new board using overlays looks like a misusing of this mechanism

Not to forget that I don't have to learn the overlay syntax 😄. This simple form seems not to have any effects when activated, so I'd probably have to understand and use that fragment@ and __fixups__ stuff as used here.

2.3. In case of new boards (with board config, patches etc) you would also build and publish images. May be a bit more work, however looks better in long term. Plus you may have "fine tuning", e.g. preinstall packages, drivers or some other soft.

I did an automatic github build with this workflow which created a working image.
But I didn't understand, how you create your images. Are there any pre-made workflows for that purpose?

2.4. In case of new board you may open PR to official Armbian repo. In this case more peoples may benefit from your research, so I would say it's a good idea. However there are few points to keep in mind: a) probably you would need to test a new images from time to time and b) seems "default Armbian image configuration" is not always the best for us (e.g. we newer use Gnome Desktop or full set of distros).

I've started with a fork of your repo with the overlay option in mind. But sure, for a separate board definition, official Armbian is the place to go.

BTW, side question: have you managed to make screen work? Looks like SKIPR Mini board has very similar configuration.

Yes. Everything that worked with the original klipad buster image now works with the new dts/dtb (at least I didn't notice any degradation yet). The generated dtb file has the same contents as the original one (apart from the phandle references).
I'll join that discussion and see, if I can help.

[redrathnure]

I am not sure, what you mean exactly.
I've copied your mkspi.csc to "./config/boards/klipad50.csc" and your board_mkspi directory to "./patch/u-boot/u-boot-rockchip64/> board_klipad50", so these are actually copies.

and

See here for the main differences: torte71@5351004

May be I missed something, however I see BOOTCONFIG="mkspi-rk3328_defconfig" andrelated patches. Perhaps better solution would be BOOTCONFIG="klipad50-rk3328_defconfig" + rename target file in patch/u-boot/u-boot-rockchip64/board_klipad50/01-mkspi-rk3328-add-defconfig.patch. And probably non need for patch/u-boot/u-boot-rockchip64/board_klipad50/02-mkspi-rk3328-add-mkspi-changes.patch one.

Not to forget that I don't have to learn the overlay syntax

Oh, yeah :)

I did an automatic github build with this workflow which created a working image.
But I didn't understand, how you create your images. Are there any pre-made workflows for that purpose?

kinda lazy to configure GH workflows and I am not really sure a free credits would be enough. Plus usually I test images before publishing release.
My workflow looks like 1) build images locally 2) compress them + calculate checksums 3) test them and 4) publish release if everything is OK (all steps are done manually)

#!/bin/bash

branches=("current" "edge")
releases=("noble" "jammy" "bookworm")

cd ~/armbian_build
sudo rm -rf output/images


for branch in "${branches[@]}"
do
  for release in "${releases[@]}"
  do
    echo Building $release $branch image...

   ./compile.sh  BOARD=mkspi BRANCH=$branch RELEASE=$release    BSPFREEZE=yes BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,gpg,img INSTALL_HEADERS=yes BUILD_KSRC=yes INSTALL_KSRC=yes

  done
done

A few remarks here:

• BSPFREEZE=yes - not really sure it has sense now (after merging changes to Armbian repo). However I still block updates of kernel, bootloader and headers from official repo.
• BUILD_DESKTOP=no BUILD_MINIMAL=no - guess the cause is obvious.
• INSTALL_HEADERS=yes BUILD_KSRC=yes INSTALL_KSRC=yes - actually it's needed to build 3/d party kernel modules, Mostly drivers for "unsupported" WIFI dongles. However in your case you WIFI already on board, so maybe no sense to pack in extra 200-300MB of data.

I've started with a fork of your repo with the overlay option in mind. But sure, for a separate board definition, official Armbian is the place to go.

IMO it's good choice :)

Yes. Everything that worked with the original klipad buster image now works with the new dts/dtb

Asking more about OS level configuration. From DTS I see only one SPI bus with 2 chips, and not sure how it works from KlipperScreen side. Do you have fb device? Does kernel recognizes it as display and input device? Is it done by standard Klipper + KlipperScreen or do you need any "special" MKS services?

[torte71]

I am not sure, what you mean exactly.
May be I missed something, however I see BOOTCONFIG="mkspi-rk3328_defconfig" andrelated patches. Perhaps better solution would be BOOTCONFIG="klipad50-rk3328_defconfig" + rename target file in patch/u-boot/u-boot-rockchip64/board_klipad50/01-mkspi-rk3328-add-defconfig.patch. And probably non need for patch/u-boot/u-boot-rockchip64/board_klipad50/02-mkspi-rk3328-add-mkspi-changes.patch one.

Ah, OK. The defconfig created by the patch (and the patch itself) should have a unique name with klipad50 in it. And the second patch which modifies that defconfig once more can be eliminated by having all correct options already in the first patch,

I did an automatic github build with this workflow which created a working image.
But I didn't understand, how you create your images. Are there any pre-made workflows for that purpose?

kinda lazy to configure GH workflows and I am not really sure a free credits would be enough. Plus usually I test images before publishing release. My workflow looks like 1) build images locally 2) compress them + calculate checksums 3) test them and 4) publish release if everything is OK (all steps are done manually)

OK. I just thought that I've overlooked some nice automatisms.
If you ever consider using a workflow, feel free to ask. The creation of an image and a release is triggered by pushing a tag to github, so I have control, when it is built. I don't really like uploading such big files.

• BSPFREEZE=yes - not really sure it has sense now (after merging changes to Armbian repo). However I still block updates of kernel, bootloader and headers from official repo.

I am also thinking of enabling bsp and kernel updates. An automatic kernel update worked fine during my test with the community image (with a temporary helper, which copies over the klipad50 dtb file afterwards - required just until the klipad get's included in mainline).

Asking more about OS level configuration. From DTS I see only one SPI bus with 2 chips, and not sure how it works from KlipperScreen side. Do you have fb device? Does kernel recognizes it as display and input device? Is it done by standard Klipper + KlipperScreen or do you need any "special" MKS services?

None of the mks services are required for normal operation/hardware setup, or at least with your images.
The beep service emits a beep, when the touch is pressed. And there was the discussion about the soft-power-off.service, where it is unclear, if writing "0" to gpio100 prevents whatever damage from the "supper" capacitor.
These are somewhat hardware related, but that's probably not what you meant with "need special mks services".

(All following output is from a clean image, as we build it. No additional drivers, services, etc. installed.)

Framebuffer device is up and running:

root@klipad50:~# find /sys -name "*fb*"
/sys/kernel/security/apparmor/features/policy/outofband
/sys/class/graphics/fb0
/sys/class/graphics/fbcon
/sys/devices/platform/display-subsystem/graphics/fb0
/sys/devices/virtual/graphics/fbcon
/sys/module/drm_kms_helper/parameters/drm_fbdev_overalloc
/sys/module/drm_kms_helper/parameters/fbdev_emulation
/sys/module/fb
/sys/module/fb/parameters/lockless_register_fb

Touchscreen is available and working as /dev/input/event0.
Though I am not sure, what /dev/input/event1 is for. There is a power button on the side, which works like a power button on a PC (keep pressed for ~3 seconds to cut power, press again to power on), but it does not emit /dev/input/event1 events if I press it.

root@klipad50:~# find /sys -name "*input*"
/sys/class/input
/sys/class/input/input1
/sys/class/input/input2
/sys/devices/platform/ff160000.i2c/i2c-1/1-0018/rk805-pwrkey.5.auto/input
/sys/devices/platform/ff160000.i2c/i2c-1/1-0018/rk805-pwrkey.5.auto/input/input2
/sys/devices/platform/ff5c0000.usb/usb4/4-1/4-1.4/4-1.4:1.0/0003:1A86:E5E3.0001/input
/sys/devices/platform/ff5c0000.usb/usb4/4-1/4-1.4/4-1.4:1.0/0003:1A86:E5E3.0001/input/input1
/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input
/sys/devices/virtual/input
/sys/firmware/devicetree/base/pinctrl/pcfg-input
/sys/firmware/devicetree/base/pinctrl/pcfg-input/input-enable
/sys/firmware/devicetree/base/pinctrl/pcfg-input-high
/sys/firmware/devicetree/base/pinctrl/pcfg-input-high/input-enable
/sys/firmware/devicetree/base/__symbols__/pcfg_input_high
/sys/firmware/devicetree/base/__symbols__/pcfg_input

And the display is detected as a HDMI device:

root@klipad50:~# find /sys -iname "*hdmi*"
/sys/kernel/btf/dw_hdmi_cec
/sys/kernel/btf/snd_soc_hdmi_codec
/sys/kernel/btf/dw_hdmi_i2s_audio
/sys/kernel/btf/dw_hdmi
/sys/kernel/btf/dw_hdmi_qp
/sys/kernel/debug/dri/display-subsystem/HDMI-A-1
/sys/kernel/debug/dri/display-subsystem/HDMI-A-1/infoframes/hdmi
/sys/kernel/debug/clk/hdmi_phy
/sys/kernel/debug/clk/hdmiphy
/sys/kernel/debug/clk/sclk_hdmi_sfc
/sys/kernel/debug/clk/dclk_hdmiphy
/sys/kernel/debug/clk/hdmiphy_peri
/sys/kernel/debug/clk/pclk_hdmi
/sys/kernel/debug/clk/pclk_hdmiphy
/sys/kernel/debug/regmap/ff3c0000.hdmi
/sys/kernel/debug/regulator/reg-dummy-regulator-dummy/ff3c0000.hdmi-avdd-1v8
/sys/kernel/debug/regulator/reg-dummy-regulator-dummy/ff3c0000.hdmi-avdd-0v9
/sys/class/devlink/phy:phy-ff430000.phy.2--platform:ff3c0000.hdmi
/sys/class/devlink/regulator:regulator.0--platform:ff3c0000.hdmi
/sys/class/devlink/platform:ff430000.phy--platform:ff3c0000.hdmi
/sys/class/devlink/platform:pinctrl--platform:ff3c0000.hdmi
/sys/class/devlink/platform:ff3c0000.hdmi--platform:display-subsystem
/sys/class/drm/card1-HDMI-A-1
/sys/devices/platform/reg-dummy/regulator/regulator.0/ff3c0000.hdmi-avdd-1v8
/sys/devices/platform/reg-dummy/regulator/regulator.0/consumer:platform:ff3c0000.hdmi
/sys/devices/platform/reg-dummy/regulator/regulator.0/ff3c0000.hdmi-avdd-0v9
/sys/devices/platform/pinctrl/consumer:platform:ff3c0000.hdmi
/sys/devices/platform/ff3c0000.hdmi
/sys/devices/platform/ff3c0000.hdmi/hdmi-audio-codec.9.auto
/sys/devices/platform/ff3c0000.hdmi/dw-hdmi-i2s-audio.7.auto
/sys/devices/platform/ff3c0000.hdmi/dw-hdmi-cec.8.auto
/sys/devices/platform/display-subsystem/supplier:platform:ff3c0000.hdmi
/sys/devices/platform/display-subsystem/drm/card1/card1-HDMI-A-1
/sys/devices/platform/ff430000.phy/consumer:platform:ff3c0000.hdmi
/sys/devices/platform/ff430000.phy/phy/phy-ff430000.phy.2/consumer:platform:ff3c0000.hdmi
/sys/devices/virtual/devlink/phy:phy-ff430000.phy.2--platform:ff3c0000.hdmi
/sys/devices/virtual/devlink/regulator:regulator.0--platform:ff3c0000.hdmi
/sys/devices/virtual/devlink/platform:ff430000.phy--platform:ff3c0000.hdmi
/sys/devices/virtual/devlink/platform:pinctrl--platform:ff3c0000.hdmi
/sys/devices/virtual/devlink/platform:ff3c0000.hdmi--platform:display-subsystem
/sys/bus/platform/devices/ff3c0000.hdmi
/sys/bus/platform/devices/hdmi-audio-codec.9.auto
/sys/bus/platform/devices/dw-hdmi-i2s-audio.7.auto
/sys/bus/platform/devices/dw-hdmi-cec.8.auto
/sys/bus/platform/drivers/dwhdmiqp-rockchip
/sys/bus/platform/drivers/inno-hdmi-phy
/sys/bus/platform/drivers/dw-hdmi-i2s-audio
/sys/bus/platform/drivers/dw-hdmi-i2s-audio/dw-hdmi-i2s-audio.7.auto
/sys/bus/platform/drivers/dw-hdmi-cec
/sys/bus/platform/drivers/dw-hdmi-cec/dw-hdmi-cec.8.auto
/sys/bus/platform/drivers/dwhdmi-rockchip
/sys/bus/platform/drivers/dwhdmi-rockchip/ff3c0000.hdmi
/sys/bus/platform/drivers/innohdmi-rockchip
/sys/bus/platform/drivers/hdmi-audio-codec
/sys/bus/platform/drivers/hdmi-audio-codec/hdmi-audio-codec.9.auto
/sys/bus/platform/drivers/rockchip-rk3066-hdmi
/sys/firmware/devicetree/base/pinctrl/hdmi_i2c
/sys/firmware/devicetree/base/pinctrl/hdmi_i2c/hdmii2c-xfer
/sys/firmware/devicetree/base/pinctrl/hdmi_pin
/sys/firmware/devicetree/base/pinctrl/hdmi_pin/hdmi-backlight
/sys/firmware/devicetree/base/pinctrl/hdmi_pin/hdmi-cec
/sys/firmware/devicetree/base/pinctrl/hdmi_pin/hdmi-hpd
/sys/firmware/devicetree/base/hdmi-sound
/sys/firmware/devicetree/base/hdmi@ff3c0000
/sys/firmware/devicetree/base/__symbols__/hdmi_in_vop
/sys/firmware/devicetree/base/__symbols__/hdmi_cec
/sys/firmware/devicetree/base/__symbols__/hdmi_hpd
/sys/firmware/devicetree/base/__symbols__/vop_out_hdmi
/sys/firmware/devicetree/base/__symbols__/hdmi_out
/sys/firmware/devicetree/base/__symbols__/hdmii2c_xfer
/sys/firmware/devicetree/base/__symbols__/hdmi_backlight
/sys/firmware/devicetree/base/__symbols__/hdmiphy
/sys/firmware/devicetree/base/__symbols__/hdmi
/sys/firmware/devicetree/base/__symbols__/hdmi_in
/sys/firmware/devicetree/base/__symbols__/hdmi_sound
/sys/module/drm_kms_helper/holders/dw_hdmi
/sys/module/drm_kms_helper/holders/dw_hdmi_qp
/sys/module/dw_hdmi_cec
/sys/module/dw_hdmi_cec/drivers/platform:dw-hdmi-cec
/sys/module/snd_soc_hdmi_codec
/sys/module/snd_soc_hdmi_codec/drivers/platform:hdmi-audio-codec
/sys/module/drm_display_helper/holders/dw_hdmi
/sys/module/drm_display_helper/holders/dw_hdmi_qp
/sys/module/dw_hdmi_i2s_audio
/sys/module/dw_hdmi_i2s_audio/drivers/platform:dw-hdmi-i2s-audio
/sys/module/rockchipdrm/drivers/platform:dwhdmi-rockchip
/sys/module/rockchipdrm/drivers/platform:rockchip-rk3066-hdmi
/sys/module/rockchipdrm/drivers/platform:dwhdmiqp-rockchip
/sys/module/rockchipdrm/drivers/platform:innohdmi-rockchip
/sys/module/dw_hdmi
/sys/module/dw_hdmi/holders/dw_hdmi_i2s_audio
/sys/module/snd_soc_core/holders/snd_soc_hdmi_codec
/sys/module/cec/holders/dw_hdmi_cec
/sys/module/cec/holders/dw_hdmi
/sys/module/snd_pcm/holders/snd_soc_hdmi_codec
/sys/module/snd/holders/snd_soc_hdmi_codec
/sys/module/dw_hdmi_qp
/sys/module/drm/holders/dw_hdmi
/sys/module/drm/holders/dw_hdmi_qp

[redrathnure]

Nice, CC @bsafh

About If you ever consider using a workflow, feel free to ask. . Yes, but no. For now manual workflow gives more benefits (e.g. well readme with actual change log and tested images).

[nubecoder]

May I propose that the board be named mks-klipad50 or, I suppose, mksklipad50 if keeping in line with mkspi.

[torte71]

Good point, I think I'll change to "mksklipad50".

[torte71]

Are these LEDs working on your boards with your image (led-0 showing heartbeat and led-1 mmc activity)?
https://github.com/redrathnure/armbian-mkspi/blob/main/patch/kernel/archive/rockchip64-6.12/dt/rk3328-mkspi.dts#L122

	leds {
		compatible = "gpio-leds";

		power_led: led-0 {
			label = "firefly:blue:power";
			linux,default-trigger = "heartbeat";
			gpios = <&rk805 1 GPIO_ACTIVE_LOW>;
			default-state = "on";
			mode = <0x23>;
		};

		user_led: led-1 {
			label = "firefly:yellow:user";
			linux,default-trigger = "mmc1";
			gpios = <&rk805 0 GPIO_ACTIVE_LOW>;
			default-state = "off";
			mode = <0x05>;
		};
	};

On klipad50, I can't get them detected as a "gpio-leds" device, dmesg complains
platform leds: deferred probe pending: leds-gpio: Failed to get GPIO '/leds/led-0'
No leds subdirectory gets created in /sys/bus/platform/drivers/leds-gpio/ and no links to firefly:blue:power or firefly:yellow:user appear in /sys/class/leds/.
(But these leds do work in the original klipad image.)

Exactly as on your mkspi, they are bound to &rk805's gpio 0 and 1.

• led-0: gpios = <&rk805 1 GPIO_ACTIVE_LOW>;
• led-1: gpios = <&rk805 0 GPIO_ACTIVE_LOW>;

Our rk805 pmic sections use different "interrupt-parent" and "interrupts" (to match the original dtb), their other settings are identical.
(Here's a link to my mksklipad50.dts.)

mkspi pmic@18:

• interrupt-parent = <&gpio2>;
• interrupts = <RK_PA6 IRQ_TYPE_LEVEL_LOW>;

klipad pmic@18:

• interrupt-parent = <&gpio1>;
• interrupts = <RK_PD0 IRQ_TYPE_LEVEL_LOW>;

In rather desperate attempts I tried your mkspi settings for pmic (gpio2, RK_PA6) and sdmmcio-regulator (gpio2 - just because it uses the same gpio as pmic) and all logic combinations of these settings. But -as expected- no change happened.

If these leds don't work on your mkspi image as well, then the kernel might be the place to look at.
But right now, I am out of ideas, what to look for next.

[redrathnure]

MKSPI board has "hard soldered" LEDs to TX/RX lines of debug UART interface (USB TypeC port).

However SKIPR board has a true LEDs with working heartbeat indications. I have never tried to reconfigure them to something else, in real machine the board is hidden and I do not care about LEDs.

[redrathnure]

OEM mkspi image has prrtty strange irq mapping for rk805. Looks like it was mapped to some unsoldered pin, which leads to thousands interruptions per second. So I changed it according to public available schematic. 'IRQ 123, nobody cares' kernel error was gone, however I would not 100% trust mks documentation:)

[torte71]

Found it.
The module "pinctrl-rk805" needs to be loaded, if the pmic is to be used as a gpio-controller (led-0 and led-1 are connect to it). It creates the required /dev/gpiochip* device node.

Now I need to find out, why this module isn't loaded automatically. The "compatible" string in the devicetree should take care of that afaik, but for whatever reason it currently doesn't.

[torte71]

About the automatic loading:
Seems the pinctrl-rk805 simply does not have implemented scanning the devicetree for compatible devices.
I've added it to the list of loaded modules and now the leds work as expected.

For comparison: The pinctrl-rockchip module does such a check via

1. rockchip_pinctrl_probe() // which calls
2. rockchip_pinctrl_register // which calls
3. rockchip_pinctrl_parse_dt() // which matches against

static const struct of_device_id rockchip_bank_match[] = {
        { .compatible = "rockchip,gpio-bank" },
        { .compatible = "rockchip,rk3188-gpio-bank0" },
        {},

Whereas nothing like this is found in the pinctrl-rk805 module.

[torte71]

And talking about strange wirings, the "rtc" seems such a case on the klipad50:

If gmac2phy (ethernet@ff550000) is disabled, calling "hwclock" times out, printing hwclock: select() to /dev/rtc0 to wait for clock tick timed out.
If I enable that ethernet device, then "hwclock" works, at least for some time.
Until a "irq 33: nobody cared (try booting with the "irqpoll" option)" happens and IRQ#33 gets disabled, then "hwclock" times out.
Funny thing is, that on the original image, "hwclock" always times out, even though there is that ethernet device enabled (for whatever reason, as there is no physical eth connector on that board).

[torte71]

Maybe some of the links in my prior posts are broken now - I've renamed my repository from "armbian-mkspi" to "armbian-mksklipad50" and its "main" branch now points at the generated, symbolic dts (not at the simply decompiled version as before).
(I've edited my posts of the last 3 days to reflect these changes)

[torte71]

@redrathnure Thanks again for your support and your work on porting the Makerbase build framework.
The Klipad50 just got included in mainline Armbian: https://www.armbian.com/mks-klipad50/ .
Having your project & PR as a template made it much more easy for me. 👍
I think you may close this feature request now.

[torte71]

• BSPFREEZE=yes - not really sure it has sense now (after merging changes to Armbian repo). However I still block updates of kernel, bootloader and headers from official repo.

I am also thinking of enabling bsp and kernel updates.

From Armbian perspective, the kernels built from this (or my mksklipad50) project are customized ones, meaning that Armbian cannot offer updates for them, so using "BSPFREEZE=yes" is still recommended.

Whereas the community builds (or any other which was compiled from unmodified "armbian/build" checkout) use their well known precompiled kernels, making updates possible (also applies to bsp and dtb).
(Btw., image building works really fast when the kernel stuff is just downloaded instead of compiled.)

[redrathnure]

yeah, this one of reason why this repo and related builds are still existed here.
In any case it a good job, thanks for contributing.

[redrathnure]

@torte71 could you give a information about your build:

• boards names/labelings
• printer or kits with these boards
• link to custom images (if you are going to build them apart of armbian releases)
• link to comunity resources, wiki, whatever related to these boards/printers.

I would post this info on a main readme just to simplify life for people who looking for these images.

[torte71]

• boards names/labelings

The board is only available as the Sovol KlipperScreen, there's just the label on the board saying "MKS KLIPAD50 Vx.y".
Here is my hardware description and description of the supported hardware in Armbian images.

• printer or kits with these boards

The Sovol SV07 and SV07+ have that KlipperScreen installed by default.
For the SV06 and SV06+, the same device is available as addon (these are Marlin printers by default).
The hard- and software is exactly identical for all of them, they only differ in the preinstalled printer.cfg.

• link to custom images (if you are going to build them apart of armbian releases)

I am not sure yet, if I will provide my own builds in the future - but the networkd/NetworkManager issues with the minimal build from the community images speak for such custom builds.

If I decide to continue doing my builds, I will use this project, :
https://github.com/torte71/mksklipad50-armbian-images/releases
(These are built from an unmodified "armbian/build" checkout, so the kernel should be upgradable.)

In any case I will continue providing complete Klipper images, which aim to mimic the original Sovol images as exactly as possible (and meaningful):
https://github.com/torte71/mksklipad50-klipper-images/releases

Currently I am awaiting the first automated builds, they should happen next week,
And then I'll decide, how to procede (bugfixing or creating images).

• link to comunity resources, wiki, whatever related to these boards/printers.

I think my site is offering the most information about that device
https://torte71.github.io/InsideSovolKlipperScreen

It describes, how I create the Klipper images, the additional services that Makerbase installed on that device and all kind of stuff that I use for copy&pasting help in the FB groups for these printers.

Apart from this

• Sovol forums: https://forum.sovol3d.com/ (actually not much help going on there)
• Sovol groups on Facebook Sovol SV06 SV07 with a quite active community
• Sovol wiki

I would post this info on a main readme just to simplify life for people who looking for these images.

A link to my "InsideSovolKlipperScreen" would be a good choice, I guess. :)

[torte71]

From 3 weeks ago: #42 (comment)

2.4. [...] b) seems "default Armbian image configuration" is not always the best for us (e.g. we newer use Gnome Desktop or full set of distros).

Using HAS_VIDEO_OUTPUT="no" in the CSC file will generate Debian/Minimal and Ubuntu/Server images instead of Debian/Minimal and Ubuntu/Desktop(Gnome). Like https://www.armbian.com/nanopi-neo-2/

Maybe that's interesting for your mkspi project too?
Just as an alternative/additional option to your custom built Debian/Server images.

(Regarding my last post: I am quite sure that I will stop offering my own Debian/Server builds, as Ubuntu/Server works perfectly well as a Klipper base in my situation. But I know you have different requirements.)

Discussion about available options on Armbian forum
Changes / PR for mksklipad50: armbian#7807

[redrathnure]

Done