Bootloader control via device identifier

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for placing a device in a bootloader state. One of the methods includes determining, during a boot process of the apparatus, whether a device of a particular type is connected to the apparatus, in response to determining that a device of the particular type is connected to the apparatus, determining a device identifier for the device, comparing the device identifier for the device with a predetermined identifier that indicates a device to which the apparatus should provide control of the boot process to determine whether the device identifier is the same as the predetermined identifier, and in response to determining that the device identifier is the same as the predetermined identifier, maintaining the apparatus in a bootloader state to provide control of the boot process of the apparatus to the device.

BACKGROUND

Some computers have a boot process that is used during startup of the computer to provide support for particular features of the computer. For example, a computer may load drivers for devices connected to or included in the computer. The computer may load an operating system and applications required for the execution of the operating system.

SUMMARY

In some implementations, a device uses a device identifier to control a bootloader. The device identifier may be a Universal Serial Bus (USB) device identifier, e.g., a vendor ID and a product ID. For instance, during a boot process, a high level bootloader can detect that a particular USB device is attached to the device based on the device identifier, stop the boot up process, and flash, e.g., re-flash, the device.

In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include the actions of determining, during a boot process of the apparatus, whether a device of a particular type is connected to the apparatus, in response to determining that a device of the particular type is connected to the apparatus, determining a device identifier for the device, comparing the device identifier for the device with a predetermined identifier that indicates a device to which the apparatus should provide control of the boot process to determine whether the device identifier is the same as the predetermined identifier, and in response to determining that the device identifier is the same as the predetermined identifier, maintaining the apparatus in a bootloader state to provide control of the boot process of the apparatus to the device. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include the actions of for each of multiple boot processes of a first device determining, during the boot process, whether a device of a particular type is connected to the first device, for a first subset of the multiple boot processes in response to determining that a device of the particular type is not connected to the first device continuing the boot process of the first device, for a second subset of the multiple boot processes in response to determining that a device of the particular type is connected to the first device, the second subset mutually exclusive from the first subset determining a device identifier for the device of the particular type, comparing the device identifier for the device of the particular type with a predetermined identifier that indicates a device to which the first device should provide control of the boot process to determine whether the device identifier is the same as the predetermined identifier, and in response to determining that the device identifier is the same as the predetermined identifier, maintaining the first device in a bootloader state to provide control of the boot process of the first device to the device of the particular type. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

The foregoing and other embodiments can each optionally include one or more of the following features, alone or in combination. The method may include receiving, from the device while the apparatus is in the bootloader state, one or more commands. Providing control of the boot process of the apparatus to the device may include receiving, from the device, an application image, and installing the application image on the apparatus. Receiving, from the device, the application image may include receiving, from the device, a firmware image. Installing the application image on the apparatus may include installing the firmware image on the apparatus. An apparatus may include a random access memory. Receiving the one or more commands may include receiving a command to store contents of the random access memory in a non-volatile memory. An apparatus may include a non-volatile memory. The method may include storing the contents of the random access memory in the non-volatile memory. The method may include sending, to the device, the contents of the random access memory for storage in the non-volatile memory. Sending, to the device, the contents of the random access memory for storage in the non-volatile memory may include sending, by way of the device, the contents of the random access memory for storage on the non-volatile memory included in a second device, connected to the device.

In some implementations, determining the device identifier for the device may include determining a vendor identifier for the device and a product identifier for the device. Determining whether a device of the particular type is connected to the apparatus may include determining whether a universal serial bus device is connected to the apparatus.

In some implementations, continuing the boot process of the first device may include providing control of the boot process from a high level bootloader to a second stage bootloader. Providing control of the boot process from a high level bootloader to a second stage bootloader may include determining, by the second stage bootloader, an operating system to load on the first device. The method may include for a first group of boot processes from the second subset in response to determining that the device identifier is not the same as the predetermined identifier continuing the boot process of the first device. Maintaining the first device in the bootloader state to provide control of the boot process of the first device to the device of the particular type may include for a second group of boot processes from the second subset in response to determining that the device identifier is the same as the predetermined identifier, the second group mutually exclusive from the first group maintaining the first device in a bootloader state to provide control of the boot process of the first device to the device of the particular type. The method may include determining whether the device identifier is the same as the predetermined identifier in response to comparing the device identifier for the device of the particular type with the predetermined identifier.

The subject matter described in this specification can be implemented in particular embodiments and may result in one or more of the following advantages. In some implementations, a developer or an end user may use the systems and methods described below to provision, e.g., flash, or reset a device. For example, a user can plug a USB dongle, e.g., with a read only memory, a device identifier, and a USB circuit, into a device, e.g., an embedded device, to provision or reset the device. In some implementations, the use of a device identifier to control or halt a boot process may allow a user to update firmware, an operating system, or both, on a device during a software development process or when a software update is available without manual configuration of the device by the user for the update, e.g., without manual selection of a button or control. In some implementations, the use of a device identifier to control or halt a boot process may allow a user to recover a device when software on the device does not work correctly, e.g., by replacing the software with updated software. For example, when a user creates a firmware version that does not allow a device to operate correctly, e.g., load an operating system, the user may place an updated version of the firmware on a connectable device to allow a device to determine an identifier for the connectable device, determine that the identifier is a predetermined identifier, and allow the connectable device to control a boot process, e.g., a bootloader state, on the device, e.g., to copy the new firmware to the device. In some implementations, the systems and methods described below may minimize the use of cables in an automated test environment, may minimize implementation cost, might not require any specialized connectors for implementation, might not require physical cable swapping or reconfiguration to restore a device to operation, or two or more of these.

DETAILED DESCRIPTION

A device determines, during a boot process, an identifier of a connected device. If the identifier matches a predetermined identifier, e.g., stored in a memory of the device, the device maintains a particular state in a bootloader. The bootloader may be a high level bootloader, e.g., that does not load an operating system and transfer operation of the device to the operating system. In some examples, the high level bootloader may be a bootloader that transfers operation of the device to a second stage bootloader when a connected device with a predetermined identifier is not connected to the device.

When the identifier for the connected device is the same as the predetermined identifier, the device may retrieve data from the connected device to allow the connected device to reset the device, to flash a file system of the device, or both. In some examples, the device may maintain the bootloader state to allow the connected device to send commands to the device, e.g., debugging commands. The device may respond to the commands by sending data to the connected device. For instance, the device may allow a developer to analyze properties of the device, using the connected device, as part of a software development process. The device may connect to the connected device using a cable, e.g., a Universal Serial Bus (USB) cable or audio cable, or a wireless connection, e.g., WiFi, Bluetooth, or near field communication (NFC), to name a few examples.

FIG. 1shows an example device100that includes a memory102, an operating system104, and firmware106. The device100may be an embedded system. In some examples, the device100may be a smart phone. The device100may be any appropriate type of computer.

The memory102may include instructions for the operating system104, the firmware106, or both. In some examples, the device100may include multiple memories as the memory102. For instance, the device100may include a first memory that stores the instructions for the firmware106and a second memory that stores the instructions for the operating system104. The first memory may be smaller than the second memory.

During time T0, the device100determines that a connected device108is connected to the device100while the device100is performing part of a boot process. For instance, the connected device108may be connected to the device100before time T0, e.g., by a user. The device100is powered on after the connected device108is connected to the device100and the device100begins a boot process. During the boot process, during time T0, the device100determines that the connected device108is connected to the device100.

The device100may perform a portion of the boot process in which the device100loads drives for components integrated into the device100. The device100may load a USB driver or a driver for an audio jack and determine that the connected device108is connected to the device, e.g., in response to loading the driver for the connected device108.

The device100requests a device identifier from the connected device108. For instance, in response to determining that the connected device108is connected to the device100, the device100may determine that the connected device108is of a particular type, e.g., from which the device100may receive commands during a boot process. The device100may request the device identifier from the connected device108in response to determining that the connected device108is connected to the device100or that the connected device108is of the particular type.

The connected device108retrieves a device identifier110from memory. The device identifier may include two or more different values. For instance, the device identifier may be a combination of a vendor identifier, e.g., for a vendor that manufactures or designed the connected device108, and a product identifier, e.g., an identifier for the particular model created by the vendor. The connected device108may use any appropriate information as part of the device identifier110that uniquely identifies the connected device108, e.g., a media access control address, or a type of device, e.g., a particular model created by a specific vendor.

The device100receives the device identifier110from the connected device108, e.g., via cable or wireless connection, and compares the device identifier110with a predetermined identifier110a. For instance, the device100may retrieve the predetermined identifier110afrom the memory102or another memory.

The device100, at time T1, compares the device identifier110with the predetermined identifier110ato determine whether the two identifiers are the same. For example, the device100compares the alphanumeric characters in the device identifier110with the alphanumeric characters in the predetermined identifier110ato determine whether the two identifiers are the same. Each of the identifiers may contain any appropriate values.

In response to determining that the device identifier110and the predetermined identifier110aare the same, the device100, during time T2, provides control of the device100or the boot process to the connected device108. For instance, the device100halts the boot process and enters a state in which the device100waits for a command from the connected device100. The device100may send a message to the connected device108indicating that the device100is waiting for a command from the connected device108.

The device100receives a command from the connected device108. For example, the command may indicate that the device100will receive a firmware update112from the connected device108and that the device100should install the firmware update112, e.g., to create updated firmware106a.

The device100receives the firmware update112from the connected device108and installs the firmware update. The firmware update may replace all or a portion of the firmware106to create the updated firmware106a.

The device100may be configured to receive data from, provide data to, or both, the connected device108in response to providing the connected device108with control of the boot process. For example, the device100may receive an update to the operating system104, the firmware106, or other data stored in the memory102. In some examples, the device100may receive a command to store data from a volatile memory of the device100into a non-volatile memory, e.g., for later analysis such as debugging. In some implementations, the device100may store data from the volatile memory in another volatile memory, e.g., of another device.

The device100may receive a command from the connected device108instructing the device100to load and execute an operating system stored on the connected device108. The operating system may allow the connected device108to re-flash the device100, e.g., to install new firmware or update existing firmware. For instance, the connected device108and the device100may connect. While the connected device108and the device100are connected, the connected device108polls the device100until the device100responds. The device100may determine that the device identifier110and the predetermined identifier110aare the same. In response to determining that the device identifier110and the predetermined identifier110aare the same, the device100indicates that the device100is ready to receive commands from the connected device108. The device100may send a message to the connected device108indicating that the device100is ready to receive a command or may clear a bit to indicate that the device100is ready to receive a command, to name a few examples. The connected device108can then send a command or multiple commands to the device100. For example, the connected device108may use a protocol, such as fastboot, to send commands to the device100.

In some examples, the device100may receive debugging commands from the connected device108or another device. For instance, the connected device108may be a USB cable that attaches the device100to a workstation. When the device100determines that the identifier for the connected device108is the same as the predetermined identifier, the device100allows the connected device108, and the workstation, to control the boot process for the device100. The device100may receive one or more debugging commands from the workstation, via the USB cable, and execute corresponding instructions in response to receipt of the commands or determine data responsive to the commands and provide the determined data to the workstation.

The workstation may present a user interface to a user that allows the user to enter, select, or both, commands that the workstation sends to the device100. The workstation receives the commands and provides the commands to the device100, e.g., with instructions for the device100to execute the command. The workstation may present the user interface on a monitor, e.g., separate from the device100, and may receive the commands from an input device, e.g., a keyboard, mouse, or speech input device. The input device may be a separate device from the device100.

The workstation may receive responses from the device100and present information from the responses in the user interface. For instance, responses may include debugging information which the workstation presents in the user interface or analyzes to determine a problem in an application that executed on the device100, e.g., the operating system104or the firmware106. The workstation may store some or all of the data from the responses in a memory, e.g., for use during analysis of the data.

In some examples, when the device100executes an operating system received from the connected device108or the workstation, the device100provides the connected device108or the workstation with a remote terminal, executing on the device100, that allows a user to provide the commands directly to the device100, e.g., using the connection for the remote terminal. In some implementations, the workstation may be part of the connected device108, e.g., the connected device may present a user interface to the user.

In some implementations, the device100is connected to the connected device108during time T0. For instance, as part of a boot process, the device100may load drivers for a wireless connection, e.g., WiFi, Bluetooth, or NFC, and connect to the connected device108at substantially the same time that the device100determines that the connected device108is connected to the device. The device100may use any appropriate method to connect to the connected device108.

In some implementations, the device100may wait for a command from the connected device108until a command is received, at which time the device100analyzes the command to determine an action to perform. In some implementations, the device100waits for a predetermined period of time until the connected device108sends a command to the device100, e.g., maintains the bootloader state until the command is received. Upon termination of the predetermined period of time, the device100may resume the boot process. For example, the high level bootloader may continue the boot process and may pass control of the device100to a second stage bootloader. In some implementations, the device100maintains the bootloader state until a command is received from the connected device108or an input included in the device100, e.g., until the device100determines that a power button to turn the device100off has been selected.

FIG. 2is a flow diagram of a process200for maintaining a first device in a bootloader state to provide control of the first device's boot process to a connected device. For example, the process200can be used by the device100shown inFIG. 1.

A first device determines, during a boot process, whether a device of a particular type is connected to a first device (202). For instance, the first device receives input indicating a selection of a power button and initiates a boot process, e.g., the first device turns on and initiates the boot process. As part of the boot process, the first device loads drivers for other types of devices and determines whether a device of the particular type is connected to the first device.

In some examples, the first device may determine that the connected device is of the particular type based on the drivers currently or recently loaded during the boot process. For instance, the first device may load a USB driver, determine that the connected device is connected to the first device, and, in response to the loading and the determination, determine that the connected device is a USB device.

The first device determines a device identifier for the connected device (204). For example, the first device sends a message to the connected device that requests the device identifier. In some examples, the message may request two or more identifiers that the first device may use as the device identifier to determine whether the connected device is of the particular type. The first device receives a response from the connected device that includes the device identifier for the connected device.

The first device compares the device identifier for the connected device with a predetermined identifier that indicates a device to which the first device should provide control of the boot process (206). The first device determines whether the device identifier the same as the predetermined identifier (208). When the first device receives two identifiers, the first device combines the two identifiers in a particular order and compares the combined identifier with the predetermined identifier. In some examples, the first device may compare each of the separate identifiers received from the connected device with corresponding predetermined identifiers. In these examples, if each of the predetermined identifiers is the same as the corresponding identifier received from the first device, the first device provides control of the boot process to the connected device.

In response to determining that the device identifier is not the same as the predetermined identifier, the first device continues the boot process (210). The first device does not pass control of the boot process to the connected device, e.g., does not pass control of a high level boot process to the connected device. The first device may continue to load device drivers. The first device, e.g., a high level bootloader, may pass control of the first device to a second stage bootloader which loads an operating system and passes control of the first device to the operating system. The first device may load drivers for all potential types of connected devices before passing control of the first device to the second stage bootloader, e.g., from the high level boot loader.

In some examples, the second stage bootloader may determine whether data for the second stage bootloader identifies the connected device as a potential device with an operating system for the first device to load. The second stage bootloader may determine whether there are multiple operating systems from which to select and present a menu to a user in response to determining that there are multiple operating systems from which to select, e.g., to allow the user to select one of the operating systems.

In response to determining that the device identifier is the same as the predetermined identifier, the first device maintains a bootloader state to provide control of the boot process to the connected device (212). For instance, the first device halts the boot process. The first device maintains the bootloader state of the high level bootloader and waits for a command from the connected device.

The first device receives, from the connected device while the first device is in the bootloader state, one or more commands (214). The first device may receive a command instructing the first device to receive data from the connected device, e.g., a firmware update, an operating system update, or both. The first device may receive a debugging command from the connected device, e.g., to store data from memory, either volatile or non-volatile, in a location for use during a debugging process.

The first device receives, from the connected device, an application image (216). In some examples, the first device may receive a command indicating that the first device will receive an application image from the connected device. The application image may be a firmware update or an operating system update.

The first device installs the application image on the first device (218). For instance, the first device receives a command to install the application image after receiving the application image. The first device may receive a command to reboot after installation of the application image is complete.

In some implementations, the process200can include additional steps, fewer steps, or some of the steps can be divided into multiple steps. For example, the first device may perform steps202through208and212without performing steps210and214through218.

In some examples, the first device may perform some of the steps of the process multiple times. For instance, the first device may perform steps202through208during each boot process and determine, using the result of the determination whether the device identifier is the same as the predetermined identifier, whether to continue the boot process or maintain the first device in the bootloader state, e.g., the high level bootloader state.

An example of one such type of computer is shown inFIG. 3, which shows a schematic diagram of a generic computer system300. The system300can be used for the operations described in association with any of the computer-implemented methods described previously, according to one implementation. The system300includes a processor310, a memory320, a storage device330, and an input/output device340. Each of the components310,320,330, and340are interconnected using a system bus350. The processor310is capable of processing instructions for execution within the system300. In one implementation, the processor310is a single-threaded processor. In another implementation, the processor310is a multi-threaded processor. The processor310is capable of processing instructions stored in the memory320or on the storage device330to display graphical information for a user interface on the input/output device340.

The memory320stores information within the system300. In one implementation, the memory320is a computer-readable medium. In one implementation, the memory320is a volatile memory unit. In another implementation, the memory320is a non-volatile memory unit.

The storage device330is capable of providing mass storage for the system300. In one implementation, the storage device330is a computer-readable medium. In various different implementations, the storage device330may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device340provides input/output operations for the system300. In one implementation, the input/output device340includes a keyboard and/or pointing device. In another implementation, the input/output device340includes a display unit for displaying graphical user interfaces.