Board support package (BSP) porting is a crucial part of product development, with designers facing tough decisions on CPU and operating system selection.
At first glance, the array of embedded CPU options from IC suppliers, module providers and single board computer suppliers may appear daunting. There are so many out there, it can be a difficult decision to select which is the right one for your design.
So to help I will examine the crucial stages when selecting and successfully deploying a CPU in product design.
1. Survey the embedded CPU landscape
CPU silicon vendors provide sample boards with feature rich chips for hardware and reference BSPs for software. They are an ideal place to start when developing a fully bespoke system. Normally, all software and hardware source design files are available and these are modified for the target design. Is this easy? Not necessarily.
Functions and functionality
When an end product is specified it will most likely contain a smaller subset of features; for instance, maybe not all four SD Card interfaces are needed, or HDMI will be used.
Designers take the sample’s hardware schematics and remove unnecessary items, whilst adding functionality that is not supported by the reference design. CPU modules are available which contain the group of core components from the reference board – CPU, RAM and flash chips on a daughter card which plugs into a simpler baseboard with the connectors and other support chips.
These are used to create bespoke hardware for embedded systems with faster turnaround than a fully customised board.
2. Focus on the bootloader
There are always essential software changes during BSP porting. The first priority is the bootloader.
Example program flow as the system powers up:
Bootloaders are responsible for setup of the platform to allow the OS to run; they configure memory and block devices such as eMMC/SD/NAND flash, download the Kernel/OS and jump to it.
For many target designs, some changes are necessary as a reference device may be unavailable or substituted. NAND and RAM chips typically require modifications.
Customising the bootloader can support faster boot times, visible splash screens, running a backup OS image in the event of failure, or restoring backup images, to name just a few. Additional requirements are not typically supported in the reference code.
When using splash screens, for instance, the CPUs display controller needs to be configured. Since CPUs having multiple output types and many GPU features, this can be a major task and requires knowledge of the specific CPU used.
Security and locking down of the system can be configured. Security layers are typically built into the processor; when security features are enabled, code will only run if signed against keys stored in the CPUs one time programmable blocks.
3. Configure the kernel/OS
Once all bootloader changes are in place for hardware configuration and OS launch, the next steps in BSP porting are the configuration of the OS. Linux and Windows Embedded both have a large catalogue of components that can be added to the OS image.
However, as adding components may slow down boot and could compromise security, it is vital that only components with a clearly defined purpose are included. Android also has a list of components that are required by the OS to function.
Removing unnecessary drivers
Reference hardware includes many features often not used on the final target platform. Removing non-essential drivers will reduce boot times, image sizes and reliability.
The OS will typically launch to a generic shell or command line by default. Any targeted device will require customisation to run the end application, check for updates, allow connections for updates and debugging etc.
Some items may require modifications to allow them to be disabled in production – debug serial outputs or ftp/telnet connections, for example. Android devices generally have the standard launcher modified to run only the end application and stop the user from roaming around the various other installed applications and changing important device settings.
4. Test, test and test again
The device should be tested at a number of points during development, from initial board bring up through to bootloader and driver development.
Once the above changes have been made, the device should undergo full system testing, including tests for the ruggedness of the OS booting and filesystem integrity; confirming that all drivers are loading and running well, ensuring there are no performance glitches and many others.
5. Give support careful consideration
Once released to end customers, these devices may need changes and modifications. Although much of these may be in the application layers, the OS could also require updates for bug fixes or new features.
Updating an OS to newer versions in the field is a challenge. How can software revision control allow previous known releases to be regenerated if required?
Some customers may require software updates, others may not require or want them, handling this from a development and a deployment perspective is a sizable task.
The effort involved in taking a reference BSP or module BSP to production depends greatly on your requirements, and how closely they resemble the reference from the original vendor.
If the product requirements differ from the reference design with regard to supported software features, this will involve effort at the bootloader, configuration and driver stages – all of which will involve testing. Hardware additions (and omissions) will also increase the effort required to take the reference software to production.
Understanding which CPU platform to use as a starting point, and its limitations with both hardware and software, will save considerable amounts of time and cost in your development.
Once the OS has been successfully ported, it’s time to turn to your attention to the application and the user interface.
At ByteSnap, we’ve built a UI development framework, SnapUI, to help in this process, by allowing developers to build graphically complex applications for embedded devices, before porting to the target hardware, and using reference boards.
Graeme Wintle is Director at ByteSnap Design