BPS Porting: Your 5 Key Steps to Development Success

By Michelle Robinson, ByteSnap

When selecting the hardware that will make up the core of your next product, there are many choices. Once this has been decided, BSP (board support package) porting must be completed to ensure the software elements fit the new hardware.

Among the key decisions you need to make are which CPU to go for and which operating system to use on it. The market has moved from silicon vendors selling just components; the start-up software they offer is now just as important as the hardware.

BSP Porting: Which CPU?

At first glance, the array of embedded CPU options from silicon vendors, module providers and single board computers may appear daunting. “There are so many out there – which one’s the right one?” is a query often put to us.

Let’s go through the crucial stages of making the right choice and successfully deploying it in a product design.

1.  Survey the Embedded CPU Landscape

CPU silicon vendors provide example boards of their feature-rich chips for customers to try out and base their design on. These examples, called reference boards for the hardware and reference BSPs for the software, 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.

Easy? Not necessarily.

Functions and Functionality

When an end product is specified it will most likely contain just a smaller subset of features the CPU can perform; for instance, perhaps not all four SD Card interfaces are needed, or HDMI will be used but the LVDS connector isn’t for an LCD panel.

Designers will take the example hardware schematics and remove items of functionality that are not required. In this process, functionality is added that is not supported by the reference design; typically this is some bespoke circuit for the purpose of the product. Example additional items could be motor control, power supplies, sensors, input and output devices of varying types.

As chips are accompanied by reference manuals running into thousands of pages, and processors have more functions than pins, the task of customization for production is not always simple.

CPU modules are available which contain the group of core components from the reference board; so 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 bespoke board.

As the less complex board is easier to design, this takes risk out of the hardware and reduces design time. In these cases, the module vendor will provide a BSP which will be based on the original CPU vendor’s BSP and will normally be production hardened.

Some vendors spend more effort ironing out issues than others – so it’s worth looking in detail before assuming they are all the same. Cost is also a factor here, with better modules charging a premium.

2. Focus on the Bootloader

Whichever route is taken, there will be essential software changes; this is the BSP porting work that needs to be undertaken. The first one to focus on is the bootloader.

Bootloaders are responsible for setup of the platform to allow the operating system 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, there will need to be some changes to these primary tasks as a device is not available or substituted for another, NAND and RAM chips typically require modifications to accommodate changes. Without these, the platform will not start.

Customizations

Many clients make customizations to the bootloader to support faster boot times, showing splash screens, running a backup OS image in the event of failure or restoring backup images just to name a few. These additional requirements are typically not supported in the reference code and require effort to change, some more than others. Splash screens for instance will need to configure the CPUs display controller into the correct mode. With CPUs having multiple output types and many GPU features, this can be a large task and one specific to the CPU that is being used.

There are limitations for what the bootloader can do; generally restrictions with USB devices, networks and other complex components that require large support stacks to function which aren’t accessible without an OS present. If there is a particular request that is needed, it is worth seeing if it will be possible or if the effort is justified implementing it in the bootloader.

Security

Security is a large issue to all embedded devices. Bootloaders often support insecure and secure modes of operation.  Security layers are typically built into the processor; if security features are enabled then code will only run if signed against keys stored in the CPUs one-time programmable blocks.

Security and locking down of the system can be a bespoke and configurable item that requires significant effort to be effective.

3. Configure the Kernel/OS

Once all the bootloader changes are in place to configure the hardware and launch the OS, the next steps in the BSP porting process are the configuration of the OS itself. Linux and Windows Embedded both have a large catalogue of components that can be added to the OS image.

Adding components may slow down boot and could compromise security, so it is vital that only the necessary and important ones should be included. All components should have a clearly defined purpose in the end product. Android has a list of components that are required by the OS for it to function normally this isn’t deviated from.

Removing Unnecessary Drivers

Reference hardware will include many features that are probably not used on the final target platform, so removing non-essential drivers will reduce boot times, image sizes and reliability.

Some hardware components in the target design will be different and this could be for a variety of reasons: the availability of chips, new features, cost, better performance or lower power.

These new components will in most cases need driver/configuration changes or new drivers to support them. Like the CPU vendors, these supporting chips (Wi-Fi/Bluetooth/ Modem/Touch etc.) will come with drivers and it should be a case of integrating these into the operating system rather than writing them from scratch.

Commonly, these drivers will be tested with one version of the OS in question. However, this may be different from the one being used, so even a compatible driver may require modifications to get it into the build system and functioning as expected.

The OS will typically launch to a generic shell or command line by default. Any targeted device will require customization to run the end application, check for updates, allow connections for updates and debugging etc. These changes will be made to the OS.

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, or using the device inappropriately.

4. Test, Test and Test Again

The device should be tested at a number of points in the development, from initial board bring up (powering up the hardware for the first time) through the bootloader and driver development.

Once all of the above changes have been made, the device should undergo system testing of all the components.

This level of testing is normally tailored to the device itself but usually consists of tests for the ruggedness of the OS booting and file system integrity; confirming that all drivers are loading consistently on each boot, running or exercising all drivers simultaneously, ensuring there are no performance glitches and many others. This should be done on a number of devices, some running automated tests others more realistic end user scenarios.

Confidence and Assurance of Quality

The more testing time, the greater confidence can be placed in the device and the software running. A device running in development maybe powered from a bench power supply for 8 hours whilst the developer is using it – perhaps resetting this platform many times during the course of the day. In the field, this device will be expected to run for years at a time without user intervention.

This confidence and assurance of quality takes time and effort to perform and should not be underestimated.

5. Give Support Careful Consideration

Once released to end customers, these devices will no doubt need changes and modifications.

Although much of this may be in the application layers, the OS could also require updates for bug fixes or thorough changes to allow new features to be accessed.

Updating the OS itself to newer versions needs to be considered; how to do this in the field is an important question. 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.

Summary

The effort involved in taking a reference BSP or module BSP to production depends a lot 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 work required to take the reference software to production.

With BSP porting, 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 its user interface.  Depending on the complexity of the application, this can take a considerable amount of time and effort to achieve the correct results.

At ByteSnap, we’ve built a UI development framework, SnapUI, to help accelerate this process.

SnapUI allows developers to build graphically complex and challenging applications for embedded devices — even before target hardware — by using reference boards.

More Info:

• ByteSnap