Designing Quick Starting Embedded Systems: Designing System Boot Time
Resources
Hello, and thank you for taking the time to take a look at this presentation on Designing Quick-Starting Embedded Systems.
In this section, we will be discussing the following topics: putting together all the elements from this presentation; when should the system developer set the boot time requirements; pick a boot mode that has local storage first in the boot order; review rough numbers of boot time; deciding on the user space; and then finally, overall, that achieving boot time is asymptotic in nature.
The processor was most likely picked for features rather than boot time. So the developer must be aware of the processor capabilities, such as the OPP of the processor and the impact on boot time. Remember to review the processor in SDK Performance Data Sheet to start.
The system developer decides if the product has a boot time requirement. The application itself will have an impact on boot time, based on required features.
Choose memory storage as the primary boot mode, such as MMC, NAND, NOR, QSPI. Having a non-memory primary boot device will have an impact on boot time.
There were some rough numbers presented in this presentation for quickly thinking about what the processor boot time potentially could be. These numbers were drawn from earlier in the presentation.
The following slides will follow the boot stages and review the numbers captured. The examples here are based on the EVMs using MMC boot mode, the PMIC ramp times, and the ROM to read the OOB, SDK, MLO images. The power phase of the mic for each of the EVM as was demonstrated. The ROM bootloader phase of the time taken to read in the MLO image.
The point here is that each processor has a minimum time that it takes to get the MLO image written by the ROM.
One trade-off is to consider XIP boot mode if the processor support, to avoid the ROM reading in the MLO image.
Falcon mode allows the direct loading of the kernel in DTB. This presentation demonstrated that the bulk of the time saved by using Falcon mode is the time it takes to load U-boot. From a rough estimate approach, this could be up to 80 milliseconds, depending on the processor.
One of the techniques discussed earlier was kernel compression. The developer can switch from LZMA to LZ4. This can be done in the kernel configuration. On the AM437x with the released SDK kernel, this yielded a decompression improvement of 1.8 seconds.
By using the kernel command line quiet option, this can save about 500 milliseconds or more, depending on the kernel init. The reason is the kernel will write to an internal log only, instead of to the console. This is one of the techniques referenced a lot when doing research on reducing kernel boot time. The box shows the argument being passed in the command line to the kernel.
Another technique discussed was a kernel DTB sized for system being used. The board DTS should be sized for the system. Starting with an EVM DTS and leaving notes from the EVM that are not used in the target system will have a negative impact on boot time. For example, this was mentioned earlier that on an AM437x SK EVM, a reduced DTB to emulate a smaller system initialized over 500 milliseconds faster.
The user space initialization is a big consideration. A quick review of the SDK Performance Data Sheet indicates the boot times for multi-user and single user. This was introduced earlier in the presentation. Again-- and it can't be emphasized enough --the system developer decides if the product has a boot time requirement.
User space choice has an impact on the development ecosystem, too. As mentioned earlier, the SDK user space is system D. If a developer wants to change the user space, then how the user space is created will change, too. Several SDK users based their product build ecosystem on the Octo recipes used to build the SDK. A change here will require changing recipes if the Octo is used to build a product and its user space.
The system developer is the owner for their product's user space choice and its development. Applications are most likely to be unique, and the support necessary to build them will be, too. Unfortunately, this choice often gets left until the end of a project, sometimes requiring the developer to address this issue with a user space change. Since user space is a significant choice, it is sometimes easier to start developing without thinking of the boot time impact until the end of the product development and production is about to begin.
If the product requires a multi-user system, then a proof of life type of boot stage might be a choice. If that is the case, then one solution is that U-boot has to be loaded and customized to provide the proof of life indication. Some examples-- from earlier --of indications are an LED, sound, or splash screen on the display. The system boot time requirement is different from a fully-running application.
Examples shown here are only to a command prompt for a single user case. The system developer must do the additional work to determine their unique application boot time.
Overall, boot time design effort depends on the boot time requirement of the product. Each product may require different features that may or may not initialize in a timely fashion.
Out-of-box versus heavy customization. The developer may have to be willing to make a trade-off, as the amount of effort necessary to achieve the boot time they require may become excessive. This is where developers will be doing significant experimentation and development to achieve the desired boot time. There are so many permutations of features and paths to initialize a system, that is not a set guideline to follow. Most likely, the desired boot time will take time to develop as the application developer takes the out-of-box SDK and customizes support as needed.
This graph tries to show the amount of effort necessary to achieve a boot time. The y-axis shows the boot time, and the x-axis shows the effort. This is for demonstration purposes only, and not to scale.
The out-of-box line is representing the starting point. The shell line showing the improvement with the fairly low effort that was realized from the single user environment demonstrated in this presentation.
A developer working on a product with a short boot time requirement, regardless if it is a single user or multi-user will find the development asymptotic in nature with each reduction of boot time.
The goal of this section was to review each element of determining boot time. The first view topic was suggesting to use a primary boot mode that is memory-based. Next, rough numbers were discussed on how to guide determining boot time. Next, it was suggested how to employ Falcon mode if supported by the processor. Also discussed was a few effective steps to reduce the kernel initialization time. Also examined the user space initialization and the impact on boot time, development, and the need for proof of life indicators on extended boot times. Finally, discussed how boot time development can be asymptotic.
Here's a list of the key points from this presentation. The earlier that the developer decides the boot time in the design process, the better. Be sure to pick the right boot mode, not just for the product, but perhaps for manufacturing as well. There are some hardware elements such as OPPs and PMICs that impact boot times. There are software elements that help in shortening boot time, such as Falcon mode DTB size, kernel compression, and boot time parameters. The developer's choice of user space for single user or multi-user can impact product development time.
The techniques presented here are a way point on the way to the design the developer requires. There are not any one-step actions to achieve a desired boot time. Be prepared for experimentation on boot time, as each product is unique, and actual results will vary.
That concludes this presentation. For more information, please take a look at these following links. Thank you for taking the time to look at this presentation and designing quick starting systems.
This video is part of a series
-
Designing quick-starting embedded systems
video-playlist (5 videos)