[Feature request]: WIFI not working on MKS SKIPR *MINI* 1.0 with Armbian-build #46
Comments
|
Just FYI "MKS SKIPR v1.0" and "MKS SKIPR Mini v1.0" are different boards. The first one is tested for my images, the second one not, because I do not have this hardware on my desk. What does it means for you:
From my experience, each new board adaptation starts from following questions:
|
|
MKS supplies an own systemd-service for WLAN - don't ask, I do not know why. the output on the **Buster ** image is the output on the Bookworm image is |
|
Disclaimer: I am not Linux kernel OR Debian configuration guru, so please double check information above and be ready that it is a useless crap...
I would start from DTS and kernel modules investigation. Till you will see inactive network device. And only after this jumping to NetworkManager, sustemD and other services. |
I'll start comparing the DTS files tomorrow The obvious difference here is that the SKIPR has no wlan onboard whereas the Mini does have one. I do not have acces to the schematic and I could not find anything about the wifi adaptations anywhere. There is no info available in which other printers this board may be used, it seems to be OEM only and is not listed in the MKS website or repos and not in the Tronxy website/repo. It does use the same Arm CPU and STM mcu. |
|
Yeah, I see. Then we use only information from worked dts and lsmod, hope it would be enough... |
Well, the MKS Buster image shows that it's a standard Broadcom wlan card (brcfm). Those modules brcfmmac and brcfmutils are present as kernel moduls in the Bookworm custom image and they can be loaded with modprobe. They "just" do not recognize the hardware.... (and are not automatically loaded, on the SKIPR without "Mini" they are of no use obviously). So it's rather unlikely that there is some unknown closed source blob for wlan. Hopefully the DTS comparison will help (they did put the DTS on the Buster image in /root/ for whatever reason, looks like they just did not clean up after the implementation, there are several not used things in /root/ and /home/mks/...) |
bsafh
changed the title
|
First quick glance at the DTS file in /root/ of the MKS Buster image: Hmm, rtl?? Not brc? Wrong file? No... the DTS is definitely the one which is used . And wlan0 is definitely working .. Strange naming though. Why isn't it that is not loaded, but wlan0 works ... There is no armbianEnv.txt in /boot/ on the MKS image, but in /boot/extlinux/extlinux.conf there ist the line This DTS/DTB is used on the MKS image on the exact Hardware the Bookworm image is intended to run. On the running printer with original MKS Buster image: Is it possible/sensible to use this DTS on the Bookworm image? Just rename it (to what name?) and copy? (Of cource make a Backup of the existing /boot/ first ...) As it is used on that exact hardware, the hardware definitions should fit? The DTS/DTB file is a copy from the working printer with the original tronxy/mks hardware and the original eMMC supplied by by TronXY/MKS, so if that does not match the hardware, the printer should not work?) |
|
Arghhh . I hit the wrong button on my smartphone .. I did NOT intend to close the issue, but I cn't reopen it... The chip on the actual board is an AMPAK AP6212 (AP 6212 written on it ...) But I find links to a Broadcom-AP6212 as well on github. There is no logo on the actual chip, just the marking AP6212. How to proceed? |
|
This seems to be the same problem on another rockchip 3328 based board with the same wlan/Bluetooth chip AP6212 #28 (comment) So, just taking the DTS/DTB from the MKS Buster image from /boot/dtb/ might actualky do the trick?? |
|
OK, a few points from my side: MKS Buster/OEM image uses Looks like MKS use the same WIFI module in different boards. I see some traces in MKS KliPad (Sovol printers???) and klipad50 (from QIDIs machines???). If it's true, you may gather some info from hteir resources (seems like a few guys manage to make wlan worked). So just a few random links from other issues:
... and from my experience diff cli is not really suitable for the compaction. It's better to use something more smarter, e.g. VSCode... So, I would say you may try to just swap dtb files and check how wlan works. If it OK, then let's compare DTS files and may be try to Funny fact: OEM image does not guaranty you correct configuration. I found errors in power domain, power and HDMI controllers in the original MKSPI images.... |
that's different. The SKIPR Mini looks like this
I know ... the "mksclient" (the one I converted to a static binary) program (assuming it controls the touchpad) displays a "RST" button (with "Firmware stopped, reset firmware?" above the button). Well, clicking it does reset the mcu - but it does also silently replace your printer.cfg with a faulty version from wherever. Not only are your adaptations gone, but the version has the direction of the extruder stepper motor reversed ... very helpful idea...
yes. diff is just a quick way to see whether two files are completely identical there are 3 versions of rk3328-roc-cc.dtb on the MKS image:
the first two are identical, the third one is smaller (1 kB) a quick glance with diff shows the main differences are that the two identical versions contain info about the touchscreen and the wlan card, and some spi0 pins which are missing in the third one (that seems to be the original one) This is the diff between them and here the rk3328-mkspi form this repo (I did not modify anything, just decompiled it) rk3328-mkspi.dts.txt the diff (I still have to install VSCode) shows quite a big number in pins being different in addition to the wlan and touchscreen stuff |
|
Have you try to swap After quick look at diff I would say:
|
|
... and a few hints about diffs:
|
most of those are present as well on the MKS SKIPR Mini / TroXY Klipper Upgrade Kit makerbase-client.service is the service with the binary only mksclient in den /home/mks/Desktop/... directory ...
|
|
I copied and ... (yes, that are public IPv6 addresses, but you still won't reach that system ... ) that looks like success! the rest of this Sunday is family-dedicated, cu l8ter |
|
Damn, I just realize they have LCD and Touchscreen related pins in OEM DTS: however there are no pin declarations. Most likely it's just leftover after "dirty" patching of mkspi image. This means your chances to have standard fb0 and input devices (with standard kernel modules) are pretty low. Perhaps you should look at #36 (comment) message and previous discussion. I have feeling |
Yes, I expected that I won't have the screen via KlipperScreen. With any luck, I might have the touchscreen via the "mksclient" program which seems to manage it. But that's for another day. wlan works now: my DHCP server does show AMPAK as vendor of the wlan card. this is the new hardware info ( |
|
And a few remark about WLAN success experiment:
Basically it means all changes only in DTS. They use standard kernel modules for it. Which is good news. This part may be easily wrapped as DTS overlay (see an example) and contributed to this and armbian repos.
Have a nice weekend :) |
|
)
upper left is the (metallic) Ethernet port. It's connected to the black socket on the right side (see from top).
|
there is no HDMI connector on the board anyway ... |
that would be nice :-) (though I never packaged anything to be excepted into official repos, but ... well, that would be good) |
|
The QR Code on the back reads The connector for the display ist labeled "H-UART 1", or "A-UART1" (the top of the first Letter is covered by the connector case). Is that any help for Göttingen the display work as KlipperScreen? |
|
No idea, to be frankly. This is match with 2 SPI declarations in OEM DTS file, but they specify |
|
Any dmesg logs related to spi, input, uart or serial words? |
|
I have a feeling that Sovol owners know how to make screen working. |
That's a good hint. I'll try that as soon as possible - probably next weekend, maybe I find a bit of spare time before that. |
yes, indeed there are This is from the running original MKS/TronXY image: |
|
@torte71 yes, that looks very much like a leftover. Seems they do not clean up after finishing their work. Which in this case might be a good thing. |
|
The kernel is different on the skipr-mini image.
And they behave differently with the display:
These are the changes from klipad50 to skipr-mini kernel-config I'll try, if I can force using the edid settings from the klipad50 when running the skipr-mini kernel. A rather desperate attempt, but as it can be easily checked: Edit: (But I strongly doubt, that this can create the missing "/dev/fb0") |
|
Okay, I'm starting to understand what they did, unfortunately. First of all, what the magic Why it's important in our context: Plus in case of OEM mkspi image they took standard display module and changed it. So even if you see What may be done:
|
on the Armbian mkspi image or on the original MKS/Tronxy image?
well, I guess the whole thing is buildt by MKS and just sourced by Tronxy (that's where I bought it directly from their shop). So I am not a customer of MKS, but of Tronxy. Tronxy supposedly does not even have the source code. So whom to ask for what exactly? I can do that, but my experience is that their will only be any answer if we ask very specific for a specific file e.g., not just for all source code. |
the screen is 100x58mm roughly (roughly 4.3 inch display?). It seems not to match anything on the Makerbase website though.
does that help? I can't determine what hardware that might be. |
On the mkspi image with the adjusted dtb (not the one with "spi_test_bus1_cs2"). (I found that command in the skipr-mini image, i.e. that image already does it at the end of the boot process) |
|
The KlipperLCD project might work. I already wondered, if the image you sent me, has ever displayed something on that screen: Then I did an strace of the "mksclient" binary, and it tries to open "/dev/ttyS1" and to connect to a wifi p2p point. |
|
the KlipperLCD project seems to use it as a KlipperScreen on a RaspberryPi, so it sort of uses it as a standard display. Unfortunately...
see here: joakimtoe/KlipperLCD#20 (comment) ... |
|
so ... that's bad, as expected. Where does that leave me? so no chance at all, I guess? |
I don't agree that KlipperLCD makes the display a standard display: It collects data periodically and then pushes this data to the screen:
Neither in the imports or the rest of the sources I see anything that would access a display device or XOrg. KlipperLCD is a mini replacement for KlipperScreen IMO, which just shows certain info. I don't know, if there are other possibilities to attach screens, e.g. via SPI or I2C, so that they are detected and supported as a standard display devices (I am no hardware expert, my playground is userspace and gui). But that would also require an existing connector to make use of these bus-systems. |
|
RE: KlipperLCD on the MKS Skipr Mini, Oren on the Infimech-TX unofficial discord has made quite a bit of progress on writing a custom firmware for the TJC screen to interact with KlipperLCD project. I've abandoned all os-level work on the Skipr-Mini due to work demands about 4 months ago, but they might be able to help you out: https://discord.com/invite/2qSEqESHKS |
oh yes, I see - sorry for the confusion |
|
This could be a solution: DisplayLink's video over usb3 There is also USB-C Alt-Mode, which allows DisplayPort over USB-C, but again, I have not the slightest idea, how well that works. And if it can be used with the usb3 port instead of usb-c. |
|
DisplayLink over USB3 in general works, I use that on Linux notebook to connect to connect to an USB3 docking station with 2 HDMI monitors - but that's an i7, not a MKS-Pi I have no idea what the USB-C connector on the board is for, it's not routed to outside of the case. |
|
Such an "internal-only" usb-c is on the klipad50 as well. Though the klipad has another usb-c port, which offers a serial console.
|
|
Another approach:
You can try copying the files from makerbase-client.list into the same location on the new system and executing the commands from makerbase-client.postinst to complete the installation. These (non-default) processes showed up with Start them in the same order, and with some luck, you'll see blinkenlights. |
That's a great idea! I'll try that tomorrow. The It did start, but it just crashed, most probably because I just copied the binary alone (+ the
|
|
Okay, now it has sense. Just to summarize current state:
And this may explain a magic around SPI bus and non existed HDMI interface :) To make it worked you would need "just" 4 steps:
About Host Agent. mksclient most likely is not the best option because a) nobody knows what is inside and b) it's is not clear how to run in in the costume images. So KlipperLCD looks like valid option here, at least as start point. LCD Firmware, in generally you already have worked one. Perhaps problem we do not know used protocol (yet?). In worth case you may experiment with firmware from other printers. So, firstly you may try to install KlipperLCD and check results. There are chance that it will works out of the box because usually there are no any reason to reinvent a Otherwise you may sniff a data sensed via serial/spi interface just to get a feeling what is going on here. And a few side notes:
|
I think I'll do that for now. I haven't got enough time to get KlipperLCD running. And once started, there is no going back because for KlipperLCD I have to flash the LCD firmware and I do not have the original firmware to flash it back in case that doesn't work. |
|
I am pretty sure, that #46 (comment) And btw., if the static linking of mksclient does not work, you can always use LD_LIBRARY_PATH variable to point it to a local copy of the required old libraries. |
Yes... thy are doing shady things: So they are replacing parts of Klipper. That's bad. Especially as they are based on Klipper 0.10.x, on my New Armbian Image I have the latest Klipper version.. (0.12.x??) Ah, that triggers another thought... Where did the old Klipper version store those sockets/device files and what were the names? |
|
You can boot the original image to locate these klipper files/directories and then create same-named symlinks in the new image to point them to their actual equivalents. But it may turn out to become a lot of work, e.g. if it depends on certain klipper behaviours, which have changed in the meantime. The changes to the mainstream klipper version (from the time when makerbase created that image) can be shown with "git diff" (in ~/klipper), "git status" gives a list of all changed or added files. Amongst others, the changes show some added gcode macros. You would have to find out for yourself, if any of those changes are required for mksclient to run correctly. I personally would not invest too much time into mksclient. |
Sounds like it, yes. Or get a Pi Zero2W + an HDMI touchscreen, put moonraker and KlipperScreen on that and connect via IP to the SKIPR Mini ... basically kill the problem by throwing enough money at it. But that's independent of any legacy stuff. |
|
I "solved" the screen challenge by buying a cheap 7 inch HDMI touchscreen from AliExpress plus a Pi Zero2W and installed KlipperScreen on that and connect to moonraker via WLAN.
|
|
Cool, Just curious what the point in skipr mini in this case? mkspi + hdmi screen OR skipr/mkspi kit with 3.5" screen would cost bit less and work bit better:) |
|
The original Tronxy "Klipper Upgrade Kit" has the SKIPR Mini in it, that's
the point ....
(that kit includes other hardware upgrades as well)
|
|
i really interested on it |
There are better boards. For example, on the SKIPR board, the CAN chip is only useable with crude hacks. The SKIPR mini from this thread is worse: noch HDMI, no SPI, only an undocumented serial display interface, limited RAM, totally outdated operating system and very old Klipper version on the eMMC image. But you cannot buy the SKIPR mini anyway, it's not listed on their website, it's an OEM board only. |
What happened?
The MKS SKIPR Mini v1.0 does have Wifi onboard, you can clearly see the Wifi antenna ... - the SKIPR v1.0 does not have Wifi.
This board (MKS SKIPR MINI) is part of the TronXY Klipper Upgrade Kit, I think, it's used as well in some TwoTree printers.
Well, the Wifi works well using the MKS original Armbian Buster Image supplied by TronXY.
The loaded wifi modules are brcmfmac, brcmfutil and cfg80211.
However, when booting the MKS SKIPR Mini with the unofficial Armbian Bookworm image from here, there is no Wifi adapter in the hardware list, no wlan0 interface and no brcfmmac module loaded ...
The mdoules are there in the kernel libs and they are present on the /boot/ partition, but they are not loaded.
I can't find any differences in /etc/udev/* either ...
I guess I'm missing something obvious, but I can't find it ...
Attached the
hwinfooutput for both boot imageshwinfo-buster.txt
hwinfo-bookworm.txt
How to reproduce?
boot the MKS SKIPR Mini v1.0 with the original MKS Armbian Buster image -> Wifi works
boot the MKS SKIPR Mini v1.0 with the Armbian Bookworm image from this repo -> no Wifi at all
Branch
main (main development branch)
On which host OS are you running the build script and observing this problem?
Debian 12 Bookworm
Are you building on Windows WSL2?
Relevant log URL
siee attachments
Code of Conduct
The text was updated successfully, but these errors were encountered: