A configuration method and related equipment

Abstract

This application provides a configuration method and related apparatus. During the configuration of AOP and TrustZone, it is necessary to first query the configuration status of TrustZone. Upon confirming that TrustZone configuration is complete, it can also be confirmed that xPU is enabled. Then, when xPU is enabled, the configuration parameters of AOP are read through xPU to complete the AOP configuration. This application adjusts the timing during the configuration process, placing the step of reading the AOP configuration parameters through xPU after querying the TrustZone configuration status. This avoids system crashes caused by calling xPU when it is not enabled, improving the success rate of internal system environment configuration and enhancing user experience.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and in particular to a configuration method and related equipment. Background Technology

[0002] With the rapid development of mobile communication technology, electronic devices (such as smartphones) have become indispensable tools in people's daily lives. During the boot process of an electronic device, the system needs to load several key boot programs sequentially to initialize the hardware and load the operating system. Typically, electronic devices load a boot loader (Xtended Boot Loader, XBL program) during the boot process to initialize and configure the internal environment.

[0003] However, during the operation of the XBL program, electronic devices often crash, freeze, or fail to start, resulting in a poor user experience. Summary of the Invention

[0004] This application provides a configuration method and related equipment, which aims to improve the success rate of initial configuration of the internal environment of electronic devices and improve user experience.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, this application provides a configuration method. During the configuration of AOP and TrustZone, the configuration status of TrustZone needs to be queried first. Upon confirming that TrustZone configuration is complete, xPU can also be confirmed to be enabled. Then, when xPU is enabled, the configuration parameters of AOP are read through xPU to complete the AOP configuration. This application adjusts the timing during configuration, placing the step of reading the AOP configuration parameters through xPU after querying the TrustZone configuration status. This avoids system crashes caused by calling xPU when it is not enabled, improving the success rate of internal system environment configuration and enhancing user experience.

[0007] In one possible implementation, after TrustZone configuration is complete, access permissions for registers are first obtained from TrustZone, and then configuration parameters are read from the registers via xPU according to the access permissions. By obtaining permissions before reading data, the configuration timing of AOP and TrustZone can be better controlled, ensuring that AOP and TrustZone complete the configuration step by step at the correct time, avoiding system freezes or configuration failures caused by improper configuration timing. Furthermore, explicit permission management can effectively prevent unauthorized modules from accessing sensitive or critical registers, ensuring the stability and security of the system during configuration or operation.

[0008] In one possible implementation, the configuration status of TrustZone can be queried by checking the status flags through the status detection module. Reading the status flags is a relatively lightweight operation that does not consume excessive system resources, allowing the system to perform resource scheduling and management more efficiently during the configuration phase. Furthermore, in some architectures that would normally require querying the configuration status via xPU, querying the status flags through the status detection module can avoid calling xPU during the TrustZone configuration process, thus improving the configuration success rate.

[0009] In one possible implementation, when the status detection module detects that the status flag indicates TrustZone configuration is complete, it triggers the xPU to acquire register access permissions. This ensures that permission acquisition occurs only after TrustZone configuration is complete, preventing unauthorized access. After successfully acquiring register access permissions, the xPU begins reading AOP configuration parameters, improving the security of configuration parameter reading.

[0010] In one possible implementation, if TrustZone configuration is incomplete, waiting for a period of time before re-querying the configuration status can effectively avoid frequent errors when TrustZone configuration is incomplete. This can reduce unnecessary error logs and alerts during the configuration process and improve system stability.

[0011] In one possible implementation, if TrustZone configuration fails, it is triggered to reconfigure. By triggering reconfiguration upon configuration failure, the success rate of configuration can be significantly improved, system stability and user experience can be enhanced, manual intervention and maintenance costs can be reduced, time can be saved and data loss can be prevented. This mechanism enhances the system's robustness and self-healing capabilities, enabling it to more effectively cope with uncertainties and failures during the configuration process.

[0012] In one possible implementation, a mechanism to record configuration failures after the number of queries to the TrustZone configuration status reaches a preset value can prevent infinite loops, improve system stability and resource utilization efficiency, and provide developers and operations personnel with clear error messages and log records, facilitating problem diagnosis and resolution. This approach not only enhances system robustness and user experience but also optimizes resource management and fault handling processes.

[0013] In one possible implementation, AOP and TrustZone can be configured simultaneously. This allows multiple tasks to be processed in parallel, reducing the overall configuration time.

[0014] In one possible implementation, TrustZone can be configured first, and then AOP can be configured after a second set of time has elapsed. By triggering TrustZone configuration first and then AOP configuration after the second set of time, this approach ensures the security and stability of system configuration, reduces resource contention and conflicts, optimizes the configuration process, and improves the configuration success rate. Furthermore, setting the second set of time based on the actual time taken for TrustZone configuration guarantees the smooth execution of the configuration process.

[0015] In one possible implementation, the reason for failure can be logged when AOP configuration fails. This not only helps to quickly locate and solve problems, but also provides valuable data support for system optimization and improvement, which can effectively improve system reliability and operational efficiency.

[0016] Secondly, this application provides a configuration device, comprising:

[0017] The trigger module is used to trigger the configuration of the real-time response processor AOP and the trusted execution environment TrustZone;

[0018] The query module is used to query the configuration status of TrustZone, and when the configuration status indicates that TrustZone configuration is complete, it reads the configuration parameters of AOP through the embedded memory protection unit xPU; the xPU is in an enabled state after TrustZone configuration is completed.

[0019] The configuration module is used to configure the AOP according to the configuration parameters.

[0020] In one possible implementation, the query module is specifically used to obtain access permissions for registers from the TrustZone when the configuration status indicates that the TrustZone configuration is complete; and based on the access permissions, read the configuration parameters from the registers through the xPU.

[0021] In one possible implementation, the query module is specifically used to query the status flag of the TrustZone through the status detection module; the status detection module is used to query the status flag of the TrustZone, and the status flag is used to indicate the configuration status of the TrustZone.

[0022] In one possible implementation, the query module is specifically used to obtain access permissions for the registers from the TrustZone via the xPU when the status flag indicates configuration is complete; and to read the configuration parameters from the registers via the xPU based on the access permissions.

[0023] In one possible implementation, the query module is further configured to re-query the configuration status of TrustZone after a first period of time when the configuration status indicates that the TrustZone configuration is incomplete.

[0024] In one possible implementation, the configuration status being "configuring" or "configuration failed" indicates that the TrustZone configuration is incomplete; the configuration module is further configured to trigger the TrustZone to reconfigure when the configuration status is "configuration failed".

[0025] In one possible implementation, the device further includes a recording module, used to record a configuration failure if the number of queries to the TrustZone configuration status reaches a preset value.

[0026] In one possible implementation, the triggering module is specifically used to simultaneously trigger the AOP and the TrustZone for configuration.

[0027] In one possible implementation, the triggering module is specifically used to trigger the TrustZone to perform configuration, and after a second time elapses since the TrustZone configuration is triggered, to trigger the AOP to perform configuration; the second time is determined based on the time taken for the TrustZone configuration.

[0028] In one possible implementation, the recording module is further configured to record the reason for the AOP configuration failure when the AOP configuration fails.

[0029] Thirdly, this application provides an electronic device, including: a processor and a memory;

[0030] Memory, which stores instructions;

[0031] A processor coupled to the memory, wherein when program instructions stored in the memory are executed by the processor, the electronic device performs the method as described in any one of the first aspects.

[0032] Fourthly, this application provides a computer storage medium including computer instructions that, when executed on a mobile terminal, cause the electronic device to perform the method as described in any one of the first aspects.

[0033] Fifthly, this application provides a computer program product including instructions; when the instructions are executed by the electronic device, the electronic device performs the method as described in any one of the first aspects. Attached Figure Description

[0034] Figure 1 An example diagram illustrating the composition of an electronic device provided in an embodiment of this application;

[0035] Figure 2 An example diagram of the software structure of an electronic device provided in an embodiment of this application;

[0036] Figure 3 A schematic flowchart illustrating a configuration method provided in an embodiment of this application;

[0037] Figure 4 A software architecture diagram provided for an embodiment of this application;

[0038] Figure 5 Another software architecture diagram provided for embodiments of this application;

[0039] Figure 6 Another software architecture diagram provided in the embodiments of this application;

[0040] Figure 7 This is a flowchart illustrating another configuration method provided in an embodiment of this application. Detailed Implementation

[0041] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the related technologies is given first:

[0042] An Always-On Processor (AOP) is used to run a real-time response system. The real-time response system (AOP subsystem) is a subsystem within the operating system of an electronic device. After the electronic device boots up, AOP remains running, even when other parts of the operating system are in sleep or low-power mode. This allows AOP to immediately process events from sensors, networks, or other input sources without fully waking the entire system, achieving both rapid response and energy conservation. In some operating systems, the AOP subsystem can work in conjunction with the operating system to handle a portion of the computational tasks, improving the overall system efficiency. AOP is typically loaded and configured during the electronic device's boot process. An AOP crash refers to a failure or breakdown of AOP, such as AOP loading failure or AOP execution failure.

[0043] An Xtended Boot Loader (XBL) is a bootloader used to load an operating system and other software onto an electronic device. When an electronic device boots up, the bootloader runs to load the operating system and initialize and manage the hardware and software. The XBL program is typically provided by the device manufacturer and is tightly integrated with the device's hardware and software to maximize device performance. During the execution of the XBL program, the electronic device implements the loading and configuration of AOP (Aspect-Oriented Programming).

[0044] A TrustZone is a secure area created within a processor. It protects sensitive data (such as access permissions) and enables the execution of critical tasks, preventing unauthorized access and tampering by third parties, thus ensuring data confidentiality and integrity. Electronic devices load and start the TrustZone during the execution of the XBL program.

[0045] An embedded memory protected unit (xPU) is a security hardware module used to provide memory protection and data encryption to protect sensitive data in embedded devices from unauthorized access. The xPU typically monitors and protects the device's memory and register access, ensuring that only authorized operations can read or modify sensitive data, thereby enhancing the device's security and data protection capabilities. In this embodiment, AOP needs to access TrustZone or registers through the xPU. The electronic device configures the xPU during the TrustZone configuration process.

[0046] When an electronic device boots up, it initializes its internal environment by loading the XBL program. During the TrustZone boot process, the xPU is configured, but it is unavailable during this configuration. During AOP configuration, AOP needs to access the AOSS_CC register through the xPU to read relevant configuration parameters. The AOSS_CC register stores control information and configuration data for the AOP subsystem (always-on subsystem, AOSS).

[0047] If AOP accesses the AOSS_CC register before the xPU has completed its configuration, it will cause the electronic device to freeze during startup.

[0048] To address this technical problem, this application provides a configuration method applied to electronic devices. Before accessing registers, the AOP first queries the configuration status of TrustZone. If TrustZone is configured successfully, it indicates that the xPU is also configured successfully and can function normally. At this point, the AOP can access TrustZone through the xPU to obtain access permissions to registers used to store AOP configuration parameters (e.g., the AOSS_CC register). Then, it accesses the registers through the xPU to obtain the relevant AOP configuration parameters for normal configuration. This allows the electronic device to successfully run the XBL program to complete the AOP configuration process, avoiding crashes and freezes that may occur when the AOP accesses registers through the xPU during xPU configuration. It also avoids register access failures due to failure to obtain access permissions from TrustZone, improving the success rate of electronic device startup and enhancing user experience.

[0049] In some embodiments, the electronic device may be a mobile phone, tablet computer, desktop computer, laptop computer, ultra-mobile personal computer (UMPC), handheld computer, netbook, personal digital assistant (PDA), wearable electronic device, smartwatch, etc. This application does not impose any special limitations on the specific form of the aforementioned electronic device. In this embodiment, the structure of the electronic device may be as follows: Figure 1 As shown, Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0050] like Figure 1 As shown, the electronic device may include a processor 110, an internal memory 120, and buttons 130, etc.

[0051] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device. In other embodiments, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0052] Processor 110 may include multiple processing units, such as AOP 111 (for running the AOP subsystem), core processing unit 112 (for loading the XBL program), and embedded memory protection unit 113. These different processing units may be independent devices or integrated into one or more processors. In one implementation, core processing unit 112 may also be used to run the AOP subsystem.

[0053] The processor 110 may also include a memory for storing instructions and data. In this embodiment, the memory in the processor 110 is a cache memory. This memory can store XBL programs and AOP subsystems, etc.

[0054] Internal memory 120 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 120. Internal memory 120 may include a program storage area and a data storage area.

[0055] The program storage area can store the operating system, AOP subsystem, XBL program, and Primary Boot Loader (PBL), as well as applications required for at least one function (such as sound playback, image playback, etc.). The data storage area can store data created during the use of the electronic device (such as audio data, phonebook, etc.). Furthermore, the internal memory 120 can include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in the internal memory 120 and / or instructions stored in memory located within the processor.

[0056] Button 130 includes a power button, volume buttons, etc. Button 130 can be a mechanical button or a touch button. The electronic device can receive button input and generate key signal inputs related to user settings and function control of the electronic device. In this embodiment, when the user presses the power button, the processor 110 loads the XBL program to perform power-on initialization.

[0057] The following is combined Figure 1 The hardware architecture diagram shown illustrates the configuration method provided in the embodiments of this application.

[0058] When the user presses button 130, the core processing unit 112 in the processor 110 loads and runs the XBL program to configure TrustZone. During the TrustZone configuration process, the embedded memory protection unit 113 is configured.

[0059] While the core processing unit 112 is running the XBL program, it triggers AOP 111 for configuration. During the configuration process of AOP 111, AOP 111 first queries the core processing unit 112 for the configuration status of TrustZone. If the configuration status of TrustZone is "configuration complete", it indicates that the embedded memory protection unit 113 is in the enabled state. Then, it obtains access permissions to the registers (taking the AOSS_CC register as an example) from TrustZone, and then accesses the AOSS_CC register through the embedded memory protection unit 113 to obtain the relevant configuration parameters of AOP 111 and complete the configuration.

[0060] If the configuration status of TrustZone is "Configuring" or "Configuration Failed," it indicates that the embedded memory protection unit 113 may not have been configured successfully or may be in the process of configuration. In this case, AOP 111 needs to wait for TrustZone to continue configuring or reconfiguring before performing subsequent actions. If TrustZone configuration is abnormal, the core processing unit 112 can also trigger TrustZone to configure itself to resolve the configuration error.

[0061] In addition, an operating system runs on top of the aforementioned components. For example, the Android open-source operating system. Applications can be installed and run on this operating system.

[0062] Operating systems for electronic devices can adopt layered architectures, event-driven architectures, microkernel architectures, microservice architectures, or cloud architectures. This application provides, for example... Figure 2 The software architecture diagram shown illustrates the software structure of an electronic device using the Android system architecture as an example.

[0063] Figure 2 In the software architecture shown, the various components communicate with each other through software interfaces. This software architecture includes the application layer, firmware layer, kernel layer, and operating system layer (OS).

[0064] The application layer provides applications for user interaction with the device, manages and runs user-installed applications, and provides application lifecycle management. It interacts with the operating system layer through system call interfaces provided by the kernel layer.

[0065] The operating system layer includes Android system services and Android Runtime (ART), which provides high-level system services and API interfaces, and manages application lifecycle, windows, notifications, and content providers. Android Runtime includes core libraries and the runtime environment, providing the runtime environment for Android applications and managing application memory, threads, and execution.

[0066] The kernel layer provides a hardware abstraction layer and manages system resources; it also provides system call interfaces to support the execution of upper-layer software. The kernel layer can manage hardware resources (such as the processor, memory, and I / O devices). It can also manage processes, memory, and file systems.

[0067] In this embodiment, the kernel layer can be used to manage the AOP subsystem and TrustZone. The kernel layer includes a status detection module, a maintenance module, and a fault repair module.

[0068] The monitoring module is used to collect and print information about AOP111 crashes. By adding the capture and printing of AOP111 crash information to the kernel's crash handling and logging mechanisms, it facilitates rapid diagnosis and problem localization.

[0069] The status detection module is used to detect the configuration status of TrustZone during system operation.

[0070] The fault repair module is used to trigger AOP111 to re-query the TrustZone configuration status and to attempt to restart TrustZone when an abnormal TrustZone configuration status is detected. A more advanced fault detection and repair mechanism is implemented in the kernel to ensure that TrustZone anomalies are monitored and handled during the operation of electronic devices.

[0071] The firmware layer is responsible for the initial system boot and hardware initialization after the electronic device is powered on, and is used to load and execute higher-level boot programs. In this embodiment, the firmware layer can specifically run a Primary Bootloader (PBL) program and an XBL program, and configure AOP111 and TrustZone. The firmware layer includes a status detection module and a fault repair module. The status detection module is used to detect and record the configuration status of TrustZone, and provides an interface for AOP111 to query, such as configuration in progress, configuration completed, or configuration failed. The fault repair module is used to attempt to restart TrustZone when an abnormal TrustZone configuration status is detected (such as a TrustZone configuration failure). A preliminary fault repair mechanism is implemented in the XBL program to ensure that TrustZone abnormalities are handled during system startup.

[0072] The following is combined Figure 2 The software architecture diagram shown illustrates the configuration method provided in the embodiments of this application.

[0073] After the electronic device is powered on, the system starts running the program stored in memory. The PBL program is loaded to perform basic hardware initialization, such as initializing the CPU, memory, and basic peripherals. After confirming normal power-on, the XBL program is loaded. AOP111 and TrustZone are then configured.

[0074] During the configuration process of AOP111, AOP111 detects the configuration status of TrustZone through the status detection module. After confirming that TrustZone is configured, AOP111 can obtain the relevant configuration parameters from the AOSS_CC register and configure it by using the access permissions obtained from TrustZone.

[0075] If AOP111 detects that TrustZone configuration is incomplete or has failed through the status detection module, it will wait for an immediate period and then check the TrustZone configuration status again through the status detection module until it confirms that TrustZone configuration is complete. If AOP111 detects that TrustZone configuration has failed through the status detection module, the fault repair module will trigger TrustZone to reconfigure. Furthermore, if AOP111 crashes during operation, the maintenance module can capture and record the crash time and cause of AOP111.

[0076] To make the technical solution of this application clearer and easier to understand, the configuration method provided by the embodiments of this application will be described below with reference to the above embodiments and corresponding drawings. This method can be applied in specific... Figure 1 Implemented on the electronic device with the structure shown. Figure 2 This is implemented in the software architecture shown. The following section describes it from a software implementation perspective, such as... Figure 3 As shown, the configuration method provided in this application embodiment may include:

[0077] S301: Electronic device starts up and PBL program runs.

[0078] When the electronic device is powered on, the processor 110 executes the PBL program. The main task of the PBL program is to initialize the hardware environment and ensure that basic system resources (such as clock, memory controller, and power management) are available. The processor 110 reads the PBL program from the internal memory 120, loads it into memory, and begins execution.

[0079] PBL programs can also include basic memory mapping tables. Memory mapping tables describe the layout of system memory. They record the physical memory regions in an electronic device and their uses, enabling subsequent programs and the operating system to correctly manage and access these memory regions. As an example, a memory mapping table includes a start address (the starting physical address of the memory region), length (the size of the memory region), type (the purpose or attribute of the memory region, such as available memory, reserved memory, and device memory), and attributes (further describing the characteristics of the memory region, such as read / write permissions, caching policies, etc.).

[0080] By running the PBL program after the electronic device is powered on, the hardware is initialized and configured at the basic hardware level, providing a stable operating environment for the XBL program. This ensures that subsequent XBL programs can continue to initialize and configure in a known good hardware state, avoiding system instability or failure due to incorrect hardware configuration.

[0081] After the PBL program finishes running, the next stage of the bootloader is triggered, that is, after the PBL program finishes running, the XBL program is triggered.

[0082] As an example, during the execution of the PBL program, the processor 110 reads the XBL image program of the XBL program from the internal memory 120 and loads it into random access memory (RAM), enabling the processor 110 to directly run the XBL program. It is important to note that the storage address of the XBL image program matches the link address of the XBL program to ensure that the XBL program can function correctly.

[0083] S302: XBL program running.

[0084] After the PBL program completes its initial boot and releases control, processor 110 runs the XBL program. The PBL program has limited configuration scope and depth, limited only to ensuring that the system can run normally up to the stage of loading the XBL. Therefore, during the execution of the XBL program, further hardware and hardware driver configuration is required to ensure that all system hardware resources and drivers are correctly loaded and configured, providing a complete and optimized environment for operating system startup.

[0085] The XBL program ensures all hardware components function correctly by configuring the system clock and power management unit; it also initializes critical peripherals (such as serial ports, network interfaces, and storage controllers) to support subsequent system configuration and operation. The XBL program loads and executes various hardware drivers to perform more detailed initialization and configuration for different types of hardware. For example, it loads storage device drivers to ensure access to and operation of different types of storage devices; it loads input / output device drivers to initialize and configure input / output devices (such as keyboards, mice, and monitors); and it loads network device drivers to initialize network interfaces for network-related operations.

[0086] After configuring the hardware and drivers, XBL also needs to configure the system environment, setting necessary boot parameters for the upcoming operating system, such as command-line arguments and boot mode. This also includes configuring the AOP subsystem and TrustZone running in AOP111.

[0087] S303: Configure the AOP subsystem and TrustZone.

[0088] The AOP subsystem is primarily responsible for power management of electronic devices and handling low-power tasks. The AOP subsystem can continue running in sleep or low-power mode of the main processor, handling various low-power tasks. These include: power state management (managing different power states of the device, such as sleep, hibernation, and deep sleep), power domain control (controlling the switching states of different power domains to optimize power consumption), and battery management (monitoring battery status, optimizing battery usage, and extending battery life).

[0089] The AOP subsystem can also be used to manage various sensors in the system. The AOP subsystem can read sensor data and perform basic processing in low-power mode, then wake up the main processor when necessary. Examples include sensor data acquisition (periodically reading sensor data such as temperature, acceleration, and light intensity) and event triggering (triggering specific events based on sensor data or waking up the main processor for further processing).

[0090] The AOP subsystem can also handle some real-time tasks that require fast response times. These tasks do not require the main processor's involvement, thus improving the system's response speed and efficiency. Examples include: scheduled tasks (such as maintaining the system clock, triggering periodic events, etc.) and interrupt handling (handling simple hardware interrupts to reduce the burden on the main processor).

[0091] TrustZone uses a hardware-supported isolation mechanism to divide the system into a secure world and a non-secure world, thereby isolating sensitive data and applications and preventing attacks from malicious code. TrustZone stores the access permissions of the AOP subsystem to the AOSS_CC register (that is, the access permissions of AOP111 to the AOSS_CC register). These permissions can be defined by Access Control Lists (ACLs), and the specific access permissions can be stored in the secure world.

[0092] The configuration process for TrustZone can be as follows: Configure TrustZone's security mechanisms, establish isolation between the secure and insecure worlds, and configure basic access control. During configuration, TrustZone needs to configure relevant xPU rules to implement memory access control, such as defining access permissions and attributes (e.g., read / write permissions) for each memory region.

[0093] It is important to note that during the TrustZone configuration process, xPU may be in a configuration state or may have already been configured and is in an active state. When TrustZone configuration is complete, xPU will be enabled. If TrustZone configuration fails, xPU may also fail to configure or may have already been configured and is in an active state.

[0094] In this embodiment, a status flag is set for TrustZone to indicate its current configuration status, including configuration in progress, configuration complete, and configuration failure. A status flag indicating configuration in progress means TrustZone is still in the configuration process and has not yet completed; in this case, xPU may be in the configuration process. A status flag indicating configuration complete means TrustZone has completed configuration; in this case, xPU is configured and enabled. A status flag indicating configuration failure means TrustZone configuration has failed; in this case, xPU may have failed to configure or may have completed configuration and is enabled. However, because TrustZone configuration has failed, the AOP subsystem cannot obtain access to the AOSS_CC register from TrustZone and therefore cannot read configuration parameters from the AOSS_CC register via xPU.

[0095] TrustZone stores the access permissions of the AOP subsystem to specific registers (i.e., registers that store configuration parameters). During the configuration process of TrustZone, an access control list for the AOP subsystem is also defined, listing the permissions of the AOP subsystem for the AOSS_CC register, and the access control list is stored in the secure storage area of ​​TrustZone to ensure that it is not tampered with.

[0096] The configuration process for the AOP subsystem can be as follows: Configure the hardware and software environment of the AOP subsystem, including setting the clock source, configuring the memory controller, and configuring the power management unit. After configuration, the AOP subsystem needs to obtain configuration parameters from the AOSS_CC register. These configuration parameters include various operating parameters of the AOP subsystem, such as the timer task interval and sensor acquisition frequency.

[0097] In one possible implementation, the AOP subsystem and TrustZone can be configured synchronously during the XBL program's execution. The AOP subsystem manages low-power and real-time tasks, while TrustZone provides a hardware-isolated, secure execution environment. Synchronous configuration can potentially reduce overall startup time. During TrustZone configuration, the AOP subsystem can configure the hardware and software environment first, and then complete the subsequent configuration process after TrustZone is configured. The overall configuration time equals the sum of the time spent on TrustZone configuration and the time spent on parameter configuration by the AOP subsystem. The time spent on parameter configuration by the AOP subsystem includes the time for the AOP subsystem to access TrustZone to obtain access to the AOSS_CC register, the time for the AOP subsystem to access the AOSS_CC register through the xPU to obtain configuration parameters, and the time for the AOP subsystem to complete the configuration based on the configuration parameters.

[0098] In another possible implementation, TrustZone is configured first during the XBL program's execution, and then the AOP subsystem is configured after a second set of time. This second set of time can be determined based on the time taken for TrustZone configuration. During the AOP subsystem's configuration process, it needs to access TrustZone to obtain access permissions and needs to access the AOSS_CC register via xPU. Therefore, TrustZone can be configured beforehand so that it is already configured when the AOP subsystem accesses it, shortening the AOP subsystem's waiting time or configuration duration. Furthermore, this configuration method reduces resource contention and race conditions, and lowers the complexity of synchronization operations.

[0099] In this embodiment of the application, in order to avoid the AOP subsystem from crashing due to accessing the xPU in the configuration, and also to avoid the AOP subsystem from failing to obtain access permissions from the TrustZone that has not been configured, resulting in configuration failure, the AOP subsystem first queries the configuration status of TrustZone before accessing the xPU, and then performs subsequent processing based on the configuration status of TrustZone.

[0100] S304: The AOP subsystem queries the configuration status of TrustZone.

[0101] This application embodiment adds a status flag to TrustZone to indicate its configuration status, allowing other programs or systems to know the configuration status of TrustZone. It should be noted that even if TrustZone configuration is incomplete, other programs or systems can still query the status flag. The configuration status of TrustZone includes three states: configuration complete, configuration in progress, and configuration failed. "Configuration in progress" and "configuration failed" can be collectively referred to as configuration incomplete.

[0102] In one possible implementation, such as Figure 4 In the software architecture shown, the AOP subsystem is directly connected to TrustZone, so the AOP subsystem can query the status flags of TrustZone to determine the configuration status of TrustZone.

[0103] In another possible implementation, such as Figure 5 The software architecture shown depicts an AOP subsystem connected to TrustZone via xPU. The AOP subsystem needs to query the status flags of TrustZone through xPU. However, if TrustZone is not fully configured, xPU may also be unconfigured; or the AOP subsystem may fail to obtain access to the AOSS_CC register, resulting in query failure. To address this situation, this application provides a software architecture, such as... Figure 6 As shown, a status detection module has been added between the AOP subsystem and TrustZone. This module can directly query the status flags of TrustZone, and the AOP subsystem can also directly access it. The AOP subsystem can bypass xPU to confirm the status of TrustZone by accessing the status detection module, thus preventing system crashes caused by the AOP subsystem calling xPU during xPU configuration.

[0104] If the AOP subsystem determines that the configuration status of TrustZone is "configuration completed", then proceed to step S305; if the AOP subsystem determines that the configuration status of TrustZone is "configuration in progress" or "configuration failed", then proceed to step S307.

[0105] S305: The AOP subsystem accesses TrustZone to obtain access to the AOSS_CC register.

[0106] After confirming that TrustZone has been configured, the AOP subsystem sends an access permission request to TrustZone to obtain access to the AOSS_CC register. The access permission request is used to request access to the AOSS_CC register (such as read / write permissions). As one example, the AOP subsystem sends the access permission request through a secure channel between the AOP subsystem and TrustZone to improve the security of requests and data transmission. As another example, the AOP subsystem sends the access permission request to TrustZone through xPU, achieving the same effect of improving the security of requests and data transmission.

[0107] Upon receiving an access permission request from the AOP subsystem, TrustZone can audit the AOP subsystem's permissions, such as verifying the AOP subsystem's identity and the validity of the request. If the audit is successful, TrustZone grants the AOP subsystem the appropriate access permissions and sends an access token or key to the AOP subsystem.

[0108] S306: The AOP subsystem obtains configuration parameters and performs configuration by accessing the AOSS_CC register through the xPU according to access permissions.

[0109] After obtaining access permissions, the AOP subsystem uses the access token or key obtained through TrustZone to access the AOSS_CC register via the system's xPU. The xPU is responsible for managing access permissions to memory and registers in different execution environments, ensuring that only authorized access can lead to successful execution.

[0110] Specifically, the AOP subsystem sends an access request to the xPU, which includes an access token (or key), the AOSS_CC register address, and the access type (read or write). After receiving the access request, the xPU verifies the access token. If the verification is successful, it accesses the AOSS_CC register according to the AOSS_CC register address and the access type. If the access type is read, it reads the configuration parameters of the AOP subsystem from the AOSS_CC register and feeds these configuration parameters back to the AOP subsystem.

[0111] Configuration parameters include, for example, power management schemes, clock frequency settings, and security monitoring parameters. The AOP subsystem then adjusts its configuration based on these parameters to ensure that the low-power and real-time tasks it manages run with optimal settings.

[0112] Specifically, the AOP subsystem parses the configuration parameters read from the AOSS_CC register and adjusts its internal settings or states accordingly, such as adjusting the clock frequency, modifying power state transition strategies, and configuring security monitoring parameters. Then, the AOP subsystem can verify the configuration through test programs or by monitoring system operation status to ensure the modified configuration is correct and the system operates stably. After configuration, the AOP subsystem feeds back the configuration results to TrustZone or other system modules to ensure the consistency of the entire system.

[0113] S307: The AOP subsystem executes step S304 again after the first time.

[0114] If the AOP subsystem queries the TrustZone configuration status and the result is "Configuring" or "Configuration failed," it needs to enter a waiting mode. That is, the AOP subsystem cannot continue to request access to the AOSS_CC register from TrustZone until TrustZone is successfully configured.

[0115] In this embodiment, a reasonable first time interval is set based on the estimated configuration time of TrustZone. The first time interval refers to the time between the last time the AOP subsystem queries the TrustZone configuration status and the next time the AOP subsystem queries the TrustZone configuration status if the result is "Configuring" or "Configuration Failed". The first time interval can be set based on past experience data, system performance standards, or real-time requirements. For example, it can be set to a few milliseconds or hundreds of milliseconds, depending on the system's sensitivity to response time. During the first time interval, the AOP subsystem enters a waiting mode and stops sending access permission requests to TrustZone or querying the TrustZone configuration status.

[0116] After the initial period, step S304 is executed again, and the AOP subsystem queries the configuration status of TrustZone again. If this query determines that TrustZone has completed configuration, step S305 is executed; if this query still determines that TrustZone is in the process of configuration or that configuration has failed, step S307 is executed again.

[0117] In this embodiment, the fault repair module can be used to re-execute step S304 of the AOP subsystem. Specifically, when the AOP subsystem queries the TrustZone configuration status through the status detection module, the status detection module simultaneously informs the fault repair module of the TrustZone configuration status. When the fault repair module determines that TrustZone is in the process of configuration, it starts a timer. After a first time interval, it triggers the AOP subsystem to re-execute step S304. When the fault repair module determines that TrustZone configuration has failed, it starts a timer and triggers TrustZone to reconfigure. After a first time interval, it triggers the AOP subsystem to re-execute step S304.

[0118] The fault recovery module automatically attempts to reconfigure TrustZone when configuration fails, reducing the need for manual intervention and improving the system's self-recovery capabilities. The linkage between the status detection module and the fault recovery module allows the system to respond to changes in TrustZone's configuration status in real time, thereby more effectively managing system resources and control processes. Furthermore, by setting reasonable first-time and timing mechanisms, the AOP subsystem can continuously check TrustZone's configuration status without wasting resources. After a delay, a re-query may reveal that TrustZone has already completed configuration. This not only increases the probability of successful queries but also reduces unnecessary error reports.

[0119] In one possible approach, if the AOP subsystem repeatedly queries and finds TrustZone in a state of configuration or configuration failure—that is, if the AOP subsystem executes step S304 more times than a preset value during a single electronic device startup—an error is reported. The maintenance module captures and records this error, and then reports it to the system. The capture and recording of errors by the maintenance module aids in subsequent troubleshooting and recovery; developers can quickly locate the root cause of the problem based on the error log. Furthermore, by setting an early warning mechanism for the number of queries, the system can effectively improve its monitoring and management capabilities of the TrustZone configuration process, thereby enhancing overall stability and reliability.

[0120] Based on the above embodiments, the configuration method will be described below from the perspective of hardware and software integration, as follows: Figure 7 As shown, the method includes:

[0121] S701: AOP111 queries the configuration status of TrustZone through the status detection module.

[0122] S702: The status detection module queries the status flags of TrustZone.

[0123] TrustZone status flags include configuration complete, configuration in progress, and configuration failed, which represent three different TrustZone states, and there are different processing procedures for each TrustZone state.

[0124] When the status flag indicates configuration complete, proceed to step S703; when the status flag indicates configuration in progress, proceed to step S705; when the status flag indicates configuration failure, proceed to step S708.

[0125] S703: The status detection module informs AOP111 that the configuration status is complete.

[0126] S704: AOP111 obtains access to the AOSS_CC register from TrustZone.

[0127] After AOP111 confirms that TrustZone is configured, it can request access to the AOSS_CC register from TrustZone. See step S305 for details.

[0128] S705: AOP111 accesses the AOSS_CC register via xPU113 to obtain configuration parameters based on access permissions.

[0129] The access order can be obtained through AOP111. Configuration parameters can be retrieved by accessing the AOSS_CC register via xPU113, and then the configuration process can be performed based on these parameters. Please refer to the relevant description in step S306 for details.

[0130] S706: The status detection module informs AOP111 and the fault repair module that the configuration status is in the process of configuration.

[0131] After confirming that the TrustZone configuration status is "Configuring," the fault repair module determines whether the number of times AOP111 queries the TrustZone configuration status is greater than a preset value N, i.e., whether the number of times AOP111 executes step S701 is greater than the preset value N. If the number of times AOP111 queries the TrustZone configuration status is greater than the preset value N, then step S707 is executed; if the number of times AOP111 queries the TrustZone configuration status is less than or equal to the preset value N, then step S708 is executed.

[0132] S707: The fault repair module reports an error to the maintenance and testing module.

[0133] If the number of times AOP111 queries the TrustZone configuration status exceeds the preset value N, the fault repair module will directly report an error to the untested module.

[0134] S708: The fault repair module triggers AOP111 to re-execute step S701.

[0135] If the number of times AOP111 queries the TrustZone configuration status exceeds the preset value N, after the first time, the fault repair module will trigger AOP111 to query the TrustZone configuration status again, that is, to re-execute step S701.

[0136] S709: The status detection module informs AOP111 and the fault repair module that the configuration status is configuration failure.

[0137] After the fault repair module confirms that the configuration status of TrustZone is "configuring," it executes step S710 to trigger TrustZone to reconfigure. It also checks whether the number of times AOP111 queries the TrustZone configuration status is greater than a preset value N, i.e., whether the number of times AOP111 executes step S701 is greater than the preset value N. If the number of times AOP111 queries the TrustZone configuration status is greater than the preset value N, then step S711 is executed; if the number of times AOP111 queries the TrustZone configuration status is less than or equal to the preset value N, then step S7012 is executed.

[0138] S710: The fault repair module triggers TrustZone reconfiguration.

[0139] S711: The fault repair module reports an error to the maintenance and testing module.

[0140] If the number of times AOP111 queries the TrustZone configuration status exceeds the preset value N, the fault repair module will directly report an error to the untested module.

[0141] S712: The fault repair module triggers AOP111 to re-execute step S701.

[0142] If the number of times AOP111 queries the TrustZone configuration status exceeds the preset value N, after the first time, the fault repair module will trigger AOP111 to query the TrustZone configuration status again, that is, to re-execute step S701.

[0143] It should be noted that the process of the core processing unit 112 running the PBL program and XBL program in this embodiment of the application is not described in detail. Please refer to the relevant description of steps S301-S302 above.

[0144] This application does not impose any special limitations on the specific form of the aforementioned electronic device. In this embodiment, the structure of the electronic device can be as follows: Figure 1As shown in the illustration. It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device. In other embodiments, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of both.

[0145] This application also provides an electronic device, including a memory and a processor, wherein:

[0146] The electronic device includes a memory that stores instructions and a processor coupled to the memory, which, when executed by the processor, causes the program instructions stored in the memory to perform the configuration method described in any of the above embodiments.

[0147] This application also provides a computer storage medium storing computer instructions. When the computer instructions are executed on a terminal, the terminal performs the aforementioned method steps to implement the configuration method in the above embodiments.

[0148] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the configuration method described in the above embodiments.

[0149] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the configuration methods in the above-described method embodiments.

[0150] In this application, the terminal, computer storage medium, computer program product or chip provided in the embodiments are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0151] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0152] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0153] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0154] The technical solution of this embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0155] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A configuration method, characterized in that, The method includes: When an electronic device is powered on and started, the Real-Time Response Processor (AOP) and the Trusted Execution Environment (TrustZone) are triggered for configuration. AOP queries the configuration status of the TrustZone, and when the configuration status indicates that the TrustZone configuration is complete, it obtains access permissions to the registers in the TrustZone. Based on the access permissions, configuration parameters are read from the register via the xPU; the xPU is enabled after the TrustZone configuration is completed. Complete the configuration of the AOP according to the configuration parameters.

2. The method according to claim 1, characterized in that, The AOP query for the configuration status of TrustZone includes: The status flag of TrustZone is queried through the status detection module; the status detection module is used to query the status flag of TrustZone, and the status flag is used to indicate the configuration status of TrustZone.

3. The method according to claim 2, characterized in that, When the configuration state indicates that the TrustZone configuration is complete, the configuration parameters of the AOP are read through the embedded memory protection unit (xPU), including: When the status flag indicates configuration complete, access to the registers is obtained from the TrustZone via the xPU; Based on the access permissions, the configuration parameters are read from the register via the xPU.

4. The method according to claim 1, characterized in that, The method further includes: If the configuration status indicates that the TrustZone configuration is incomplete, the configuration status of TrustZone will be queried again after the first time.

5. The method according to claim 4, characterized in that, When the configuration status is "Configuring" or "Configuring failed", it indicates that the TrustZone configuration is incomplete. The method further includes: If the configuration status is "configuration failed", the TrustZone will be triggered to reconfigure.

6. The method according to claim 4, characterized in that, The method further includes: If the number of queries to the TrustZone configuration status reaches a preset value, then the configuration is recorded as failed.

7. The method according to any one of claims 1-6, characterized in that, The configuration of the triggering real-time response processor AOP and the trusted execution environment TrustZone includes: Simultaneously, the AOP and TrustZone are triggered for configuration.

8. The method according to any one of claims 1-6, characterized in that, The configuration of the triggering real-time response processor AOP and the trusted execution environment TrustZone includes: The TrustZone configuration is triggered, and after a second time elapses from the triggering of the TrustZone configuration, the AOP configuration is triggered; the second time is determined based on the time spent on TrustZone configuration.

9. The method according to any one of claims 1-6, characterized in that, The method further includes: If the AOP configuration fails, record the reason for the failure.

10. An electronic device, comprising: Memory, which stores program instructions; A processor coupled to the memory, wherein when program instructions stored in the memory are executed by the processor, the electronic device performs the configuration method as described in any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by an electronic device, implements the configuration method as described in any one of claims 1-9.

Images