Transplanting method and testing method of ThreadX SMP operating system

Abstract

The invention provides a transplanting method and a testing method of a ThreadX SMP operating system, the transplanting method is used for transplanting the operating system to an RISC-V64-bit processor for operation, and the transplanting method comprises the following steps: obtaining hardware needing to be adapted on the RISC-V64-bit processor as target hardware; according to the condition of the target hardware, codes corresponding to a plurality of program modules of a ThreadX SMP operating system are modified and / or written, adaptation of the ThreadX SMP operating system to the target hardware of the RISC-V64-bit processor is completed, and the program modules are assembly programs written by using an RISC-V instruction. According to the technical scheme, the ThreadX SMP operating system is adapted to each interface between the target hardware and the ThreadX SMP operating system, so that the ThreadX SMP operating system can normally run on the processor with the RISC-V64-bit architecture, and the transplanting work of the ThreadX SMP operating system is realized. Through testing, the transplanted system can run reliably.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, in particular to the field of operating system transplantation technology, and more particularly to a transplantation method and a testing method for a ThreadX SMP operating system. Background Art

[0002] Azure RTOS ThreadX SMP is a high-performance, real-time symmetric multiprocessor (SMP) kernel designed by Express Logic specifically for embedded applications. Its high-real-time performance and comprehensive ecosystem have made it popular with developers.

[0003] The x86 instruction set architecture is currently the most commonly used. However, due to its growing instruction set, redundant instructions, and high cost, more and more designers are turning to the RISC-V architecture. The RISC-V architecture is a free, open-source, and simple instruction set architecture. Its most significant feature is its openness: it can be freely used for any purpose, allowing anyone to design, manufacture, and sell chips or software based on the RISC-V architecture.

[0004] Operating system porting involves migrating an operating system from one hardware platform to another, ensuring proper functionality and excellent performance. However, operating system porting is extremely difficult because different hardware often utilizes different instruction architectures, device interfaces, and hardware resources. Porting requires modifying and optimizing the operating system source code based on the hardware characteristics of the target platform, which is a massive undertaking and challenging to debug.

[0005] The ThreadX operating system has been ported to various processor architectures, but there is no ThreadX SMP operating system ported to the RISC-V 64 architecture, making it difficult to meet the needs of developers using RISC-V 64 processors. A solution is needed to reliably port the ThreadX operating system to RISC-V 64 processors.

[0006] It should be noted that this background information is intended solely to introduce relevant information related to the present invention to facilitate understanding of the present invention's technical solution. It does not necessarily constitute prior art. Relevant information submitted and disclosed together with the present invention's solution should not be considered prior art unless there is evidence that the relevant information was disclosed prior to the filing date of the present invention. Summary of the Invention

[0007] Therefore, the object of the present invention is to overcome the above-mentioned defects of the prior art and provide a transplantation method and a testing method for a ThreadX SMP operating system.

[0008] The purpose of the present invention is achieved through the following technical solutions:

[0009] According to a first aspect of the present invention, a method for porting a ThreadX SMP operating system is provided for porting the operating system to a RISC-V 64-bit processor for operation. The method comprises: obtaining hardware that needs to be adapted on the RISC-V 64-bit processor as target hardware; and completing the adaptation of the ThreadX SMP operating system to the target hardware of the RISC-V 64-bit processor by modifying and / or writing codes corresponding to multiple program modules of the ThreadX SMP operating system according to the conditions of the target hardware, wherein the program modules are assembly programs written using RISC-V instructions.

[0010] Optionally, the codes corresponding to the multiple program modules include codes corresponding to a boot program, which is configured to: guide the ThreadX SMP operating system to start on a RISC-V 64-bit processor so that the ThreadX SMP operating system can run on the hardware of the RISC-V 64-bit processor.

[0011] Optionally, the codes corresponding to the multiple program modules also include codes corresponding to the device driver, which is configured to: during the startup phase of the ThreadX SMP operating system, call the reset handler to configure the hardware registers to a predetermined working state so that the ThreadX SMP operating system can normally use the relevant devices of the target hardware.

[0012] Optionally, the codes corresponding to the multiple program modules also include codes corresponding to an interrupt handler, which is configured to: when an interrupt is triggered, identify the interrupt type corresponding to the currently triggered interrupt from a plurality of preset interrupt types, and jump to execute the interrupt handler of the corresponding interrupt type, so that the ThreadX SMP operating system can correctly trigger the interrupt.

[0013] Optionally, the codes corresponding to the multiple program modules also include codes corresponding to the system-scheduled programs, which are configured to: be triggered to execute when there is no executable thread on the core, poll the execution list to idle and wait for the executable thread; when a new thread enters the execution list, configure registers for the new thread and schedule the new thread to start running.

[0014] Optionally, the codes corresponding to the multiple program modules further include codes corresponding to a multi-core critical resource protection program, which is configured to: perform protection when multiple cores access shared critical resources.

[0015] Optionally, the codes corresponding to the multiple program modules also include codes corresponding to commonly used system calls, and commonly used system calls include thread stack creation, current running core acquisition, current core status acquisition, current running thread acquisition, multi-core preemption and system return.

[0016] According to a second aspect of the present invention, a ThreadX SMP operating system running on a RISC-V 64-bit processor is provided, comprising: code corresponding to a bootloader, configured to: guide the startup of the ThreadX SMP operating system on the RISC-V 64-bit processor, so that the operating system can run on the hardware of the RISC-V 64-bit processor; code corresponding to a device driver, configured to: during the startup phase of the ThreadX SMP operating system, call a reset handler to configure the registers of the hardware to a predetermined working state, so that the ThreadX SMP operating system can normally use the relevant devices of the target hardware; code corresponding to an interrupt handler, configured to: when an interrupt is triggered, identify the interrupt type corresponding to the currently triggered interrupt from a plurality of preset interrupt types, jump to execute the interrupt handler corresponding to the interrupt type, so that the ThreadX The SMP operating system can correctly trigger interrupts; the code corresponding to the system-scheduled program is configured to: be triggered to execute when there is no runnable thread on the core, poll the execution list to idle and wait for the executable thread; when a new thread enters the execution list, configure the registers for the new thread and schedule the new thread to start running; the code corresponding to the program for multi-core critical resource protection is configured to: provide protection when multiple cores access shared critical resources; and / or the code corresponding to commonly used system calls, which include thread stack creation, current running core acquisition, current core status acquisition, current running thread acquisition, multi-core preemption and system return.

[0017] According to a third aspect of the present invention, a test method for testing the running status of the ThreadX SMP operating system described in the second aspect on a RISC-V 64-bit processor is provided, wherein the RISC-V 64-bit processor includes n cores, namely core 0 to core n-1, and the test method includes: initializing the test, core 0 waits for the input of a test item while idling, and cores 1 to core n-1 idle; inputting multiple test items, core 0 creates multiple test threads for the n cores according to the test items, and allocates the multiple test items to the multiple test threads, wherein each test item is used to test whether at least one function of the ThreadX SMP operating system is normal; the n cores run the test threads to start executing the corresponding test items; after the test is completed, the test results are output, and core 0 deletes all created test threads and reclaims the allocated resources.

[0018] According to a fourth aspect of the present invention, an electronic device is provided, comprising: one or more processors; and a memory, wherein the memory is used to store executable instructions; the one or more processors are configured to implement the steps of the method described in the third aspect by executing the executable instructions. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The embodiments of the present invention are further described below with reference to the accompanying drawings, in which:

[0020] Figure 1 A schematic diagram of the position of the ThreadX SMP operating system in the overall structure after transplantation according to an embodiment of the present invention;

[0021] Figure 2 Schematic diagram of the architecture of the code directory after the ThreadX SMP operating system is transplanted according to an embodiment of the present invention;

[0022] Figure 3 A schematic diagram of a test framework operation method according to an embodiment of the present invention;

[0023] Figure 4 Schematic diagram of the test framework structure according to an embodiment of the present invention. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below through specific embodiments in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0025] As mentioned in the background technology section, it is necessary to solve the problem of how to reliably port the ThreadX operating system to a RISC-V 64-bit processor. To this end, in the present invention, the hardware that needs to be adapted on the RISC-V 64-bit processor is first collected as the target hardware. This target hardware cannot be directly used by the ThreadX operating system and requires interface adaptation. Then, based on the situation of the target hardware, the code corresponding to multiple program modules of the ThreadX SMP operating system is modified and / or written to complete the adaptation of the ThreadX SMP operating system to the target hardware of the RISC-V 64-bit processor. Using this porting method, by adapting the various interfaces between the ThreadX SMP operating system and the target hardware, the ThreadX SMP operating system can run normally on a processor with a RISC-V 64-bit architecture, thus completing the porting of the ThreadX SMP operating system.

[0026] The present invention is applicable to most RISC-V 64-bit architecture processors. Depending on the specific processor, the code corresponding to the program module is written using RISC-V instructions. For illustrative purposes, the subsequent embodiments utilize the DX-T502 EVB development board from Zhongke Jingshang Technology Co., Ltd. as an example. The inventors also ran and tested the ported ThreadX SMP operating system on the Andes CoreAX45MP processor on the DX-T502 EVB development board, demonstrating that the ported system functions normally and operates reliably.

[0027] The position of the ThreadX SMP operating system in the overall structure after transplantation is shown as follows: Figure 1 As shown, the processor is the RISC-V 64-bit AndesCore AX45MP, the ThreadX SMP operating system is ported and runs on the processor, and the application runs on the ThreadX SMP operating system.

[0028] The porting process mainly involves porting the operating system and testing it. The following describes the porting and testing framework for the ThreadX SMP operating system.

[0029] (1) ThreadX SMP operating system porting

[0030] The schematic structure of the code directory after the ThreadX SMP operating system is transplanted is as follows: Figure 2 As shown, there are main file directory, source code directory, driver directory, startup code, interrupt code, real-time operating system directory, operating system components, operating system transplantation related code, etc.

[0031] The transplanted ThreadX SMP operating system includes: code corresponding to a bootloader, which is configured to: guide the startup of the ThreadX SMP operating system on a RISC-V 64-bit processor, so that the operating system can run on the hardware of the RISC-V 64-bit processor; code corresponding to a device driver, which is configured to: during the startup phase of the ThreadX SMP operating system, call a reset handler to configure the hardware registers to a predetermined working state, so that the ThreadX SMP operating system can normally use the relevant devices of the target hardware; code corresponding to an interrupt handler, which is configured to: when an interrupt is triggered, identify the interrupt type corresponding to the currently triggered interrupt from a plurality of preset interrupt types, jump to execute the interrupt handler corresponding to the interrupt type, so that the ThreadX The SMP operating system can correctly trigger interrupts; the code corresponding to the system-scheduled program is configured to: be triggered to execute when there is no runnable thread on the core, poll the execution list to idle and wait for the executable thread; when a new thread enters the execution list, configure the registers for the new thread and schedule the new thread to start running; the code corresponding to the program for multi-core critical resource protection is configured to: provide protection when multiple cores access shared critical resources; and the code corresponding to commonly used system calls, which include thread stack creation, current running core acquisition, current core status acquisition, current running thread acquisition, multi-core preemption and system return. It should be noted that when compiling the above code, the assembly program should be written using RISC-V instructions. The RISC-V 64-bit instruction architecture is very different from other instruction architectures, including instructions, registers, and bit widths. Different types of instruction sets and register definitions vary greatly. Therefore, during the porting process, these six parts of code need to be rewritten using an assembly program that conforms to the RISC-V architecture. Compared to RISC-V32, the register bit width of RISC-V64 is 64 bits, so some instructions need to be modified to 64-bit instructions. This is mainly reflected in the modification of some load word and store word instructions to load double and store double instructions. In addition, to adapt to the RISC-V 64-bit architecture's changes to data type macro definitions in the source code, the ThreadX SMP operating system needs to be compiled as 64 bits on the 64-bit architecture. Therefore, some macro definitions for assigning or comparing ULONG types also need to be modified to 64 bits.

[0032] The codes corresponding to each program module are explained below.

[0033] Modification and adaptation of the code corresponding to the bootloader. The ThreadX SMP startup code is located in the directories platcode / src / driver / bsp / start.S and reset.c, platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_initialize_low_level.S, tx_thread_smp_initialize_wait, tx_thread_smp_low_level_initialize, tx_thread_context_restore, tx_thread_context_save, and tx_thread_interrupt_control. The system startup process first initializes the RISC-V processor's operating environment, including initializing the operating environment of the four cores. This includes clearing registers, configuring the interrupt mode, disabling and clearing all interrupts, and initializing the global pointer. Each core then configures its own stack pointer based on the hardware design. Next, after cores one through three enable interrupts, they call the system initialization wait function (tx_initialize_wait), entering a waiting phase where the zero core completes the initialization of its functional components. The zero core then enters the reset handler (reset_handler) to perform system initialization. The reset handler (reset_handler) first configures and initializes interrupts and hardware. This phase requires initializing the specified hardware (or specific hardware, referring to the hardware specified in the requirements) on the target device based on user requirements. Next, the zero core enters the kernel initialization routine (_tx_initialize_kernel_enter) to initialize the various functional components of the ThreadX SMP operating system. These components include thread queues and functional modules. During the initialization phase, operations such as bit setting ensure that each core completes initialization synchronously. Finally, each core calls the scheduler function (_tx_thread_schedule()) to enter the scheduler. This completes the system boot process by launching the bootloader. The system initialization wait function (tx_initialize_wait function) is called because the four cores of the Andes Core AX45MP quad-core processor run independently. In order to avoid the problem that the zero core is still performing system initialization operations and the other cores complete the initialization of the core operating environment and enter the system operation in advance, the tx_initialize_wait function is called to notify the zero core that the operating environment initialization has been completed and wait for the zero core to complete the system initialization, thereby realizing the synchronization function.

[0034] The code corresponding to the device driver is stored in platcode / src / driver. According to the hardware configuration on the EVB development board, the corresponding hardware driver is stored in the driver directory. During the system startup phase, when the zero core calls the reset handler (reset_handler), the hardware initialization operation is completed at the same time. During the hardware initialization operation, the system sets the hardware registers to make the hardware device in the predetermined working state. After the system starts, the program can call the device driver to realize the interaction with the hardware on the EVB development board. During the porting process, adaptation is required for the target hardware of different manufacturers. Schematically, for DX-T502, it is necessary to write a board support package BSP for use with the ThreadX SMP operating system for the entire SOC where the processor is located, that is, the peripheral modules of DX-T502, including BOOT and peripheral drivers.

[0035] The interrupt handler code is stored in the platcode / src / driver / bsp / trap.c file and in the platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_thread_smp_core_preempt.S, tx_thread_context_restore.S, tx_timer_interrupt.S, and tx_initializa_low_level.S files. The platcode / src / driver / bsp / trap.c file contains the interrupt handler functions for various external interrupts. The platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_thread_smp_core_preempt.S file contains the thread switching soft interrupt trigger. Calling this function triggers the target core's soft interrupt, thereby implementing a thread switch operation on the target core. The platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_thread_context_restore.S file contains the context restoration routine. After interrupt processing is complete, the system will jump to this routine to restore the original execution context and resume execution. The platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_timer_interrupt.S file contains the clock interrupt handler. When the system encounters a clock interrupt, it will jump to this routine to update the time slice and complete the clock interrupt processing. The platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_initializa_low_level.S file contains the interrupt context save routine and some interrupt handlers. When an interrupt is triggered, the system will immediately jump to this routine. After saving the execution context, it will determine the interrupt type and jump to the corresponding interrupt handler. When an interrupt is triggered, the system jumps to the interrupt handler, which first restores the stack contents of the currently running program. Interrupt handlers are classified into various types. Next, the system jumps to the corresponding interrupt handler based on the interrupt type. For example, depending on the interrupt type, the system might jump to a clock interrupt, soft interrupt, or external interrupt handler. Clock interrupts require hardware parameters configured for the system clock interrupt. Soft interrupts require a corresponding soft interrupt handler function configured for each core. Modify the core preemption function (_tx_thread_smp_core_preempt function).This function will trigger a soft interrupt, and the interrupt number is the number of cores that need to be preempted. The soft interrupt trigger requires setting the corresponding position on the corresponding RISC-V64-bit system, and the corresponding CPU core will call the soft interrupt function (_tx_software_interrupt). After the soft interrupt function is executed, the processing of this soft interrupt is completed by calling the completion function of the soft interrupt. The external interrupt system needs to modify the device external interrupt processing function (machine_ei_handler function). When an external interrupt arrives, the system first determines the interrupt type. If the interrupt type is an external interrupt, the device external interrupt processing function (machine_ei_handler) is called to enter the external interrupt processing program. The program then calls the corresponding interrupt processing function through the corresponding interrupt number to complete the interrupt processing. After that, the completion function of the external interrupt is called to end the interrupt processing. After completing the interrupt processing, the system will restore the context of the original program and continue execution. Regarding some files of the interrupt part in the actual transplantation process of the inventor, a schematic introduction is given as follows: trap.c: The content stored in this file is the interrupt processing function of various external interrupts. tx_thread_smp_core_preempt.S: This file stores the _tx_thread_smp_core_preempt function, which implements the process preemption function. tx_thread_context_restore.S: This file stores the _tx_thread_context_restore function, which restores the context of the original running thread after interrupt processing is complete. tx_timer_interrupt.S: This file stores the tx_timer_interrupt function, which handles clock interrupts. tx_initializa_low_level.S: This file stores the _tx_initialize_low_level function and the _tx_exception_handler function. The _tx_initialize_low_level function initializes the system stack and memory space global variables required for system operation, as well as the system clock. The _tx_exception_handler function is used for interrupt processing, including storing the context when an interrupt arrives, determining the interrupt type, and entering the corresponding interrupt handler. tx_software_interrupt: This function triggers the target core's soft interrupt, causing it to complete a thread switch. machine_ei_handler: This function handles external interrupts and jumps to the corresponding external interrupt handler based on the corresponding external interrupt number.The complete function of the external interrupt: After the external interrupt is processed, the corresponding interrupt number is cleared to 0, completing the interrupt operation. At this point, the system can respond to the interrupt again.

[0036] The code for the system-scheduled program is stored in the platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_thread_schedule.S file. This file contains the _tx_thread_schedule function, which schedules threads. If a runnable thread exists, the current core runs it. Otherwise, the program loops continuously, waiting for a runnable thread to appear. This means that the program begins running when no runnable threads exist on the core. The program busy-waits, polling the execution list. When a new thread enters the execution list, the program configures registers for that thread and begins execution. In other words, when no runnable threads exist on the core, the system-scheduled program runs to schedule the next runnable thread. When there are no runnable threads on the core or the conditions for triggering thread switching are met, the core will run the program. If there are no runnable threads, the program will enter an infinite loop, repeatedly reading the runnable thread pointer. If the pointer is empty, it will continue to read in a loop. If a new runnable thread enters the pointer, it will jump out of the loop and run the thread pointed to by the pointer.

[0037] The code for multi-core critical resource protection is stored in the files platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_thread_smp_protect.S and platcode / src / rtos / ports_smp / risc_v64_smp / gnu / src / tx_thread_smp_unprotect.S. The tx_thread_smp_protect.S file contains the _tx_thread_smp_protect function, which disables interrupts and acquires the _tx_thread_smp_protection spin lock, thereby synchronizing various operating system components. The tx_thread_smp_unprotect.S file contains the _tx_thread_smp_unprotect function, which enables interrupts and releases the _tx_thread_smp_protection spin lock, thereby synchronizing various operating system components. _tx_thread_smp_protection is a spin lock structure used for synchronization in the ThreadX SMP operating system. Critical resources are shared resources that can only be used by one processor process at a time. Resources shared by processor processes using mutual exclusion are called critical resources. For example, hardware peripherals that are considered critical resources typically include printers and tape drives, while software resources that are shared by multiple processes include message queues, variables, arrays, and buffers. Multi-core access to critical resources is protected by mutual exclusion, ensuring that only one computer process can access the resource at a time. Illustratively, when access to a shared critical resource is required, the system first calls the critical section protection function (tx_thread_smp_protect function). This atomic operation acquires the ThreadX operating system's spin lock structure (_tx_thread_smp_protection). If the lock is successfully acquired, the critical section is accessed normally; otherwise, the process enters a busy wait queue until another core releases the lock. After a core accesses the critical resource and needs to terminate access to the critical section, the system calls the unprotect critical section function (tx_thread_smp_unprotect function) to release the lock, completing access to the critical section. Subsequently, if the waiting queue is not empty, the core at the head of the waiting queue calls the critical section protection function (tx_thread_smp_protect function) and obtains the spin lock structure (_tx_thread_smp_protection) of the ThreadX operating system through atomic operations. The rest is similar and will not be elaborated on.

[0038] Common system calls include thread stack creation, obtaining the current running core, obtaining the current core status, obtaining the current running thread, multi-core preemption, and system return, or a combination thereof. These system calls are used to set up the thread stack during thread creation, obtain the CPU ID of the calling routine, obtain the current core status, obtain the thread control block pointer of the thread running on the current CPU, trigger a soft interrupt to another core to complete cross-core thread preemption, and return core control from the thread to the ThreadX system. Thread stack creation, called by the thread creation function, creates a corresponding stack for the newly created thread in the specified address space. Obtaining the current running core obtains the processor core number where the current thread is running by reading the register storing the current running core number. Obtaining the current core status obtains the current processor core system status and is primarily used during the initialization phase to indicate whether the current core has completed initialization. Obtaining the current running thread obtains the thread control block pointer of the thread running on the current core. Multi-core preemption triggers a soft interrupt on a core, causing it to complete a thread switch. The system return function means that when a thread is resumed or suspended, the right to use the current processor core can be returned to the system, and the system will call the next thread.

[0039] (2) Testing framework for the ported ThreadX SMP operating system

[0040] The test framework operation method designed by the present invention is as follows Figure 3 As shown, it includes: writing a test project based on the ThreadX project; compiling the test file project corresponding to the test project; uploading the compiled file to the EVB development board; running the test and returning the test results through the serial port.

[0041] A schematic test framework structure diagram for the transplanted ThreadX SMP operating system is shown below: Figure 4 As shown in the figure, the processor includes four cores, namely core 0, core 1, core 2 and core 3 (hereinafter referred to as core 0, core 1, core 2 and core 3). On this processor, the running process of the test framework is as follows:

[0042] ① Initialization test: zero cores are idling and waiting for test items to be input, while one to three cores are idling;

[0043] ② After the test project is input, the zero core creates several test threads for each of the four cores according to the test project;

[0044] ③ Four cores run the test threads to start the test;

[0045] ④After the test is completed, the test results are output, all created test threads are deleted by Zero Core, and the allocated resources are reclaimed;

[0046] ⑤The four cores return to idle state, and zero cores wait for the next test input.

[0047] The test framework provided by this invention designs the following test cases for the kernel module, thread management module, and interrupt module of the ThreadX SMP operating system:

[0048]

[0049]

[0050] The test framework designed by the present invention tests each functional module of the operating system to prove and ensure that the transplanted operating system can run correctly.

[0051] In summary, this paper adapts the underlying code, including the ThreadX SMP operating system bootloader, device drivers, and interrupt handlers, to enable the ThreadX SMP operating system to operate properly on a RISC-V 64-bit processor. Furthermore, to verify the correctness of the porting, a testing framework was designed to validate the various functional modules of the ThreadX SMP operating system, ensuring proper operation of the ported operating system.

[0052] It should be noted that although the above describes the various steps in a specific order, it does not mean that the steps must be performed in the above specific order. In fact, some of these steps can be executed concurrently or even in a different order as long as the required functions can be achieved.

[0053] The present invention may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present invention.

[0054] Computer-readable storage media can be a tangible device that holds and stores the instructions used by an instruction execution device. Computer-readable storage media can, for example, include, but are not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, a punch card or a raised structure in a groove on which instructions are stored, for example, and any suitable combination thereof.

[0055] While various embodiments of the present invention have been described above, the above descriptions are intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or technological improvements in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for porting a ThreadX SMP operating system to a RISC-V 64-bit processor, the method comprising: Get the hardware that needs to be adapted on the RISC-V64 processor as the target hardware; According to the situation of the target hardware, the adaptation of the ThreadX SMP operating system to the target hardware of the RISC-V 64-bit processor is completed by modifying and / or writing the codes corresponding to multiple program modules of the ThreadX SMP operating system, and the program modules are assembly programs written using RISC-V instructions.

2. The method according to claim 1, characterized in that The codes corresponding to the multiple program modules include codes corresponding to a boot program, which is configured to: guide the ThreadX SMP operating system to start on the RISC-V 64-bit processor, so that the ThreadX SMP operating system can run on the hardware of the RISC-V 64-bit processor.

3. The method according to claim 2, characterized in that The codes corresponding to the multiple program modules also include codes corresponding to the device driver, which is configured to: during the startup phase of the ThreadX SMP operating system, call a reset handler to configure the hardware registers to a predetermined working state so that the ThreadX SMP operating system can normally use the relevant devices of the target hardware.

4. The method according to claim 3, characterized in that The codes corresponding to the multiple program modules also include codes corresponding to an interrupt handler, which is configured to: when an interrupt is triggered, identify the interrupt type corresponding to the currently triggered interrupt from a plurality of preset interrupt types, and jump to execute the interrupt handler of the corresponding interrupt type, so that the ThreadX SMP operating system can correctly trigger the interrupt.

5. The method according to claim 4, characterized in that The codes corresponding to the multiple program modules also include codes corresponding to the system-scheduled programs, which are configured to: be triggered to execute when there is no executable thread on the core, poll the execution list to idle and wait for the executable thread; when a new thread enters the execution list, configure the registers for the new thread and schedule the new thread to start running.

6. The method according to claim 5, characterized in that The codes corresponding to the plurality of program modules further include codes corresponding to a multi-core critical resource protection program, which is configured to: perform protection when multiple cores access shared critical resources.

7. The method according to claim 6, characterized in that The codes corresponding to the multiple program modules also include codes corresponding to common system calls, and the common system calls include thread stack creation, current running core acquisition, current core status acquisition, current running thread acquisition, multi-core preemption and system return.

8. A ThreadX SMP operating system running on a RISC-V 64-bit processor, comprising: The code corresponding to the bootloader is configured to: guide the startup of the ThreadX SMP operating system on the RISC-V 64-bit processor, so that the operating system can run on the hardware of the RISC-V 64-bit processor; The code corresponding to the device driver is configured to: during the startup phase of the ThreadX SMP operating system, call a reset handler to configure the hardware registers to a predetermined working state so that the ThreadX SMP operating system can normally use the relevant devices of the target hardware; The code corresponding to the interrupt handler is configured to: when an interrupt is triggered, identify the interrupt type corresponding to the currently triggered interrupt from a plurality of preset interrupt types, and jump to execute the interrupt handler corresponding to the interrupt type, so that the ThreadX SMP operating system can correctly trigger the interrupt; The code corresponding to the system-scheduled program is configured to: be triggered to execute when there are no runnable threads on the core, poll the execution list to idle and wait for an executable thread; when a new thread enters the execution list, configure the registers for the new thread and schedule the new thread to start running; The code corresponding to the multi-core critical resource protection program is configured to: protect when multiple cores access shared critical resources; and Code corresponding to common system calls, including thread stack creation, current running core acquisition, current core status acquisition, current running thread acquisition, multi-core preemption and system return.

9. A method for testing the running status of the ThreadX SMP operating system according to claim 8 on a RISC-V 64-bit processor, wherein the RISC-V 64-bit processor includes n cores, namely core 0 to core n-1, the testing method comprising: Initialization test, core 0 waits for test item input while idling, cores 1 to n-1 idle, where; Input multiple test items, and core 0 creates multiple test threads for n cores according to the test items, and assigns the multiple test items to the multiple test threads, wherein each test item is used to test whether at least one function of the ThreadX SMP operating system is normal; The n cores run the test threads and start executing the corresponding test items; After the test is completed, the test results are output, and core 0 deletes all created test threads and reclaims the allocated resources.

10. An electronic device, characterized in that: include: one or more processors; as well as a memory, wherein the memory is used to store executable instructions; The one or more processors are configured to implement the steps of the method of any one of claims 1 to 7 and 9 by executing the executable instructions.

Images