How to perform a firmware update recovery, bootable devices and systems
Patent Information
- Application Number
- JP2025180092
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-03-31
- Filing Date
- 2025-10-27
- Publication Date
- 2026-10-14
Smart Images

Figure 2026167405000001_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present invention relate to a method for performing firmware update recovery, a bootable device, and a system.
Background Art
[0002]
[0001] A boot loader performs booting at startup to initialize the system by loading required software, typically an operating system or firmware, into memory. The boot loader stored in a non-volatile memory such as a flash memory is responsible for managing this process and ensuring that the correct program is loaded and executed. It often includes a mechanism for updating firmware by writing new code to the flash memory while maintaining system integrity. To ensure the reliability of the loaded software, checksums are generally used to verify data integrity and detect corruption or errors before execution. This prevents system failures caused by incorrect or incomplete updates.
Summary of the Invention
Problems to be Solved by the Invention
[0003] The problem to be solved by the present invention is to provide a method for performing firmware update recovery, a bootable device, and a system.
Means for Solving the Problems
[0004] The method of the embodiment is a method performed by a bootloadable device operably coupled to a bootloader device via at least one interface, the bootloadable device comprising: a first non-volatile memory having a boot program; a second non-volatile memory having a set of sequential memory blocks, each having a first sequential memory block having a base address corresponding to an entry point from which a processing circuit can first obtain code for execution in response to power-up or reset of the bootloadable device; and the processing circuit operably coupled to the first non-volatile memory and the second non-volatile memory, wherein the processing circuit, by executing the boot program, programs a bootload verification program in response to the entry point of the second non-volatile memory programming the last firmware image block of a set of firmware image blocks constituting a firmware module into the corresponding sequential memory block of the second non-volatile memory; and the processing circuit, by executing the bootload verification program, notifies the bootloader device via the interface whether or not the bootloadable device has booted the firmware module. [Brief explanation of the drawing]
[0005]
[0002] The present disclosure will be described in full below with reference to the accompanying drawings illustrating embodiments of the present disclosure. However, the present disclosure should not be construed as being limited to the embodiments described herein. Rather, these embodiments are provided so as to be thorough and complete and to fully convey the scope of the present disclosure to those skilled in the art. Throughout, similar numbers refer to similar elements.
[0006] [Figure 1] Figure 1 shows one embodiment of a system that can operate to perform a boot load according to the various embodiments described herein. [Figure 2A]Figure 2A shows another embodiment of the boot loader device according to various aspects described herein. [Figure 2B] Figure 2B shows another embodiment of a bootloadable device according to various aspects described herein. [Figure 3A] Figure 3A illustrates an embodiment of a method performed by a boot loader device that performs boot loading according to various embodiments described herein. [Figure 3B] Figure 3B shows an embodiment of a method performed by a boot loader device that performs boot loading according to various embodiments described herein. [Figure 3C] Figure 3C shows one embodiment of a method performed by a bootloadable device that performs bootloading according to the various embodiments described herein. [Figure 4] Figure 4 illustrates another embodiment of the device according to the various aspects described herein. [Modes for carrying out the invention]
[0007]
[0007] For the sake of brevity and illustrative purposes, this disclosure is described primarily by reference to its exemplary embodiments. In the following description, numerous specific details are given in order to give a full understanding of this disclosure. However, it will be readily apparent to those skilled in the art that this disclosure may be implemented without being limited to these specific details.
[0008]
[0008] The disclosure further includes, in particular, systems and methods for performing a boot load. For example, upon reset or power-up, the processing circuitry of a boot loadable device can be initialized by executing a predetermined sequence of instructions stored in a first non-volatile memory (e.g., flash, ROM). This typically begins with a hardware or firmware-based bootstrapping routine that checks for conditions indicating whether to enter boot loader mode or proceed to normal operating mode. If valid boot conditions are detected, such as a specific pin state, a received command, or corrupted firmware, the circuitry can transfer control to a boot program residing in a dedicated memory area of the non-volatile memory. The boot program can then establish communication with the boot loader device, for example, via a first interface (e.g., UART, USB, SPI, I2C) to receive firmware modules (e.g., program instructions or code, data). Once each block of the firmware module has been received, the processing circuitry can verify the integrity of the block, for example, by using a checksum or similar verification method, before writing the block to a second non-volatile memory. Each of the first and second non-volatile memories may be a separate memory or the same memory.
[0009]
[0009] Various verification methods ensure data integrity during boot loading or memory operation, with checksums being one of the simplest techniques. A more robust alternative is cyclic redundancy check (CRC), widely used in communication protocols and memory verification. Hash algorithms such as SHA-256 or MD5 provide stronger integrity checks by generating a unique fingerprint of the data. For sensitive applications, both integrity and authenticity can be verified with a message authentication code (MAC) or digital signature, ensuring that the firmware has not been tampered with. Error correction techniques such as Reed-Solomon coding or Hamming coding can not only detect errors in stored or transmitted data but also correct them. Other techniques include redundant data comparison, where data is written multiple times to check consistency, and parity checks, which detect single-bit errors. The choice of verification method depends on the application's requirements for reliability, security, and computational efficiency. Once a firmware module is received and stored in a second non-volatile memory, the bootloadable device may perform integrity checks (e.g., checksum verification) before rebooting and executing the newly loaded firmware module. If the boot conditions are not met during the next power-up or reset sequence of the bootable device, the processing circuit can jump to the entry point of the newly loaded firmware module in the second non-volatile memory, initialize the system, and execute the new firmware code.
[0010]
[0010] During bootloading, flushing refers to the process of erasing and programming flash memory, a type of non-volatile storage commonly used in firmware, which is organized into a hierarchical structure consisting of memory cells, pages, blocks, planes, and dies. At the lowest level, memory cells store data using floating gate transistors, and each cell can hold one or more bits depending on the type of flash memory (SLC, MLC, TLC, or QLC). These cells are grouped into pages, which function as the smallest unit of read and write operations. Page sizes typically range from 4KB to 16KB. A collection of pages forms a block, which is the smallest unit that can be erased in flash memory. Block sizes generally range from 256KB to several megabytes and contain multiple pages, usually 64 to 256 pages per block. To improve parallelism and performance, multiple blocks are grouped into planes, and multiple planes are integrated into a die, which represents a single silicon chip. A complete flash memory package may contain multiple dies to increase storage capacity. Flash memory must be erased before new data can be written to it, and this process is typically performed using a predetermined block size that varies depending on the type of memory. For example, NOR flash often has small sector sizes ranging from 4KB to 64KB, making it ideal for frequent updates. In contrast, NAND flash uses larger block sizes of 128KB to several megabytes, optimizing it for high-density storage but requiring more complex management. Choosing the appropriate flash memory and block size impacts firmware update efficiency, power consumption, and overall system performance.
[0011]
[0011] The bootloader device can perform a hard or soft reset of the bootloadable device to initiate the bootload process or to apply a firmware update. A hard reset is typically achieved by directly controlling the reset pin of the bootloadable device, either by pulling the reset pin low via a dedicated hardware connection or by briefly cutting and restoring power. This restarts the device from its initial power-on state and clears all volatile memory. In contrast, a soft reset is performed using software commands sent via a first interface. The bootloader device can send a specific reset command to trigger a software interrupt or instruct the bootloadable device to perform a reset sequence via its internal watchdog timer. A soft reset allows for a controlled reboot without fully cycling the power, which is useful for seamless firmware updates and debugging.
[0012]
[0012] The disclosure further includes, in particular, systems and methods for performing firmware update recovery. For example, if a bootloadable device fails to boot up, the bootloader device may become unresponsive during boot-up. Furthermore, other system devices may not be able to detect a bootloadable device that is not booting. For bootloadable devices with limited non-volatile memory capacity, such as those configured to store only one firmware file, solutions with fail-safe mechanisms or solutions that maintain multiple firmware versions are not feasible. If a failure occurs during firmware transfer from the bootloader device to the bootloadable device, the system may hang or experience delays, significantly impacting system performance and user experience. In one example, to resolve this without adding additional hardware components that increase hardware costs, a software-based assurance mechanism can be applied by modifying the firmware of the bootloadable device to assert a general-purpose input / output (GPIO) pin before initiating a firmware update, thereby allowing the bootloader device to monitor the state of the GPIO pin. If the state of a GPIO pin does not change within a specified time (e.g., 1, 5, 10, 20, or 30 seconds), the bootloader device triggers a recovery process to prevent infinite waiting, ensure system responsiveness without requiring additional hardware changes, improve reliability, and reduce boot delays.
[0013]
[0013] Figure 1 shows one embodiment of a system 100 that is operable to perform a boot load according to various embodiments described herein. In Figure 1, the system 100 may include a boot loader device 101 (e.g., an embedded controller device, a microcontroller device, an ASIC, a DSP) having a processing circuit 103 operably coupled to a memory 105 containing a firmware module 107 (e.g., an application) and a boot load verification program 109. Furthermore, the firmware module 107 may include executable code, configuration data, lookup tables, calibration data, security data, authentication data, user data, system data, firmware update data, the boot load verification program 109, etc., or any combination thereof. System 100 may also include a boot loadable device 111 (e.g., an embedded controller device, a microcontroller device, an ASIC, a DSP) having a processing circuit 113 operably coupled to memory 115, which includes a first non-volatile memory 117 (e.g., ROM, flash) having a boot program 118, and a second non-volatile memory 119 (e.g., flash) containing a set of sequential memory blocks 121-{1,...,Z} having specific block sizes (e.g., 64kB, 128kB, 256kB, 512kB, 1MB, 2MB, 4MB). Each of the first and second non-volatile memories 117, 119 may be separate memories or the same memory. The boot program 118 may be configured to initialize the boot loadable device 111 at power-up or reset (e.g., soft reset, hard reset) by loading firmware into the first or second non-volatile memory 117, 119. The boot load verification program 109, when executed by the processing circuit 113 of the boot loadable device 111, can be configured to indicate to the boot loader device 101 via the second interface 131b whether the boot loadable device 111 has been successfully booted.The firmware module 107 can be represented (configured) by sequential firmware blocks 123-{1,...,N}, where the size of each firmware block 123-{1,...,N} corresponds to the size of each sequential memory block 121-{1,...,Z} of the second non-volatile memory 119 of the bootloadable device 111.
[0014]
[0014] In Figure 1, the boot loader device 101 and the boot loadable device 111 can share the first, second, and third interfaces 131a to c. For example, the first interface 131a is a serial interface (e.g., UART, USB, SPI, I2C), the second interface 131b is a GPIO interface, and the third interface 131c is a hard reset interface. In yet another example, the first interface 131a may be configured to enable communication between the bootloader device 101 and the bootloadable device 111; the second interface 131b may be configured to enable the bootloadable device 111 to indicate to the bootloader device 101 whether the bootloadable device 111 has successfully boot-loaded to the second non-volatile memory 119 or whether the bootloadable device 111 has boot-loaded; and the third interface 131c may be configured to enable the bootloader device 101 to hard reset the bootloadable device 111, such as via a reset circuit 133. In one example, the reset circuit 133 may be a watchdog timer reset circuit configured to generate a reset signal to restart the bootloadable device 111 if the bootloadable device 111 does not provide instructions within a certain period (e.g., 1 second, 2 seconds, 5 seconds, 10 seconds, 20 seconds, 30 seconds). In another example, the reset circuit 133 may be a GPIO-controlled reset circuit configured to trigger the reset line of the bootloadable device 111. In yet another example, the reset circuit 133 may be an open-drain reset circuit with a pull-up resistor configured to allow the bootloader device 101 to pull the reset pin of the bootloadable device 111 low, thereby triggering a reset of the bootloadable device 111. The bootloader device 101 may also be configured to allow a soft reset of the bootloadable device 111 via the first interface 107a.The first interface 107a, the second interface 107b, and the third interface 107c may be the same interface, different interfaces, or any combination thereof. In some embodiments, the first, second, and third interfaces 107a-107c are the same interface. In other embodiments, each interface 107a-107c is distinct. In yet another embodiment, two of the interfaces 107a-107c are the same interface, while the remaining interfaces are different.
[0015]
[0015] During operation, the boot loader device 101 can perform a power-on or reset sequence to put the boot loader device 101 into boot mode. Furthermore, the boot loader device 101 can monitor the second interface 131b to determine whether the boot loadable device 111 has booted up. For example, the boot loader device 101 can monitor specific GPIO pins of the boot loadable device 111 to determine whether the boot loadable device 111 has booted up, such as a high signal on a specific GPIO pin indicating that the boot loadable device 111 is booted up, and a low signal on a specific GPIO pin indicating that the boot loadable device 111 is not booted up. If the boot loader device 101 determines that the boot loadable device 111 has booted up in response to an instruction from the boot loadable device 111 via the second interface 131b that the boot loadable device 111 has booted up, the boot loader device 101 can configure the boot loader device 101 for normal operating mode. However, if the bootloader device 101 determines that the bootloadable device 111 is not bootloaded after a certain period of time (e.g., 1 second, 2 seconds, 5 seconds, 10 seconds, 20 seconds, 30 seconds) in which instructions from the bootloadable device 111 via the second interface 131b indicate that the bootloadable device 111 is not bootloaded, the bootloader device 101 can establish communication with the bootloadable device 111 via the first interface 131a. Additionally or alternatively, the bootloadable device 101 can enable a hard reset of the bootloadable device 111 via a third interface 131c, such as via a reset circuit 133, or it can enable a soft reset of the bootloadable device 111 via the first interface 131a.
[0016]
[0016] Furthermore, in response to power-on or reset of the boot loadable device 111, the boot loadable device 111 can be executed by the processing circuit 113, which executes a boot program 118 stored in the first non-volatile memory 117. The boot loadable device 111 can be erased by the boot program 118 executed by the processing circuit 113, which has a boot load verification program 124 stored in the entry point 127 of the second non-volatile memory 119. The base address of the first memory block 1211 corresponds to the entry point 127 from which the processing circuit 113 can first fetch (also called "acquire") the code for execution in response to power-on or reset of the boot loadable device 111. The boot loadable device 111 can establish communication with the boot loader device 101 via the first interface 131a by the boot program 118 executed by the processing circuit 113. The boot loader device 101, based on the firmware module verification code 125 contained in the firmware module 107, enables verification that the firmware module 107 has been programmed into the second non-volatile memory 119 without errors, by providing a first sequential firmware block 1231 having a boot load verification program 124 and a last sequential firmware block 123 having a firmware module verification code 125 (e.g., checksum, CRC) via the first interface 131a. NEach firmware block 123-{1,...,N} constituting the firmware module 107 can be transmitted to the bootloadable device 111. The bootloadable device 111 can notify the bootloader device 101 via the second interface 131b whether or not the bootloadable device 111 has been bootloaded, through a bootload verification program 124 executed by the processing circuit 113. For example, the bootloadable device 111 can notify the bootloadable device 101 whether or not the bootloadable device 111 has been bootloaded by changing the state of a specific GPIO pin of the bootloadable device 111 to a high or low state, with the specific GPIO pin operably coupled to the bootloader device 101.
[0017]
[0017] Furthermore, the boot loadable device 111 can receive each block 123-{1,...,N} of the firmware module 107 from the boot loader device 101 via the first interface 131a by the boot program 118 executed by the processing circuit 113, the first block 1231 has the boot load verification program 109 at the base address of that block 1231, and the last block 123 N That is block 123 NThe final address of the firmware module has a firmware module verification code 125. The boot loadable device 111 can verify that each received block 123-{1,...,N} was received without error based on the block verification code (e.g., checksum, CRC) contained in each received block 123-{1,...,N}, by the boot program 118 executed by the processing circuit 113. Furthermore, the boot loadable device 111 can detect or correct errors in each received block 123-{1,...,N} based on the block verification code contained in that block 123-{1,...,N}, by the boot program 118 executed by the processing circuit 113. The boot loadable device 111 can verify that each received block 123-{1,...,N} was received without error based on the block verification code contained in that block 123-{1,...,N}, by the boot program 118 executed by the processing circuit 113. N Each receive block 123-{1,...,N} up to can be programmed into the corresponding block 121-{1,...,N} of the second non-volatile memory 119. Furthermore, the boot loadable device 111 can program the last block 123 of the firmware module 107. NIn response to programming the corresponding blocks 121-{1,...,N} of the second non-volatile memory 119, the boot program 118 executed by the processing circuit 113 can program the boot load verification program 109 of the second non-volatile memory 119 or the first block 1231 of the firmware module 107 having the boot load verification program 109 at the entry point 127. Furthermore, the boot loadable device 111 can verify, by the boot program 118 executed by the processing circuit 113, that the firmware module has been programmed into the second non-volatile memory without errors, based on the firmware module verification code 125 contained in the firmware module. The boot loadable device 111 can also detect or correct boot load errors of the firmware module 107 based on the firmware module verification code 125, by the boot program 118.
[0018] In FIG. 1, in response to transmitting a set of a series of firmware image blocks 123-{1, ..., N} constituting the firmware module 107 to the bootable device 111, the bootloader device 101 can enable a soft or hard reset of the bootable device 111 via the respective first or third interface 131a,c, and the third interface 131c is coupled between the bootloader device 101 and the bootable device 111 via the reset circuit 133 or the like. In response to the soft or hard reset, the bootable device 111 can execute, by the processing circuit 113, the boot load verification program 109 stored in the second nonvolatile memory 119, starting from the entry point 127 at the base address of the second nonvolatile memory 119. The bootable device 111 can indicate, via the second interface 131b, to the bootloader device 101 that the bootable device has boot loaded the firmware module 107 by the boot load verification program 109 executed by the processing circuit 113. The bootloader device 101 can monitor the second interface 131b to determine whether the bootable device 111 has completed booting. In response to the instruction from the bootable device 111 via the second interface 131b that the bootable device 111 has completed booting, and in response to determining that the bootable device 111 has completed booting, the bootloader device 101 can configure the bootloader device 101 to a normal operation mode.
[0019]
[0019] FIG. 2A illustrates another embodiment of a bootloader device 200a in accordance with various aspects described herein. In FIG. 2A, the apparatus 200a may include processing circuitry 201a operatively coupled to one or more of a memory 203a, a first interface circuit 211a, a second interface circuit 212a, a third interface circuit 213a, and the like, or any arbitrary combination thereof. Each of the interface circuits 211a, 212a, 213a may be configured to communicate via any communication technology (e.g., UART, USB, SPI, I2C, GPIO, etc.). The processing circuitry 201a may be configured to perform the processes described herein, such as by executing instructions stored in the memory 203a. In this regard, the processing circuitry 201a may implement particular functional means, units, or modules.
[0020]
[0020] FIG. 2B illustrates another embodiment of a bootloadable device 200b in accordance with various aspects described herein. In FIG. 2B, the apparatus 200b may include processing circuitry 201b operatively coupled to one or more of a memory 203b, a first interface circuit 211b, a second interface circuit 212b, a third interface circuit 213b, and the like, or any arbitrary combination thereof. The memory 203b may include a first non-volatile memory 205b (e.g., ROM, flash) having a boot program 206b, and a second non-volatile memory 207b (e.g., flash). Each of the interface circuits 211b, 212b, 213b may be configured to communicate via any communication technology (e.g., UART, USB, SPI, I2C, GPIO, etc.). The processing circuitry 201b may be configured to perform the processes described herein, such as by executing instructions stored in the memory 203b. In this regard, the processing circuitry 201b may implement particular functional means, units, or modules.
[0021]
[0021] Figure 3A shows one embodiment of method 300a for performing a boot load, which is performed by a boot loader device according to various embodiments described herein. In Figure 3A, method 300a can begin, for example, in block 301a, where the method may include a processing circuit executing a boot program stored in a second non-volatile memory in response to a power-up or reset sequence performed by the boot loadable device that puts the boot loadable device into boot mode. In block 303a, method 300a may include the boot program executed by the processing circuit erasing a first block having a boot load verification program that begins at the entry point of the second non-volatile memory. In block 305a, method 300a may include the boot program executed by the processing circuit establishing communication with the boot loader device via a first interface. In block 307a, method 300a may include a boot program executed by a processing circuit receiving each block of the firmware module from a boot loader device via a first interface, wherein the first received block has a boot load verification program at its base address, and the last received block has a firmware module verification code. In block 309a, method 300a may include a boot program executed by a processing circuit verifying that each received block was received without error based on the block verification code contained in each received block. In block 311a, method 300a may include a boot program executed by a processing circuit detecting or correcting an error in one of the received blocks based on the block verification code. In block 313a, method 300a may include a boot program executed by a processing circuit programming each block received from the second block to the last block of the firmware module into the corresponding block in the second non-volatile memory.In block 315a, method 300a includes, in response to programming the last block of the firmware module into the corresponding block of the second non-volatile memory, a boot program executed by a processing circuit to program a boot load verification program into the entry point of the second non-volatile memory, or programming the first block of the firmware module having the boot load verification program into the entry point. In block 317a, method 300a may include the boot program verifying that the firmware module was received without errors based on the firmware module verification code contained in the firmware module. In block 319a, method 300a may include the boot program detecting or correcting errors in the firmware module based on the firmware module verification code.
[0022]
[0022] Figure 3B shows one embodiment of method 300b performed by a bootloadable device that performs bootloading according to various embodiments described herein. In Figure 3B, method 300b can begin, for example, in block 301b, where a processing circuit may execute bootload verification program code stored in the second non-volatile memory in response to a power-on or reset sequence performed by the bootloadable device that puts the bootloadable device into normal operating mode, starting from the entry point of the base address of the second non-volatile memory. In block 303b, method 300b includes the bootload verification program executed by the processing circuit notifying the bootloader device via a second interface whether or not the bootloadable device has been bootloaded.
[0023]
[0023] Figure 3C shows one embodiment of method 300c performed by a bootloadable device that performs bootloading according to various embodiments described herein. In Figure 3C, method 300c can begin, for example, in block 301c, which may include performing a power-on or reset sequence to put the bootloader device into bootloader operating mode. In block 303c, method 300c may include monitoring a second interface to determine whether the bootloadable device is bootloaded. In block 305c, method 300c may include determining that the bootloadable device is bootloaded in response to an instruction from the bootloader device via the second interface that the bootloadable device is bootloaded. In block 307c, method 300c may include configuring the bootloader device to operate in normal operating mode. In block 309c, method 300c may include determining that a bootloadable device is not bootloaded in response to an instruction from a bootloader device via a second interface that the bootloadable device is not bootloaded. In block 311c, method 300c may include establishing communication with the bootloadable device via a first interface. In block 313c, method 300c may include the bootloader device transmitting to the bootloadable device via the first interface each block of the firmware module having a first sequential memory block of the firmware module having a bootload verification program and the last sequential memory block having firmware module verification code. In block 315c, method 300c may include soft-resetting or hard-resetting the bootloadable device via the respective first or third interface, the third interface being coupled between the bootloader device and the bootloadable device.
[0024]
[0024] Figure 4 shows another embodiment of the boot loader device or boot loadable device 400 according to various aspects described herein. In Figure 4, the device 400 includes an input / output interface 405 via a bus 403, artificial intelligence circuitry 409 (e.g., neural network circuitry, machine learning circuitry), a network connectivity interface 411, a power supply 413, memory 415 including random access memory (RAM) 417, read-only memory (ROM) 419 and non-volatile memory 421, a communication subsystem 431, and / or any other components, or any combination thereof, of processing circuitry 401 operably coupled to them. In one example, the device 400 can be operably coupled to one or more optical sensor devices via a wired communication interface (e.g., USB, Ethernet) or a wireless communication interface (e.g., WiFi, Bluetooth). Furthermore, the device 400 can be operably coupled to one or more optical sensor devices via the network connectivity interface 411 or the communication subsystem 431.
[0025]
[0025] The input / output interface 405 may be configured to provide an input device, an output device, or a communication interface to an input / output device. Device 400 may be configured to use an output device via the input / output interface 405. The output device 461 may use the same type of interface port as the input device. For example, a USB port or a Bluetooth port can be used to provide input to and output from device 400. The output device may be a speaker, sound card, video card, display, monitor, printer, actuator, transducer 475 (e.g., speaker, ultrasonic emitter), emitter, smart card, another output device, or any combination thereof. Device 400 may be configured to use an input device via the input / output interface 405 to allow a user to take information into device 400. The input device may include a position-sensing display, sensors, microphone, mouse, trackball, directional pad, trackpad, scroll wheel, smart card, etc. The position-sensing display may include a capacitive or resistive touch sensor for sensing input from the user. The sensor may be, for example, an accelerometer, gyroscope, tilt sensor, force sensor, magnetometer, optical or image sensor, infrared sensor, proximity sensor, microphone, ultrasonic sensor, other similar sensors, or any combination thereof.
[0026]
[0026] In Figure 4, the non-volatile memory 421 may include an operating system 423, application programs 425, data 427, etc., or any combination thereof. In other embodiments, the non-volatile memory 421 may include other similar types of information. A particular device may utilize all or only a subset of the components shown in Figure 4. The level of integration between components may vary from device to device. Furthermore, a particular device may include multiple instances of components such as multiple processors, memory, neural networks, network connectivity interfaces, and transceivers.
[0027]
[0027] In Figure 4, the processing circuit 401 may be configured to process computer instructions and data. The processing circuit 401 can be configured to implement any of a set of state machines that operate to execute machine instructions stored in memory as machine-readable computer programs, for example, one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC), programmable logic with appropriate firmware, one or more stored programs in combination with appropriate software, a general-purpose processor such as a microprocessor or digital signal processor (DSP), or any combination thereof. For example, the processing circuit 401 may include two CPUs (Central Processing Units). The data may be information in a form suitable for use by a computer.
[0028]
[0028] In Figure 4, the artificial intelligence circuit 409 may be configured to learn to perform tasks by considering examples such as performing object detection, classification, or identification based on an image. In one example, the first artificial intelligence circuit is configured to perform activity detection. Furthermore, the second artificial intelligence circuit is configured to perform object classification or identification. In Figure 4, the network connection interface 411 may be configured to provide a communication interface to the network 443a. The network 443a may encompass wired and / or wireless networks such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 443a may comprise a Wi-Fi network. The network connection interface 411 may be configured to include receiver and transmitter interfaces used to communicate with one or more other devices over the communication network according to one or more communication protocols such as Ethernet, TCP / IP, SONET, ATM, etc. The network connection interface 411 can implement receiver and transmitter functions suitable for the communication network link (e.g., optical, electrical, etc.). The transmitter and receiver functions may share circuit components, software, or firmware, or they may be implemented separately.
[0029]
[0029] The RAM 417 may interface with the processing circuit 401 via the bus 403 and be configured to provide storage or a cache of data or computer instructions during the execution of software programs such as operating systems, application programs, and device drivers. The ROM 419 may be configured to provide computer instructions or data to the processing circuit 401. For example, the ROM 419 may be configured to store immutable low-level system code or data for basic system functions such as basic input / output (I / O), booting, or receiving keystrokes from a keyboard, which are stored in non-volatile memory. The non-volatile memory 421 may be configured to include memory such as RAM, ROM, flash, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, or flash drive. In one example, the non-volatile memory 421 may be configured to include an operating system 423, an application program 425 such as a web browser, a web application, a user interface, a browser data manager as described herein, a widget or gadget engine, or another application, and data files 427. The non-volatile memory 421 may store any or a combination of various operating systems for use by the device 400.
[0030]
[0030] The non-volatile memory 421 can be configured to include several physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disk (HD-DVD) optical disk drive, an internal hard disk drive, a Blu-ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external microDIMM SDRAM, smart card memory such as a subscriber identification module or a removable user identification (SIM / RUIM) module, other memory, or any combination thereof. The non-volatile memory 421 can enable the device 400 to access computer executable instructions, application programs, etc., stored on a temporary or non-temporary memory medium, to offload data, or to upload data. Products such as those utilizing communication systems can be tangibly embodied in the non-volatile memory 421, which may have a device-readable medium.
[0031]
[0031] The processing circuit 401 may be configured to communicate with network 443b using a communication subsystem 431. Networks 443a and 443b may be the same network or different networks. The communication subsystem 431 may be configured to include one or more transceivers used to communicate with network 443b. For example, the communication subsystem 431 may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication according to one or more communication protocols such as IEEE802.11, CDMA, WCDMA®, GSM, LTE, UTRAN, WiMax. Each transceiver may include a transmitter 433 and / or receiver 435 to implement appropriate transmitter or receiver functions for a RAN link (e.g., frequency allocation). Furthermore, the transmitter 433 and receiver 435 of each transceiver may share circuit components, software, or firmware, or they may be implemented separately.
[0032]
[0032] In Figure 4, the communication functions of the communication subsystem 431 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as the use of the Global Positioning System (GPS) for determining location, other similar communication functions, or any combination thereof. For example, the communication subsystem 431 may include cellular communication, Wi-Fi communication, Bluetooth® communication, and GPS communication. The network 443b may encompass wired and / or wireless networks such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 443b may be a cellular network, a Wi-Fi network, and / or a near-field wireless network. The power supply 413 may be configured to supply alternating current (AC) or direct current (DC) power to the components of the device 400.
[0033]
[0033] The features, benefits, and / or functions described herein may be implemented in one of the components of device 400, or they may be divided among multiple components of device 400. Furthermore, the features, benefits, and / or functions described herein may be implemented in any combination of hardware, software, or firmware. In one example, the communication subsystem 431 may be configured to include any of the components described herein. Furthermore, the processing circuit 401 may be configured to communicate with any of such components via the bus 403. In another example, any of such components can be represented by program instructions stored in memory that, when executed by the processing circuit 401, perform the corresponding functions described herein. In another example, the functions of any of such components may be divided between the processing circuit 401 and the communication subsystem 431. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware, while computationally intensive functions may be implemented in hardware.
[0034]
[0034] Those skilled in the art will also understand that embodiments of this specification further include corresponding computer programs.
[0035]
[0035] A computer program, when executed on at least one processor of the device, includes instructions that cause the device to perform one of the processes described above. The computer program relating thereto may include one or more code modules corresponding to the means or units described above.
[0036]
[0036] Embodiments further include a carrier containing such a computer program. This carrier may include one of electronic signals, optical signals, radio signals, or a computer-readable storage medium.
[0037]
[0037] In connection therewith, embodiments of this specification also include a computer program product which, when stored on a non-temporary computer-readable (storage or recording) medium and executed by the device's processor, contains instructions that cause the device to perform the actions described above.
[0038]
[0038] Embodiments further include a computer program product which includes a portion of program code for performing any of the embodiments herein when the computer program product is executed by a computing device. The computer program product may be stored on a computer-readable recording medium.
[0039]
[0039] Alternatively or additionally, some or all of the functions may be implemented by a state machine that does not have stored program instructions, or by one or more application-specific integrated circuits (ASICs) in which each function or some combination of particular functions is implemented as a custom logic circuit. Of course, a combination of the two methods may also be used. Furthermore, those skilled in the art will expect that such software instructions and programs and ICs can be easily generated with minimal experimentation, guided by the concepts and principles disclosed herein, despite the many design choices motivated by potentially great effort and, for example, available time, current technology, and economic considerations.
[0040]
[0040] As used herein, the term “product” is intended to encompass computer programs accessible from any computing device, carrier, or medium. For example, computer-readable media may include magnetic storage devices such as hard disks, floppy disks, or magnetic strips; optical discs such as compact discs (CDs) or digital multipurpose discs (DVDs); smart cards; and flash memory devices such as cards, sticks, or key drives. Furthermore, it should be understood that carrier waves may be used to carry computer-readable electronic data, including those used when sending and receiving electronic data such as email, or when accessing computer networks such as the Internet or a local area network (LAN). Naturally, those skilled in the art will recognize that many modifications can be made to this configuration without departing from the scope or spirit of the subject matter of this disclosure.
[0041]
[0041] Further embodiments will now be described. While at least some of these embodiments can be described as applicable in a particular context for illustrative purposes, the embodiments are also applicable in other contexts not explicitly described.
[0042]
[0042] In an exemplary embodiment, the method is performed by a bootloadable device operably coupled to a bootloader device via first and second interfaces. The bootloadable device further includes a processing circuit operably coupled to a first non-volatile memory having a boot program and a second non-volatile memory having a set of sequential memory blocks, each having a first sequential memory block with a base address corresponding to an entry point from which the processing circuit can first fetch code for execution in response to a power-up or reset sequence performed by the bootloadable device. The method includes programming a bootload verification program at the entry point of the second non-volatile memory by the boot program executed by the processing circuit in response to programming the last sequential memory block of the set of sequential memory blocks of the firmware module into the corresponding sequential memory block of the second non-volatile memory. In addition, the bootload verification program is configured, when executed by the processing circuit, to notify the bootloader device via the second interface whether the bootloadable device has booted the firmware module.
[0043]
[0043] According to another embodiment, the method may include the processing circuit executing a boot program stored in a second non-volatile memory in response to a power-up or reset sequence performed by the boot loadable device that puts the boot loadable device into boot mode.
[0044]
[0044] According to another embodiment, the method may include erasing the first sequential memory block of the second non-volatile memory having a boot load verification program that begins at the entry point of the second non-volatile memory, by a boot program executed by a processing circuit.
[0045]
[0045] According to another embodiment, the method may include establishing communication with a boot loader device via a first interface by a boot program executed by a processing circuit.
[0046]
[0046] According to another embodiment, the method may include receiving each of a set of firmware image blocks constituting a firmware module from a boot loader device via a first interface by a boot program executed by a processing circuit, wherein the first firmware image block of the set of firmware image blocks has a boot load verification program, and the last firmware image block of the set of firmware image blocks has firmware module verification code.
[0047]
[0047] According to another embodiment, the method may include a boot program executed by the processing circuit programming each of the received firmware image blocks from the second to the last of a set of firmware image blocks into the corresponding sequential memory blocks of the second non-volatile memory.
[0048]
[0048] According to another embodiment, the method may include programming a boot load verification program, or the first of a set of firmware image blocks having a boot load verification program, at the entry point of the first sequential memory block of the second non-volatile memory, in response to a boot program executed by a processing circuit programming the last firmware image block of a set of firmware image blocks into a corresponding one of a set of sequential memory blocks of the second non-volatile memory.
[0049]
[0049] According to another embodiment, the method may include obtaining a firmware module verification code from a firmware module by a boot program executed by a processing circuit, and verifying by a boot program executed by a processing circuit that the firmware module has been received and programmed into a second non-volatile memory without errors based on the firmware module verification code.
[0050]
[0050] According to another embodiment, the method may include a boot load verification program executed by the processing circuit notifying the boot loader device via a second interface whether or not the boot loadable device has been booted.
[0051]
[0051] According to another embodiment, the first interface can be associated with a serial interface, and the second interface can be associated with a GPIO interface.
[0052]
[0052] According to one embodiment, a bootloadable device is operably coupled to a bootloader device via first and second interfaces. Furthermore, the bootloadable device includes a processing circuit operably coupled to a first non-volatile memory having a boot program and a second non-volatile memory having a set of sequential memory blocks, the first of which is a set of sequential memory blocks having a base address corresponding to an entry point from which the processing circuit can first fetch code for execution in response to a power-up or reset sequence performed by the bootloadable device. The bootloadable device further includes a memory having a memory containing instructions executable by the processing circuit, the processing circuit being configured to program a bootload verification program at the entry point of the second non-volatile memory in response to the boot program performed by the processing circuit programming the last firmware image block of a set of firmware image blocks constituting a firmware module into a corresponding one of the sequential memory blocks of the second non-volatile memory. In addition, the bootload verification program, when executed by the processing circuit, is configured to notify the bootloader device via a second interface whether or not the bootloadable device has booted up the firmware module.
[0053]
[0053] According to another embodiment, the memory may include further instructions that can be executed by a processing circuit, which is configured to execute a boot program stored in a second non-volatile memory in response to a power-up or reset sequence performed by the boot loadable device that puts the boot loadable device into boot mode.
[0054]
[0054] According to another embodiment, the memory may include further instructions that can be executed by a processing circuit, and the processing circuit is configured to erase a first sequential memory block of the second non-volatile memory having a boot load verification program that begins at the entry point of the second non-volatile memory, by a boot program executed by the processing circuit.
[0055]
[0055] According to another embodiment, the memory may include further instructions that can be executed by a processing circuit, and the processing circuit is configured to establish communication with a boot loader device via a first interface by a boot program executed by the processing circuit.
[0056]
[0056] According to another embodiment, the memory may include further instructions that can be executed by a processing circuit, the processing circuit is configured to receive each of a set of firmware image blocks constituting a firmware module from a boot loader device via a first interface by a boot program executed by the processing circuit, the first of the set of firmware image blocks having a boot load verification program, and the last of the set of firmware image blocks having firmware module verification code.
[0057]
[0057] According to another embodiment, the memory may include further instructions that can be executed by a processing circuit, and the processing circuit is configured to program each of the series of firmware image blocks received from the second to the last of a set of firmware image blocks into the corresponding sequential memory blocks of the second non-volatile memory by a boot program executed by the processing circuit.
[0058]
[0058] According to another embodiment, the memory may include further instructions executable by a processing circuit, and the processing circuit is configured to program a boot load verification program, or the first of a set of firmware image blocks having a boot load verification program, at the entry point of the first sequential memory block of the second non-volatile memory, in response to a boot program executed by the processing circuit programming the last firmware image block of a set of firmware image blocks into a corresponding one of a set of sequential memory blocks of the second non-volatile memory.
[0059]
[0059] According to another embodiment, the memory may include further instructions that can be executed by a processing circuit, the processing circuit is configured to obtain a firmware module verification code from the firmware module by a boot program executed by the processing circuit. Based on the firmware module verification code, the boot program executed by the processing circuit is configured to verify that the firmware module has been received without error and programmed into a second non-volatile memory.
[0060]
[0060] According to another embodiment, the memory may include further instructions that can be executed by a processing circuit, and the processing circuit is configured to notify the boot loader device via a second interface whether or not the boot loadable device has been booted, by a boot load verification program executed by the processing circuit.
[0061]
[0061] In one embodiment, the system includes a boot loader device and a boot loadable device operably coupled to the boot loader device via first and second interfaces. The boot loadable device further includes a processing circuit operably coupled to a first non-volatile memory having a boot program and a second non-volatile memory having a set of sequential memory blocks, the first of which has a base address corresponding to an entry point from which the processing circuit can first fetch code for execution in response to a power-up or reset sequence performed by the boot loadable device. The boot loadable device is operable to program a boot load verification program at the entry point of the second non-volatile memory in response to the boot program, executed by the processing circuit, programming the last firmware image block of a set of firmware image blocks constituting a firmware module into a corresponding one of the sequential memory blocks of the second non-volatile memory, the boot load verification program being configured when executed by the processing circuit to notify the boot loader device via the second interface whether or not the boot loadable device has boot-loaded the firmware module.
[0062]
[0062] The above-mentioned detailed description is essentially illustrative and is not intended to limit the Disclosure or the Use and Application of the Disclosure. Furthermore, there is no intention to be bound by any expression or implied theory presented in the above-mentioned Field of Use, Background Art, Abstract, or Detailed Description. The Disclosure provides various examples, embodiments, etc., that can be described herein with respect to functional block elements or logical block elements. Various embodiments described herein are presented as methods, devices (or apparatus), systems, or products which may include several components, elements, members, modules, nodes, peripherals, etc. Furthermore, these methods, apparatus, systems, or products may or may not include additional components, elements, members, modules, nodes, peripherals, etc.
[0063]
[0063] Furthermore, various embodiments described herein can be implemented using standard programming or engineering techniques to generate software, firmware, hardware (e.g., circuitry), or any combination thereof, and can control computing devices to implement the disclosed subject matter. It will be understood that some embodiments may consist of one or more general-purpose or dedicated processors, such as microprocessors, digital signal processors, customized processors, and field-programmable gate arrays (FPGAs), and a set of specific stored program instructions (including both software and firmware) that control one or more processors to perform some, most, or all of the functions of the methods, apparatus, and systems described herein in conjunction with specific non-processor circuits.
[0064]
[0064] Throughout this specification and its embodiments, the following terms have meanings at least as expressly relating to this specification unless otherwise explicitly indicated by the context. Relational terms such as “first” and “second” may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying an actual relationship or order between such entities or actions. The term “or” is intended to mean comprehensive “or” unless otherwise specified or it is evident from the context that it refers to an exclusive form. Furthermore, the terms “a,” “an,” and “the” are intended to mean one or more unless otherwise specified or it is evident from the context that they refer to a singular form. The term “include” and its various forms mean “include, but not limited to.” References to “one embodiment,” “embodiment,” “exemplary embodiment,” “various embodiments,” and other similar terms indicate that embodiments of the disclosed technology described in such terms may include certain functions, features, structures, or characteristics, but not all embodiments may include certain functions, features, structures, or characteristics. Furthermore, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, but may. The terms “substantially,” “essentially,” “approximately,” “about,” or any other version thereof are defined as close to what is understood by those skilled in the art, and in one non-limiting embodiment, this term is defined as within 10%, in another embodiment within 5%, in yet another embodiment within 1%, and in yet another embodiment within 0.5%. An apparatus or structure “configured” in a particular way is configured at least in that way, but may be configured in ways not listed. [Explanation of Symbols]
[0065] 100 Systems 101 Boot loader device 103 Processing Circuit 105 memory 107 Firmware Modules 107a First Interface 107b Second Interface 107c Third Interface 109 Bootload Verification Program 111 Bootloadable Device 113 Processing Circuit 115 memory 117. The first non-volatile memory 118 Boot Program 119. Second non-volatile memory 121 1~Z Sequential memory block one two three 1~N Firmware block 124 Bootload Verification Program 125 Firmware Module Verification Code 127 Entry Point 1 131a First Interface 131b Second Interface 131c Third Interface 133 Reset Circuit 200a Boot loader device 200b Bootloadable Device 201a Processing Circuit 201b Processing Circuit 203a Memory 203b memory 205b First non-volatile memory 206b Boot Program 207b Second non-volatile memory 211a Interface Circuit 211b Interface Circuit 212a Interface Circuit 212b Interface Circuit 213a Interface Circuit 213b Interface Circuit 300a method 300b method 300c method Block 301a Block 301b 301c Block Block 303a Block 303b 303c block 305a Block 305c block 307a Block 307c Block Block 309a 309c Block 311a Block 311c block 313a Block 313c Block 315a Block 315c block 317a Block Block 319a 400 Bootloadable Devices 401 Processing Circuit Bus 403 405 Input / Output Interface 409 Artificial Intelligence Circuits 411 Network Connection Interface 413 Power supply 415 memory 417 Random Access Memory (RAM) 419 Read-only memory (ROM) 421 Non-volatile memory 423 Operating Systems 425 Application Programs 427 data 431 Communication Subsystem 433 Transmitter 435 Receiver 443a Network 443b Network
Claims
1. A method performed by a boot loadable device operably coupled to a boot loader device via at least one interface, The aforementioned boot loadable device is A first non-volatile memory having a boot program, A second non-volatile memory having a set of sequential memory blocks, each having a first sequential memory block with a base address corresponding to an entry point from which the processing circuit can first obtain executable code in response to power-up or reset of the bootloadable device; The processing circuit is operably coupled to the first non-volatile memory and the second non-volatile memory, It has the following characteristics: The processing circuit, upon executing the boot program, programs a boot load verification program in response to the fact that the entry point of the second non-volatile memory has programmed the last firmware image block of the set of firmware image blocks constituting the firmware module into the corresponding sequential memory block of the second non-volatile memory. The processing circuit executes the boot load verification program to notify the boot loader device via the interface whether or not the boot loadable device has booted the firmware module. A method that includes the act of doing so.
2. The processing circuit executes the boot program stored in the second non-volatile memory in response to the power being turned on or the boot loadable device being reset, which puts the boot loadable device into boot mode. The method according to claim 1, further comprising:
3. The processing circuit erases the first sequential memory block of the second non-volatile memory, which can have the boot load verification program starting at the entry point of the second non-volatile memory, by executing the boot program. The method according to claim 1, further comprising:
4. The processing circuit establishes communication with the boot loader device via the interface by executing the boot program. The method according to claim 1, further comprising:
5. The processing circuit, by executing the boot program, receives each of the sets of firmware image blocks constituting the firmware module from the boot loader device via the interface, and determines that the first firmware image block of the set of firmware image blocks has the boot load verification program, and the last firmware image block of the set of firmware image blocks has the firmware module verification code. The method according to claim 1, further comprising:
6. The processing circuit executes the boot program to program each of the received firmware image blocks, from the second to the last of the set of firmware image blocks, into the corresponding sequential memory block of the second non-volatile memory. The method according to claim 1, further comprising:
7. The processing circuit, in response to executing the boot program and programming the last firmware image block of the set of firmware image blocks into the corresponding sequential memory block of the second non-volatile memory, programs the boot load verification program, or the first of the set of firmware image blocks having the boot load verification program, at the entry point of the first sequential memory block of the second non-volatile memory. The method according to claim 6, further comprising:
8. The processing circuit executes the boot program to obtain a firmware module verification code from the firmware module, and verifies, based on the firmware module verification code, that the firmware module was received without error and programmed into the second non-volatile memory. The method according to claim 1, further comprising:
9. The processing circuit executes the boot load verification program to notify the boot loader device via the interface whether or not the boot loadable device has been booted. The method according to claim 1, further comprising:
10. The method according to claim 1, wherein the interface is associated with a serial interface, a general-purpose input or output (GPIO) interface.
11. A boot loadable device operably coupled to a boot loader device via at least one interface, A first non-volatile memory having a boot program, A second non-volatile memory having a set of sequential memory blocks, each having a first sequential memory block having a base address corresponding to an entry point from which the processing circuit can first obtain executable code in response to power-up or reset of the bootloadable device; A processing circuit operably coupled to the first non-volatile memory and the second non-volatile memory, A memory containing instructions that can be executed by the processing circuit, It has, The processing circuit is configured to program a boot load verification program in response to the execution of the boot program, which, at the entry point of the second non-volatile memory, programs the last sequential memory block of the set of sequential memory blocks of the firmware module into the corresponding sequential memory block of the second non-volatile memory. The processing circuit is configured to notify the bootloader device via the interface whether or not the bootloadable device has booted up the firmware module by executing the bootload verification program. Boot loadable device.
12. The memory includes further instructions that can be executed by the processing circuit, The processing circuit is configured to execute the boot program stored in the second non-volatile memory in response to the power-on or reset sequence performed by the boot loadable device that puts the boot loadable device into boot mode. The boot loadable device according to claim 11.
13. The memory includes further instructions that can be executed by the processing circuit, The boot loadable device according to claim 12, wherein the processing circuit is configured to erase the first sequential memory block of the second non-volatile memory having the boot load verification program that begins at the entry point of the second non-volatile memory by executing the boot program.
14. The memory includes further instructions that can be executed by the processing circuit, The processing circuit is configured to establish communication with the boot loader device via the interface by executing the boot program. The boot loadable device according to claim 12.
15. The memory includes further instructions that can be executed by the processing circuit, The processing circuit is configured to execute the boot program and receive each of the sets of firmware image blocks constituting the firmware module from the boot loader device via the interface, the first of the sets of firmware image blocks having the boot load verification program, and the last of the sets of firmware image blocks having the firmware module verification code. The boot loadable device according to claim 11.
16. The memory includes further instructions that can be executed by the processing circuit, The processing circuit is configured to execute the boot program and program each of the received firmware image blocks, from the second to the last of the set of firmware image blocks, into the corresponding sequential memory block of the second non-volatile memory. The boot loadable device according to claim 15.
17. The memory includes further instructions that can be executed by the processing circuit, The processing circuit is configured to, in response to executing the boot program and programming the last firmware image block of the set of firmware image blocks into the corresponding sequential memory block of the second non-volatile memory, to program the boot load verification program, or the first one of the set of firmware image blocks having the boot load verification program, at the entry point of the first sequential memory block of the second non-volatile memory. The boot loadable device according to claim 16.
18. The memory includes further instructions that can be executed by the processing circuit, The processing circuit is configured to execute the boot program to obtain a firmware module verification code from the firmware module, and to verify, based on the firmware module verification code, that the firmware module was received without error and programmed into the second non-volatile memory. The boot loadable device according to claim 11.
19. The processing circuit is configured to notify the boot loader device via the interface whether or not the boot loadable device has been booted up by executing the boot load verification program. The boot loadable device according to claim 11.
20. Boot loader device and A system comprising a boot loadable device operably coupled to the boot loader device via at least one interface, The aforementioned boot loadable device is A first non-volatile memory having a boot program, A second non-volatile memory having a set of sequential memory blocks, each having a first sequential memory block with a base address corresponding to an entry point from which the processing circuit can first obtain executable code in response to power-up or reset of the bootloadable device; The processing circuit is operably coupled to the first non-volatile memory and the second non-volatile memory, It has the following characteristics: The processing circuit is configured to program a boot load verification program in response to the execution of the boot program, which, at the entry point of the second non-volatile memory, programs the last sequential memory block of the set of sequential memory blocks of the firmware module into the corresponding sequential memory block of the second non-volatile memory. The processing circuit is configured to notify the bootloader device via the interface whether or not the bootloadable device has booted up the firmware module by executing the bootload verification program. system.