Equipment management method and device and electronic equipment

Abstract

The invention discloses an equipment management method and device and electronic equipment, and relates to the technical field of computers.The method comprises the steps that under the condition that a task processing request is received, a component cooperation requirement, a task processing requirement and an operation range corresponding to a to-be-executed work task are determined; determining an authority level corresponding to the work task according to the component cooperation demand, the task processing requirement and the operation range; setting a working mode of the RISC-V architecture according to the authority level and the task execution state of the working task; wherein the permission hierarchy comprises a first permission hierarchy and / or a second permission hierarchy; the first permission level comprises an operation permission corresponding to an operation system in the RISC-V architecture; the second permission level comprises operation permissions corresponding to the processor components in the RISC-V architecture.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a device management method, apparatus and electronic device. Background Technology

[0002] With its open-source and scalable characteristics, the RISC-V architecture has been widely used in embedded systems, the Internet of Things (IoT), edge computing, and high-performance computing. As smart devices increasingly demand longer battery life, faster real-time response, and enhanced security, power management has become one of the core areas of optimization for the RISC-V architecture.

[0003] Traditional RISC-V architecture power management primarily relies on operating system-led software mechanisms for access control and mode switching. At the access control level, it employs a traditional privileged hierarchy (such as user mode / kernel mode). The operating system manages hardware resources uniformly through software drivers, and processor components can only passively execute tasks under the operating system's scheduling, lacking independent operational privileges. At the operating mode switching level, mode switching depends on the operating system's layer-by-layer calls, and hardware components cannot autonomously control their power consumption.

[0004] Traditional power management solutions are limited by operating system software, resulting in low processing efficiency and poor energy-saving effects. Summary of the Invention

[0005] This application provides at least one device management method, apparatus, and electronic device.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a device management method, the method comprising:

[0008] Upon receiving a task processing request, determine the component collaboration requirements, task processing requirements, and operation scope corresponding to the work task to be executed;

[0009] Based on the component collaboration requirements, task processing requirements, and operational scope, determine the permission level corresponding to the work task;

[0010] Set the working mode of the RISC-V architecture according to the permission level and the task execution status;

[0011] The permission levels include a first permission level and / or a second permission level; the first permission level includes the operating permissions corresponding to the operating system in the RISC-V architecture; the second permission level includes the operating permissions corresponding to the processor components in the RISC-V architecture.

[0012] Secondly, embodiments of this application provide a device management apparatus, the apparatus comprising:

[0013] The determination module is used to determine the component coordination requirements, task processing requirements, and operation scope corresponding to the work task to be executed upon receiving a task processing request.

[0014] The hierarchy determination module is used to determine the permission level corresponding to the work task based on the component collaboration requirements, task processing requirements, and operation scope.

[0015] The mode setting module is used to set the working mode of the RISC-V architecture according to the permission level and the task execution status.

[0016] The permission levels include a first permission level and / or a second permission level; the first permission level includes the operating permissions corresponding to the operating system in the RISC-V architecture; the second permission level includes the operating permissions corresponding to the processor components in the RISC-V architecture.

[0017] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement some or all of the steps in the above-described method.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method.

[0019] Fifthly, embodiments of this application provide a computer program product, wherein when a computer program or instruction is executed by a processor, it implements some or all of the steps in the above-described method.

[0020] The device management method provided in this application divides the operation permissions of the RISC-V architecture into a first permission level and a second permission level, thereby achieving permission isolation between the corresponding operation permissions of the operating system and the processor components. This prevents the operating system from mistakenly operating the processor components due to software vulnerabilities. At the same time, the second permission level corresponding to the processor components can independently execute their corresponding tasks and autonomously trigger the switching of the RISC-V architecture's working mode without waiting for operating system scheduling. This reduces the context overhead of mode switching and helps improve the response speed of the processor components. While ensuring the real-time response of tasks, it avoids the risk of permission overstepping, achieving the dual effect of hardware resource protection and task decoupling. This improves the task processing efficiency of the RISC-V architecture while saving power consumption. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0022] Figure 1 A flowchart illustrating a device management method provided in an embodiment of this application;

[0023] Figure 2 A schematic diagram illustrating mode switching of a RISC-V architecture provided in an embodiment of this application;

[0024] Figure 3 A flowchart illustrating another device management method provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram of the composition structure of a device management apparatus provided in an embodiment of this application;

[0026] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] In the following description, references to "some embodiments" are made, which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0030] This application provides a device management method that can be executed by a Central Processing Unit (CPU) in a RISC-V architecture. The RISC-V architecture refers to electronic devices using RISC-V, such as servers, computer equipment, industrial control equipment, autonomous driving equipment, smart IoT devices, and edge computing devices. Computer equipment may include single-board computers, laptops, tablets, etc. Smart IoT devices may include smart speakers, robotic vacuum cleaners, etc.

[0031] Reference Figure 1 The diagram illustrates a flowchart of a device management method provided in an embodiment of this application. Figure 1 As shown, the method may specifically include the following steps:

[0032] Step S101: Upon receiving a task processing request, determine the component collaboration requirements, task processing requirements, and operation scope corresponding to the work task to be executed;

[0033] Step S102: Determine the permission level corresponding to the work task based on the component collaboration requirements, task processing requirements, and operation scope;

[0034] Step S103: Set the working mode of the RISC-V architecture according to the permission level and the task execution status of the task.

[0035] The permission levels include a first permission level and / or a second permission level; the first permission level includes the operating permissions corresponding to the operating system in the RISC-V architecture; the second permission level includes the operating permissions corresponding to the processor components in the RISC-V architecture.

[0036] It should be noted that the RISC-V architecture in this embodiment includes a central processing unit (CPU), an operating system, and processor components. The operating system is the "global scheduling center" of the RISC-V architecture, primarily used to coordinate global resources and manage non-real-time or low-priority tasks. Processor components refer to hardware modules in the RISC-V architecture that focus on specific real-time functions and can operate independently, typically working in conjunction with the CPU. For example, processor components may include an analog-to-digital converter (ADC) controller, a pulse width modulation (PWM) controller, a communication controller, a timer or counter module, a direct memory access (DMA) controller, and so on. The CPU is the RISC-V core of the RISC-V architecture. As the core processing unit, it executes tasks with corresponding permissions at both the operating system level and the processor component level, and is subject to the permission control of these two levels. For example, when the operating system level schedules global tasks and the processor component level executes real-time tasks, the CPU, as the core, undertakes the computational operations.

[0037] In this embodiment, the operational permissions of the RISC-V architecture are divided into a first permission level and a second permission level. The first permission level can also be referred to as the operating system level, which includes the operational permissions corresponding to the operating system; the second permission level can also be referred to as the processor component level, which includes the operational permissions corresponding to the processor component.

[0038] For example, the first permission level may include global control permissions, the scope of which can cover global resources, system core configuration, and cross-component collaboration within the RISC-V architecture. For instance, the first permission level may include global resource allocation permissions, system core configuration permissions, cross-component collaborative scheduling permissions, system permissions and update permissions, and non-real-time task management permissions. Global resource allocation permissions may include allocating memory space, such as partitioning independent memory partitions for tasks like user interface display, historical data storage, and network communication to prevent resource conflicts; or, global resource allocation permissions may include allocating peripheral interfaces, such as assigning global peripherals like Ethernet ports and USB ports to specific applications, or assigning a USB port to a data export tool, and so on. System core configuration permissions can include modifying the RISC-V kernel mode, such as switching the CPU from user mode (U-mode) to supervisor mode (S-mode) to perform system-level operations; alternatively, they can include configuring the interrupt controller, such as setting the priority of system-level interrupts, for example, setting the priority of power failure interrupts to be higher than that of keyboard input interrupts; or, they can include initializing hardware, such as initializing global hardware such as the memory controller and clock module when the RISC-V architecture starts up, to ensure that the architecture can operate normally. Cross-component collaborative scheduling permissions can include coordinating ADC sampling and data storage, such as instructing the ADC controller (processor component) to complete sampling and triggering the CPU to write data to the hard disk; or, they can include scheduling motor control and status monitoring, such as synchronously calling the temperature sensor (processor component) to monitor the motor temperature while the motor is running, and pausing the motor if the temperature exceeds a threshold, and so on. System security and update permissions can include verifying and executing system firmware updates, such as verifying the signature of the new firmware to prevent malicious code injection; or, system security and update permissions can include setting permission isolation, such as prohibiting user-level tasks (such as user-facing applications) from accessing kernel memory; or, system security and update permissions can include clearing global logs, such as deleting sensitive logs (such as permission change records) during system operation, and so on. Non-real-time task management permissions can include initiating the generation of historical data reports, such as scheduling the CPU to collect and generate reports of the past 24 hours of operating data during motor control intervals; or, non-real-time task management permissions can include responding to remote management commands, such as receiving commands or requests from the host computer, such as device parameter query requests, integrating data from various components, and returning the results, and so on.

[0039] The second permission level corresponds to the real-time task execution and local hardware control of the processor components. The scope of permissions is limited to the processor components and directly associated hardware (such as sensors and lower-level devices), and must meet the real-time task requirements of "low latency and high responsiveness." For example, the second permission level may include sampling permissions for the ADC controller, related permissions for the PWM controller, related permissions for the communication controller, related permissions for the DMA controller, and related permissions for the timer module. Specifically, the ADC controller's sampling permissions may include starting or stopping sampling, configuring sampling parameters (such as sampling accuracy and sampling frequency), and reading sampling results. The PWM controller's related permissions may include setting PWM parameters (such as pulse frequency and duty cycle), output adjustment permissions (such as immediately modifying the PWM duty cycle based on motor speed feedback), and triggering motor protection. The communication controller's related permissions may include configuring communication parameters (such as baud rate, data bits, and stop bits), data transmission and reception permissions, and triggering communication interrupts. The DMA controller's related permissions may include setting data transmission paths, starting or pausing transmission, and reading transmission status. The timer module's related permissions may include setting the timing period, starting a timer interrupt, and resetting the timer.

[0040] This application embodiment achieves physical isolation of operation permissions by dividing the operation permissions of the RISC-V architecture into a first permission level and a second permission level, which can prevent the operating system from accidentally operating the processor components due to software vulnerabilities. The first permission level ensures the orderly management of the global resources and system core configuration of the RISC-V architecture by the operating system, while the second permission level meets the real-time task requirements of the processor components, thus achieving a balance between global stability and local efficiency.

[0041] After receiving a task processing request, the RISC-V architecture can first analyze the component coordination requirements, task processing requirements, and operation scope of the task to be executed, and then determine the permission level corresponding to the task based on the component coordination requirements, task processing requirements, and operation scope.

[0042] The component collaboration requirement is used to determine whether a task requires cross-component collaboration. For example, tasks can be categorized into cross-component tasks and single-component tasks based on whether cross-component collaboration is required. If a task requires the cooperation of two or more processing components or modules, it is determined to be a cross-component task; if a single component can complete the task independently, it can be determined to be a single-component task.

[0043] Task processing requirements can include real-time requirements, computing power requirements, etc. For example, based on real-time requirements, tasks can be divided into real-time tasks and non-real-time tasks; based on computing power requirements, tasks can be divided into high-computing-power tasks and regular tasks. For instance, if a task requires a response time in milliseconds or microseconds, it is determined to be a real-time task; if a task allows a response time in seconds, it is determined to be a non-real-time task.

[0044] The scope of operation is used to reflect the resource impact of a task, such as whether it involves system security or core configuration, or whether it involves global resource allocation.

[0045] In some embodiments, the task permission level can be quickly determined by following these steps:

[0046] The first step is to examine the scope of operation. If the task's scope involves memory, global peripherals (such as hard drives and Ethernet ports), or system core configurations (such as kernel mode), it is directly classified as the first level of access control. If the task's scope only involves the hardware parameters of a single processor component, such as ADC sampling accuracy or PWM duty cycle, proceed to the second step.

[0047] The second step is to examine the task processing requirements. If the task requires a millisecond or microsecond response, such as emergency protection or real-time control, it is classified as a second-level permission task. If the task allows a second-level response, such as data statistics or report generation, it is classified as a non-real-time task. Proceed to the third step.

[0048] The third step is to examine the component collaboration requirements. If the task is a cross-component task that requires the cooperation of two or more modules, such as a task involving the entire process of sampling, transmission, and storage, it is classified as the first permission level. If the task is a single-component task that can be completed independently by a single component, such as reading UART data or configuring timers, it is classified as the second permission level.

[0049] For example, for non-real-time tasks or global management tasks, their corresponding permission level can be determined as the first permission level; for real-time tasks, their corresponding permission level can be determined as the second permission level. For instance, resource allocation tasks involve global resource allocation, requiring ensuring that the allocated memory partition does not overlap with other tasks (such as motor control or data storage) to avoid global resource conflicts. The operations of these tasks affect global resources and require unified scheduling by the operating system, thus determining their corresponding first permission level. For hardware parameter configuration tasks, such as "configuring the sampling precision of the ADC controller to 12 bits," this task only needs to adjust the ADC's own register parameters and does not affect the operation of memory or other peripherals (such as PWM or UART). The corresponding operations only act on local processing components and do not require global control, corresponding to the second permission level. For emergency control tasks, such as "immediately stop PWM output when motor overcurrent occurs," the task requires stopping the PWM signal within 10 microseconds when overcurrent occurs, otherwise the motor will burn out. This requires high real-time performance and an ultra-fast response. Therefore, it corresponds to the second priority level, allowing the corresponding processor component to directly trigger the RISC-V architecture's operating mode switch for rapid response, without waiting for operating system scheduling. For data statistics tasks, which are non-real-time tasks, such as "generating a motor operation report for the past 24 hours," report generation can be completed during periods of stable motor operation. There is no emergency response requirement, and the operating system can coordinate resources, corresponding to the first priority level. For tasks requiring cross-component collaboration, such as "synchronously storing ADC sampling data to the local hard drive," this task involves the entire process of sampling, transmission, and data transfer, requiring coordination of the ADC (sampled data), DAM (data transmission), and hard drive (global storage peripheral) modules. The operating system needs to schedule the timing of each module, corresponding to the first priority level. For tasks that do not require cross-component collaboration, such as single-component data operation tasks like "reading sensor data received by the UART controller," this task only requires the UART controller to receive serial data from the sensor and directly read the result from its data register, without the involvement of other modules, corresponding to the second permission level. For tasks involving system security or core configuration, such as core system operation tasks like "switching the CPU from user mode (U-mode) to supervisor mode (S-mode) to perform a firmware update," this task requires modification of the underlying system program, and kernel mode switching involves permission upgrades, requiring strict control by the operating system, corresponding to the first permission level. For tasks that only involve component function configuration, such as "setting the timer module's timing period to 50 milliseconds," these tasks only affect component functionality and do not involve system security or core configuration, corresponding to the second permission level.

[0050] In this embodiment, after determining the permission level corresponding to the task, the working mode of the RISC-V architecture can be set according to the permission level and execution status of the task. For the processor component, it can independently execute the corresponding task and autonomously trigger the switching of the RISC-V architecture's working mode without waiting for operating system scheduling, reducing context switching overhead and improving the response speed of real-time tasks.

[0051] It should be noted that the operating modes of the RISC-V architecture can be divided according to actual power management requirements. For example, the operating modes of the RISC-V architecture may include a power mode, a low-power mode, and a power-saving mode. The power mode is used to meet high computing power requirements, the low-power mode is used to balance the energy efficiency and response speed of the RISC-V architecture, and the power-saving mode is used to minimize the standby power consumption of the RISC-V architecture.

[0052] As an example, for tasks corresponding to the first permission level, the RISC-V architecture can be set to low-power mode, and then switched back to power mode after the task is completed. For tasks corresponding to the second permission level, the RISC-V architecture can be set to power mode to meet the low response and high computing power requirements of real-time tasks, achieve rapid local optimization, and trigger a mode switch to enter power-saving mode after the task is completed to reduce standby power consumption.

[0053] Operating systems or processor components can switch the operating modes of the RISC-V architecture via hardware instructions. For example, in a smartwatch, after the motion coprocessor (processor component) completes heart rate data acquisition, it can directly enter a power-saving mode via hardware instructions. At the same time, the operating system level can set the entire device to enter a low-power mode via hardware instructions, avoiding the energy consumption overhead of traditional software layer-by-layer scheduling. In edge computing devices, after the NPU (processor component) completes AI inference tasks, it can immediately trigger the architecture to switch back to a low-power mode via hardware instructions, thereby reducing ineffective standby power consumption.

[0054] The processor unit level can independently execute real-time tasks (such as ADC sampling and motor control) without operating system scheduling, reducing context switching overhead. For example, in industrial automation scenarios, sensor driving (processor unit level) and logic control (operating system level) can run in parallel. After sensor data acquisition is completed, hardware instructions directly trigger operating system processing, ensuring data real-time performance while avoiding the risk of permission violations, achieving the dual effect of hardware resource protection and task decoupling.

[0055] It is understandable that the scope of the hardware instructions called at the operating system and processor component levels is different. The first hardware instruction called by the operating system is used to implement global energy consumption strategies, such as dynamically adjusting the low power threshold according to the system load; the second hardware instruction called at the processor component level is used to implement local fast optimization, such as directly triggering mode switching after the task is completed.

[0056] Alternatively, after determining the permission level corresponding to the task, the permission level can send a mode switching request or mode switching command to the power management module of the RISC-V architecture, requesting the power management module to adjust the working mode of the RISC-V architecture.

[0057] As another example, the real-time task of "immediately stopping PWM output and recording fault data when the motor experiences overcurrent" only involves the PWM controller (processor unit) and the fault register, requiring no global operating system resources and only millisecond-level response, corresponding to the second privilege level. After detecting an overcurrent signal, the PWM controller (processor unit) can directly send a mode switching request to the RISC-V architecture's power management module, requesting a switch from low-power mode (the mode in which the motor was previously running stably) to power mode, without waiting for an operating system response, thus reducing context switching overhead. Upon receiving the request, the power management module immediately switches its operating mode from low-power mode to power mode. Once the PWM controller confirms that the motor has stopped and the fault data has been written to the register (i.e., the task execution status becomes "complete"), it autonomously sends a mode recovery request to the power management module, requesting the module to switch the RISC-V architecture's operating mode from power mode back to low-power mode, restoring the CPU clock frequency and peripheral power supply to balance energy efficiency.

[0058] Alternatively, for non-real-time tasks, such as "generating a motor operation report for the past 24 hours," global resources need to be read, such as sampled data in memory and logs on the local hard drive. This requires operating system scheduling and must be completed within 10 seconds, corresponding to the first priority level. The operating system level (first priority level) makes a global overall judgment. Currently, the processor components (PWM controller, ADC, etc.) at the second priority level are all in a periodic low-load operation state, such as the PWM adjusting once every 10ms and the ADC sampling once every 50ms, which can be scheduled as the global working mode. The operating system sends a mode switching instruction to the power management module to switch the RISC-V architecture's working mode from the power mode (the mode after handling urgent tasks) to the low-power mode. When the report is generated and stored on the hard drive, that is, when the task execution status changes to "completed," the operating system determines that "there are no planned tasks in the next hour" and maintains the low-power mode, which ensures the response speed of motor control while avoiding unnecessary energy consumption.

[0059] Alternatively, if the operating system (first-level privilege tier) detects that all global tasks have been completed, and all processor components report no real-time task requests (i.e., no work tasks triggered at the second-level privilege tier), the operating system can send a standby command to all processor components and a mode-switching command to the power management module. This switches the RISC-V architecture's operating mode to a power-saving mode, achieving global and local coordination and minimizing the RISC-V architecture's standby power consumption. When a work task corresponding to the second-level privilege tier is received, the processor component can directly trigger a wake-up interrupt autonomously without waiting for operating system scheduling. After being woken up by the interrupt, the processor component can directly send a mode-switching request to the power management module, requesting that the RISC-V architecture's operating mode be switched to a low-power mode to restore normal functionality and execute the corresponding work task.

[0060] The device management method provided in this application divides the operation permissions of the RISC-V architecture into a first permission level and a second permission level, thereby achieving permission isolation between the corresponding operation permissions of the operating system and the processor components. This prevents the operating system from mistakenly operating the processor components due to software vulnerabilities. At the same time, the second permission level corresponding to the processor components can independently execute their corresponding tasks and autonomously trigger the switching of the RISC-V architecture's working mode without waiting for operating system scheduling. This reduces the context overhead of mode switching and helps improve the response speed of the processor components. While ensuring the real-time response of tasks, it avoids the risk of permission overstepping, achieving the dual effect of hardware resource protection and task decoupling. This improves the task processing efficiency of the RISC-V architecture while saving power consumption.

[0061] In some embodiments, step S103, setting the working mode of the RISC-V architecture according to the permission level and the task execution status of the task, includes:

[0062] Step S11: When switching between the first and second permission levels, set the working mode of the RISC-V architecture to the first mode.

[0063] Step S12: When the permission level is the first permission level or the second permission level, set the working mode of the RISC-V architecture to the second mode, and after the task is completed, set the working mode of the RISC-V architecture to the first mode.

[0064] The first mode is used to meet high computing power requirements, for example, the first mode can be a power consumption mode; the second mode is used to balance the energy efficiency and response speed of the RISC-V architecture, for example, the second mode can be a low power consumption mode.

[0065] Reference Figure 2This diagram illustrates a mode switching schematic of a RISC-V architecture provided in an embodiment of this application. Figure 2 As shown, when the RISC-V architecture involves task jumps across different permission levels, the operating mode of the RISC-V architecture is forcibly set to either the first mode or the power mode for faster response. For example, when the CPU jumps from a task at the first permission level to execute a task at the second permission level, or vice versa, the operating mode of the RISC-V architecture is directly set to the power mode.

[0066] This application defines that when the RISC-V architecture switches between the first permission level (operating system level) and the second permission level (processor component level), the RISC-V architecture's operating mode is directly forced to switch to a power-saving mode, and cross-level synchronization is achieved through hardware startup signals (such as interrupts and handshake signals). This mechanism eliminates the mode switching delay that traditionally relies on software scheduling, ensuring that critical tasks (such as autonomous driving obstacle avoidance algorithms and UAV emergency braking commands) are activated instantly upon switching, meeting millisecond-level response requirements. For example, in a UAV flight control system, when the obstacle avoidance sensor (processor component level) detects an obstacle and switches to the operating system level to execute path planning, the architecture immediately enters the operating mode, and the CPU seamlessly takes over the computing tasks, avoiding obstacle avoidance failures caused by low-power mode wake-up delays. At the same time, the forced operating mode prioritizes the execution of high-priority tasks, preventing task timeouts caused by resource preemption, which is particularly suitable for scenarios with stringent real-time requirements such as avionics and industrial robots.

[0067] When the task to be executed corresponds to the first or second permission level, the working mode of the RISC-V architecture can be set to the second mode or low-power mode. After the task is completed, the working mode of the RISC-V architecture can be switched back to the first mode or low-power mode.

[0068] For example, the CPU can set the operating mode of the RISC-V scalable architecture based on software operation instructions at the operating system level (first authority level), software operation instructions at the processor component level (second authority level), and hardware operation instructions. Specifically, the operating system level software operation instructions are used to set the RISC-V architecture to a low-power mode based on global energy consumption strategies (such as adjusting low-power thresholds based on system load or setting overall system low power consumption). The processor component level software operation instructions are used to set the RISC-V architecture to a low-power mode, allowing the processor component to continue executing lightweight tasks in low-power mode. The processor component level hardware operation instructions are used to autonomously trigger the processor component to quickly switch the RISC-V architecture's operating mode to low-power mode after the corresponding task has finished executing, without requiring operating system scheduling. It can be understood that when the operating system needs to globally control energy consumption or set overall system low power consumption, it calls the operating system level software operation instructions; when the processor component needs to independently execute lightweight tasks while maintaining its own software operation, it calls its software operation instructions; and when the processor component needs to quickly switch back to power mode after completing its task without operating system intervention, it uses its hardware operation instructions.

[0069] For example, when the task to be executed corresponds to the first permission level (operating system level), software operation instructions at the operating system level set the RISC-V architecture to low-power mode, execute the task, and after the task is completed, set the RISC-V architecture to power mode. When the task to be executed corresponds to the second permission level (processor component level), software operation instructions at the processor component level set the RISC-V architecture to low-power mode, execute the task, and after the task is completed, hardware operation instructions at the processor component level set the RISC-V architecture to power mode.

[0070] It is understood that, in the embodiments of this application, when the processor component level sets the RISC-V architecture to a low-power mode through software operation instructions, the processor component can continue to execute its corresponding work tasks in the low-power mode without interrupting its own task execution due to the architecture entering the low-power mode, so as to achieve the coordination of local task processing and low-power control.

[0071] As an example, suppose the RISC-V architecture is in power mode. The CPU executes tasks corresponding to the second priority level (processor unit level) in power mode, such as real-time tasks like sensor data acquisition and ADC sampling. If the next task to be executed is a task corresponding to the first priority level (operating system level), the processor unit can send a hardware start signal to the operating system. This hardware start signal informs the operating system of the processor unit's task execution status, such as entering a power-saving state upon task completion. This allows the operating system to subsequently send instructions to set the RISC-V architecture to a low-power mode. Through the hardware start signal, operational coordination and state synchronization between the operating system level and the processor unit level can be achieved. After the task corresponding to the second priority level (processor unit level) is completed, the processor unit level enters a power-saving state, effectively setting a portion of the RISC-V architecture (processor unit level) to power-saving mode. After the CPU jumps from the second privilege level to the first privilege level, the operating system sets the RISC-V architecture's working mode to the second mode or low-power mode through software operation instructions. In low-power mode, the CPU executes the work tasks corresponding to the first privilege level (operating system level). After the task is completed, the RISC-V architecture's working mode is set back to the first mode or low-power mode.

[0072] It should be noted that operational coordination and state synchronization between the first authority level (operating system level) and the second authority level (processor component level) can be achieved through the coordination of hardware and software configurations. For example, hardware configuration requires an interrupt controller, handshake signal module, hardware state machine, and register / cache control circuitry, while software configuration requires instruction coordination between the first authority level (operating system level) and the second authority level (processor component level). During mode switching, the hardware automatically saves and restores register values ​​and stack pointers, ensuring cache consistency through hardware mechanisms, and achieving cross-level synchronization through a hardware start signal.

[0073] This application embodiment divides the operation permissions of the RISC-V architecture into a first permission level and a second permission level. The operating mode of the RISC-V architecture is set based on the permission level corresponding to the task to be executed and the task execution status. When the architecture jumps between the first and second permission levels, the operating mode of the RISC-V architecture is directly set to power mode. When jumping from the processor unit level to the operating system level software or vice versa, the operating mode of the RISC-V architecture can be set to low-power mode. When the task in low-power mode is completed, the architecture directly jumps back to the original power mode. Specifically, when the second permission level triggers the RISC-V architecture to set its operating mode to low-power mode, the task corresponding to the processor unit can continue to be executed. When the processor unit sets the RISC-V architecture's operating mode through hardware operation instructions... When the RISC-V architecture operates in low-power mode, it can directly switch back to the original power mode, better adapting to the task processing needs of embedded and IoT devices, such as low-power sensor nodes and battery-powered wearable devices. The RISC-V architecture can be independently controlled to be in low-power mode through a second level of access, reducing operating system intervention. It is also suitable for edge computing and real-time systems, such as industrial automation controllers and autonomous driving assistance systems. Hardware operation commands can be used to directly trigger the RISC-V architecture to be in low-power mode or trigger the automatic switching mechanism of power mode to meet real-time requirements. At the same time, in fields such as heterogeneous computing and AIoT, aerospace and avionics, data centers and servers, hardware protection, power consumption reduction and critical task computing power can be achieved through hierarchical access and fast mode switching.

[0074] It should be noted that after the task corresponding to the second privilege level is completed, the processor can enter power saving mode. Subsequently, if the operating system sets the entire RISC-V architecture to low power mode based on the global power consumption policy, and if the second privilege level (processor unit level) initiates a task processing request at this time, the CPU will directly jump from power saving mode to working mode to respond to the task processing request and execute the corresponding task.

[0075] Furthermore, when the CPU performs tasks whose operation privileges are limited to the second privilege level (processor component level) and are unrelated to the power consumption mode, the operating mode of the RISC-V architecture can be set to the power consumption mode.

[0076] Reference Figure 3 The diagram illustrates a flowchart of a device management method provided in an embodiment of this application. Figure 3As shown, when the RISC-V architecture jumps from the task corresponding to the first permission level (operating system level) to the task corresponding to the second permission level (processor component level), the RISC-V architecture's operating mode is directly set to power mode. When the operation permission of the task to be executed is limited to the second permission level (processor component level), it is determined whether the task is related to power consumption, such as whether low latency or high computing power is required. If the task is related to power consumption, the power mode is maintained. If the task is not related to power consumption, the RISC-V architecture's operating mode can be set to low-power mode. After the task is completed, if there are no other tasks to be executed, the RISC-V architecture's operating mode can be set to power-saving mode. If there are other tasks to be executed, the RISC-V architecture's operating mode can be directly switched to power mode to ensure the continuity of task processing.

[0077] In some embodiments, step S103, setting the working mode of the RISC-V architecture according to the permission level and the task execution status of the task, includes:

[0078] Step S21: Invoke device control commands according to permission level and task execution status; device control commands are used to set the working mode of RISC-V architecture.

[0079] Step S22: Based on the permission registers corresponding to the operating system and processor components, determine whether the permission level includes the permission to call device control instructions;

[0080] Step S23: If the permission level includes the permission to call device control commands, set the working mode of the RISC-V architecture based on the device control commands;

[0081] Step S24: If the permission level does not include the permission to call device control commands, determine that the current call for device control commands is invalid.

[0082] In this embodiment, the permission settings for the operating mode of the RISC-V architecture can be controlled by the permission register at the first permission level (operating system level) and the second permission level (processor component level).

[0083] Specifically, in this embodiment, permission registers are configured for the first permission level (operating system level) and the second permission level (processor component level). By configuring the permission registers, the device control instruction calling permissions are assigned to the first permission level and the second permission level. The device configuration instructions are used to set the working mode of the RISC-V architecture.

[0084] As an example, a common permission register can be configured for the first permission level (operating system level) and the second permission level (processor component level). Corresponding level labels or level IDs can be configured for each level. By changing the level label or level ID in the permission register, the permission to invoke device control commands can be granted to either the first permission level (operating system level) or the second permission level (processor component level). For example, assuming the level ID corresponding to the first permission level is "01" and the level ID corresponding to the second permission level is "02", when the ID number in the permission register is "01", it is determined that the first permission level has the permission to invoke device control commands; when the ID number in the permission register is "02", it is determined that the second permission level has the permission to invoke device control commands; when the ID number in the permission register contains both "01" and "02", it is determined that both the first and second permission levels have the permission to invoke device control commands.

[0085] As another example, corresponding permission registers can be configured for the first permission level (operating system level) and the second permission level (processor component level). In other words, in some embodiments, the permission registers in this application include a first permission register corresponding to the operating system and a second permission register corresponding to the processor component.

[0086] If the first permission level is included in the permission level, and the first permission register contains the identification information of the RISC-V architecture, then it is determined that the permission level (i.e. the first permission level) contains the permission to call device control instructions.

[0087] If the permission level includes a second permission level, and the second permission register contains identification information for the RISC-V architecture, then it is determined that the permission level (i.e., the second permission level) contains the permission to call device control instructions.

[0088] In this embodiment, the identification information of the RISC-V architecture, such as the ID number, is written into the corresponding permission registers. Combined with hardware mechanisms such as bus arbitration and register access control, the access permission for calling device control instructions is restricted between the first permission level (operating system level) and the second permission level (processor component level). If a permission level currently does not have the permission to call device control instructions, the call fails, thus ensuring that both the first and second permission levels can legally call device control instructions to set the operating mode of the RISC-V architecture.

[0089] In some embodiments, the device control instructions include a first control instruction and / or a second control instruction; the first control instruction is used to set the global operating mode of the RISC-V architecture; the second control instruction is used to set the operating mode of the processor component. A first permission level includes the access permission to call the first control instruction; a second permission level includes the access permission to call the second control instruction.

[0090] In this embodiment, corresponding device control instructions can be pre-configured for the first permission level (operating system level) and the second permission level (processor component level) to limit the operating scope of each level. During the RISC-V architecture power-on initialization phase, basic configurations can be performed on the first permission register (operating system exclusive) and the second permission register (processor component exclusive) based on the corresponding device control instructions for the first permission level (operating system level) and the second permission level (processor component level), providing a basis for subsequent permission judgments.

[0091] For example, assume the first privilege register is OS-REG and the second privilege register is PERIPH-REG. The identification information stored in the first privilege register includes a global list of device IDs for the RISC-V architecture, such as the power management module ID: 0x001, memory controller ID: 0x002, operating mode control ID: 0x003, etc. The first privilege register is associated with the operating system (first privilege level) and the bus arbiter, and is used to record the device identifiers corresponding to device control instructions that the operating system can call; only the operating system is allowed to access it. The identification information stored in the second privilege register includes device IDs associated with dedicated processor components, such as the operating mode control sub-IDs corresponding to the PWM controller: 0x003-01, the ADC: 0x003-02, etc. The second privilege register is associated with each processor component (second privilege level) and the bus arbiter, and is used to record the sub-device identifiers corresponding to device control instructions that the processor component can call; only the processor component is allowed to access it.

[0092] In one possible application scenario, the operating system needs to set the RISC-V architecture to power-saving mode via the first device control instruction when the device is in standby (no task). The specific steps are as follows:

[0093] Step 1: Based on the permission level and task status, invoke the first device control instruction. The operating system (first permission level) detects that all global tasks have completed and the processor has no real-time requests, so it needs to set the RISC-V architecture to power-saving mode to reduce standby power consumption. The operating system generates the first device control instruction, with the instruction format including "target device ID (0x003, i.e., working mode control module) + mode parameter (power-saving mode: 0x03) + initiator identifier (OS: 0x0A)", and sends it to the power management module via the system bus.

[0094] Step 2: Verify call permissions based on the first permission register. After receiving the first device control instruction from the operating system, the bus arbiter automatically reads the first permission register (OS_REG) and verifies whether the target device ID (0x003) in the instruction is stored in the OS_REG storage list. If OS_REG contains the working mode control ID: 0x003 (written during initialization), it is determined that the first permission level contains the call permission for the first device control instruction. If OS_REG does not contain this ID (e.g., due to configuration error), it is determined that the permissions are insufficient. In the application scenario of this embodiment, OS_REG stores 0x003, therefore the verification passes.

[0095] Step 3: Execute the first device control instruction to set the operating mode of the RISC-V architecture. The bus arbiter forwards the verified first device control instruction to the power management module. The power management module parses the instruction parameters (0x03 = power saving mode) and performs the following operations: reduce the CPU (RISC-V core) clock to 100MHz, shut down unnecessary core submodules; send power-down instructions to the PWM controller and ADC (preserving register data); only keep the UART wake-up pin powered, and shut down peripherals such as Ethernet and USB, etc. Furthermore, the power management module can provide status feedback after the setting is complete. For example, the power management module returns a "mode switch successful" signal to the operating system, and the operating system records the current operating mode as power saving mode.

[0096] In another possible application scenario, the PWM controller (processor component) needs to autonomously initiate a second device control command when the motor experiences overcurrent (emergency task) to switch the RISC-V architecture's operating mode to a power-saving mode (high computing power). This process does not require operating system scheduling, and the specific steps are as follows:

[0097] Step 1: Based on the permission level and task status, initiate the second device control command. The PWM controller (second permission level) detects that the motor current exceeds the threshold, and the task execution status is "emergency operation." It needs to quickly switch the RISC-V architecture's operating mode to power mode to ensure fault handling computing power. The PWM controller autonomously generates the second device control command, the format of which includes "target sub-device ID (0x003-01, i.e., the PWM-associated operating mode control sub-module) + mode parameter (power mode: 0x01) + initiator identifier (PWM: 0x0B)", and sends it to the power management module via the local bus.

[0098] Step 2: Verify calling permissions based on the second permission register. After receiving the second device control command from the PWM controller, the bus arbiter automatically reads the second permission register (PERIPH_REG) and verifies whether the "target sub-device ID (0x003-01)" in the command is in the storage list of PERIPH_REG. If PERIPH_REG contains the PWM corresponding operating mode control sub-ID: 0x003-01 (written during initialization), it is determined that the second permission level (PWM controller) has the calling permission for this device control command; if PERIPH_REG does not contain this sub-ID, such as only writing the ADC sub-ID 0x003-02, it is determined that the permission is insufficient. In the application scenario of this application embodiment, PERIPH_REG stores 0x003-01, therefore the verification passes.

[0099] Step 3: Execute the second device control command and set the operating mode. The bus arbiter directly forwards the second device control command to the power management module, without going through the operating system, reducing context switching overhead. The power management module parses the command parameters (0x01 = power consumption mode) and performs the following targeted operations (affecting only PWM-related resources): increases the clock frequency of the PWM fault handling core in the CPU to 1GHz (other cores remain at 500MHz to balance power consumption); enables the fault protection submodule of the PWM controller, increasing the power supply to the rated value; temporarily disables peripherals unrelated to PWM, such as the ADC sampling submodule, and prioritizes power allocation, etc. Furthermore, the power management module can provide status feedback after the setting is completed. For example, the power management module returns a "mode switching successful" signal to the PWM controller, and the PWM controller immediately executes the "motor stop + fault data recording" task.

[0100] In another possible application scenario, insufficient permissions at the first or second permission level may cause device control command calls to fail. If a processor component at the second permission level attempts to call device control commands beyond its own permissions, a permission verification failure will be triggered, resulting in the call failing. Taking an ADC controller (processor component) making an unauthorized call to the global power-saving mode as an example, the specific steps may include:

[0101] Step 1: The ADC controller initiates an unauthorized command. For example, the ADC controller (second level of authority) detects that it has no sampling task and mistakenly initiates the first device control command to "set global power saving mode". The command format includes "target device ID (0x003, global working mode control) + mode parameter (0x03) + initiator identifier (ADC: 0x0C)".

[0102] Step 2: Based on the permission register verification, insufficient permissions are determined. The bus arbiter reads the second permission register (PERIPH_REG) and finds that it only stores "the sub-ID corresponding to the ADC: 0x003-02", but not "the global device ID: 0x003". At the same time, the bus arbiter detects that the initiator identifier is "ADC (0x0C)", which does not belong to the first permission level (OS: 0x0A), so it cannot access the first permission register (OS_REG). Finally, it is determined that the second permission level where the ADC controller is located does not contain the permission to call the first device control instruction corresponding to the global power saving mode.

[0103] Step 3: Instruction call failure triggers the security mechanism. The bus arbiter directly discards the unauthorized access instruction from the ADC, without forwarding it to the power management module; simultaneously, it sends an "unauthorized access alarm" to the operating system, which records the alarm log, including information such as the initiating ADC, the target device ID, and a timestamp, to prevent malicious or accidental operations from affecting the entire system. The ADC controller can only execute instructions within its own permissions, such as calling sub-ID 0x003-02 to switch the ADC's local low-power mode, without affecting the overall operating mode.

[0104] This application embodiment verifies the permissions of the first and second permission levels through the permission register, ensuring the legality and security of setting the working mode of the RISC-V architecture at the first and second permission levels. This can effectively prevent unauthorized access and ensure the stability of the RISC-V architecture.

[0105] In some embodiments, the first permission level includes read permission for hardware registers; the second permission level includes both read permission and write permission for hardware registers.

[0106] In this embodiment, the first permission level (operating system level) can only read the hardware registers of the second permission level (processor component level), but cannot modify them; the second permission level (processor component level) components can read and modify the hardware registers. This permission isolation effectively prevents accidental modification of processor component status information due to operating system vulnerabilities or system failures, such as accidentally shutting down critical peripherals, thus improving the stability of the RISC-V architecture.

[0107] In some embodiments, temporary write permissions for hardware registers can be configured for the first permission level (operating system level), which may specifically include the following steps:

[0108] Step S31: Upon receiving a write request from the operating system for a hardware register, perform a security check on the write request;

[0109] Step S32: If the write request passes the security check, configure temporary write permissions for hardware registers in the first permission level, and configure the effective time of the temporary write permissions.

[0110] In this embodiment, the first permission level (operating system level) can be temporarily granted write access to the hardware registers of the second permission level (processor component level) under specific scenarios, such as during system upgrades, to ensure security through a time-limited authorization mechanism.

[0111] For example, the operating system layer (OS layer) can initiate write requests through a hardware security module in security scenarios such as system upgrades and hardware debugging. Write requests require signature verification, such as public / private key verification of firmware upgrade packages. After successful verification, the hardware generates a one-time token containing the operation scope and effective time, temporarily unlocking the write channel of the processor component-level registers. For instance, during firmware upgrades in industrial equipment, the OS layer can modify sensor controller registers to update the firmware after obtaining time-limited authorization. After the effective time (e.g., 10ms) expires, a hardware timer automatically closes the write permission to prevent abuse of permissions. This mechanism, through a "request-verification-time-limited authorization-automatic revocation" process, achieves dynamic and flexible adjustment of permissions while ensuring hardware security. It meets special needs such as system upgrades while ensuring the unbypassable nature of permission revocation through hardware gating circuits, avoiding security risks caused by software vulnerabilities, and ensuring the stability of the RISC-V architecture.

[0112] Furthermore, in this embodiment, an encryption mechanism can be introduced on the basis of hierarchical access control to perform hardware encryption on instructions and data transmitted across levels, such as the AES-GCM algorithm, to prevent data leakage or malicious attacks.

[0113] For example, to address the data transmission security risks between the OS layer and the processor component layer in a hierarchical access control architecture, a hardware-level encryption module can be integrated, employing the AES-GCM algorithm to achieve encrypted transmission of instructions and data across layers. When the OS layer sends an instruction, the hardware encryption module automatically appends a random number (Nonce) to the plaintext, generating ciphertext and an authentication tag before transmitting it via the bus. Upon receiving the instruction, the processor component layer decrypts it using a pre-shared key (a factory-programmed AES-256 key or a temporary session key) and verifies data integrity using the tag. If verification fails, the instruction is discarded and an interrupt is triggered. For instance, in medical devices, physiological data transmitted from a heart rate sensor to the OS layer is encrypted to prevent man-in-the-middle attacks from stealing private information; in avionics scenarios, flight control instructions are encrypted during transmission to ensure they are not tampered with.

[0114] In summary, the device management method provided in this application divides the operation permissions of the RISC-V architecture into a first permission level and a second permission level, thereby achieving permission isolation between the corresponding operation permissions of the operating system and the processor components. This prevents the operating system from mistakenly operating the processor components due to software vulnerabilities. Simultaneously, the second permission level corresponding to the processor components can independently execute their corresponding tasks and autonomously trigger the switching of the RISC-V architecture's working mode without waiting for operating system scheduling. This reduces the context overhead of mode switching, improves the response speed of the processor components, and avoids the risk of permission overreach while ensuring real-time task response. This achieves the dual effect of hardware resource protection and task decoupling, improving the task processing efficiency of the RISC-V architecture while saving power consumption.

[0115] Based on the foregoing embodiments, this application provides a device management apparatus, which includes various modules and units included in each module. It can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0116] Figure 4 This is a schematic diagram of the composition structure of a device management device provided in an embodiment of this application, such as... Figure 4 As shown, the device management device 400 includes: a permission division module 401, a hierarchy determination module 402, and a mode setting module 403, wherein:

[0117] The determination module 401 is used to determine the component coordination requirements, task processing requirements and operation scope corresponding to the work task to be executed when a task processing request is received;

[0118] The hierarchy determination module 402 is used to determine the permission level corresponding to the work task based on the component collaboration requirements, task processing requirements and operation scope.

[0119] The mode setting module 403 is used to set the working mode of the RISC-V architecture according to the permission level and the task execution status of the task.

[0120] The permission levels include a first permission level and / or a second permission level; the first permission level includes the operating permissions corresponding to the operating system in the RISC-V architecture; the second permission level includes the operating permissions corresponding to the processor components in the RISC-V architecture.

[0121] In some embodiments, the mode setting module 403 includes:

[0122] The first setting unit is used to set the working mode of the RISC-V architecture to the first mode when switching between the first permission level and the second permission level.

[0123] The second setting unit is used to set the working mode of the RISC-V architecture to the second mode when the permission level is the first permission level or the second permission level, and to set the working mode of the RISC-V architecture to the first mode after the work task is completed.

[0124] The first mode is used to meet high computing power requirements; the second mode is used to balance the energy efficiency and response speed of the RISC-V architecture.

[0125] In some embodiments, the mode setting module 403 includes:

[0126] The first invocation unit is used to invoke device control instructions based on the permission level and task execution status; the device control instructions are used to set the working mode of the RISC-V architecture.

[0127] The first determining unit is used to determine whether the permission level includes the permission to call device control instructions based on the permission registers corresponding to the operating system and processor components.

[0128] The third setting unit is used to set the working mode of the RISC-V architecture based on the device control instructions, provided that the permission level includes the permission to call device control instructions.

[0129] In some embodiments, the mode setting module 403 further includes:

[0130] The second determining unit is used to determine that the current call to the device control command is invalid when the permission level does not include the permission to call the device control command.

[0131] In some embodiments, the permission register includes a first permission register corresponding to the operating system and a second permission register corresponding to the processor component; the mode setting module 403 further includes:

[0132] The third determining module is used to determine that the permission level includes the permission to call device control instructions if the first permission register contains identification information of the RISC-V architecture when the permission level includes the first permission level.

[0133] The fourth determination module is used to determine, if the second permission register contains identification information of the RISC-V architecture, that the permission level includes the permission to call device control instructions when the permission level includes the second permission level.

[0134] In some embodiments, the device control instructions include a first control instruction and / or a second control instruction; the first control instruction is used to set the global operating mode of the RISC-V architecture; the second control instruction is used to set the operating mode of the processor component.

[0135] The first permission level includes the permission to invoke the first control command; the second permission level includes the permission to invoke the second control command.

[0136] In some embodiments, the first permission level includes read permission for hardware registers; the second permission level includes both read permission and write permission for hardware registers.

[0137] In some embodiments, the device management apparatus 400 further includes:

[0138] The verification module is used to perform security verification on write requests when a write request for a hardware register is received from the operating system.

[0139] The permission configuration module is used to configure temporary write permissions for hardware registers in the first permission level when a write request passes security verification, and to configure the effective time of the temporary write permissions.

[0140] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0141] It should be noted that, in the embodiments of this application, if the above-described data processing method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This 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.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0142] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0143] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0144] This application provides a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device performs some or all of the steps in the above-described method.

[0145] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0146] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0147] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 5 As shown, the electronic device 500 includes: a processor 501, a communication interface 502, and a memory 503, wherein:

[0148] The processor 501 typically controls the overall operation of the electronic device 500. This overall operation may include implementing the device control method provided in the embodiments of this application, for example... Figure 1 The method shown.

[0149] Communication interface 502 enables computer devices to communicate with other terminals or servers via a network.

[0150] The memory 503 is configured to store instructions and applications executable by the processor 501, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 501 and various modules in the electronic device 500. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 501, the communication interface 502, and the memory 503 can be performed via bus 504.

[0151] This application provides a computer storage medium that stores one or more programs, which can be executed by one or more processors to implement the steps of the device management method as described in any of the above embodiments.

[0152] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0153] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0154] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0155] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0156] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0157] The above are merely embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A device management method characterized by, The method comprises: In the case of receiving a task processing request, determining the component cooperation demand, task processing requirement and operation range corresponding to the work task to be executed; According to the component cooperation demand, the task processing requirement and the operation range, the permission level corresponding to the work task is determined; According to the permission level and the task execution state of the work task, the working mode of the RISC-V architecture is set; The permission level includes a first permission level and / or a second permission level; the first permission level includes the operation permission corresponding to the operating system in the RISC-V architecture; the second permission level includes the operation permission corresponding to the processor component in the RISC-V architecture.

2. The method of claim 1, wherein, According to the permission level and the task execution state of the work task, the working mode of the RISC-V architecture is set, which comprises: In the case of switching the permission level between the first permission level and the second permission level, the working mode of the RISC-V architecture is set to a first mode; In the case of the permission level being the first permission level or the second permission level, the working mode of the RISC-V architecture is set to a second mode, and after the work task is executed, the working mode of the RISC-V architecture is set to the first mode; The first mode is used to meet the high computing power demand; the second mode is used to balance the energy efficiency and response speed of the RISC-V architecture.

3. The method of claim 1, wherein, According to the permission level and the task execution state, the device control instruction is called; the device control instruction is used to set the working mode of the RISC-V architecture; Based on the permission registers corresponding to the operating system and the processor component, it is determined whether the permission level contains the calling permission of the device control instruction; In the case that the permission level contains the calling permission of the device control instruction, the working mode of the RISC-V architecture is set based on the device control instruction. The method further comprises:

4. The method of claim 3, wherein, In the case that the permission level does not contain the calling permission of the device control instruction, it is determined that the current call for the device control instruction is invalid. The permission register includes a first permission register corresponding to the operating system and a second permission register corresponding to the processor component; the method further comprises:

5. The method of claim 3, wherein, In the case that the permission level includes the first permission level, if the RISC-V architecture identification information is contained in the first permission register, it is determined that the permission level contains the calling permission of the device control instruction; In the case that the permission level includes the second permission level, if the RISC-V architecture identification information is contained in the second permission register, it is determined that the permission level contains the calling permission of the device control instruction. ​ 6. The method according to any one of claims 3 to 5, characterized in that, The device control instruction comprises a first control instruction and / or a second control instruction; the first control instruction is used to set a global working mode of the RISC-V architecture; and the second control instruction is used to set a working mode of the processor component. The first permission level comprises a calling permission of the first control instruction; and the second permission level comprises a calling permission of the second control instruction.

7. The method according to any one of claims 1 to 5, characterized in that, The first permission level comprises a read permission of a hardware register; and the second permission level comprises a read permission and a write permission of the hardware register.

8. The method of claim 7, wherein, The method further comprises: In a case where a write request of the operating system for the hardware register is received, performing security verification on the write request; In a case where the write request passes the security verification, configuring a temporary write permission for the hardware register in the first permission level, and configuring an effective time of the temporary write permission.

9. An equipment management apparatus characterized by comprising: The apparatus comprises: A permission division module, configured to divide an operation permission of a RISC-V architecture into a first permission level and a second permission level; the first permission level comprises an operation permission corresponding to an operating system; and the second permission level comprises an operation permission corresponding to a processor component; A level determination module, configured to, in a case where a task processing request is received, determine a permission level corresponding to a working task to be executed; A mode setting module, configured to set a working mode of the RISC-V architecture according to the permission level and a task execution state of the working task.

10. An electronic device comprising a memory and a processor, said memory storing a computer program operable on the processor, characterized in that, The processor implements the steps in the method of any one of claims 1 to 8 when executing the program.

Images