Configuration method and related equipment

Abstract

According to the configuration method and the related device, in the process of configuring the AOP and the TrustZone, the configuration state of the TrustZone needs to be inquired firstly, when it is confirmed that configuration of the TrustZone is completed, it can also be confirmed that xPU is in the enabled state, and then when the xPU is in the enabled state, configuration parameters of the AOP are read through the xPU, and configuration of the AOP is completed. According to the method, the time sequence is adjusted in the configuration process, and the step of reading the configuration parameters of the AOP through the xPU is carried out after the TrustZone configuration state is inquired, so that system crash caused by calling the xPU when the xPU is not started is avoided, the success rate of internal environment configuration of the system is improved, and the user experience is improved.

Description

Technical Field

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

[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 startup process of an electronic device, the system needs to sequentially load multiple key boot programs to initialize the hardware and load the operating system. Typically, during the startup process, an electronic device loads a boot loader (XBL) to initialize and configure its internal environment.

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

[0004] The present application provides a configuration method and related devices, aiming to improve the success rate of initialization configuration of the internal environment of electronic devices and enhance user experience.

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

[0006] First, the present application provides a configuration method. During the configuration of AOP and TrustZone, it is necessary to first query the configuration status of TrustZone. When confirming that the TrustZone configuration is complete, it is also possible to confirm that the xPU is in the enabled state. Then, when the xPU is in the enabled state, the configuration parameters of the AOP are read through the xPU to complete the configuration of the AOP. The present application adjusts the timing during the configuration process and places the step of reading the configuration parameters of the AOP through the xPU after querying the TrustZone configuration status to avoid system crashes caused by calling the xPU when the xPU is not enabled, thereby improving the success rate of the system's internal environment configuration and improving the user experience.

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

[0008] In one possible implementation, the TrustZone configuration status can be queried by querying the status flags through the status detection module. Reading the status flags is a lightweight operation that does not consume excessive system resources, enabling more efficient resource scheduling and management during the configuration phase. Furthermore, in architectures that typically require the xPU to query the configuration status, querying the status flags through the status detection module can avoid calling the xPU during the TrustZone configuration process, improving the configuration success rate.

[0009] In one possible implementation, when the status detection module detects that the status flag indicates that TrustZone configuration is complete, it triggers the xPU to obtain register access rights. This ensures that access is granted only when TrustZone configuration is complete, preventing unauthorized access. After successfully obtaining register access rights, the xPU begins reading the AOP's configuration parameters, improving the security of configuration parameter reading.

[0010] In one possible implementation, if TrustZone configuration is determined to be incomplete, waiting for a period of time before re-querying the configuration status can effectively avoid frequent error messages 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 triggers a TrustZone reconfiguration. By triggering reconfiguration upon configuration failure, the configuration success rate, system stability, and user experience can be significantly improved, while reducing manual intervention and maintenance costs, saving time and preventing data loss. This mechanism enhances the system's robustness and self-healing capabilities, enabling it to more effectively handle uncertainties and failures during the configuration process.

[0012] In one possible implementation, when the number of TrustZone configuration status queries reaches a preset threshold, a mechanism for logging configuration failures can prevent infinite loops, improve system stability and resource utilization efficiency, and provide developers and operations personnel with clear error messages and logs to facilitate problem diagnosis and resolution. This approach not only improves system robustness and user experience, but also optimizes resource management and troubleshooting.

[0013] In one possible implementation, AOP and TrustZone can be configured at the same time. Configuring them simultaneously allows for processing multiple tasks in parallel, reducing overall configuration time.

[0014] In one possible implementation, TrustZone can be configured first, and then AOP can be configured after a second timeout has passed. By triggering TrustZone configuration first and then AOP configuration after the second timeout, this approach ensures system configuration security and stability, reduces resource contention and conflicts, optimizes the configuration process, and improves configuration success rates. Furthermore, setting the second timeout based on the actual duration of TrustZone configuration ensures a smooth configuration process.

[0015] In one possible implementation, the cause of the failure can be recorded when the AOP configuration fails. This not only helps to quickly locate and solve the problem, but also provides valuable data support for system optimization and improvement, effectively improving system reliability and operation and maintenance efficiency.

[0016] In a second aspect, the present application provides a configuration device, comprising:

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

[0018] a query module, configured to query the configuration status of the TrustZone and, when the configuration status indicates that the TrustZone configuration is complete, read the configuration parameters of the AOP through an embedded memory protection unit xPU; the xPU is in an enabled state after the TrustZone configuration is complete;

[0019] A configuration module is used to complete the configuration of the AOP according to the configuration parameters.

[0020] In a possible implementation, the query module is specifically configured to obtain access rights to registers from the TrustZone when the configuration state indicates that the TrustZone configuration is complete; and read the configuration parameters from the registers through the xPU based on the access rights.

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

[0022] In a possible implementation, the query module is specifically configured to obtain register access rights from the TrustZone through the xPU when the status flag indicates configuration completion; and read the configuration parameters from the register through the xPU based on the access rights.

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

[0024] In a possible implementation, when the configuration status is configuring or configuration failed, it is used to indicate that the TrustZone configuration is incomplete; the configuration module is further used to trigger the TrustZone to reconfigure when the configuration status is configuration failed.

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

[0026] In a possible implementation, the trigger module is specifically configured to simultaneously trigger the AOP and the TrustZone to be configured.

[0027] In a possible implementation, the trigger module is specifically used to trigger the TrustZone to be configured, and trigger the AOP to be configured after a second time has passed since the TrustZone was triggered to be configured; the second time is determined according to the time consumed by the TrustZone configuration.

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

[0029] In a third aspect, the present application provides an electronic device, comprising: a processor and a memory;

[0030] a memory storing instructions;

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

[0032] In a fourth aspect, the present application provides a computer storage medium comprising computer instructions, which, when executed on a mobile terminal, enables the electronic device to execute the method as described in any one of the first aspects.

[0033] In a fifth aspect, the present application provides a computer program product, comprising instructions; when the instructions are executed by the electronic device, the electronic device executes the method as described in any one of the first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 An exemplary diagram of the composition of an electronic device provided in an embodiment of the present application;

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

[0036] Figure 3 A flowchart of a configuration method provided in an embodiment of the present application;

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

[0038] Figure 5 Another software architecture diagram provided for an embodiment of the present application;

[0039] Figure 6 Another software architecture diagram provided for an embodiment of the present application;

[0040] Figure 7 A flowchart of another configuration method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] To make the description of the following embodiments clear and concise, a brief introduction to the related technologies is first given:

[0042] The real-time response processor (Always On Processor, AOP) is used to run the real-time response system. The real-time response system (AOP subsystem) is a subsystem in the operating system of an electronic device. After the electronic device is turned on, the AOP is always in operation. Even when other parts of the operating system are in sleep or low-power mode, the AOP continues to run so that it can immediately process events from sensors, networks or other input sources without fully waking up the entire system, which can achieve both fast response and energy saving. In some operating systems, the AOP subsystem can work in conjunction with the operating system to process part of the computing tasks to improve the efficiency of the overall system. The AOP is usually loaded and configured during the startup of the electronic device. AOP crash refers to a situation where the AOP fails or crashes, such as AOP loading failure or AOP running failure.

[0043] An extended boot loader (XBL) is a boot program used to load an operating system and other software onto an electronic device. When an electronic device boots up, it runs the boot loader to load the operating system and initialize and manage the hardware and software. The XBL is typically provided by the device manufacturer and is tightly integrated with the device's hardware and software to maximize its performance. The XBL is used by the electronic device to load and configure the AOP.

[0044] The TrustZone is a secure area created within the processor. It protects sensitive data (such as permissions) and critical tasks, preventing unauthorized access and tampering, thereby ensuring data confidentiality and integrity. Electronic devices load and start the TrustZone when running an XBL program.

[0045] The Embedded Memory Protected Unit (xPU) is a secure hardware module that provides memory protection and data encryption to protect sensitive data in embedded devices from unauthorized access. The xPU is typically capable of monitoring and protecting device 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 an embodiment of the present application, the 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 the xPU is unavailable during the configuration process. During the AOP configuration process, the AOP needs to access the AOSS_CC register through the xPU and read the relevant AOP configuration parameters from the AOSS_CC register. The AOSS-CC register stores control information and configuration data for the AOSS subsystem (AOSS).

[0047] If the AOP accesses the AOSS_CC register before the xPU has completed configuration, the electronic device will be stuck when starting up.

[0048] In response to this technical problem, an embodiment of the present application provides a configuration method for electronic devices. Before accessing the register, the AOP first queries the configuration status of TrustZone. If the configuration of TrustZone is completed, it means that the xPU has also been configured and the xPU can work normally. At this time, the AOP can normally access TrustZone through the xPU to obtain access rights to the registers (such as the AOSS_CC register) used to store the AOP configuration parameters, and then access the registers through the xPU to obtain the relevant configuration parameters of the AOP for normal configuration, so that the electronic device can smoothly run the XBL program to complete the configuration process of the AOP, avoiding the AOP from crashing and getting stuck when accessing the registers through the xPU during the xPU configuration process, and also avoiding the register access failure caused by failure to obtain access rights from the TrustZone, thereby 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, laptop, notebook computer, ultra-mobile personal computer (UMPC), handheld computer, netbook, personal digital assistant (PDA), wearable electronic device, smart watch, etc. The present application does not impose any special restrictions on the specific form of the above electronic devices. In this embodiment, the structure of the electronic device may be as follows: Figure 1 As shown, Figure 1 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

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

[0051] It should be 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 shown, or may combine or separate certain 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. For example, processor 110 may include AOP 111 (for running the AOP subsystem), core processing unit 112 (for loading XBL programs), and embedded memory protection unit 113. The 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 the embodiment of the present application, the memory in the processor 110 is a cache memory. The memory may store XBL programs and AOP subsystems, etc.

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

[0055] Among them, the program storage area can store the operating system, AOP subsystem, XBL program and initial boot loader (Primary Boot Loader, PBL), at least one application required for a function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device (such as audio data, a phone book, etc.), etc. In addition, the internal memory 120 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a 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 a memory provided in the processor.

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

[0057] The following combination Figure 1 The hardware architecture diagram shown introduces the configuration method provided in the embodiment of the present application.

[0058] When the user presses the button 130 , the core processing unit 112 in the processor 110 loads and runs the XBL program to configure the 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 the AOP 111 to perform configuration. During the AOP 111 configuration process, the AOP 111 first queries the core processing unit 112 for the TrustZone configuration status. If the TrustZone configuration status is complete, indicating that the embedded memory protection unit 113 is enabled, the AOP 111 obtains access rights to registers (for example, the AOSS_CC register) from the TrustZone. Furthermore, the AOSS_CC register is accessed through the embedded memory protection unit 113 to obtain the relevant configuration parameters of the AOP 111 and complete the configuration.

[0060] If the TrustZone configuration status is Configuring or Failed, it indicates that the embedded memory protection unit 113 may not have been successfully configured or is in the process of being configured. In this case, AOP 111 needs to wait for TrustZone to continue or reconfigure, and then perform subsequent actions after confirming that the TrustZone configuration is complete. If the TrustZone configuration is abnormal, the core processing unit 112 can also trigger TrustZone to configure to resolve the configuration anomaly.

[0061] In addition, an operating system runs on the above components, such as the Android open source operating system, on which applications can be installed and run.

[0062] The operating system of the electronic device can adopt a layered architecture, event-driven architecture, micro-kernel architecture, micro-service architecture, or cloud architecture. Figure 2 The software architecture diagram shown uses the Android system architecture as an example to illustrate the software structure of the electronic device.

[0063] Figure 2 In the software structure shown, each component communicates through a software interface. The software architecture includes the application layer (Applications), the firmware layer (Firmware), the kernel layer (Kernel), and the operating system (OS) layer.

[0064] The application layer provides applications for users to interact with devices, manages and runs user-installed applications, and provides application lifecycle management. It interacts with the operating system layer through the system call interface provided by the kernel layer.

[0065] The operating system layer includes Android system services and the Android Runtime (ART), which provide high-level system services and APIs, and manage application lifecycles, windows, notifications, and content providers. The Android Runtime, which includes core libraries and a runtime environment, provides the operating environment for Android applications and manages their memory, threads, and execution.

[0066] The kernel layer provides hardware abstraction and manages system resources. It also provides the system call interface to support the operation of upper-layer software. The kernel layer manages hardware resources (such as processors, memory, and I / O devices). It also manages processes, memory, and file systems.

[0067] In the embodiment of the present application, 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 maintenance module is used to collect and print AOP111 crash information. 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 location.

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

[0070] The fault recovery module triggers the AOP111 to re-query the TrustZone configuration status and attempts to restart the TrustZone if a TrustZone configuration anomaly is detected. Implementing a more advanced fault detection and recovery mechanism in the kernel ensures that TrustZone anomalies are monitored and handled during electronic device operation.

[0071] The firmware layer is responsible for the initial booting of the system and hardware initialization after the electronic device is powered on, and is used to load and execute more advanced boot programs. In an embodiment of the present application, the firmware layer can specifically run the boot loader (Primary Bootloader, PBL) program and the 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 provide an interface for AOP111 to query, such as configuring, configuration completed, or configuration failed. The fault repair module is used to attempt to restart TrustZone when an abnormality in the TrustZone configuration status is detected (such as a TrustZone configuration failure is detected). A preliminary fault repair mechanism is implemented in the XBL program to ensure that TrustZone exceptions are handled during system startup.

[0072] The following combination Figure 2 The software architecture diagram shown introduces the configuration method provided in the embodiment of the present application.

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

[0074] During the configuration process of AOP111, AOP111 detects the configuration status of TrustZone through the status detection module. After determining that the TrustZone configuration is completed, AOP111 can obtain relevant configuration parameters from the AOSS_CC register and perform configuration by using the access rights of the AOSS_CC register obtained from TrustZone.

[0075] If the AOP111 detects that the TrustZone configuration is incomplete or has failed through the status detection module, it waits for an initial period of time and then rechecks the TrustZone configuration status through the status detection module until it confirms that the TrustZone configuration is complete. If the AOP111 detects a TrustZone configuration failure through the status detection module, the fault recovery module triggers TrustZone reconfiguration. Furthermore, if the AOP111 crashes or reports an error during operation, the maintenance module can capture and record the crash time and cause.

[0076] In order to make the technical solution of this application clearer and easier to understand, the configuration method provided by the embodiment of this application is introduced below in combination with the above embodiments and corresponding drawings. Figure 1 The electronic device of the structure shown is implemented and Figure 2 The following is an introduction from the perspective of software implementation, such as Figure 3 As shown, the configuration method provided in the embodiment of the present application may include:

[0077] S301: The electronic device is powered on and the PBL program is running.

[0078] When the electronic device is powered on, processor 110 executes the PBL program. The PBL program's primary task is to initialize the hardware environment and ensure that essential system resources (such as clocks, memory controllers, and power management) are available. Processor 110 reads the PBL program from internal memory 120, loads it into memory, and begins execution.

[0079] The PBL program can also include a basic memory mapping table. The memory mapping table is used to describe the layout of the system memory. The memory mapping table records the physical memory areas in the electronic device and their uses, so that subsequent programs and operating systems can correctly manage and access these memory areas. As an example, the memory mapping table includes the starting address (the starting physical address of the memory area), length (the size of the memory area), type (the purpose or attributes of the memory area, such as available memory, reserved memory, and device memory), and attributes (further describing the characteristics of the memory area, such as read / write permissions, caching policy, etc.).

[0080] By running the PBL program after the electronic device is turned 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] When the PBL program is finished running, it triggers the running of the next stage boot loader program, that is, after the PBL program is finished running, it triggers the running of the XBL program.

[0082] As an example, when executing a PBL program, processor 110 reads the XBL image program of the XBL program from internal memory 120 and loads it into random access memory (RAM), allowing processor 110 to directly run the XBL program. It should be noted that the storage address of the XBL image program matches the link address of the XBL program to ensure that the XBL program can run properly.

[0083] S302: XBL program runs.

[0084] After the PBL program completes initial boot and releases control, processor 110 executes the XBL program. The PBL program's configuration scope and depth are limited, ensuring the system can operate normally until the XBL is loaded. Therefore, during the XBL program's execution, 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 the operating system startup.

[0085] The XBL program configures the system clock and power management unit to ensure the proper functioning of all hardware components. It also initializes key 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 detailed initialization and configuration for different hardware types. For example, it loads storage device drivers to ensure access and operation of different types of storage devices; loads input / output device drivers to initialize and configure input and output devices (such as keyboards, mice, and monitors); and loads network device drivers to initialize network interfaces for network-related operations.

[0086] After hardware and driver configuration, XBL also needs to configure the system environment and set the necessary startup parameters for the operating system to be started, such as command line parameters, startup mode, etc. 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 some low-power tasks. The AOP subsystem can continue to operate even when the main processor is in sleep or low-power mode, handling various low-power tasks. Examples include power state management (managing the device's different power states, such as sleep, hibernation, and deep sleep), power domain control (controlling the on / off 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 the various sensors in the system. It 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 (periodic reading of 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 real-time tasks that require fast response times. These tasks do not require the main processor's participation, which can improve the system's response speed and efficiency. For example, scheduled tasks: executing periodic scheduled tasks (such as maintaining the system clock and triggering periodic events) and interrupt handling (handling simple hardware interrupts to reduce the burden on the main processor).

[0091] TrustZone uses hardware-supported isolation mechanisms to divide the system into a secure world and a non-secure world, isolating sensitive data and applications to prevent malicious code attacks. TrustZone stores the AOP subsystem's access rights to the AOSS_CC registers (and, consequently, AOP111's access rights to the AOSS_CC registers). These rights can be defined by access control lists (ACLs), which are stored in the secure world.

[0092] The TrustZone configuration process involves configuring the security mechanism, setting up the isolation between the secure and non-secure worlds, and configuring basic permission management. During the configuration process, TrustZone also requires configuring xPU rules to implement memory access control. This includes defining the access permissions and attributes (e.g., read / write permissions) for each memory region.

[0093] It should be noted that during the TrustZone configuration process, the xPU may be in the configuration state or may have been configured and is in the startup state. When the TrustZone configuration is complete, the xPU is adjusted to the enabled state. If the TrustZone configuration fails, the xPU may also fail to configure or may have been configured and is in the startup state.

[0094] In an embodiment of the present application, a status flag is set for TrustZone, and the status flag is used to indicate the current configuration status of TrustZone, including configuring, configuration completed, and configuration failed. If the status flag is configuring, it indicates that TrustZone is still in the configuration process and has not yet been completed. At this time, the xPU may be in configuration; if the status flag is configuration completed, it indicates that TrustZone has completed configuration. At this time, the xPU configuration is complete and is in the enabled state; if the status flag is configuration failed, it indicates that the TrustZone configuration failed. At this time, the xPU may have failed to configure or may have completed configuration and is in the enabled state. However, due to the failure of TrustZone configuration, the AOP subsystem cannot obtain access rights to the AOSS_CC register from TrustZone, and still cannot read configuration parameters from the AOSS_CC register through the xPU.

[0095] TrustZone stores the AOP subsystem's access permissions to specific registers (i.e., registers storing configuration parameters). During the TrustZone configuration process, an access control list (ACL) for the AOP subsystem is defined, listing the AOP subsystem's permissions to the AOSS_CC register. This ACL is then stored in a secure storage area within TrustZone to prevent tampering.

[0096] The AOP subsystem configuration process includes configuring the AOP subsystem's hardware and software environment, including setting the AOP subsystem's clock source, memory controller, and power management unit. After configuration is complete, the AOP subsystem retrieves configuration parameters from the AOSS_CC register. These parameters include various AOP subsystem operating parameters, such as scheduled task intervals and sensor acquisition frequency.

[0097] In one possible implementation, the AOP subsystem and TrustZone can be configured synchronously during the running of the XBL program. The AOP subsystem is responsible for managing low-power and real-time tasks, while TrustZone provides a hardware-isolated secure execution environment. If the two are configured synchronously, the overall startup time may be reduced. During the TrustZone configuration process, the AOP subsystem can first configure the hardware and software environment. After the TrustZone configuration is completed, the AOP subsystem completes the subsequent configuration process. The overall configuration time is equal to the sum of the time consumed by the TrustZone configuration and the time consumed by the AOP subsystem to complete the parameter configuration. The time consumed by the AOP subsystem to complete the parameter configuration includes the time it takes for the AOP subsystem to access the TrustZone to obtain access rights to the AOSS_CC register, the time it takes for the AOP subsystem to access the AOSS_CC register through the xPU to obtain configuration parameters, and the time it takes for the AOP subsystem to complete the configuration according to the configuration parameters.

[0098] In another possible implementation, during the running of the XBL program, TrustZone is configured first, and after a second time, the AOP subsystem is configured. The second time can be determined based on the time it takes to configure TrustZone. During the configuration of the AOP subsystem, it is necessary to access TrustZone to obtain access rights, and it is necessary to access the AOSS_CC register through the xPU. Therefore, TrustZone can be configured first so that when the AOP subsystem accesses TrustZone, TrustZone has been configured, shortening the waiting time or configuration time of the AOP subsystem. In addition, this configuration method reduces resource competition and race conditions, and reduces the complexity of synchronization operations.

[0099] In an embodiment of the present application, in order to avoid the system crash caused by the AOP subsystem accessing the configured xPU, and to avoid the configuration failure caused by the AOP subsystem being unable to obtain access rights from the incompletely configured TrustZone, the AOP subsystem first queries the configuration status of the TrustZone before accessing the xPU, and then performs subsequent processing based on the configuration status of the TrustZone.

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

[0101] The embodiments of the present application add a status flag to TrustZone to indicate the configuration status of TrustZone, so that other programs or systems can know the configuration status of TrustZone. It should be noted that even if the TrustZone configuration is not complete, other programs or systems can still query the status flag. The configuration status of TrustZone includes three states: configuration completed, configuring, and configuration failed. Among them, "configuration in progress" and "configuration failed" can be collectively referred to as incomplete configuration.

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

[0103] In another possible implementation, Figure 5 In the software architecture shown, the AOP subsystem is connected to TrustZone through xPU. The AOP subsystem needs to query the status flag of TrustZone through xPU. However, if TrustZone is not configured, xPU may not be configured; or the AOP subsystem cannot obtain access rights to the AOSS_CC register, the AOP subsystem will fail to query. In response to this situation, the embodiment of the present application provides a software architecture, such as Figure 6 As shown in the figure, a new status detection module is added between the AOP subsystem and TrustZone. This status detection module can directly query the TrustZone status flag, and the AOP subsystem can also directly access the status detection module. By accessing the status detection module, the AOP subsystem can bypass the xPU to confirm the TrustZone status, avoiding system crashes caused by the AOP subsystem calling the xPU during xPU configuration.

[0104] If the AOP subsystem determines that the configuration status of TrustZone is after configuration is completed, step S305 is executed; if the AOP subsystem determines that the configuration status of TrustZone is in configuration or configuration fails, step S307 is executed.

[0105] S305: The AOP subsystem accesses TrustZone to obtain access rights 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 rights to the AOSS_CC register. The access permission request is used to request access rights to the AOSS_CC register (such as read and write permissions). As an 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 the xPU, which also improves the security of requests and data transmission.

[0107] After receiving the access permission request from the AOP subsystem, TrustZone can perform a permission audit on the AOP subsystem, such as verifying the identity of the AOP subsystem and the validity of the request. If the audit passes, TrustZone grants the AOP subsystem the corresponding access permission and sends the access token or key to the AOP subsystem.

[0108] S306: The AOP subsystem accesses the AOSS_CC register through the xPU according to the access rights to obtain configuration parameters and perform configuration.

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

[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 based on the AOSS_CC register address and access type. If the access type is read, the AOP subsystem configuration parameters are read from the AOSS_CC register and fed back to the AOP subsystem.

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

[0112] Specifically, the AOP subsystem parses the configuration parameters read from the AOSS_CC register and, based on the parsed parameters, adjusts the AOP subsystem's internal settings or states. These adjustments can include adjusting clock frequencies, modifying power state transition strategies, and configuring security monitoring parameters. The AOP subsystem can then verify the configuration by testing programs or monitoring system operating status to ensure the correctness of the modified configuration and stable system operation. After configuration is complete, the AOP subsystem feeds the configuration results back to TrustZone or other system modules to ensure overall system consistency.

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

[0114] If the AOP subsystem queries the TrustZone configuration status and the result is "Configuring" or "Configuration Failed", it needs to enter the 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 an embodiment of the present application, a reasonable first time is set based on the expected configuration time of TrustZone. The first time refers to the interval from the last time the AOP subsystem queried the TrustZone configuration status and the result was "configuring" or "configuration failed" to the next time the AOP subsystem queries the TrustZone configuration status. The first time 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. Within the first time, the AOP subsystem enters a waiting mode and stops issuing access permission requests to TrustZone or querying the configuration status of TrustZone.

[0116] After the first time has passed, step S304 is executed again, and the AOP subsystem queries the configuration status of TrustZone again. If this query determines that TrustZone configuration is complete, step S305 is executed; if this query still determines that TrustZone is in configuration or configuration fails, step S307 is executed again.

[0117] In an embodiment of the present application, the AOP subsystem can be made to re-execute step S304 through a fault repair module. Specifically, the fault repair module and the status detection module, when the AOP subsystem queries the TrustZone configuration status through the status detection module, the status detection module synchronously informs the fault repair module of the configuration status of TrustZone. When the fault repair module determines that TrustZone is in configuration, it starts timing, and after the first time has passed, it triggers the AOP subsystem to re-execute step S304. When the fault repair module determines that the TrustZone configuration has failed, it starts timing and triggers TrustZone to reconfigure, and after the first time has passed, 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 appropriate initial times and timing mechanisms, the AOP subsystem can continuously check the TrustZone configuration status without wasting resources. After a delay, when requerying, TrustZone may already have completed configuration. This not only increases the probability of successful queries but also reduces unnecessary error reports.

[0119] In one possible scenario, if the AOP subsystem repeatedly queries and finds that the TrustZone is in a configuration or configuration failure state—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 and testing module captures and records the error and then reports it to the system. This error capture and recording facilitates subsequent troubleshooting and recovery, allowing developers to quickly locate the root cause of the problem based on the error log. Furthermore, by establishing an early warning mechanism for query counts, the system can effectively improve its ability to monitor and manage the TrustZone configuration process, thereby enhancing overall stability and reliability.

[0120] Based on the above embodiment, the configuration method is introduced from the perspective of software and hardware combination. Figure 7 As shown, the method includes:

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

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

[0123] The TrustZone status flags include configuration complete, configuration in progress, and configuration failed, which represent three different TrustZone states. Different processing flows correspond to different TrustZone states.

[0124] When the status flag indicates that the configuration is completed, step S703 is executed; when the status flag indicates that the configuration is in progress, step S705 is executed; when the status flag indicates that the configuration fails, step S708 is executed.

[0125] S703: The status detection module informs the AOP 111 that the configuration status is configuration completed.

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

[0127] After the AOP 111 determines that the TrustZone configuration is complete, it may request access rights to the AOSS_CC register from the TrustZone. For details, please refer to the description of step S305.

[0128] S705: AOP111 accesses the AOSS_CC register through xPU113 according to the access rights to obtain configuration parameters.

[0129] AOP 111 obtains the access order, and can access the AOSS_CC register through xPU 113 to obtain configuration parameters, and then perform the configuration process according to the configuration parameters. For details, please refer to the relevant description of step S306.

[0130] S706: The status detection module informs the AOP 111 and the fault repair module that the configuration status is configuring.

[0131] After confirming that the TrustZone configuration status is configuring, the fault recovery module determines whether the number of times AOP 111 has queried the TrustZone configuration status is greater than a preset value N. In other words, it determines whether the number of times AOP 111 has executed step S701 is greater than the preset value N. If the number of times AOP 111 has queried the TrustZone configuration status is greater than the preset value N, step S707 is executed; if the number of times AOP 111 has queried the TrustZone configuration status is less than or equal to the preset value N, 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 recovery module directly reports an error to the untested module.

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

[0135] If the number of times that the AOP 111 queries the TrustZone configuration status exceeds a preset value N, after a first time, the fault recovery module triggers the AOP 111 to re-query the TrustZone configuration status, ie, re-execute step S701.

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

[0137] After the fault recovery module confirms that the TrustZone configuration status is configuring, it executes step S710 to trigger TrustZone reconfiguration. It also determines whether the number of times AOP 111 has queried the TrustZone configuration status is greater than a preset value N, that is, whether the number of times AOP 111 has executed step S701 is greater than the preset value N. If the number of times AOP 111 has queried the TrustZone configuration status is greater than the preset value N, it executes step S711. If the number of times AOP 111 has queried the TrustZone configuration status is less than or equal to the preset value N, it executes step S7012.

[0138] S710: The fault recovery 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 recovery module directly reports an error to the untested module.

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

[0142] If the number of times that the AOP 111 queries the TrustZone configuration status exceeds a preset value N, after a first time, the fault recovery module triggers the AOP 111 to re-query the TrustZone configuration status, ie, re-execute step S701.

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

[0144] This application does not impose any special restrictions on the specific form of the above electronic device. In this embodiment, the structure of the electronic device can be as follows: Figure 1As shown. It will be 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 shown, or combine or separate certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0145] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein:

[0146] A memory storing instructions; a processor coupled to the memory, wherein when the program instructions stored in the memory are executed by the processor, the electronic device executes the configuration method described in any one of the above embodiments.

[0147] An embodiment of the present application also provides a computer storage medium, which stores computer instructions. When the computer instructions are executed on a terminal, the terminal executes the above-mentioned related method steps to implement the configuration method in the above-mentioned embodiment.

[0148] The embodiment of the present application further provides a computer program product, which, when executed on a computer, enables the computer to execute the above-mentioned related steps to implement the configuration method in the above-mentioned embodiment.

[0149] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory to enable the chip to execute the configuration method in the above-mentioned method embodiments.

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

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

[0152] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

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

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

[0155] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A configuration method, characterized in that: The method comprises: Trigger the real-time response processor AOP and the trusted execution environment TrustZone for configuration; querying the configuration status of the TrustZone, and when the configuration status indicates that the TrustZone configuration is complete, reading the configuration parameters of the AOP through an embedded memory protection unit xPU; the xPU is in an enabled state after the TrustZone configuration is complete; The configuration of the AOP is completed according to the configuration parameters.

2. The method according to claim 1, characterized in that When the configuration state indicates that the TrustZone configuration is complete, reading the configuration parameters of the AOP through the embedded memory protection unit xPU includes: When the configuration state indicates that the TrustZone configuration is complete, obtaining access rights to registers from the TrustZone; The configuration parameters are read from the register via the xPU based on the access permission.

3. The method according to claim 1, characterized in that Querying the configuration status of the TrustZone includes: The status flag of the TrustZone is queried through a 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.

4. The method according to claim 3, characterized in that When the configuration state indicates that the TrustZone configuration is complete, reading the configuration parameters of the AOP through the embedded memory protection unit xPU includes: When the status flag indicates that configuration is complete, obtaining access rights to registers from the TrustZone through the xPU; The configuration parameters are read from the register via the xPU based on the access permission.

5. The method according to claim 1, wherein The method further comprises: If the configuration status indicates that the TrustZone configuration is not complete, the configuration status of the TrustZone is requeried after a first period of time.

6. The method according to claim 5, characterized in that When the configuration status is Configuring or Configuration Failed, it indicates that the TrustZone configuration is incomplete; The method further comprises: If the configuration status is configuration failure, the TrustZone is triggered to reconfigure.

7. The method according to claim 5, characterized in that The method further comprises: If the number of queries for the TrustZone configuration status reaches a preset value, the configuration failure is recorded.

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

9. The method according to any one of claims 1 to 7, characterized in that: The triggering of the real-time response processor AOP and the trusted execution environment TrustZone is configured, including: The TrustZone is triggered to perform configuration, and after a second time has passed since the TrustZone was triggered to perform configuration, the AOP is triggered to perform configuration; the second time is determined according to the time taken for the TrustZone configuration.

10. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: If the AOP configuration fails, the reason for the AOP configuration failure is recorded.

11. An electronic device comprising: a memory storing instructions; A processor is coupled to the memory, and when the program instructions stored in the memory are executed by the processor, the electronic device executes the configuration method according to any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by the electronic device, the configuration method according to any one of claims 1 to 10 is implemented.

Images