Since @FSF is now considering #RYF certification for devices that require binary-only, closed source firmware to operate, such as the #Librem5, we were wondering: should the RYF program be split into two tiers: RYF Basic and RYF Plus? No blobs allowed in the latter, even in ROM!
@RoboMuu You may need to change the machine XML to do that, which would mean a rebuild of the firmware. We're not aware of a runtime way to switch the PHB mode.
@RoboMuu@RaptorCompSys Sorry about that! We've cleaned up the digital graffiti as best as possible. Abuse reports are always appreciated, but long term @gitlab really needs to make it easier to mass delete accounts (or allow manual account activation, the captchas are not working well as can be seen).
Since this has come up a couple times, we'd like to ask if our hard-line open firmware stance is what you all would like to see, or if the P10 concerns are relegated to specific users. Let us know below!
Dear OSF Community, as you may know, on behalf @InsurgoTech, we are working on #coreboot-based Dasharo Trustworthy Computing for @RaptorEng Talos II and Talos II Lite. Beta testers are welcome! If you want to contribute to the effort, please subscribe to: https://t.co/Fve1YTZRfz
While we applaud the overall extent of source code available for the #POWER10 firmware stack, two key P10-specific firmware components remain closed source at this time. The first is the off-chip OMI DRAM bridge, and the second is the on-chip PPE I/O processor (links below).
We believe that, as an open ISA, POWER is still a viable path toward resolving these issues and restoring owner controllable computing to the market. We are very disappointed that @IBM chose not to walk this path with us, but they are just one closed vendor in a crowded market.
With #BigTech asserting so much post-sale control lately over the devices you ostensibly "own" (even previously owner-control friendly players like @IBM), there are nearly no options left for individuals and corporations that value privacy, auditability, and transparency... 😟
Source-free binaries and proprietary, use-restricted license here: https://t.co/8KOZXzr3Sb -- just one reason we are not doing P10 systems. If @IBM were to release a proper open firmware we would reconsider, but for now P9, *not* P10, is the only owner controlled / secure option.
@carlosedp@RaptorCompSys@ZephyrIoT@OlofKindgren When developed on a POWER host system, as we do, it doesn't even need a cross compiler! Over time, native execution in something like a QEMU environment would be practical, all we need to do is emulate the peripherals vs. the entire CPU on a POWER host.
@carlosedp@RaptorCompSys@ZephyrIoT@OlofKindgren We're definitely interested in seeing Kestrel ported to other FPGAs, especially others that support the fully open tooling. That said, there are key advantages to using a POWER-compliant CPU at the heart of Kestrel -- e.g. "compile once, run anywhere" for any POWER LE device.
@stewartsmith @mramboar @mpc7500v2 That said, we'd be quite happy to see a new port / rebase that retained our original feature set on top of the new OpenBMC APIs / services. At the end of the day, Zephyr almost feels like a more stable base / platform for our BMC requirements.
Our Kestrel POWER-based soft BMC continues to mature! Here's a screenshot of its internal Web server, which has fully working firmware upload capability as of this post. Check out the source and start collaborating with us on Kestrel project page! https://t.co/2sJw84IoCX
@stewartsmith @mramboar @mpc7500v2 Yes, it's a problem, one we're not too happy about either. The reason it happened that way is that, in addition to the boot time issues, OpenBMC still has far too much overall churn and missing functionality. We then had to implement said functionality on top as custom patches.
@pietrushnic@lpnplant We're always happy to collaborate on projects like Kestrel and merge changes from other contributors - just open a merge request on our Gitlab when ready. Our goal is to have Kestrel available and maintained as a ready to use reference implementation for secure, open BMC designs.
@pietrushnic@lpnplant Interesting! You could wire a Versa ECP5 board directly to your Talos II Lite and enable all Kestrel functionality:
https://t.co/jyZfHu2u9i
Our LPC HDL already has TPM cycles implemented, so Kestrel is ready to accept a TPM daemon implementation if you wanted to work on one!
@stewartsmith@mpc7500v2 To be fair, this isn't a huge issue for server operators. We keep pushing solutions outside of the server space, however, and in those markets boot time matters -- both from cold+dark to ready to start, and from ready to start to fully online. OpenBMC needs work in this area. 😉
@stewartsmith@mpc7500v2 To put that in perspective, when we load the bitstream via OpenOCD (vs. the internal ECP5 SPI Flash bootstrap) we're online in around 5 seconds. The ASpeed ASIC using the OpenBMC stack, with a nearly 20x faster clock speed, hasn't even initialized the kernel by that point.
@hughsient We're seeing similar, hence the focus on a Web server prior to any IPMI network daemons. In fact we'll probably prioritize Redfish and see if network IPMI is even necessary (IPMI BT is still required by the POWER hosts we support, so that's been implemented for some time...)
@hughsient At the moment it's still in early stages -- just getting the Web server up and running to this extent from the relatively raw Zephyr sources was challenging. The intent is eventually to support IPMI and Redfish via new server daemons.
@pietrushnic Depends on what you want to test! The basic BMC will function with just the ECP5 Versa board, but without a host attached to that board you're basically limited to booting the BMC and interacting with the Web server / BMC shell.