ARM TargetingMultipleDevices
Targeting Multiple ARM Based Devices
This page was written to help shed a little light on the issues of targeting multiple ARM based devices. I hope that this page does not make you feel like this task is impossible, but I think that you should be prepared with the reality of the task ahead of you. There are software out there that target many devices such as routers and phones, but the maintainers and authors of this software have more problems to overcome than software targeting a standard PC type x86/x64 device with BIOS and bus technologies with plug and play support.
A many readers of this page are likely coming from a background of the x86/x64 platform and will be accustomed to having a BIOS and the lack of software, hardware, and physical limitations to replacing storage devices and manipulating these storage devices. This is partially due to the small size of many ARM devices which creates physical limitations. The lack of BIOS type services and other architectures such as plug and play technologies which are not present on an ARM device. And, also software limitations such as image verification problems that prevent unauthorized images from being uploaded or placed on storage mediums in the device or even the absence of methods to replace images and system files on the device.
ARM Devices
The ARM processor is used in smartphones, laptops, tablet and notepad computers, and other embedded systems.
Booting Of ARM Processor
It boots by starting at some specific address. This address is usually located on ROM/FLASH that has been mapped onto the memory bus. This piece of code starts the booting process. In some small device is may be the only code that is executed. On more complex devices such as tablets and smart phones for instance it simply boot straps the system to load from other storage mediums such SD cards both internal and external for one example.
No BIOS On ARM
There is no industry standard software for booting an ARM based system such as BIOS like on the x86/x64 platforms. There could exist software that is similar or just like BIOS but this will likely be customized and in many cases not exist at all. So to work with hardware your going to have to communicate directly with it from the beginning.
Three Major Problems
The ability to develop system software to target a broad range of ARM devices is problematic in three different ways:
- Different hardware and memory with no industry standard enumeration or inspection functionality
- ROM/FLASH protection mechanisms enforced in hardware and/or in software to prevent unauthorized code from being flashed onto the boot ROM/FLASH memory
- Physical and software (but generally not hardware) protection mechanisms to replace secondary boot image (or kernel)
Different Hardware And Memory
A lot of ARM based devices have custom chips which contain hardware that will vary from chip to chip, device to device, and board to board. This is exactly the same as a device built on the standard x86/x64 platform except there is no industry standard method to enumerate hardware on an ARM based device like what exists on the x86/x64. A good example is the amount of memory which is normally different from device to device. This means that your system software will have to know ahead of time how much memory is on the device, where the memory is located, and the different types of memory on the device. It will also need to know what hardware is on the device there is no industry standard method to request a list of hardware and where it is located on the board. There is no plug and play support for devices on most ARM boards.
//It is possible that a range of ARM based devices may support a field that identifies the amount of memory in the device, but there is no industry standard location of this field or it's format, and it may or may not exist on one of your target devices.//
ROM/FLASH Protection Mechanisms
Most devices employ at least a software security mechanism to prevent you from uploading custom ROM images to the device that are not authorized. If all devices used the exact same mechanism then this would not be a problem because you could employ a one solution for all, but in reality all devices have different mechanisms. Some may even use some type of hardware protection requiring you to interface electrically with the device to enable flashing of a custom ROM.
Secondary Image (Kernel) Protection Mechanisms
Not all devices have a kernel, but many advanced devices do. And, some devices just have a secondary boot image which was too large to fit onto the boot ROM/FLASH. This is generally stored in secondary storage which is loaded into memory by the boot code on the ROM/FLASH. Since the boot code is normally quite custom to the device you might find a better route to developing for a wide range of devices by targeting the secondary image.
There exist two major issues:
- physical protection mechanisms or access issues
- software protection mechanisms or access issues
Physical Protection Mechanism Or Access Issues
You may not be able to physically access the storage in such a way that would make deployment a reality for many devices for the users that wish to install your system software. If the storage was accessible for example by USB cable and allowed you to write a new secondary boot image then this would be a potential device that you could support. However, if you required the user to electrically interface with the storage by soldering wires or performing some other task of advanced skill then you are going to have issues deploying your software to casual and basic users of the device.
Software Protection Mechanism Or Access Issues
Some devices may either not provide a mechanism to replace the secondary boot image, or actually protect it from being replaced in much the same way the boot ROM may be protected such as requiring the image to have some special code in it at a specific location, or even be signed using public key cryptography. Of course if you could circumvent this then you could deploy your software to a wide range of devices but consideration must be taken that many devices may have completely different methods for verification of the image to be replaced. So you would have to have some method of testing each device to ensure that your methods works and each method would have to be maintained adding to a lot of overhead.
//However, this is quite possible. You just must be aware of these issues.//