Hacker News Reader

Comment by bad_hat_henry | Hacker News Reader

It says WiFi/Ethernet is done. It also looks like Power management is done? Getting GUI online? The pictures show a full desktop working.

View on HN

They have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution.

Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs it in the DT for Linux to use it:

https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59

That's literally all you need to get "graphics".

I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop".

FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers.

I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)

> but these aren't new drivers.

The GPU is probably going to be the monster here, unless you have found that it bears similarly to something else?

And Bluetooth. Bluetooth is always a joke.

Indeed, the GPU is likely going to be more work than everything else combined. We already have Alyssa Rosenzweig from panfrost working on that, and some other mesa folks. I'll be doing kernel work; I have some experience with Radeon GPU kernel-side drivers to lean on.

Alyssa already got her first triangle rendered the other day (from macOS, but without using any macOS Metal frameworks):

https://rosenzweig.io/blog/asahi-gpu-part-2.html

Kernel work is blocked on the lower levels of the kernel being solid first, but I'll be jumping on that as soon as I can.

Bluetooth is just Broadcom again. I think it's the usual UART HCI stuff? I saw a Corellium patch fly by to their UART driver related to that I think, adding hardware flow control support? That driver is a waste of time; I don't know why but Corellium are writing bespoke drivers for some (simple) hardware that already has near-compatible Linux drivers (PASemi I2C is another one). I already added M1 support to the Samsung UART driver in Linux in ~200 lines of patch, and that has more features that Corellium's bespoke >600 line driver. It seems in general they're happy to waste time on code and approaches that will never make it to upstream Linux without a complete rewrite/rethink... which speaks about their approach to this.

Ok, on the I2C driver because you are saying that:

A separate I2C driver was done because the PA Semi one is polled, not interrupt-driven.

Polling to wait on a slow bus such as I2C is brutal. And we don't know if the original PA Semi hardware even supports being interrupt-driven (in the same way?).

As such the drivers don't even have much in common here.

This is exactly why you talk to the author of the existing driver, and/or the maintainer if someone else, to figure out what to do and how to avoid code duplication.

That's what they aren't doing. Talking to anyone.

Sounds like support is further along than I thought!

I'm pretty sure the graphics support is frame buffer only at this point though.

Reply on news.ycombinator.com