sudo iw wlP2p1s0 scan
command failed: Network is down (-100)
…which is kind of logical as the system is locked in “in-flight mode”.
Installed Intel AX200. ...but it is hard blocked
sorry you might need to bring it up first
sudo ip link set wlP2p1s0 up
sudo iw wlP2p1s0 scan
sudo ip link set wlP2p1s0 up
RTNETLINK answers: Operation not possible due to RF-kill
yes, looked around
maybe the adapter requires some kind of secure boot uefi environment
it seems there’s a utility called “mokutil”
“sudo zypper install mokutil”
and “sudo mokutil --disable-validation”
reboot ?
but this is probably way off track
When troubleshooting no time is wasted. I am thankful for the time you put in.
My personal guess is that ACPI and/or UEFI is the culprit somehow. It seems a Rockchip 3588 system should use device tree mode but I can’t tell if my system does. Everything is still suspected until proven otherwise, it seems.
So… trying another distribution for reference.
Downloaded the image for Debian Bullseye, flashed it to a SD memory and booted the machine.
The good news is that in bullseye the AX200 works out of the box. Both wifi and bluetooth.
The bad news is that the hardware works fine in bullseye but not in Tumbleweed. So it has to be software related. So now I have to find something that hardblocks the ax200 in software. Imagine that.
So I’m comparing to a third distro; Armbian Jammy (with panfork).
Wish me luck.
Oh, by the way… mokutil says that my system isn’t locked.
Could not get anything on the display with the Armbian Jammy experiment.
Using the kernel parameter noacpi doesn’t fix the hard block.
rfkill is controlled by a gpio. It’s better to use devicetree instead of acpi because that is defined in devicetree.
Yes, using Device Tree Mode is suggested by the EDK UEFI firmware that I’m using to boot from NVME. If I can find the setting for switching to device tree mode, the firmware apparently installs a DTB compatible with (most) Rockchip SDK Linux 5.10 legacy kernel variants. Would this be good enough for the 6.8 kernel of Tumbleweed?
And, out of curiosity, how does the GPIO control the bluetooth and wifi? The hard block of rfkill was pointing to a hardware switch but it never hit me that the GPIO might be involved.
There are two pins on the M.2 interface that allows wireless functionality to be killed, pin 54 and 56 to be exact. Only when they’re pulled high is the card allowed to operate.
If you’re running the upstream or collabora’s 6.8 kernel, these pins were not described in the device tree, so they can’t be controlled by software.
If you absolutely need to run upstream kernel, wait for 6.9 release, or you can try isolating pin 54 and 56 on the card with a piece of adhesive tape, or you can try applying this patch to the 6.8 device tree.
And no, do not attempt to run the 6.8 kernel with 5.10 DTB. The format is different.
OpenSUSE Tumbleweed uses a fairly “upstream” kernel, afaik, but in the meantime I am trying out other distributions to see what the experience will be like and that is quite enjoyable in itself. I have an Ethernet cable plugged in so I can wait for the wireless stuff.
The thing that worried me was that I replaced the stock pigtails with shorter ones. I’ve never done that before so I wasn’t sure that I had assembled everything correctly. As Tumbleweed blocked the interfaces there was no way of knowing if the hardware was working properly.
But trying other distributions (Debian and Armbian) erased that worry. The hardware works fine and communicates with the router and Bluetooth peripherals the way they are supposed to. In fact, the reception of the wireless is the best I’ve ever had on a device. Very happy about that.
So I guess I can wait for now and report on the progress as it happens on the openSUSE side of things.
Hello Hukka,
I was able to install Opensuse Tumbleweed . Pcie NVME disk is recognised.
Iwlwifi does not load iwl-firmware properly. I am now with kernel 6.9 rc7.
Do you have more information?
Regards
Uli
Well, all I need right now is that the switch to turn off the hard block should be in kernel 6.9. If you’re using the RC then it should be there. I don’t know more than that at this time.
1 Like
Hi, I’m on the newest OpenSUSE Tumbleweed with kernel version 6.11 and face the same issue. Have you happened to find a resolution? rfkill list all still shows the following and doesn’t seem to make the setting tweakable by user (i.e. “soft blocked”)
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
In Tumbleweed Arm I’m still using wireless keyboard and mouse (with a USB dongle) and an ethernet cable, sorry to say. Neither bluetooth nor wifi with the AX200 module. I can wait.
Riek’s Ubuntu variant has both bluetooth and wifi working.
Testing the new Armbian release (24.11) later this week.
Thank you for your reply. So based on your thread, it seems Debian-based systems are working. I’ll try Debian and Ubuntu tomorrow. Hopefully it works and I don’t have to return my new laptop.
Things are a bit more complicated than that.
Joshua Riek has done a lot of work to make Arm-based computers a valid option for a lot of people. His variant of Ubuntu has better support for Arm hardware than what it is based on.
The same can be said about the Armbian releases. A lot of effort has been put on making the Arm architecture almost as easy to use as the (more common) Intel and AMD offerings.
The OS releases from Radxa are well made but use a slower (more conservative) release cycle, which offers better hardware compatibility but without the newest drivers.
None of above can be designated “official” Debian or Ubuntu releases. Using one of the above options will give you a computer that you can trust, but all of them have added value compared to the base distributions. They are all tweaked for Arm hardware and thus not quite “standard”. Keep that in mind.
I don’t have a preference when choosing between debian- arch- or rpm-based distributions. I use a bit of everything and distrohop if I need to. All my computers are Arm-based, though.
1 Like
Thank you for your reply. I see what’s going on rn. I actually just tried Debian and it doesn’t work. I also discovered the previous kernel fix was for rockchip only so is unlikely to go to my AMD cpu laptop I guess?
I’ve done some extra search during the day and it is evident now my problem was caused by some crappy, untweakable setting in BIOS. My best shot now is probably just insulate tape the two hardware lock pins.