Hacker News Reader

Comment by notaplumber1 | Hacker News Reader

The recently released OpenBSD 7.2 boots and installs on it, support for the same Qualcomm Snapdragon SoC used in the ThinkPad x13s was added during last release cycle, so support for the Microsoft Dev Kit 2023 came for the most part for free.

https://www.openbsd.org/72.html

OpenBSD developer Patrick Wildt shared boot messages (dmesg) here: https://twitter.com/bluerise/status/1585584481854816256

Another UK tech reviewer Alex Ellis showed it booting OpenBSD into X11: https://blog.alexellis.io/linux-on-microsoft-dev-kit-2023/

View on HN

Yeah I don't get how Linux is running on the Thinkpad and openbsd was able to boot but a device trees is the blocker for Linux? Are they just on some distro that doesn't have the new kernel packaged?

Oh, it's because of "APCI" mode working with openbsd apparently...

The upstreamed Qualcomm drivers in the Linux kernel require a device tree from the vendor which doesn't exist yet for this machine, I believe the Linux community has something cobbled together for the ThinkPad x13s, or got something from Lenovo.

> Oh, it's because of "APCI" mode working with openbsd apparently...

Indeed, OpenBSD attempts to support these machines to some extent in ACPI mode, but from what I read the ACPI tables are in bad shape/incomplete. "Good enough for Windows, ship it.".

> but from what I read the ACPI tables are in bad shape/incomplete. "Good enough for Windows, ship it.".

It is a bit more nuanced than this. Qualcomm ships a giant custom (mandatory, most the platform will not even work without it!) driver stack on Windows and uses ACPI definitions more than most x86 platform vendors, to the extent that it even exposed a bug in the Windows ACPI implementation when an ACPI method return buffer would exceed 64 kB so since this generation of SoC a lot of the Windows drivers instead bundle their own 'subset' of certain ACPI buffers and the main DSDT is empty as a result.

Linux on ARM still doesn't really use ACPI except where forces more influential than Qualcomm managed (e.g. SBSA?) so even downstream Linux kernels for Qualcomm still use DT.

Appreciate the additional context. It does seem like though a lot of magic is contained in the Qualcomm Windows drivers, with large parts of the ACPI tables being stubs or broken (requiring hardcoded driver quirks/workarounds).

Wonder if that means alternative OS's will eventually reach the Galaxy Book Go. Its rock bottom price intrigues me but it seems to lack dev support in that regard. Maybe these attempts to support similar specs of machine will trickle down to it.

Thankfully from the kernel perspective the Galaxy Book Go SoC is pretty well supported because Chromebooks did ship with the same SoC.

However, that specific device doesn’t have good support. Would take some developer time to do so… (and not sure if that will happen)

One singular guy seems to be working on it but who knows really how far they'll get? https://www.reddit.com/r/GalaxyBook/comments/yfefif/finally_...

I believe the Samsung Galaxy Book Go was tested with OpenBSD during the initial development for the ThinkPad x13s, keyboard support was added in this commit.

https://github.com/openbsd/src/commit/74edc71ccae4051eda11fa...

Many of these older generation "Windows on Snapdragon" laptops unfortunately did not use fast NVMe storage however, only slow eMMC and eUFS (Universal Flash Storage), the latter currently being unsupported by OpenBSD.

As best I can tell, there are exactly two comments in that file (I don't count the licensing and ahem CVS metadata), and neither of them add any enlightenment at all. Kernel development must be a very special culture. I tried finding the equivalent file in the Linux kernel, but while looking I saw there is at least one example of commentary to go along with a struct: https://sourcegraph.com/github.com/torvalds/linux/-/blob/dri...

Apologies, I was pointing out the commit message itself rather than the contents of the commit, it's indeed full of magic numbers. It's reverse engineered, there are no docs from Qualcomm.

This is commit is plumbing work fixing GPIO support, which indirectly makes the keyboard work. I don't have any boot logs for the machine, but as I understand they have standard Microsoft-compatible HID keyboards/touchpads that work with OpenBSD's existing drivers.

https://man.openbsd.org/qcgpio

https://man.openbsd.org/qciic

Yes, sorry, I wasn't directing the vile at you, that was just the first time I had seen a file from the OpenBSD kernel and was shocked at how aggressively opaque it was

And, to your point, if it was reverse engineered, that's more reason to comment, not less, because (a) memory is fleeting (b) if I wanted to contribute, I could read along about how Zen Master OpenBSD Reverser found those so I could go find more

Reply on news.ycombinator.com