marcan eh? are you by chance https://twitter.com/marcan42 ;-)?
I can not wait for proper linux -- installable by a noob like me on an m1 -- to be available. Thank you for the 100x time again for your efforts here
I can not wait for proper linux -- installable by a noob like me on an m1 -- to be available. Thank you for the 100x time again for your efforts here
Easily installable Linux shouldn't take much longer, for those adventurous enough to be happy with a bunch of missing hardware support (but still a usable machine for a subset of use cases). We're pretty much tying up loose ends to get to that point now, I have a quickly shrinking list of TODOs. Of course, "proper" support for everything will take longer :-)
Seriously though, a big part of my role in the first year has been building tooling to make that part of the process efficient and enjoyable for everyone. We have a Python REPL for interacting with the bare metal hardware, scaffolding for building prototypes of hardware drivers in it (e.g. register and register map definitions), things like the ability to run functions on another CPU core for SMP tests, hardware exception handling so it's actually hard to crash and have to reboot, and even a hypervisor that can run full macOS and inspect all of its hardware accesses, with a rich event tracing framework that goes from raw register maps to coprocessor message passing to decoding remote procedure calls with C++ argument unmarshaling between firmware and the OS, in both directions. All controlled from any host machine running Linux or macOS, over a simple USB connection with the target.
Something that's always fascinated me are drivers -- those lowlevel bits of software make everything so nice. Sucks when something isn't supported. But it's one thing to take a spec and having docs and things to write one but soemthing clearly more amazing to have to reverse engineer something and then write a driver for it.