"...the Jedi Knights were the guardians of peace and justice ... before the dark times" (Yoda)

As an engineer who has written a half dozen bootloaders in the last 5 years, I sometimes feel like I'm living in "the dark times."


In the "Old Republic" (lets say that was 1995), small systems were largely built using personal computer (PC) technology originally pioneered in the early 1980's by IBM. The manual shown here actually included source codes to the original PC BIOS.

IBM PC Bios Manual circa 1985

In those days the boot and startup sequence had guardians which ensured harmony during hardware enumeration and device startup. Those guardians were the specialized embedded software components called the Basic Input/Output System (the "BIOS"). Wikipedia describes the BIOS as " non-volatile firmware used to perform hardware initialization during the booting process (power-on startup), and to provide runtime services for operating systems and programs." Like the mythical Jedi Knights, who were the guardians of peace and justice, on older small systems, it was the BIOS that was guardian of hardware initialization and booting. The BIOS was the bootloader.


Many of us are too young to remember the "Old Republic", or not well enough traveled to have ever visited that galaxy so far, far away. But, because so many small devices (e.g. iPods, Fitbit watches, etc.) are often built using CPU technology of the lightweight Arm® Cortex® -M processor family, which lack a standardized BIOS solution, many of us, from the point of view of BIOS support, we are indeed living in "dark times."


The sharper point is that software built with processors such as the Arm Cortex -M suffer from a technology gap in the lack of both industry boot standards or support for a standard BIOS. Exacerbating this technology gap, these Cortex-M processors are "lightweight" only in terms of size, weight and power. In terms of performance, these CPUs are more like full computer systems, in that they host RAM, and peripherals such as UARTs and network interfaces all in a single package. Remember the rolling memory test seen on PCs right on power on? That was the BIOS doing that test. The point is, there's a lot that can go wrong during startup, and very little help that can be provided when things do go wrong.


Why does it matter to the programmer / engineer? It matters because without BIOS support, the programmer is left on his own to solve problems such as bootloading, device failures, and upgrade and expansion paths.


Why does it matter to the end user? It matters because without a BIOS console, troubleshooting by the end user of startup/initialization and boot problems is virtually impossible. What if that memory test fails on a system without a console?


In a troubleshooting scenario, the sometimes the only narrative is that the machine either boots or it does not. Consider for a moment; how can you display a simple memory failure, when you don't have a console to show that failure? Simply stated, there is no standardized interface for troubleshooting.


Industry consortia such as the UEFI Forum have responded in recent years with BIOS support for the larger "big footprint" Arm (e.g. Arm Cortex -A8, -A15, etc) processors. However, in the BIOS realm, Arm Cortex -M processors have largely not been served by either industry "de facto" standards, or by BIOS consortia.


There is a technology gap, and for the foreseeable future, engineers like myself are staying very busy doing custom bootloaders.


To quote Yoda on troubleshooting: "do or do not, there is no 'try'." Well, OK, that quote doesn't really work, but neither does the troubleshooting. Perhaps Yoda, as a bootloader or BIOS engineer on an Arm Cortex -M , might say "boot or boot not, there is no troubleshooting."


0 views

© 2018 by Constellation Data Systems, Inc.