Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
SoCs and Blobs
One problem Dale mentioned with regard to supporting the N800 was lack of documentation. Most ARM SoCs these days come with a GPU and a DSP embedded on the same die, and getting the most from the device requires supporting both. I asked Dale how difficult it is:
So far, OpenBSD has not supported any ARM SOCs with GPUs and DSPs. To support a DSP in a secure manner would be tricky. Allowing userland to download code directly to the DSP could result in an insecure system; however, requiring all DSP code to be in the kernel or in LKMs would be limiting. This would be a challenge to do well.
An interesting problem. The DSP on many of these chips typically has a higher level of privilege than userspace code should be allowed. This isn't a problem for a lot of applications, where the DSP is used only for decoding a few types of media and isn't accessed directly by third-party userland software, but can be a challenge for other operating systems. Dale continued:
A few pieces were missing for the N800, documentation for the graphics chip was nonexistent, the OMAP SOC documentation was under NDA, and we couldn't find information on how to connect to the serial port embedded on the chip.
It's worth noting that this situation isn't unique to the OpenBSD world. A lot of Linux devices that use ARM SoCs don't support the DSP or GPU, or possibly support them, but solely with binary-only drivers. Unfortunately, this is still a lot more common in the embedded world than on the desktop. OpenBSD has a much stricter policy on code written under NDA and on binary-only drivers, and therefore will not support any device that cannot have open drivers written for it. If someone is sufficiently motivated, undocumented devices will be reverse-engineered. In particular, Reyk Floeter has done some superb work reverse-engineering wireless devices, and written drivers that have since been ported to Linux. But reverse-engineering something as complex as a modern GPU is a daunting task.
I asked Dale what could be done by device manufacturers to make it easy for OpenBSD and other open source operating systems to support their hardware. He responded:
Continuing to make specs publicly available would go a long way. When the Nokia N800 was first being considered, the OMAP specs weren't openly available. However, with the release of the Beagle Board, OMAP specs were openly released.
It's worth noting that the stock Linux install on the N800 doesn't include support for the PowerVR MBX GPU core on the OMAP2 SoC at the heart of the device. The lack of documentation for this, and for the SGX in newer SoCs, means that open source operating systems cannot provide 3D support or accelerated compositing. This situation is very unfortunate, because hardware compositing on the desktop offloads a lot of work from the CPU. Doing the same on handheld devices helps keep the device responsive, since the CPU core is typically much slower than a desktop or laptop equivalent, and it reduces power consumption, helping battery life.
As always, if you're interested in seeing OpenBSD support your device, you should contact the developers. It costs a manufacturer very little to provide samples and documentation to developers, and can give a big benefit in terms of extra sales from having another software platform well supported by the device.