際際滷

際際滷Share a Scribd company logo

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

Marc Karasek
Marc Karasek

The document discusses how to add more functionality to an embedded system without increasing the package size. It recommends layering the firmware code into platform-dependent, system-dependent, and OS/application layers. Each layer should be able to load the layer above it. It also suggests including robust debug capabilities to help troubleshoot problems early in the boot process using a small, lightweight debug monitor. Layering the code in this way allows for a modular debugging approach rather than a monolithic one.

1 of 7
How to put 10lbs of functionality into a 5lb package. How to put 10lbs of functionality into a 5lb package. By Marc Karasek Senior Firmware Engineer marckarasek@ivivity.com ESC-370 San Jose California Spring 2007 Page 1 of 7
How to put 10lbs of functionality into a 5lb package. How to put 10lbs of functionality into a 5lb package..........................................................1 Overview: ............................................................................................................................3 Layering Your Code :..........................................................................................................4 In looking at the boot process for todays 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. ............................5 Debugging 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, .....................................................................................5 Assumptions : ......................................................................................................................5 Definitions : ........................................................................................................................6 ESC-370 San Jose California Spring 2007 Page 2 of 7
How to put 10lbs of functionality into a 5lb package. Overview: In todays embedded designs more and more functionality is being crammed into smaller packages. As this functionality increases so does the amount of upper layer OS software needed to run it. With cost always a driving factor, flash devices used for the system software need to be as small as possible. A combination of cost + increased system functionality means less space available for the boot/initialization code. At the same time there is pressure to also add functionality too the boot/initialization code. As an embedded systems engineer, you need to be able to understand the implications associated with adding this functionality. Will you need to increase the size of the flash part, can you live without this feature or is it a must have or can you squeeze some more space from your current flash? You must become an embedded systems engineer to know what affect a specific feature request will have on the system. Knowing what the choices you have when a feature request hits your inbox is only the first step. You also need to be able to communicate this information to your managers/executives. It maybe that the request for this wiz-bang new feature has come from your manager and he/she is just convinced that the end product will be a complete disaster without it. You must be able to explain what are the options associated with adding this new feature. We have all heard the line one time or another that it is only code and what is the big deal. If we are prepared ahead of time to deal with these requests, then putting 10 lbs of functionality into a 5 lb package will be a lot easier. There are a few things 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
How to put 10lbs of functionality into a 5lb package. Layering Your Code : In looking at the boot process for todays 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 at what initialization needs to be done and break this up into sections. From this see what is platform dependent and what is platform agnostic. This is your first point of layering. If you have any system initialization code, this would become the next layer. The final layer would be the OS/application for the device. So we now have three layers for our firmware (see Figure 1). Platf orm Dependent Code Sy stem Dependent Code OS/Application ESC-370 San Jose California Spring 2007 Page 4 of 7
How to put 10lbs of functionality into a 5lb package. Figure 1 : Firmware Layering 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). 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 understanding of embedded systems and an understanding of the general boot process for microprocessors. An understanding of C is expected and some assembly would be helpful. Layering your code : ESC-370 San Jose California Spring 2007 Page 5 of 7
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
How to put 10lbs of functionality into a 5lb package. As embedded engineers we are faced with pressures to put the maximum functionality into our systems within the minimal footprint. What this means from a boot code perspective is the initialization code is being squeezed into a 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 tradeoffs associated this.] Presentation on how to modularize your boot code into different layers. This will include examples of code using the MIPS processor. How to add debug output into the boot process without slowing down the process and fitting into the available boot device being used. How to satisfy requirements of having multiple boot images in a system with a minimal footprint in the boot process. ESC-370 San Jose California Spring 2007 Page 7 of 7

More Related Content

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

  • 1. How to put 10lbs of functionality into a 5lb package. How to put 10lbs of functionality into a 5lb package. By Marc Karasek Senior Firmware Engineer marckarasek@ivivity.com ESC-370 San Jose California Spring 2007 Page 1 of 7
  • 2. How to put 10lbs of functionality into a 5lb package. How to put 10lbs of functionality into a 5lb package..........................................................1 Overview: ............................................................................................................................3 Layering Your Code :..........................................................................................................4 In looking at the boot process for todays 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. ............................5 Debugging 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, .....................................................................................5 Assumptions : ......................................................................................................................5 Definitions : ........................................................................................................................6 ESC-370 San Jose California Spring 2007 Page 2 of 7
  • 3. How to put 10lbs of functionality into a 5lb package. Overview: In todays embedded designs more and more functionality is being crammed into smaller packages. As this functionality increases so does the amount of upper layer OS software needed to run it. With cost always a driving factor, flash devices used for the system software need to be as small as possible. A combination of cost + increased system functionality means less space available for the boot/initialization code. At the same time there is pressure to also add functionality too the boot/initialization code. As an embedded systems engineer, you need to be able to understand the implications associated with adding this functionality. Will you need to increase the size of the flash part, can you live without this feature or is it a must have or can you squeeze some more space from your current flash? You must become an embedded systems engineer to know what affect a specific feature request will have on the system. Knowing what the choices you have when a feature request hits your inbox is only the first step. You also need to be able to communicate this information to your managers/executives. It maybe that the request for this wiz-bang new feature has come from your manager and he/she is just convinced that the end product will be a complete disaster without it. You must be able to explain what are the options associated with adding this new feature. We have all heard the line one time or another that it is only code and what is the big deal. If we are prepared ahead of time to deal with these requests, then putting 10 lbs of functionality into a 5 lb package will be a lot easier. There are a few things 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. How to put 10lbs of functionality into a 5lb package. Layering Your Code : In looking at the boot process for todays 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 at what initialization needs to be done and break this up into sections. From this see what is platform dependent and what is platform agnostic. This is your first point of layering. If you have any system initialization code, this would become the next layer. The final layer would be the OS/application for the device. So we now have three layers for our firmware (see Figure 1). Platf orm Dependent Code Sy stem Dependent Code OS/Application ESC-370 San Jose California Spring 2007 Page 4 of 7
  • 5. How to put 10lbs of functionality into a 5lb package. Figure 1 : Firmware Layering 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). 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 understanding of embedded systems and an understanding of the general boot process for microprocessors. An understanding of C is expected and some assembly would be helpful. Layering your code : ESC-370 San Jose California Spring 2007 Page 5 of 7
  • 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. How to put 10lbs of functionality into a 5lb package. As embedded engineers we are faced with pressures to put the maximum functionality into our systems within the minimal footprint. What this means from a boot code perspective is the initialization code is being squeezed into a 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 tradeoffs associated this.] Presentation on how to modularize your boot code into different layers. This will include examples of code using the MIPS processor. How to add debug output into the boot process without slowing down the process and fitting into the available boot device being used. How to satisfy requirements of having multiple boot images in a system with a minimal footprint in the boot process. ESC-370 San Jose California Spring 2007 Page 7 of 7