Successfully reported this slideshow.

How to put 10lbs of functionality into a 5lb package.

192 views

Published on

paper from Spring 2007 Embedded Systems Conference

  • Be the first to comment

  • Be the first to like this

How to put 10lbs of functionality into a 5lb package.

  1. 1. How to put 10lbs of functionality into a 5lb package. How to put 10lbs of functionality into a 5lb package.ByMarc KarasekSenior Firmware Engineermarckarasek@ivivity.comESC-370 San Jose California Spring 2007 Page 1 of 7
  2. 2. How to put 10lbs of functionality into a 5lb package.How to put 10lbs of functionality into a 5lb package..........................................................1Overview: ............................................................................................................................3Layering Your Code :..........................................................................................................4 In looking at the boot process for today’s embedded designs, more functionality is being added earlier in the process. Some examples are : power status, OS flash image integrity and system recovery. Each of these requires a different amount of software support. Some will require notification to the user of the status and some will require interaction with the user. Most of these features are in addition to bringing the system up to a point where an OS and/or application can run. ..................................................4 Many embedded designs have one large firmware image that is both the boot code and the OS/application rolled into one. This monolithic approach to the code has many limitations associated with it. Some examples are : ......................................................4 Upgrading the firmware is a potentially dangerous problem that could leave the device nonfunctional. ................................................................................................................4 The ability to maintain multiple images, a requirement in some cases, is impossible without some form of hardware support. ........................................................................4 Each layer should have a mechanism to load the layer above it. It should also have as much debug capability in the code as possible. (See next section). .............................5 Having split the monolithic firmware image into these layers allows us to move from a monolithic way of debugging the code to a more modular approach. ............................5Debugging without the Bloat :.............................................................................................5 Most embedded firmware has some form of debug monitor capabilities in it. This is usually accessed by a key sequence during boot time or through a menu system that is the default interface for the device. This debug monitor usually requires that the majority of the system be functional in order to work. This does not lend itself to debugging problems that occur early in the boot process and is usually used to help debug OS/applications. In order to debug the hardware/boot code better we need a monitor that needs little to no resources to run. One such monitor is Micromon developed for the MIPs family of chips by IDT. This monitor as a standalone binary is only 13K in size, yet it provides all of the features needed to help debug during system bring-up. It could very easily be adapted to another processor. It only needs 8 GP registers for the stack and input positions........................................................................5 Using the split firmware above, .....................................................................................5Assumptions : ......................................................................................................................5Definitions : ........................................................................................................................6ESC-370 San Jose California Spring 2007 Page 2 of 7
  3. 3. How to put 10lbs of functionality into a 5lb package.Overview:In today’s embedded designs more and more functionality is being crammedinto smaller packages. As this functionality increases so does the amount ofupper layer “OS” software needed to run it. With cost always a drivingfactor, flash devices used for the system software need to be as small aspossible. A combination of cost + increased system functionality means lessspace available for the boot/initialization code. At the same time there ispressure to also add functionality too the boot/initialization code. As anembedded systems engineer, you need to be able to understand theimplications associated with adding this functionality. Will you need toincrease the size of the flash part, can you live without this feature or is it amust have or can you squeeze some more space from your current flash?You must become an “embedded systems engineer” to know what affect aspecific feature request will have on the system.Knowing what the choices you have when a feature request hits your inboxis only the first step. You also need to be able to communicate thisinformation to your managers/executives. It maybe that the request for thiswiz-bang new feature has come from your manager and he/she is justconvinced that the end product will be a complete disaster without it. Youmust be able to explain what are the options associated with adding this newfeature. We have all heard the line one time or another that ‘it is only codeand what is the big deal’.If we are prepared ahead of time to deal with these requests, then ‘putting 10lbs of functionality into a 5 lb package’ will be a lot easier. There are a fewthings an engineer can do up front that will help: 1) Layering the firmware, with a clear plan for what each layer of the code is responsible for. 2) Adding debug code while minimizing the impact to the boot process and avoiding code bloat. 3) Maintaining multiple firmware images in a system with a minimal footprint in the boot process.ESC-370 San Jose California Spring 2007 Page 3 of 7
  4. 4. How to put 10lbs of functionality into a 5lb package.Layering Your Code :In looking at the boot process for today’s embedded designs, more functionality is being added earlier in the process. Some examples are : power status, OS flash image integrity and system recovery. Each of these requires a different amount of software support. Some will require notification to the user of the status and some will require interaction with the user. Most of these features are in addition to bringing the system up to a point where an OS and/or application can run.Many embedded designs have one large firmware image that is both the boot code and the OS/application rolled into one. This monolithic approach to the code has many limitations associated with it. Some examples are : • Upgrading the firmware is a potentially dangerous problem that could leave the device nonfunctional. • The ability to maintain multiple images, a requirement in some cases, is impossible without some form of hardware support.A better way to deal with this is to modularize or layer the code. Look atwhat initialization needs to be done and break this up into sections. Fromthis see what is platform dependent and what is platform agnostic. This isyour first point of layering. If you have any system initialization code, thiswould become the next layer. The final layer would be the OS/applicationfor the device. So we now have three layers for our firmware (see Figure 1). Platf orm Dependent Code Sy stem Dependent Code OS/ApplicationESC-370 San Jose California Spring 2007 Page 4 of 7
  5. 5. How to put 10lbs of functionality into a 5lb package. Figure 1 : Firmware LayeringEach layer should have a mechanism to load the layer above it. It should also have as much debug capability in the code as possible. (See next section).Having split the monolithic firmware image into these layers allows us to move from a monolithic way of debugging the code to a more modular approach.Debugging without the Bloat :Most embedded firmware has some form of debug monitor capabilities in it. This is usually accessed by a key sequence during boot time or through a menu system that is the default interface for the device. This debug monitor usually requires that the majority of the system be functional in order to work. This does not lend itself to debugging problems that occur early in the boot process and is usually used to help debug OS/applications. In order to debug the hardware/boot code better we need a monitor that needs little to no resources to run. One such monitor is Micromon developed for the MIPs family of chips by IDT. This monitor as a standalone binary is only 13K in size, yet it provides all of the features needed to help debug during system bring-up. It could very easily be adapted to another processor. It only needs 8 GP registers for the stack and input positions.Using the split firmware above,Assumptions :The assumptions for this paper are that the reader has a good understandingof embedded systems and an understanding of the general boot process formicroprocessors. An understanding of C is expected and some assemblywould be helpful.Layering your code :ESC-370 San Jose California Spring 2007 Page 5 of 7
  6. 6. How to put 10lbs of functionality into a 5lb package.Definitions :Boot Device :Reset Vector :ESC-370 San Jose California Spring 2007 Page 6 of 7
  7. 7. How to put 10lbs of functionality into a 5lb package.As embedded engineers we are faced with pressures to put the maximum functionality intoour systems within the minimal footprint.What this means from a boot code perspective is the initialization code is being squeezed intoa smaller footprint so that the upper layer applications have more room. At the same time,we are being asked to add additional functionality.[Understanding how to add as much functionality into your boot code, and the tradeoffsassociated this.] Presentation on how to modularize your boot code into different layers. Thiswill include examples of code using the MIPS processor. How to add debug output into theboot process without slowing down the process and fitting into the available boot device beingused. How to satisfy requirements of having multiple boot images in a system with a minimalfootprint in the boot process.ESC-370 San Jose California Spring 2007 Page 7 of 7

×