the_panopticon

This is great to see. Google has role-modeled open source hardware/silicon with efforts like https://opentitan.org/ and https://developers.google.com/silicon in the past, too. I wonder how this AI Coral NPU IP will differ from Nvidia's NVDLA https://nvdla.org/ effort with the ecosystem?

Very interesting. It sounds like tuning at the PTX level can increase workload efficiencies, such as quote "Specifically, we employ customized PTX (Parallel Thread Execution) instructions" from the DeepSeek folks https://arxiv.org/abs/2412.19437.

This article is a nice addition to the community since rarely is a complete rewrite of a firmware corpus possible. Speaking of Rust and host or boot firmware, the recently published https://techcommunity.microsoft.com/t5/surface-it-pro-blog/s... provides a nice experience report. Other work on moving Rust into EDKII for UEFI style firmware https://github.com/tianocore/edk2-staging/tree/edkii-rust is described in https://uefi.org/sites/default/files/resources/Enabling%20RU... and https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resour.... There's also guidance on Rust for firmware in a book chapter https://link.springer.com/chapter/10.1007/978-1-4842-6106-4_....

This is a good read. Dr. Blaise Agüera y Arcas was a keynote speaker at https://attend.ieee.org/newera/program/ here in Seattle a week ago but he didn't really get a chance to delve deeply into his position. During his slot there ended up being a lot of back-and-forth about whether AGI truly achieved or just seeing ACI, etc, among the folks from MS, Meta, Google, UW, and even https://www.dia.mil/ rep.

This reminds me of the saying https://en.wiktionary.org/wiki/success_has_many_fathers,_fai... that I’ve seen often played out in big companies, too.

There is still support for CSM in the open source https://github.com/tianocore/tianocore.github.io/wiki/Compat... and even nice projects like https://github.com/coreboot/seabiosto fabricate the CSM16 binary, but many vendors have stopped validating this path, including production of legacy BIOS option roms for adapters (net, gfx, etc) https://www.phoronix.com/news/Intel-Legacy-BIOS-EOL-2020. I still believe CSP's maintain some of this support in their hypervisors' guest firmware for legacy OS binaries/ISO boot support? Also since Windows requires UEFI Secure boot enabled by default and CSM has to be disabled for the UEFI secure boot path, this is another reason legacy BIOS boot isn't exercised so much these days. We could have added legacy oroms hashes to UEFI Secure boot implementations https://patents.google.com/patent/US8694761B2/en, too, but again folks pushed back in their zeal to remove legacy BIOS overall. We didn't add the CSM spec https://www.intel.com/content/dam/www/public/us/en/documents... to the PI https://uefi.org/specs/PI/1.8A/ since folks were hoping UEFI would remove the need for CSM. I still remember being challenged in the early 2000's by a long-time BIOS mgr at Intel "Is removing legacy a good idea with EFI? You know, we're really at legacy."

Fascinating work. The ARC std https://en.wikipedia.org/wiki/ARC_(specification) was used to boot the Dec Alpha Windows machines, along w/ MIPS, etc. Anyone know of other open source variants of that in the wild? At intel in 1998 the original efi spec was modeled on & inspired by Arc. The Intel boot initiative (IBI) in fact looked mostly like Arc. EFI (now UEFI) is sort of Arc + installable GUID-based interfaces (aka protocols) a la MS COM https://en.wikipedia.org/wiki/Component_Object_Model. Page 8 of https://www.intel.com/content/dam/www/public/us/en/documents... recounts some of those travails.