Dual-storage system starting method and device

Abstract

The invention provides a dual-storage system starting method and device. An architecture in which a master control chip SOC works cooperatively with an external memory DDR, a nonvolatile memory SPI NOR and an SD card is adopted. After the SOC is powered on, a BootROM guide code is executed, a system is initialized, ID Blocks containing a DDR initialization program and an SPL secondary loading program are sequentially obtained and verified from multiple storage media, the DDR initialization program is loaded, DDR is initialized, and the SPL secondary loading program is loaded to the DDR to run. The method comprises the following steps of: firstly, loading an SD (Secure Digital) card, then loading U-Boot firmware, completing initialization of residual hardware and security mirror verification, then detecting and verifying a kernel mirror format and Header information in the SD card, then loading a Linux kernel, an equipment tree and a ramdisk, mounting rootfs to an RAM (Random Access Memory) space, and mounting the SD card as a user data storage space. According to the method, high reliability of system guiding is ensured through the SPI NOR, large-capacity storage and flexible upgrading are achieved through the SD card, and the comprehensive performance of the embedded system in the aspects of reliability, storage expansibility and cost effectiveness is remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of embedded system technology, and in particular to a dual-storage system boot method and a dual-storage system boot device. Background Technology

[0002] With the development of computer technology, embedded devices with various functions are widely used in people's production and daily life. Embedded devices are application-centric, based on modern computer technology, and are specialized computer devices that can flexibly customize hardware and software modules according to user needs (function, reliability, cost, size, power consumption, environment, etc.).

[0003] In traditional technology, embedded devices contain only one memory chip, and the system and file system are all stored in this single memory chip. This means that if the memory chip is damaged or the file system stored on it is corrupted, the system will not be able to start normally.

[0004] Furthermore, embedded systems have profound requirements for reliability design, cost optimization, and flexible scalability. This cannot be achieved simply by stacking two memory chips; it requires deep integration based on the complementary characteristics of storage media and the evolution of system architecture. Summary of the Invention

[0005] In view of the above problems, the present invention is proposed to provide a dual-storage system boot method and a corresponding dual-storage system boot device that overcomes or at least partially solves the above problems.

[0006] This invention discloses a dual-storage system boot method. The core component of the circuit board PCBA is a main control chip SOC, which is equipped with external DDR memory, non-volatile SPI NOR memory, and an SD card. The external DDR memory is used for code execution and data interaction processing, the non-volatile SPI NOR memory is used for system boot, and the SD card is used to store system firmware and serve as user data storage space. The method includes:

[0007] After the main control chip SOC is powered on, it executes the boot code in the internally embedded read-only memory BootROM to initialize the system, including the system's CPU configuration, clock and key peripherals;

[0008] The identification block ID Block is sequentially obtained and verified from multiple storage media. The identification block ID Block contains the DDR initialization program and the SPL level 2 loading program.

[0009] Based on the hardware I / O configuration, the read-only memory BootROM collects the I / O level, reads the DDR initialization program from the corresponding FLASH into the SRAM, initializes the external memory DDR, and copies the SPL level 2 loading program from the storage medium to the external memory DDR for execution.

[0010] The external DDR memory reads the uboot firmware from the non-volatile SPI NOR memory, initializes the remaining hardware of the system, and loads and verifies the security image.

[0011] Detect the SD card connection, verify the format and header information of the kernel image on the connected SD card, and load the kernel and set the environment variables for the storage type;

[0012] Load the Linux kernel, device tree (dtb), and ramdisk; and based on the contents of the device tree (dtb) and kernel drivers, initialize all SoC-related functions and peripheral functions, copy the rootfs image contents to the RAM space, and mount the RAM space.

[0013] Attach the SD card to the system and use it as customer data storage space.

[0014] Optionally, the main control chip SOC connects to the non-volatile memory SPI NOR via the FSPI four-wire interface, connects to the external memory DDR via the LPDDR5 interface, and connects to the SD card via the SDMMC interface.

[0015] Optionally, the SD card is divided into a boot partition, a rootfs partition, and a data partition. Ordinary users have read permissions, while administrator users have read, write, and execute permissions.

[0016] Optionally, the identifier block ID is sequentially retrieved and verified from multiple storage media, including:

[0017] Perform magic number verification, version and length verification, hash verification, and hardware parameter verification on the ID Block;

[0018] If the identification block ID obtained from all storage media fails to be verified, the DDR initialization program and SPL secondary loading program are downloaded via the USB port.

[0019] Optionally, the external DDR memory reads the uboot firmware from the non-volatile SPI NOR memory, initializes the remaining system hardware, loads and verifies the security image, including:

[0020] The SPL Level 2 loader transfers control to the secure image BL31, which initializes the secure world environment and enables the ARM TrustZone hardware isolation mechanism.

[0021] Security image BL31 verifies security images BL32 and BL33 step by step based on a trust chain, and uses a pre-set public key certificate to verify the image signature and hash value.

[0022] Optionally, the system detects the SD card connection and verifies the format and header information of the kernel image on the connected SD card, as well as the environment variables for loading the kernel and setting the storage type, including:

[0023] Periodically scan to check if an SD card is inserted and continuously read the uboot's MMC device environment variables;

[0024] When the read U-Boot MMC device environment variables match the preset conditions, the boot environment is set to the MMC device type and sequence number in the currently loaded MMC device environment variables;

[0025] The kernel image on the SD card is formatted and its header information is verified. If the verification fails, the screen will display a message indicating that the SD card failed to load and prompt the user to insert a valid SD card. At the same time, the boot process will terminate and enter Maskrom mode.

[0026] Optionally, the rootfs image contents are copied to the RAM space, and the RAM space is mounted, including:

[0027] When the SD card is detected and a partition corresponding to the root file system rootfs exists in the SD card partition table, create RAM space and mount it as tmpfs format;

[0028] Copy the data of the rootfs partition in the SD card to the RAM space, perform a root file system switch operation, and migrate the system operating environment to the RAM space.

[0029] This invention also discloses a dual-storage system boot device. The core component of the circuit board PCBA is a main control chip SOC, which is equipped with external memory DDR, non-volatile memory SPI NOR, and an SD card. The external memory DDR is used for code execution and data interaction processing, the non-volatile memory SPI NOR is used for system boot, and the SD card is used to store system firmware and serve as user data storage space. The device includes:

[0030] The SOC startup initialization module is used to execute the boot code in the internally embedded read-only memory BootROM after the main control chip SOC is powered on, and initialize the system, including the system's CPU configuration, clock and key peripherals.

[0031] The ID Block verification module is used to sequentially obtain and verify ID Blocks from multiple storage media. The ID Block contains a DDR initialization program and an SPL level 2 loading program.

[0032] The ID Block loading and running module is used to collect the level of IO from the read-only memory BootROM according to the hardware IO configuration, read the DDR initialization program from the corresponding FLASH to SRAM, initialize the external memory DDR, and copy the SPL secondary loading program in the storage medium to the external memory DDR for execution.

[0033] The Uboot security image loading and verification module is used to read the Uboot firmware from the non-volatile memory SPINOR from the external memory DDR, initialize the remaining hardware of the system, and load and verify the security image.

[0034] The SD card access and verification module is used to detect SD card access, verify the format and header information of the kernel image in the accessed SD card, and load the kernel and set the environment variables for the storage type.

[0035] The rootfs mount module is used to load the Linux kernel, device tree (dtb), and ramdisk. Based on the contents of the device tree (dtb) and kernel drivers, it initializes all SoC-related functions and peripheral functions, copies the rootfs image contents to the RAM space, and mounts the RAM space.

[0036] The SD card mounting module is used to mount SD cards to the system for use as customer data storage space.

[0037] Optionally, the main control chip SOC connects to the non-volatile memory SPI NOR via the FSPI four-wire interface, connects to the external memory DDR via the LPDDR5 interface, and connects to the SD card via the SDMMC interface.

[0038] Optionally, the SD card is divided into a boot partition, a rootfs partition, and a data partition. Ordinary users have read permissions, while administrator users have read, write, and execute permissions.

[0039] Optionally, the identifier block ID block verification module is also used for:

[0040] Perform magic number verification, version and length verification, hash verification, and hardware parameter verification on the ID Block;

[0041] If the identification block ID obtained from all storage media fails to be verified, the DDR initialization program and SPL secondary loading program are downloaded via the USB port.

[0042] Optionally, the Uboot security image loading and verification module is also used for:

[0043] The SPL Level 2 loader transfers control to the secure image BL31, which initializes the secure world environment and enables the ARM TrustZone hardware isolation mechanism.

[0044] Security image BL31 verifies security images BL32 and BL33 step by step based on a trust chain, and uses a pre-set public key certificate to verify the image signature and hash value.

[0045] Optionally, the SD card access and verification module is also used for:

[0046] Periodically scan to check if an SD card is inserted and continuously read the uboot's MMC device environment variables;

[0047] When the read U-Boot MMC device environment variables match the preset conditions, the boot environment is set to the MMC device type and sequence number in the currently loaded MMC device environment variables;

[0048] The kernel image on the SD card is formatted and its header information is verified. If the verification fails, the screen will display a message indicating that the SD card failed to load and prompt the user to insert a valid SD card. At the same time, the boot process will terminate and enter Maskrom mode.

[0049] Optionally, the rootfs mount module is also used for:

[0050] When the SD card is detected and a partition corresponding to the root file system rootfs exists in the SD card partition table, create RAM space and mount it as tmpfs format;

[0051] Copy the data of the rootfs partition in the SD card to the RAM space, perform a root file system switch operation, and migrate the system operating environment to the RAM space.

[0052] This invention has the following advantages:

[0053] The dual-storage system boot method of this invention adopts an architecture in which the main control chip SOC works in conjunction with external memory DDR, non-volatile memory SPI NOR, and SD card. After the SOC powers on, it executes the BootROM boot code to initialize the CPU, clock, and key peripherals. Then, it sequentially obtains and verifies the ID Block containing the DDR initialization program and the SPL secondary loading program from multiple storage media, loads the DDR initialization program and initializes the DDR, and loads the SPL secondary loading program into the DDR for execution. Subsequently, it loads the U-Boot firmware, completes the remaining hardware initialization and security image verification, then detects and verifies the kernel image format and header information in the SD card, and finally loads the Linux kernel, device tree, and ramdisk, mounts the rootfs to the RAM space, and mounts the SD card as the user data storage space. This method ensures high reliability of system booting through SPI NOR and achieves large-capacity storage and flexible upgrades using the SD card, significantly improving the overall performance of embedded systems in terms of reliability, storage scalability, and cost-effectiveness. Attached Figure Description

[0054] Figure 1 This is a flowchart of the steps of the dual-storage system boot method provided in the embodiments of the present invention;

[0055] Figure 2 This is a schematic diagram of the hardware configuration of the present invention;

[0056] Figure 3 This is a flowchart of the Bootrom startup process provided in an embodiment of the present invention;

[0057] Figure 4 This is a flowchart of the SPL loading UBOOT stage provided in an embodiment of the present invention. Detailed Implementation

[0058] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0059] Reference Figure 1 The flowchart illustrates a dual-storage system boot method provided in an embodiment of the present invention, which may specifically include the following steps:

[0060] Step 101: After the main control chip SOC is powered on, it executes the boot code in the internally embedded read-only memory BootROM to initialize the system, including the system's CPU configuration, clock and key peripherals.

[0061] Step 102: Sequentially obtain and verify the ID Block from multiple storage media. The ID Block contains the DDR initialization program and the SPL secondary loading program.

[0062] Step 103: According to the hardware IO configuration, the read-only memory BootROM collects the IO level, reads the DDR initialization program from the corresponding FLASH into SRAM, initializes the external memory DDR, and copies the SPL level 2 loading program in the storage medium to the external memory DDR for execution.

[0063] Step 104: The external memory DDR reads the uboot firmware from the non-volatile memory SPI NOR, initializes the remaining hardware of the system, and loads and verifies the security image;

[0064] Step 105: Detect the SD card connection, verify the format and header information of the kernel image in the connected SD card, and load the kernel and set the environment variables for the storage type.

[0065] Step 106: Load the Linux kernel, device tree (dtb), and ramdisk; and based on the contents of the device tree (dtb) and kernel drivers, initialize all SoC-related functions and peripheral functions, copy the rootfs image contents to the RAM space, and mount the RAM space.

[0066] Step 107: Mount the SD card to the system for use as customer data storage space.

[0067] refer to Figure 2 The hardware configuration of this invention can be as follows:

[0068] (1) The core components of the PCBA are a SoC controller paired with external DDR, SPI NOR and SD card;

[0069] (2) External DDR is used for code execution and data interaction processing;

[0070] (3) Spinor is used as a boot system;

[0071] (4) SD is used as storage space for system firmware and user data;

[0072] In an optional embodiment of the present invention, the main control chip SOC is connected to the non-volatile memory SPI NOR via the FSPI four-wire interface, connected to the external memory DDR via the LPDDR5 interface, and connected to the SD card via the SDMMC interface.

[0073] The SoC connects to the Spinor via a four-wire FSPI interface, connects to the DDR via an LPDDR5 interface, uses LPDDR5 chips for better performance, and connects to the SD card via an SDMMC interface.

[0074] DDR uses LPDDR5 chips with a capacity of 16GB, a 32-bit width, a maximum operating frequency of 3200MHz, and an actual speed of 6400Mbps.

[0075] The SPINOR has a minimum capacity of only 64Mbit, a clock frequency of 133MHz, and a four-wire read rate of up to 532Mbit / s.

[0076] The SD card uses SDR104 mode with a speed of 150MHz. The SD card is divided into three partitions: boot, rootfs, and data. The boot partition is allocated 128MB, the rootfs partition 6144MB, and the remaining space is allocated to the data partition. Regular users only have read permissions, while administrator users have read, write, and execute permissions.

[0077] The above hardware configuration provides a fundamental guarantee for the in-depth requirements of embedded systems, such as reliability design, cost optimization, and flexible scalability.

[0078] 1. Reliability Design:

[0079] (1) SPINOR’s XIP capability ensures that it can still start after a power failure;

[0080] (2) The SD card supports write protection switch and encryption protocol (such as CPRM);

[0081] (3) Physical isolation: SPI NOR and SD card are powered independently to avoid single point of failure;

[0082] (4) Separation of permissions: The NOR area is prohibited from direct access by users, and the SD card is managed through the file system;

[0083] (5) Fault domain separation design (avoiding single point of failure).

[0084] 2. Cost optimization

[0085] (1) The configuration of SPI NOR+SD card is cheaper than eMMC device of the same storage size;

[0086] (2) Both SPI NOR and SD cards are standard components, and domestic alternatives are mature, thus avoiding the eMMC monopoly;

[0087] (3) The SD card is hot-swappable, reducing after-sales costs;

[0088] (4) The marginal cost of capacity expansion is that only the SD card needs to be replaced while keeping the motherboard design unchanged, which greatly reduces development and material management costs.

[0089] 3. Flexible scalability

[0090] (1) Upgrade and maintenance of SD card supports on-site hot-swap upgrade, which can be performed by the user;

[0091] (2) Storage capacity can be expanded at will;

[0092] (3) Modular design: Enables the same motherboard to adapt to different hardware configuration versions;

[0093] (4) SD cards can be categorized for different systems and apps, and are suitable for use in multiple scenarios.

[0094] The SoC startup process in this invention is as follows:

[0095] Primarily, it's the bootrom, a read-only memory (ROM) embedded inside the chip, used to store the first-stage boot code that executes upon power-on. (Reference) Figure 3 The Bootrom startup process.

[0096] a. After the chip is powered on, the Cortex-A53 fetches the first instruction from a fixed address, and the ROMcode begins to run.

[0097] b. Initialize the system, such as initializing the CPU configuration, clock, and some critical peripherals (USB controller, MMC controller, SPI controller). Specific initialization steps are as follows:

[0098] 1. CPU core initialization

[0099] (1) After the CPU is reset, it starts executing instructions from address 0xFFFF_0000 (BootROM mapped area).

[0100] The core runs in ARM SVC (Supervisor) mode with interrupts (IRQ / FIQ) disabled.

[0101] (2) Critical Register Configuration

[0102] Configure the CP15 coprocessor: Initialize MMU (disable), cache (L1 / L2 Cache initially disabled), branch prediction.

[0103] Configure the vector table base address: points to the exception handler inside the BootROM.

[0104] (3) Stack pointer initialization

[0105] Allocate an internal SRAM area as temporary stack space.

[0106] 2. Clock system initialization

[0107] An external 24MHz crystal oscillator (OSC24M) is enabled as the master clock source. The PLL is configured to generate the CPU clock frequency via APLL, generate the DDR memory clock via DPLL, and provide the base clock for peripherals (USB / MMC, etc.) via CPLL.

[0108] Set up a frequency divider to divide the PLL output frequency. At this stage, initialize the base frequency. For example, the MMC controller requires a 50MHz clock.

[0109] 3. Initialization of critical peripheral controllers

[0110] (1) USB controller initialization

[0111] Power supply and PHY enable, enable the power domain of the USB OTG controller, reset and activate the USB PHY (configured via GRF (General Register File)).

[0112] Set the working mode to Device Mode (waiting for host connection).

[0113] (2) MMC / SD controller initialization

[0114] The controller is reset by sending a reset signal (MMC0_CON[0] = 1) through the CRU (Clock & Reset Unit).

[0115] Set the MMC controller clock divider (e.g., 24MHz → 400KHz initialization frequency).

[0116] Configured in 1-bit mode (initial communication), voltage (3.3V), timing (SD 2.0 standard).

[0117] (3) SPI controller initialization

[0118] The operating mode is set to host mode, and DMA is disabled (only PIO is supported in the BootROM stage).

[0119] The chip select signal sets the CSn pin to an active level (typically active low).

[0120] c. Obtain the ID BLOCK (containing the DDR initialization program and the SPL secondary loader) sequentially from Nor Flash, Nand Flash, eMMC, and SD / MMC. If the ID BLOCK is correct, start the program; otherwise, download it from the USB port.

[0121] If the storage medium fails to boot, it enters Maskrom mode. In this mode, the DRAM is not yet initialized, and it relies on the chip's internal SRAM. It limits the size of the firmware downloaded at one time (usually ≤4KB), only responds to the db low-level command, and waits for the host to download the firmware via USB.

[0122] d. Based on the hardware I / O configuration, the bootrom acquires the I / O level, reads the DDR initialization code from the corresponding FLASH into the internal SRAM, initializes the DDR, and then copies the remaining code in the FLASH, the SPL secondary loader, to the DDR for execution.

[0123] Configuring the boot mode via SARADC_VIN0_BOOT is a hardware-level boot selection mechanism that uses an ADC (Analog-to-Digital Converter) to detect the voltage value of a specific pin and dynamically determine the boot media sequence. External resistors (R1, R2) with ±1% accuracy divide the pull-up power supply voltage (1.8V) into different levels, representing different boot modes.

[0124] 0-0.3V is for SD boot, 0.3-0.6V is for EMMC boot, 0.6-0.9V is for SPI0 port boot, and 0.9-1.2V is for SPI1 port boot.

[0125] The system startup process of this invention is as follows:

[0126] (1) Taking Rockchip's SoC as an example, the startup process is divided into 5 stages:

[0127] bootrom→ddr bin+spl→uboot→kernel→rootfs

[0128] The bootrom is stored inside the SoC, the SPI NOR stores the second and third stage firmware, namely idblock.img (containing ddr bin and spl) and uboot.img, and the SD card stores the fourth and fifth stage firmware, namely boot.img (containing kernel, dtb, ramdisk) and rootfs.img.

[0129] (2) After the SOC bootrom initializes the DDR, the third stage is: the DDR reads the uboot firmware of the SPI NOR, initializes the remaining critical hardware (DISPLAY / IO / UART / PMIC controllers, etc.), loads and verifies the security image (BL31 / BL32 / BL33), and finally scans to check if an SD card is inserted. When an SD card is detected, the format and header information of the kernel image in the SD card are verified. If the verification is successful, the process jumps to load the kernel and set the environment variables of the storage type.

[0130] (3) The fourth stage involves loading the Linux kernel (zImage / Image), device tree (dtb), and ramdisk. First, the kernel image (zImage / Image) is loaded, then the device tree (dtb) redirection is loaded, and finally the ramdisk is loaded. In this stage, based on the dtb content and kernel drivers, all SoC-related functions and peripheral functions are initialized. In the ramdisk section, the rootfs image content is copied to the RAM space, mounted, and switched to / sbin / init. The RAM space size depends on the capacity of the DDR chips, with a minimum of 4GB allocated for storing the rootfs image.

[0131] In the fifth stage, the SD card is mounted to the system and used as customer data space. For the read-only rootfs, the rootfs is mounted to the RAM space.

[0132] In an optional embodiment of the present invention, sequentially retrieving and verifying the identifier block IDBlock from multiple storage media includes:

[0133] Perform magic number verification, version and length verification, hash verification, and hardware parameter verification on the ID Block;

[0134] If the identification block ID obtained from all storage media fails to be verified, the DDR initialization program and SPL secondary loading program are downloaded via the USB port.

[0135] BootROM verification of the ID Block is a rigorous multi-level verification process involving multiple dimensions such as signature, data structure, and hardware parameters.

[0136] 1. Magic Number Validation

[0137] Check field: The first 4 bytes must be equal to 0x524B4657 (ASCII encoding of "RKFW");

[0138] Failure action: Immediately terminate loading and mark the current media as invalid.

[0139] 2. Version and Length Verification (Sanity Check)

[0140] Check fields:

[0141] The version must be greater than or equal to the minimum supported version (e.g., 0x00010000);

[0142] The bootloader's byte size (code_length) must satisfy the following condition: 4KB ≤ length ≤ remaining SRAM space;

[0143] Failure action: Discard the current ID Block and try the next storage device.

[0144] 3. Cryptographic Verification

[0145] Verification object: SHA256 hash of the bootloader binary (Pre-loader or MiniLoader).

[0146] Calculation process:

[0147] The bootloader, consisting of code_length bytes, is read from the storage medium, its SHA256 value is calculated using the CRYPTO hardware acceleration engine, and the result is compared with the hash field in the ID Block.

[0148] Failed action:

[0149] If the hash does not match, it is considered that the bootloader has been tampered with, the startup is terminated and it reverts to Maskrom mode.

[0150] 4. Hardware Parameter Validation (HW Config Validation)

[0151] The hardware parameters in the key field hw_config must meet the following requirements: DDR timing: compatible with the current onboard memory model; GPIO without multiplexing configuration; voltage parameters: within the chip's safe range.

[0152] In an optional embodiment of the present invention, the external memory DDR reads the uboot firmware of the non-volatile memory SPI NOR, initializes the remaining hardware of the system, loads and verifies the security image, including:

[0153] The SPL Level 2 loader transfers control to the secure image BL31, which initializes the secure world environment and enables the ARM TrustZone hardware isolation mechanism.

[0154] Security image BL31 verifies security images BL32 and BL33 step by step based on a trust chain, and uses a pre-set public key certificate to verify the image signature and hash value.

[0155] The process of loading and verifying the security image (BL31 / BL32 / BL33) during the U-Boot phase follows the ARM TrustedFirmware (ATF) secure boot specification.

[0156] refer to Figure 4SPL transfers control to BL31, and then BL31 initializes the secure world, that is, sets up SecureMonitor (exception vector, register isolation) and enables the ARM TrustZone hardware isolation mechanism.

[0157] BL31 refers to EL3 Runtime Firmware, which is responsible for switching between Secure World and Non-Secure World; BL32 is usually OP-TEE (Open Portable Trusted Execution Environment), used for loading Secure World; BL33 is the U-BOOT runtime stage.

[0158] BL31 verifies BL32 / BL33 using Chain of Trust (CoT) step-by-step verification:

[0159] (1) Parse the image header to obtain the hash value and signature;

[0160] (2) Verify the signature using a pre-built public key certificate (fuse or embedded in firmware);

[0161] (3) Calculate the mirror hash and compare it with the hash in the certificate.

[0162] In an optional embodiment of the present invention, detecting SD card access, verifying the format and header information of the kernel image in the accessed SD card, and loading the kernel and setting environment variables for the storage type include:

[0163] Periodically scan to check if an SD card is inserted and continuously read the uboot's MMC device environment variables;

[0164] When the read U-Boot MMC device environment variables match the preset conditions, the boot environment is set to the MMC device type and sequence number in the currently loaded MMC device environment variables;

[0165] The kernel image on the SD card is formatted and its header information is verified. If the verification fails, the screen will display a message indicating that the SD card failed to load and prompt the user to insert a valid SD card. At the same time, the boot process will terminate and enter Maskrom mode.

[0166] In this embodiment, the system periodically scans to detect if an SD card is inserted, for example, with a scan cycle of 100ms. During this period, it continuously acquires the uboot's MMC device environment variables. If a match is found, the boot environment is set to the currently loaded MMC device type and serial number. Then, the system verifies the format and header information of the kernel image in the SD card. If the verification fails, the screen displays a message indicating that loading the SD card has failed. A normal SD card needs to be inserted, and the boot process is terminated and the system enters Maskrom mode.

[0167] In an optional embodiment of the present invention, copying the rootfs image content to the RAM space and mounting the RAM space includes:

[0168] When the SD card is detected and a partition corresponding to the root file system rootfs exists in the SD card partition table, create RAM space and mount it as tmpfs format;

[0169] Copy the data of the rootfs partition in the SD card to the RAM space, perform a root file system switch operation, and migrate the system operating environment to the RAM space.

[0170] In this embodiment, the trigger condition for copying the rootfs image content to the RAM space is set as follows:

[0171] (1) Determine whether the SD card device, / dev / mmcblkN, is recognized;

[0172] (2) Determine whether a rootfs partition exists based on the partitioning of the SD card;

[0173] (3) If the above conditions are met, allocate 4GB RAM space and mount it as tmpfs format, then copy the rootfs partition in the SD card to the RAM space.

[0174] (4) Execute switch_root to start / sbin / init in RAM.

[0175] The present invention has the following technical effects:

[0176] A. Operational stability

[0177] Physical isolation: The system runs in RAM, and hot-swapping of SD cards / EMMC, power failure, and vibration have no effect.

[0178] Read-only rootfs: The root partition is not writable, so there is no risk of write amplification or file system corruption during system operation.

[0179] Power loss safety: Sudden power outages only result in the loss of volatile data, without damaging the file system.

[0180] B. Extend flash memory lifespan

[0181] SD card (TLC) lifespan ≈ 1000 full write / erase cycles → directly extends lifespan by 5 to 10 times.

[0182] Logs and temporary files will be moved to tmpfs, and logs will be saved to SD storage space periodically.

[0183] C. Improve read and write speed

[0184] DDR's sequential and random read / write speeds are tens of times faster than flash memory.

[0185] D. Improve security

[0186] Physical read-only: The system partition is in RAM, and external media can be physically locked and write-protected.

[0187] Trusted Startup Chain:

[0188] BootROM → SPI NOR (SPL / U-Boot) → Boot → RAM rootfs → Verify signature verification → Run.

[0189] Non-persistent malicious files: reboot restores the original image, minimizing the attack surface.

[0190] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0191] This invention provides a dual-storage system boot device. The core component of the PCBA is a main control chip SOC, which is equipped with external DDR memory, non-volatile SPI NOR memory, and an SD card. The external DDR memory is used for code execution and data interaction processing, the non-volatile SPI NOR memory is used for system booting, and the SD card is used to store system firmware and serve as user data storage space. Specifically, it may include the following modules:

[0192] The SOC startup initialization module is used to execute the boot code in the internally embedded read-only memory BootROM after the main control chip SOC is powered on, and initialize the system, including the system's CPU configuration, clock and key peripherals.

[0193] The ID Block verification module is used to sequentially obtain and verify ID Blocks from multiple storage media. The ID Block contains a DDR initialization program and an SPL level 2 loading program.

[0194] The ID Block loading and running module is used to collect the level of IO from the read-only memory BootROM according to the hardware IO configuration, read the DDR initialization program from the corresponding FLASH to SRAM, initialize the external memory DDR, and copy the SPL secondary loading program in the storage medium to the external memory DDR for execution.

[0195] The Uboot security image loading and verification module is used to read the Uboot firmware from the non-volatile memory SPINOR from the external memory DDR, initialize the remaining hardware of the system, and load and verify the security image.

[0196] The SD card access and verification module is used to detect SD card access, verify the format and header information of the kernel image in the accessed SD card, and load the kernel and set the environment variables for the storage type.

[0197] The rootfs mount module is used to load the Linux kernel, device tree (dtb), and ramdisk. Based on the contents of the device tree (dtb) and kernel drivers, it initializes all SoC-related functions and peripheral functions, copies the rootfs image contents to the RAM space, and mounts the RAM space.

[0198] The SD card mounting module is used to mount SD cards to the system for use as customer data storage space.

[0199] Optionally, the main control chip SOC connects to the non-volatile memory SPI NOR via the FSPI four-wire interface, connects to the external memory DDR via the LPDDR5 interface, and connects to the SD card via the SDMMC interface.

[0200] Optionally, the SD card is divided into a boot partition, a rootfs partition, and a data partition. Ordinary users have read permissions, while administrator users have read, write, and execute permissions.

[0201] Optionally, the identifier block ID block verification module is also used for:

[0202] Perform magic number verification, version and length verification, hash verification, and hardware parameter verification on the ID Block;

[0203] If the identification block ID obtained from all storage media fails to be verified, the DDR initialization program and SPL secondary loading program are downloaded via the USB port.

[0204] Optionally, the Uboot security image loading and verification module is also used for:

[0205] The SPL Level 2 loader transfers control to the secure image BL31, which initializes the secure world environment and enables the ARM TrustZone hardware isolation mechanism.

[0206] Security image BL31 verifies security images BL32 and BL33 step by step based on a trust chain, and uses a pre-set public key certificate to verify the image signature and hash value.

[0207] Optionally, the SD card access and verification module is also used for:

[0208] Periodically scan to check if an SD card is inserted and continuously read the uboot's MMC device environment variables;

[0209] When the read U-Boot MMC device environment variables match the preset conditions, the boot environment is set to the MMC device type and sequence number in the currently loaded MMC device environment variables;

[0210] The kernel image on the SD card is formatted and its header information is verified. If the verification fails, the screen will display a message indicating that the SD card failed to load and prompt the user to insert a valid SD card. At the same time, the boot process will terminate and enter Maskrom mode.

[0211] Optionally, the rootfs mount module is also used for:

[0212] When the SD card is detected and a partition corresponding to the root file system rootfs exists in the SD card partition table, create RAM space and mount it as tmpfs format;

[0213] Copy the data of the rootfs partition in the SD card to the RAM space, perform a root file system switch operation, and migrate the system operating environment to the RAM space.

[0214] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0215] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0216] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0217] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A method for booting a dual-storage system, characterized in that, The core component of the PCBA (Printed Circuit Board Assembly) is a main control chip (SOC), coupled with external DDR memory, non-volatile SPI NOR memory, and an SD card. The DDR memory is used for code execution and data interaction processing, the SPI NOR memory is used for system booting, and the SD card is used to store system firmware and serve as user data storage space. The method includes: After the main control chip SOC is powered on, it executes the boot code in the internally embedded read-only memory BootROM to initialize the system, including the system's CPU configuration, clock and key peripherals; The identification block ID Block is sequentially obtained and verified from multiple storage media. The identification block ID Block contains the DDR initialization program and the SPL level 2 loading program. Based on the hardware I / O configuration, the read-only memory BootROM collects the I / O level, reads the DDR initialization program from the corresponding FLASH into the SRAM, initializes the external memory DDR, and copies the SPL level 2 loading program from the storage medium to the external memory DDR for execution. The external DDR memory reads the uboot firmware from the non-volatile SPI NOR memory, initializes the remaining hardware of the system, and loads and verifies the security image. Detect the SD card connection, verify the format and header information of the kernel image on the connected SD card, and load the kernel and set the environment variables for the storage type; Load the Linux kernel, device tree (dtb), and ramdisk; and based on the contents of the device tree (dtb) and kernel drivers, initialize all SoC-related functions and peripheral functions, copy the rootfs image contents to the RAM space, and mount the RAM space. Attach the SD card to the system and use it as customer data storage space.

2. The method according to claim 1, characterized in that, The main control chip SOC connects to the non-volatile memory SPI NOR via the FSPI four-wire interface, connects to the external memory DDR via the LPDDR5 interface, and connects to the SD card via the SDMMC interface.

3. The method according to claim 1, characterized in that, The SD card is divided into a boot partition, a rootfs partition, and a data partition. Ordinary users have read permissions, while administrator users have read, write, and execute permissions.

4. The method according to claim 1, characterized in that, Sequentially retrieve and verify the identifier block (ID) from multiple storage media, including: Perform magic number verification, version and length verification, hash verification, and hardware parameter verification on the ID Block; If the identification block ID obtained from all storage media fails to be verified, the DDR initialization program and SPL secondary loading program are downloaded via the USB port.

5. The method according to claim 1, characterized in that, The external DDR memory reads the uboot firmware from the non-volatile SPINOR memory, initializes the remaining system hardware, loads and verifies the security image, including: The SPL Level 2 loader transfers control to the secure image BL31, which initializes the secure world environment and enables the ARM TrustZone hardware isolation mechanism. Security image BL31 verifies security images BL32 and BL33 step by step based on a trust chain, and uses a pre-set public key certificate to verify the image signature and hash value.

6. The method according to claim 1, characterized in that, The system detects the SD card connection and verifies the format and header information of the kernel image on the connected SD card, as well as loads the kernel and sets the environment variables for the storage type, including: Periodically scan to check if an SD card is inserted and continuously read the uboot's MMC device environment variables; When the read U-Boot MMC device environment variables match the preset conditions, the boot environment is set to the MMC device type and sequence number in the currently loaded MMC device environment variables; The kernel image on the SD card is formatted and its header information is verified. If the verification fails, the screen will display a message indicating that the SD card failed to load and prompt the user to insert a valid SD card. At the same time, the boot process will terminate and enter Maskrom mode.

7. The method according to claim 1, characterized in that, Copy the rootfs image contents to the RAM space, and mount the RAM space, including: When the SD card is detected and a partition corresponding to the root file system rootfs exists in the SD card partition table, create RAM space and mount it as tmpfs format; Copy the data of the rootfs partition in the SD card to the RAM space, perform a root file system switch operation, and migrate the system operating environment to the RAM space.

8. A dual-storage system boot device, characterized in that, The core component of the PCBA (Printed Circuit Board Assembly) is a main control chip (SOC), coupled with external DDR memory, non-volatile SPI NOR memory, and an SD card. The DDR memory is used for code execution and data interaction processing, the SPI NOR memory is used for system booting, and the SD card is used to store system firmware and serve as user data storage space. The device includes: The SOC startup initialization module is used to execute the boot code in the internally embedded read-only memory BootROM after the main control chip SOC is powered on, and initialize the system, including the system's CPU configuration, clock and key peripherals. The ID Block verification module is used to sequentially obtain and verify ID Blocks from multiple storage media. The ID Block contains a DDR initialization program and an SPL level 2 loading program. The ID Block loading and running module is used to collect the level of IO from the read-only memory BootROM according to the hardware IO configuration, read the DDR initialization program from the corresponding FLASH to SRAM, initialize the external memory DDR, and copy the SPL secondary loading program in the storage medium to the external memory DDR for execution. The Uboot security image loading and verification module is used to read the Uboot firmware from the non-volatile memory SPI NOR from the external memory DDR, initialize the remaining hardware of the system, and load and verify the security image. The SD card access and verification module is used to detect SD card access, verify the format and header information of the kernel image in the accessed SD card, and load the kernel and set the environment variables for the storage type. The rootfs mount module is used to load the Linux kernel, device tree (dtb), and ramdisk. Based on the contents of the device tree (dtb) and kernel drivers, it initializes all SoC-related functions and peripheral functions, copies the rootfs image contents to the RAM space, and mounts the RAM space. The SD card mounting module is used to mount SD cards to the system for use as customer data storage space.

9. The apparatus according to claim 8, characterized in that, The main control chip SOC connects to the non-volatile memory SPI NOR via the FSPI four-wire interface, connects to the external memory DDR via the LPDDR5 interface, and connects to the SD card via the SDMMC interface.

10. The apparatus according to claim 8, characterized in that, The SD card is divided into a boot partition, a rootfs partition, and a data partition. Ordinary users have read permissions, while administrator users have read, write, and execute permissions.

Images