Hacker News Reader

Comment by dpifke | Hacker News Reader

Does anyone know if this has a closed coprocessor equivalent to the Intel Management Engine? Or how open the firmware is?

View on HN

SolidRun CSA here. The SOC by itself will run with a fully OSS firmware, either u-boot or edk2. We are working on SBSA compliance and hope to have that ready for the production run of SOCs. While the entire device can be run with fully OSS firmware there will be some missing functionality. There are some configuration pieces for SERDES lanes that is handled by the microcode in the SOC. There is a binary firmware that is needed for the high speed networking. We are still discussing with NXP how this will evolve going forward.

For a management interface we have integrated what we call a micro-BMC. It is an STM MC, that is wired up to power up/down, thermals, and can reflash the SPI-NOR chip for recover and firmware updates out of band. This is a technology we are working on so the BMC can act more as an IoT gateway to handle many boards, vs each board needing to manage security individually. This chip is fully unlocked and open for developers to play around with.

Yeah, it has several coprocessors and operating modes below the operating system. But I don't see any docs on the openness of their firmware. And FWIW, any chip this complicated borderlibe requires a management Co processors as the main cores are way too power hungry for a lot of tasks, and need a lot of babysitting to initialize fully. The Cell processor in the PS3 is architecturally a SPI slave for instance.

> The Cell processor in the PS3 is architecturally a SPI slave for instance.

That's very interesting. Why did they build it like that? Do you have more information on this?

Yeah, the term to search for is "configuration ring". It's the big shift register of most of the stuff you need to baby sit in order to bring up the Cell.

If you are looking for cheap open hardware, there are not that many options around. Last practical one was the Asus C201PA with Rockchip ARM. The only closed component was the wireless chip, and that's easy to fix with a little Atheros dongle.

I'd love to hear about other alternatives if you know any.

I'm also wondering how the BIOS/UEFI equivalent on these machines works--I really hate how the Raspberry Pi does it (boot partition on SD card contains all data).

Apparently they are going for SBSA, which means it will have proper UEFI implementation, including possibly ACPI, so you will have normal UEFI experience.

At work we just got an aarch64 box from a vendor that has a very x86-like UEFI setup. Right down to the "BIOS" setup screens. It was very familiar seeming, but I'd rather have something like coreboot.

Coreboot only handles low-level initialization, it will still need a higher level payload unless you're going to hardcode your kernel to the board for every update.

Now, coreboot+tianocore uefi for somewhat open firmware...

This board appears to have some flash onboard, so it's at least better than booting from SD card.

The COM Express 7 module, has SPI-NOR for booting, a second SPI for UEFI secure variable storage, and eMMC for an embedded or recovery OS. Other than that you can boot your distro from eMMC, USB, Sata, or NVME.

The Minoca guys wrote a UEFI loader for RPi FWIW.

Could you please elaborate on how Raspberry Pi's approach is an issue?

Between the official boot firmware not being UEFI compatible and not being onboard it means you have to create a custom installation image and apply it to the disk rather than grabbing a generic installer and going. Also you need to do this for each bootable media you wish to create rather than once (and update each).

Philosophically, I actually like the RPi approach (ie. a simple image with device tree) a lot more than ACPI/UEFI. ACPI involves a whole super privileged virtual machine with byte code from god knows where, whereas device tree gives more or less complete control over to the kernel image (sure PSCI is a thing, but that's a lot more defined WRT boundaries to me than ACPI).

Basically an ACPI system is a lot easier to bootstrap because you don't need to support all of the little subcomponents of the board explicitly, but once you supprt devoce tree, you support the board in a much more complete and meaningful way, and it's truly your kernel running the show.

Reply on news.ycombinator.com