The boot_metrics.log file

You can use the boot_metrics.log file to monitor startup times for your system.

The boot_metrics.log file contains time measurements from board reset to a particular system event (the time from board reset varies depending on your platform).

Note: Although this log is purely for reference purposes, you can get important information from it that can help you tune your system startup.

Variation in timers

Each measurement in the log starts with either (hw) or (sw):
  • Times that start with (hw) are measured using a simple utility called timestamp that makes a call to the ClockCycles() kernel function. This function provides the timestamp utility with the number of clock cycles since the board was reset. Note that these measurements aren't entirely accurate because they're taken close to—but not simultaneously with—the event that's being measured. The timestamp utility is just a process that's run in the background at a normal priority, as closely as possible to the event being measured.
  • Times that start with (sw) are doing some other measurement, such as querying the system for the date.

On some boards, the time reported by the timestamp utility correlates very closely with the time elapsed since power was actually applied to the board (i.e., a board reset was done either in software or by pressing the reset button). This is the most desirable implementation. In some cases, however, the time reported by the timestamp utility could represent the time since the IPL started, or even the time since the startup driver started. This situation results in measurements that are much smaller than would be observed using a stopwatch from power on. These measurements are obviously less accurate, but can still be useful in comparing one software build to another.

The particular measurements you get depend on whether:
  • the board provides a counter in the hardware that starts as close as possible to power-on reset (PoR). If the board doesn't provide a hardware counter, you can use the counter provided in the kernel, but it won't start counting until the kernel takes control, which is well after PoR.
  • the IPL/startup driver can (or actually does) initialize this hardware counter to zero
  • the startup driver performs a “cold” or “warm” reset on shutdown (software reset). A cold reset generally initializes the hardware more thoroughly than a warm reset, so a cold reset would be more likely to set the hardware counter to 0.

Contents of boot_metrics.log

The boot_metrics.log is found in the /dev/shmem directory. Its contents may look like this:

(hw) CAR_BOOT_METRICS: (CF_unit2_first_frame) at 473.129761 seconds
(hw) CAR_BOOT_METRICS: (CF_unit4_first_frame) at 500.512986 seconds
(hw) CAR_BOOT_METRICS: (CF_unit3_first_frame) at 563.645573 seconds
(hw) CAR_BOOT_METRICS: (CF_unit1_first_frame) at 619.666507 seconds

The events that appear in the log file are as shown in the following table:

This log entry: Corresponds to this system event:
CF_unitX_first_frame

The camera unit X on the device has received its first frame.

In the camera configuration file (See the Camera configuration file section in the System Services Reference)), this is the camera that you have configured as CAMERA_UNIT_X.

In the above example, four camera units are specified in the configuration file as units CAMERA_UNIT_1, CAMERA_UNIT_2, CAMERA_UNIT_3, and CAMERA_UNIT_4. The camera application connects to these four cameras, and therefore, you can observe the time each receives its first frame in the boot_metrics.log file.

You can write additional events to the log by running the timestamp utility (e.g., timestamp event_name). The event information will be written to /dev/shmem/boot_metrics.log.