System burning method of embedded device and electronic device

Abstract

The invention discloses a system burning method of embedded equipment and electronic equipment, in a recovery mode, to-be-burnt equipment can receive an external instruction to carry out firmware updating, target specification types of multiple to-be-burnt equipment are determined according to a product identification code, and the to-be-burnt equipment is stored in the product identification code. And obtaining the flash script, the root file system and a differentiated configuration file corresponding to the target specification type. As the multiple to-be-burnt devices in the current batch have the same hardware specification, the target specification types of the multiple to-be-burnt devices are determined through the read product identification codes, so that the differentiated configuration files corresponding to the target specification types are obtained. Since the flash script and the root file system both support devices of various specifications and types, embedded devices of different specifications and types can be processed, and only specific differentiated configuration files need to be provided for the embedded devices of different specifications, so that the number of repeated mirror images is greatly reduced, and the resource reuse rate between embedded device modules is improved.

Description

Technical Field

[0001] The present application relates to the technical field of embedded system mass production, and in particular to a system burning method and electronic equipment for embedded devices. Background Art

[0002] With the development of AI edge computing, embedded devices are widely used in fields such as autonomous driving, robotics, and smart security. An embedded device module refers to an integrated hardware component designed for a specific embedded application. It typically includes a processor (such as a CPU, GPU, FPGA, etc.), memory (such as RAM, Flash), communication interfaces (such as USB, UART, SPI, I2C, etc.), and other necessary peripheral circuits. These modules are designed to be directly integrated into larger systems to implement specific functions such as data processing, communication, and control. To adapt to different performance requirements, manufacturers typically provide embedded device modules with multiple specifications, for example, with differences in computing performance, storage interface, memory size, power consumption limits, and other aspects.

[0003] In related technologies, in order to meet the hardware characteristics and functional requirements of different devices and optimize system performance, these different embedded device modules usually need to customize system images separately during actual deployment or production line burning. However, customizing system images for different embedded device modules will lead to repeated production of system images, which is time-consuming and storage-intensive, and has a low resource reuse rate between embedded device modules.

[0004] Therefore, how to improve the resource reuse rate between embedded device modules during the production line burning process is an urgent problem that needs to be solved. Summary of the Invention

[0005] The present application provides a system burning method and electronic equipment for an embedded device, so as to at least solve the problem of low resource reuse rate between embedded device modules during production line burning in the related art.

[0006] This application provides a system burning method for an embedded device, the method comprising: When multiple devices to be programmed are in recovery mode, obtaining a product identification code of any one of the multiple devices to be programmed; the multiple devices to be programmed are all embedded devices of the same specification type; Determining target specification types of the plurality of devices to be programmed according to the product identification codes; Obtain a flashing script, a root file system, and a differentiated configuration file corresponding to the target specification type; the flashing script and the root file system both support devices of various specifications to be burned; Combining the root file system and the difference configuration files corresponding to the target specification type to generate a target burning file; In response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned.

[0007] The present application also provides a system burning device for an embedded device, the device comprising: An acquisition module, configured to acquire a product identification code of any one of the multiple devices to be programmed when the multiple devices to be programmed are in recovery mode; the multiple devices to be programmed are all embedded devices of the same specification and type; A determination module, configured to determine target specification types of the plurality of devices to be programmed according to the product identification code; The calling module is used to obtain the flashing script, the root file system and the differential configuration files corresponding to the target specification type; the flashing script and the root file system both support the devices to be burned of various specifications; A combining module, configured to combine the root file system and the difference configuration files corresponding to the target specification type to generate a target burning file; The burning module is used to execute the flashing script in response to the target burning instruction, and burn the target burning file to the multiple devices to be burned.

[0008] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned system burning methods for embedded devices when executing the computer program.

[0009] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the system burning method of any of the above-mentioned embedded devices are implemented.

[0010] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned system burning methods for embedded devices when the computer program is executed by a processor.

[0011] Through this application, when multiple devices to be burned are in recovery mode, the product identification code of any one of the multiple devices to be burned is obtained, wherein the multiple devices to be burned are embedded devices of the same specification type. In recovery mode, the devices to be burned can accept external commands to perform firmware updates. Based on the product identification code, the target specification types of the multiple devices to be burned are determined, and the flashing script, root file system, and differentiated configuration files corresponding to the target specification types are obtained. Since the multiple devices to be burned in the current batch have the same hardware specifications, the target specification types of the current multiple devices to be burned are determined by reading the product identification code, so as to obtain differentiated configuration files corresponding to the target specification types. Since the flashing script and root file system both support devices of various specification types, they can handle embedded devices of different specification types. Only specific differentiated configuration files need to be provided for embedded devices of different specifications, thereby greatly reducing the number of duplicate images and improving the resource reuse rate between embedded device modules. The current flashing host receives the flashing command and executes the flashing process in the flashing script. The automated script is responsible for batch writing the target burning files to the devices to be burned, further improving the automation level and burning efficiency of the flashing process. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 This is a flow chart of a method for burning a system of an embedded device provided in an embodiment of the present application; Figure 2 A schematic structural diagram of a system burning device for an embedded device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0014] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0015] It should be noted that, in the description of this application, the terms "include", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or electronic device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or electronic device. The terms "first", "second", etc. in this application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0016] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0017] Explanation of terms: Embedded device modules are highly integrated electronic components designed for specific embedded applications. They typically include a processor (CPU, GPU, etc.), memory (RAM, Flash), communication interfaces (such as USB, SPI, I2C, etc.), and other necessary peripheral circuits. These modules are designed to be directly integrated into larger systems to implement specific functions such as data processing, communication, and control. Examples of common embedded module devices include the Jetson AGX Orin, OrinNX, and Orin Nano.

[0018] eMMC: Embedded MultiMedia Card (used to store multimedia data such as audio, video, and images). Usually integrated directly into the device's motherboard rather than as a removable storage medium.

[0019] NVMe stands for Non-Volatile Memory Express. This refers to a storage medium that is non-volatile, meaning that data is not lost after a power outage. Both eMMC and NVMe are storage devices used for data reading and writing.

[0020] Rootfs: Root File System. This is the most fundamental file system in a Linux system. It is the first file system loaded when the operating system boots up. It is the foundation of the entire operating system and contains all the files, directories, and structures required to run the operating system. The root file system is the mount point for all other file systems, and all user and system programs depend on it for operation.

[0021] Bootloader: A bootloader is the first software program that runs during the startup process of a computer or other electronic device. Its primary function is to initialize the hardware, load the operating system kernel, and start it. The bootloader is a critical step in the startup process, ensuring the system transitions from the hardware state to the operating system state. It initializes the hardware and loads and starts the operating system kernel.

[0022] USB: Universal Serial Bus.

[0023] USB PID: USB Product ID, product identification code, is a unique identifier assigned by USB device manufacturers to their products.

[0024] EEPROM: A non-volatile memory that can be electrically erased and rewritten, and data is not lost when power is off.

[0025] Recovery mode: RCM, short for recovery mode, is a special boot mode a device enters when it fails to boot or needs to be reflashed. Recovery mode is a special boot mode in many operating systems (particularly Android and other embedded systems) used for troubleshooting, repairing, or recovering from system issues.

[0026] QSPI stands for Quad Serial Peripheral Interface. In embedded systems, the bootloader is often placed in QSPI Flash memory. QSPI is a highly efficient serial communication interface, an extension of the SPI interface introduced by Motorola.

[0027] Bootloaders and Quad Serial Peripheral Interface (QSPI) Flash are closely related in embedded systems. The bootloader is the first program that runs at system startup, responsible for initializing the hardware and loading the operating system or application. QSPI Flash is a non-volatile memory typically used to store the bootloader, operating system image, device tree file (DTB), and other firmware.

[0028] UEFI (Unified Extensible Firmware Interface) is a modern firmware interface standard that replaces the traditional BIOS (Basic Input / Output System). UEFI provides a more flexible, secure, and efficient boot and initialization mechanism. The UEFI workflow: When the system is powered on or reset, the UEFI firmware is first loaded into memory. During the boot process, UEFI initializes hardware devices such as the CPU, memory, and storage devices. The UEFI firmware loads a boot program (such as GRUB or Windows Boot Manager) and passes boot parameters. The boot program then loads the operating system kernel and transfers control to the operating system.

[0029] extlinux.conf: is the configuration file of the EXTLINUX boot loader, that is, the boot configuration file, which is used to define options and parameters when the system starts.

[0030] MassFlash: A tool for batch burning embedded devices (such as the NVIDIA Jetson series). It can burn firmware to multiple devices simultaneously, significantly improving production efficiency.

[0031] post_init.sh: This is an initialization script executed during the system startup process, typically used to perform device- or system-specific initialization tasks. It runs at the end of system startup to ensure that all necessary configuration and setup are complete. This script is commonly used in embedded systems, servers, and desktop systems to perform hardware initialization, network configuration, service startup, and other functions.

[0032] With the development of AI edge computing, embedded devices are widely used in fields such as autonomous driving, robotics, and smart security. An embedded device module refers to an integrated hardware component designed for a specific embedded application. It typically includes a processor (such as a CPU, GPU, FPGA, etc.), memory (such as RAM, Flash), communication interfaces (such as USB, UART, SPI, I2C, etc.), and other necessary peripheral circuits. These modules are designed to be directly integrated into larger systems to implement specific functions such as data processing, communication, and control. To adapt to different performance requirements, manufacturers typically provide embedded device modules with multiple specifications, for example, with differences in computing performance, storage interface, memory size, power consumption limits, and other aspects.

[0033] In related technologies, in order to meet the hardware characteristics and functional requirements of different devices and optimize system performance, these different embedded device modules usually need to customize system images separately during actual deployment or production line burning. However, customizing system images for different embedded device modules will lead to repeated production of system images, which is time-consuming and storage-intensive, and has a low resource reuse rate between embedded device modules.

[0034] Based on the above problems, an embodiment of the present application provides a system burning method for an embedded device, and the method is described in detail in conjunction with the execution flow of the system burning method for an embedded device.

[0035] Reference Figure 1 As shown, the system burning method of the embedded device provided by the embodiment of the present invention includes the following steps: S11 . When multiple devices to be programmed are in recovery mode, obtain a product identification code of any one of the multiple devices to be programmed.

[0036] The multiple devices to be programmed are all embedded devices of the same specification and type.

[0037] Recovery mode, or RCM for short, is a special boot mode a device enters when it fails to boot or needs to be reflashed. Recovery mode is a special boot mode in many operating systems, particularly Android and other embedded systems, used for troubleshooting, repairing, or recovering from system issues.

[0038] Product Identification Code: USB PID, or USB Product ID, is a unique identifier assigned by USB device manufacturers to their products.

[0039] Specifically, since the multiple devices to be burned are all embedded devices of the same specification type, that is, the multiple devices to be burned in the current batch have the same hardware specifications, when the multiple devices to be burned are in recovery mode, the product identification code of any one of the multiple devices to be burned is obtained.

[0040] In some embodiments, before executing the above step S11 (obtaining the product identification code of any one of the multiple devices to be programmed when the multiple devices to be programmed are in recovery mode), the following steps may also be executed: Communicate and connect with multiple devices to be burned through a universal serial bus hub; In response to a preset control mode, the plurality of devices to be burned are controlled to enter a recovery mode.

[0041] The preset control method includes but is not limited to: a specific function key, or a specific command.

[0042] Specifically, the flashing host communicates with multiple devices to be flashed via a universal serial bus (USB) hub. After the embedded device is connected to the flashing host via the USB hub, it can enter recovery mode using a specific function key (such as the Recovery key). Alternatively, if the embedded device is connected to the flashing host via a USB hub and USB debugging is enabled, it can enter recovery mode using ADB commands.

[0043] By communicating with multiple devices to be programmed through a USB hub and controlling them to enter recovery mode, you can simplify the connection management of multiple devices and reduce the number of physical interfaces required. This method can control multiple devices to enter recovery mode at the same time, laying the foundation for batch programming and improving work efficiency. Automated control also reduces the possibility of human error.

[0044] S12: Determine target specification types of the multiple devices to be programmed according to the product identification code.

[0045] Specifically, each product identification code corresponds to a specification type, and the collected product identification codes are used to query an internal database or a data table to determine the target specification types corresponding to the current plurality of devices to be programmed.

[0046] For example, refer to Table 1, which shows a mapping table of product identification codes and specification types. Based on the product identification code, the table is searched to determine the target specification types of multiple devices to be programmed. For example, if the product identification code is "7023," its corresponding target specification type is "Specification Type 1."

[0047] Table 1

[0048] S13: Obtain a flashing script, a root file system, and a differential configuration file corresponding to the target specification type.

[0049] The flashing script and the root file system both support devices of various specifications and types to be burned.

[0050] A flashing script is a collection of automated commands or instructions. Through a standardized flashing process, the flashing script ensures that all devices are updated according to the same steps and configurations, ensuring the consistency of the update.

[0051] Optionally, the root file system includes: pre-installed drivers, pre-installed applications, and system management tools required for embedded devices of various specifications and types.

[0052] Specifically, a universal root file system (RFS) for all embedded device modules is built on the flashing host. Universal drivers, user applications, and system management tools are pre-installed in the root file system. The flashing host retrieves the flashing script, the root file system, and differentiated configuration files corresponding to the target specification type from a preset storage location.

[0053] The root file system (Root File System) includes pre-installed drivers, pre-installed applications, and system management tools required for a variety of embedded device types. These pre-installed drivers and applications support a wide range of device specifications, improving system compatibility. This universal root file system design offers several benefits: developers no longer need to build and configure file systems individually for each device type, reducing duplication of effort and development time. The unified root file system simplifies device deployment and software updates.

[0054] In some embodiments, the differentiated configuration files corresponding to the target specification type include: a first configuration file of the embedded device of the target specification type in the system boot phase and a second configuration file in the system boot success phase.

[0055] In the disclosed embodiment, differentiated configuration files include a first configuration file and a second configuration file. The first configuration file is loaded by the bootloader at the very early stage of system startup. The second configuration file is customized for each module (specific model or series) of the embedded device. These two configuration files are loaded during the system startup process and used to configure the system. The first and second configuration files ensure that devices of different specifications and types are correctly configured according to their specific hardware and software requirements.

[0056] Optionally, the first configuration file includes a boot configuration file in a boot loader stage, which is used to initialize hardware and load an operating system kernel.

[0057] Specifically, the first configuration file includes a boot configuration file for the boot loader stage, which includes the UEFI DTB, UEFI Bootloader, MB1 / MB2 files, firmware files, UEFI configuration files, etc. The UEFI DTB is the device tree file used for UEFI booting, the UEFI Bootloader is the UEFI boot program file, and MB1 / MB2 are the first and second stage boot loader files. The firmware file includes firmware images loaded during the boot process, such as GPU firmware and network controller firmware. The UEFI configuration file contains configuration data used during the UEFI boot process, such as boot options and security settings.

[0058] These boot configuration files contain key information and instructions required for system startup. Their function is to initialize the hardware and load the operating system kernel, ensuring that the device can correctly initialize the hardware, load the operating system kernel, and ultimately start the operating system.

[0059] Optionally, the second configuration file includes: a device tree file, a startup configuration file, a kernel image file and an initialization script; the device tree file is used to initialize hardware devices; the startup configuration file is used to configure the system's operating parameters; the kernel image file is used to initialize hardware devices and provide system services; the initialization script is used to execute initialization tasks for embedded devices.

[0060] Specifically, the device tree file describes the hardware configuration and is used to initialize hardware devices. Each embedded device module has its own dedicated device tree file, for example, jetson_agx_orin.dtb. The startup configuration file (extlinux.conf) defines the boot menu and startup parameters. Each embedded device module has its own startup configuration file. The kernel image file is the operating system kernel file. The initialization script is used to perform specific initialization tasks after the system boots. Each embedded device module has its own dedicated initialization script.

[0061] Together, these secondary configuration files ensure smooth operation of the embedded device from boot to operation. The device tree file and kernel image ensure proper hardware initialization and the provision of system services, while the startup configuration file and initialization scripts allow users to customize system behavior and automate initialization tasks based on specific needs. This approach increases system flexibility, customizability, and automation, thereby improving user experience and system reliability.

[0062] S14: combining the root file system and the difference configuration files corresponding to the target specification type to generate a target burning file.

[0063] Specifically, the root file system and the differential configuration files corresponding to the target specification type are combined to generate a target burning file.

[0064] S15. In response to the target burning instruction, execute the flashing script to burn the target burning file to the multiple devices to be burned.

[0065] Optionally, the above step S15 (in response to the target burning instruction, executing the flashing script to burn the target burning file to the multiple devices to be burned) can be implemented as follows: In response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned in parallel.

[0066] Specifically, in response to the target burning instruction, the flashing script is executed, and the target burning file is burned to the multiple devices to be burned in parallel through MassFlash. MassFlash is a tool for batch burning embedded devices, which can burn firmware to multiple devices to be burned at the same time, significantly improving production efficiency.

[0067] By batch-parallel flashing of embedded devices of the same specification type, flashing efficiency can be significantly improved and time can be saved. The current flashing host receives the flashing command and executes the flashing process in the flashing script. The automated script is responsible for writing the target flashing files in batches to the devices to be flashed, further improving the automation and efficiency of the flashing process.

[0068] An embodiment of the present application provides a system flashing method for an embedded device. When multiple devices to be flashed are in recovery mode, a product identification code is obtained for any one of the multiple devices to be flashed. The multiple devices to be flashed are embedded devices of the same specification type. In recovery mode, the devices to be flashed can accept external commands for firmware updates. Based on the product identification code, the target specification types of the multiple devices to be flashed are determined, and a flashing script, a root file system, and differentiated configuration files corresponding to the target specification types are obtained. Because the multiple devices to be flashed in a current batch have the same hardware specifications, the target specification types of the multiple devices to be flashed are determined by reading the product identification codes, allowing differentiated configuration files corresponding to the target specification types to be obtained. Because both the flashing script and the root file system support devices of various specification types, they can handle embedded devices of different specification types, requiring only specific differentiated configuration files for each type. This significantly reduces the number of duplicate images and improves resource reuse between embedded device modules. Upon receiving the flashing command, the flashing process in the flashing script is executed. The automated script is responsible for batch-writing the target flashing files to the devices to be flashed, further improving the automation and efficiency of the flashing process.

[0069] In some embodiments, the above step S15 (in response to the target burning instruction, executing the flashing script to burn the target burning file to the multiple devices to be burned) can be implemented as follows: In response to the target burning instruction, executing the flashing script, and writing the first configuration file and the second configuration file into the preset storage media corresponding to the plurality of devices to be burned respectively; The root file system is written into the main storage areas corresponding to the plurality of devices to be burned.

[0070] Specifically, during the flashing process, the first configuration file and the second configuration file are exclusive startup files required for embedded devices of a specific specification type. It can be understood that exclusive startup files are usually customized for specific embedded devices or embedded modules and contain device-specific configurations, while the root file system can be used across multiple device modules and contains common applications and configurations. Exclusive startup files include but are not limited to: device tree files, boot loaders, kernel images, drivers required for system startup, and temporary file systems. These exclusive startup files are usually written to the device's boot partition or a dedicated area of the boot medium, such as the eMMC boot partition or the MB1 and MB2 areas of the QSPI Flash. The root file system includes but is not limited to: pre-installed applications and their dependent libraries, system services, and application configuration files. The root file system is usually written to the device's main storage area, such as the main partition of the eMMC.

[0071] In the disclosed embodiments, the first and second configuration files are dedicated boot files required by specific embedded devices. Dedicated boot files and the unified root file system serve different purposes during the flashing process and are written to different locations on the device to meet different functional requirements. The dedicated boot file ensures the device boots correctly based on its hardware characteristics, while the unified root file system provides the operating system runtime environment and resources.

[0072] In some embodiments, in response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned, so that the multiple devices to be burned execute multiple stages of boot programs in sequence, load the operating system kernel, and mount the root file system.

[0073] Optionally, the above steps (so that the multiple devices to be burned execute multiple stages of boot programs in sequence, load the operating system kernel, and mount the root file system) can be implemented as follows: For any one of the plurality of devices to be programmed, loading a first-stage boot program from a preset storage medium via a boot read-only memory; Loading the second-stage bootloader via the first-stage bootloader; loading the Unified Extensible Firmware Interface via the second-stage bootloader; Loading the operating system kernel and initialization memory files through the unified extensible firmware interface and passing startup parameters; the operating system kernel is used to manage system resources and provide an interface for user space and hardware interaction; After the operating system kernel is started, the root file system is mounted according to the boot parameters, and the initialization process of the user space is started.

[0074] Specifically, during the startup process of the embedded device, multiple stages of boot programs are executed in sequence, the operating system kernel is loaded, and the root file system is mounted.

[0075] BootROM (Boot Read-Only Memory) is the first stage in the system startup process. It is stored in the device's non-volatile memory, such as ROM or flash memory. The code contained in BootROM is primarily used to initialize the processor core and necessary hardware peripherals in preparation for loading the next stage of the bootloader. The BootROM is responsible for detecting and initializing hardware such as the clock, power management module, and serial ports, and loading the first-stage bootloader, MB1 (Minimal Bootloader 1), from a predefined storage medium (such as QSPI Flash).

[0076] MB1 is the first-stage bootloader, typically used to load more complex bootloaders. It is responsible for loading the second-stage bootloader, MB2 (Minimal Bootloader 2). It also performs some basic hardware detection and initialization, such as initializing the memory controller to ensure the system can access memory and loading the device tree file, in preparation for the execution of MB2.

[0077] MB2 is the second-stage bootloader. It's more complex than MB1 and can load more advanced bootloaders. MB2 is typically responsible for loading the Unified Extensible Firmware Interface (UEFI) or directly loading the operating system kernel, performing more complex hardware initialization, such as initializing the GPU and network interfaces. It also loads the device tree file, ensuring it correctly describes the hardware configuration and preparing the hardware environment for the operating system to boot.

[0078] UEFI is a modern firmware interface standard that replaces the traditional BIOS and provides more powerful boot and management capabilities. UEFI loads the operating system kernel and initialization memory file (initrd) based on the extlinux.conf or other boot configuration files, passes boot parameters such as the root file system location and console settings, and then transfers control to the operating system kernel.

[0079] The kernel is the core of the operating system, responsible for managing system resources and providing an interface for user space to interact with the hardware. After the kernel boots up, it takes over hardware resources, mounts the root file system (rootfs), and starts initialization processes in user space, such as system services and applications.

[0080] The boot chain begins with BootROM, which initializes the hardware and loads MB1. MB1 then loads MB2, which in turn loads UEFI. UEFI then loads the operating system kernel. Finally, the kernel takes over the entire system, mounts the root file system, and starts user space processes. This process ensures that the system can boot safely and reliably from a power-off state to a running operating system state. Each step builds on the previous one, gradually bringing the system to a fully operational state.

[0081] In some embodiments, after executing the above steps (after the operating system kernel is started, mounting the root file system according to the boot parameters, and starting the user space initialization process), the following steps may also be executed: Execute the initialization script to complete the configuration of the multiple devices to be burned.

[0082] The initialization script is used to execute various initialization tasks after the system of the target embedded device is started.

[0083] Initialization tasks are a critical step in the startup process of embedded devices, ensuring that the device is properly configured and ready to perform its intended functions.

[0084] Optionally, the initialization tasks include: setting a host name, initializing a network interface, initializing a remote debugging port, loading a sensor driver of a target embedded device, and starting an application service.

[0085] Assign a unique and descriptive name to an embedded device for easier identification and management. This simplifies device management on the network, especially in environments with multiple similar devices, and helps correctly identify and reference the device in network services and applications.

[0086] Configuring the device's network interface so that it can connect to the network and communicate, allowing remote access and management of the device, facilitating maintenance and monitoring, and supporting remote transmission of data and services is particularly important for Internet of Things (IoT) devices.

[0087] Setting up a remote debugging port allows developers to remotely monitor and debug devices, making it easier to diagnose and fix problems in device operation and improve development and testing efficiency, especially when the device is difficult to physically access.

[0088] Loading and managing sensor drivers enables the device to identify and use attached sensors, ensuring that the device can fully utilize its hardware capabilities, ensuring compatibility between the sensor and the device operating system, and improving system stability.

[0089] Start the services and background processes required for device operation, ensure the normal operation of system services, support device functions, and provide services expected by users, such as data collection, processing, and user interface.

[0090] Specifically, after the device to be programmed boots up, the system service automatically executes the initialization script post_init.sh to complete the embedded module-specific configuration, ensuring that runtime behavior fully adapts to the hardware characteristics. Various initialization tasks include, but are not limited to, setting the host name, initializing network interfaces, configuring the debug interface, and loading module-specific sensor drivers or application services.

[0091] Performing these initialization tasks is crucial for the successful startup and operation of embedded devices. These initialization tasks ensure that the device can correctly configure the network, load necessary drivers, start services, and is ready to perform its designed functions. Automating these tasks can significantly improve device deployment efficiency, reduce human error, and speed up the system startup process.

[0092] The system burning method for embedded devices provided by the embodiment of the present disclosure, through this application, when multiple devices to be burned are in recovery mode, obtains the product identification code of any one of the multiple devices to be burned, wherein the multiple devices to be burned are embedded devices of the same specification type. In recovery mode, the devices to be burned can accept external instructions to update the firmware. According to the product identification code, the target specification type of the multiple devices to be burned is determined, and the flashing script, root file system and differentiated configuration files corresponding to the target specification type are obtained. Since the multiple devices to be burned in the current batch have the same hardware specifications, the target specification type of the current multiple devices to be burned is determined by reading the product identification code, so as to obtain differentiated configuration files corresponding to the target specification type. Since the flashing script and root file system both support devices of various specification types, they can handle embedded devices of different specification types. Only specific differentiated configuration files need to be provided for embedded devices of different specifications, thereby greatly reducing the number of duplicate images and improving the resource reuse rate between embedded device modules. At the same time, by batch burning embedded devices of the same specification type, the burning efficiency can be significantly improved and time can be saved. The current flashing host receives the burning command and executes the flashing process in the flashing script. The automation script is responsible for writing the target burning files in batches to the device to be burned, further improving the automation level and burning efficiency of the burning process.

[0093] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0094] Figure 2 This is a structural diagram of a system burning device 200 for an embedded device provided by the present disclosure, as shown in FIG. Figure 2 As shown, the device of this embodiment includes: The acquisition module 210 is used to acquire a product identification code of any one of the multiple devices to be burned when the multiple devices to be burned are in recovery mode; the multiple devices to be burned are all embedded devices of the same specification type; A determination module 220 is configured to determine target specification types of the plurality of devices to be programmed based on the product identification code; Calling module 230, used to obtain a flashing script, a root file system, and a differential configuration file corresponding to the target specification type; the flashing script and the root file system both support various specifications of the device to be burned; A combining module 240 is configured to combine the root file system and the difference configuration files corresponding to the target specification type to generate a target burning file; The burning module 250 is configured to execute the flashing script in response to the target burning instruction, and burn the target burning file to the multiple devices to be burned.

[0095] As an optional implementation of the embodiment of the present disclosure, the device further includes a control module, and the control module is specifically configured to: Communicate and connect with multiple devices to be burned through a universal serial bus hub; In response to a preset control mode, the plurality of devices to be burned are controlled to enter a recovery mode.

[0096] As an optional implementation of the embodiment of the present disclosure, the burning module 250 is specifically configured to: In response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned in parallel.

[0097] As an optional implementation of the embodiment of the present disclosure, the differentiated configuration file corresponding to the target specification type includes: a first configuration file of the embedded device of the target specification type in the system boot phase and a second configuration file in the system boot success phase; the first configuration file includes a boot configuration file in the boot loader phase, which is used to initialize the hardware and load the operating system kernel; the second configuration file includes: a device tree file, a startup configuration file, a kernel image file and an initialization script; the device tree file is used to initialize the hardware device; the startup configuration file is used to configure the operating parameters of the system; the kernel image file is used to initialize the hardware device and provide system services; the initialization script is used to execute the initialization task of the embedded device.

[0098] As an optional implementation of the embodiment of the present disclosure, the root file system includes: pre-installed drivers, pre-installed applications, and system management tools required for embedded devices of various specifications and types.

[0099] As an optional implementation of the embodiment of the present disclosure, the burning module 250 is further specifically configured to: execute the flashing script in response to the target burning instruction, and write the first configuration file and the second configuration file into the preset storage media corresponding to the multiple devices to be burned respectively; The root file system is written into the main storage areas corresponding to the plurality of devices to be burned.

[0100] As an optional implementation of the embodiment of the present disclosure, the burning module 250 is further specifically configured to: In response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned, so that the multiple devices to be burned sequentially execute multiple stages of boot programs, load the operating system kernel, and mount the root file system.

[0101] As an optional implementation of the embodiment of the present disclosure, the burning module 250 is further specifically configured to: For any one of the plurality of devices to be programmed, loading a first-stage boot program from a preset storage medium via a boot read-only memory; Loading the second-stage bootloader via the first-stage bootloader; loading the Unified Extensible Firmware Interface via the second-stage bootloader; Loading the operating system kernel and initialization memory files through the unified extensible firmware interface and passing startup parameters; the operating system kernel is used to manage system resources and provide an interface for user space and hardware interaction; After the operating system kernel is started, the root file system is mounted according to the boot parameters, and the initialization process of the user space is started.

[0102] As an optional implementation of the embodiment of the present disclosure, the device further includes: The initialization module is used to execute the initialization script to complete the configuration of the multiple devices to be burned; the initialization script is used to execute various initialization tasks after the system of the target embedded device is started.

[0103] For the description of the features in the embodiment corresponding to the system burning apparatus 200 for embedded devices, reference may be made to the relevant description of the embodiment corresponding to the system burning method for embedded devices, which will not be described in detail here.

[0104] The disclosed embodiments provide a system flashing device for an embedded device. When multiple devices to be flashed are in recovery mode, the device obtains a product identification code from any one of the multiple devices to be flashed. The multiple devices to be flashed are embedded devices of the same specification type. In recovery mode, the devices to be flashed can accept external commands for firmware updates. Based on the product identification code, the device determines the target specification types of the multiple devices to be flashed, and then obtains a flashing script, a root file system, and differentiated configuration files corresponding to the target specification types. Since the multiple devices to be flashed in a current batch have the same hardware specifications, the target specification types of the multiple devices to be flashed are determined by reading the product identification codes, allowing the device to obtain differentiated configuration files corresponding to the target specification types. Since both the flashing script and the root file system support devices of various specification types, they can handle embedded devices of different specification types, requiring only specific differentiated configuration files for each type. This significantly reduces the number of duplicate images and improves resource reuse between embedded device modules. Upon receiving the flashing command, the flashing process in the flashing script is executed. The automated script is responsible for batch-writing the target flashing files to the devices to be flashed, further improving the automation and efficiency of the flashing process.

[0105] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps of any of the above-mentioned system burning method embodiments for embedded devices.

[0106] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned system burning method embodiments for embedded devices when running.

[0107] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0108] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned system burning method embodiments for embedded devices are implemented.

[0109] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned system burning method embodiments of the embedded device are implemented.

[0110] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0111] The above describes in detail the system burning method for an embedded device provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only intended to help understand the method and core concept of this application. It should be noted that for those skilled in the art, without departing from the principles of this application, various improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A system burning method for an embedded device, characterized in that: The method comprises: When multiple devices to be programmed are in recovery mode, obtaining a product identification code of any one of the multiple devices to be programmed; the multiple devices to be programmed are all embedded devices of the same specification type; Determining target specification types of the plurality of devices to be programmed according to the product identification codes; Obtain a flashing script, a root file system, and a differential configuration file corresponding to the target specification type; the flashing script and the root file system both support devices of various specifications to be burned; Combining the root file system and the difference configuration files corresponding to the target specification type to generate a target burning file; In response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned.

2. The system burning method of the embedded device according to claim 1, characterized in that: When the plurality of devices to be programmed are in recovery mode, before obtaining the product identification code of any one of the plurality of devices to be programmed, the method further includes: Communicate and connect with multiple devices to be burned through a universal serial bus hub; In response to a preset control mode, the plurality of devices to be burned are controlled to enter a recovery mode.

3. The system burning method of the embedded device according to claim 2, characterized in that: The step of executing the flashing script in response to the target burning instruction to burn the target burning file to the plurality of devices to be burned comprises: In response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned in parallel.

4. The system burning method of the embedded device according to claim 1, characterized in that: The differentiated configuration files corresponding to the target specification type include: a first configuration file of the embedded device of the target specification type in the system boot phase and a second configuration file in the system boot success phase; the first configuration file includes a boot configuration file in the boot loader phase, which is used to initialize the hardware and load the operating system kernel; the second configuration file includes: a device tree file, a startup configuration file, a kernel image file and an initialization script; the device tree file is used to initialize the hardware device; the startup configuration file is used to configure the operating parameters of the system; the kernel image file is used to initialize the hardware device and provide system services; the initialization script is used to execute the initialization task of the embedded device.

5. The system burning method of the embedded device according to claim 1, characterized in that: The root file system includes: pre-installed drivers, pre-installed applications and system management tools required for embedded devices of various specifications and types.

6. The system burning method of the embedded device according to claim 4, characterized in that: The step of executing the flashing script in response to the target burning instruction to burn the target burning file to the plurality of devices to be burned comprises: In response to the target burning instruction, executing the flashing script, and writing the first configuration file and the second configuration file into the preset storage media corresponding to the plurality of devices to be burned respectively; The root file system is written into the main storage areas corresponding to the plurality of devices to be burned.

7. The system burning method of the embedded device according to claim 1, characterized in that: The method further comprises: In response to the target burning instruction, the flashing script is executed to burn the target burning file to the multiple devices to be burned, so that the multiple devices to be burned sequentially execute multiple stages of boot programs, load the operating system kernel, and mount the root file system.

8. The system burning method of the embedded device according to claim 7, characterized in that: The method of causing the plurality of devices to be burned to sequentially execute the boot programs of multiple stages, load the operating system kernel, and mount the root file system includes: For any one of the plurality of devices to be programmed, loading a first-stage boot program from a preset storage medium via a boot read-only memory; Loading the second-stage bootloader via the first-stage bootloader; loading the Unified Extensible Firmware Interface via the second-stage bootloader; Loading the operating system kernel and initialization memory files through the unified extensible firmware interface and passing startup parameters; the operating system kernel is used to manage system resources and provide an interface for user space and hardware interaction; After the operating system kernel is started, the root file system is mounted according to the boot parameters, and the initialization process of the user space is started.

9. The system burning method of the embedded device according to claim 8, characterized in that: After the operating system kernel is started, the root file system is mounted according to the boot parameters, and the initialization process of the user space is started, the method further includes: Execute the initialization script to complete the configuration of the multiple devices to be burned; the initialization script is used to perform various initialization tasks after the system of the target embedded device is started.

10. An electronic device, characterized in that: The electronic device comprises: Memory for storing computer programs; A processor, configured to implement the steps of the system burning method for an embedded device according to any one of claims 1 to 9 when executing the computer program.

Images