How about a new #OpenBSD story for breakfast (if you're having breakfast now, that is)?
The first episode of the story of OpenBSD and Motorola 88000 processors can be read at http://miod.online.fr/software/openbsd/stories/m88k1.html. With pictures!
| Github | https://github.com/tobhe |
| www | https://tobhe.de |
@cynicalsecurity @krzk Just some wild guesses but do you have any peripherals connected? Changed the NVMe at some point?
My firmware is sometimes a little weird and errors randomly, what has helped in the past is entering the boot menu and selecting the OpenBSD option manually.
@cynicalsecurity
> Do you reckon I should try that?
Not sure I was guessing it might be the reason why mine works and yours doesn't but I am not on the newest either.
> To answer you previous question - it started not booting since that change in 7.8-current which required you to do something (I forget what) and not doing it resulted in a fnctl fail just before booting the kernel
That doesn't ring a bell unfortunately and I don't see anything related in https://www.openbsd.org/faq/current.html either
How about a new #OpenBSD story for breakfast (if you're having breakfast now, that is)?
The first episode of the story of OpenBSD and Motorola 88000 processors can be read at http://miod.online.fr/software/openbsd/stories/m88k1.html. With pictures!
Fedora Asahi Remix 43 is now available, bringing some new goodies for hardware and software support!
https://fedoramagazine.org/fedora-asahi-remix-43-is-now-available/

We are happy to announce the general availability of Fedora Asahi Remix 43. This release brings Fedora Linux 43 to Apple Silicon Macs. Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all the exciting improvements brought by Fedora Linux 43. Notably, package management is significantly upgraded with RPM 6.0 […]
@valpackett @pid_eins There are some slight differences in how systemd-stub and dtbloader handle the EDID lookup. Ubuntu adpoted the systemd approach so it was easier to start from there.
From here onwards anyone can of course upstream them directly into systemd when they submit them.
FWIW I think CHIDs in the dtb are actually an idea worth exploring.
…for the system Linux is running on.
In v257 we added the general infrastructure to do such matching in systemd-stub (our EFI stub), based on "CHIDs" (which are hashes of certain SMBIOS identifiers). With v260 we now ship a database (contributed by Canonical, containing entries for various Snapdragon devices), that can be built into UKIs for suitable architectures that make them "just work", very similar to behaviour on PCs: the UKI contains both the Devicetree blobs, and this matching…
…by firmware, Devicetree is different there: it binds hardware to OS concepts, and hence is somewhat specific to both the system *and* the OS. And that makes things a lot harder in some ways, because it must be provided by the OS but is also device specific, and needs to be there in earliest boot, before the kernel initializes.
In systemd v260 there's now not only infrastructure in place to help with this, but we by default ship with a database that automatically selects the right Devicetree…