.. _multicore_general_description: Multicore General Description ========================================================== Overview -------- Core0 and Core1 are two independent cores, each with its own internal independent resources, such as ILM/DLM, PLIC, MCHTMR, FGPIO, PMP/PMA, etc. Both also have peripheral resources shared by SOC, such as AXI_SRAM, UART, DMA, etc. In dual core design, it is necessary to plan the allocation of memory resources and peripheral resources. The system always starts from Core0, and Core1 cannot self start, so Core0 is the primary core and Core1 is the secondary core. After Core0 starts, it initializes the basic resources of SOC, such as clock, memory, power, etc. Then, it specifies the start address of Core1 and releases Core1, so that the dual core can run. Memory Allocation ----------------- The organization diagram of the dual core sample memory is as follows: .. image:: ../../../../samples/multicore/doc/Multicore_Memory.png :alt: Multicore_Memory.png - Core0: It has ILM, DLM, XIP Flash, SRAM/SDRAM, NonCachable memory, and shared memory with Core1. The code can run in ILM or XIP Flash, and the data is in DLM or SRAM/SDRAM. - Core1: It has ILM, DLM, SRAM/SDRAM, NonCachable memory, and shared memory with Core0. The code runs in ILM, and the data is in DLM or SRAM/SDRAM. Core1 Code Storage Location --------------------------- The linker file of Core1 Project is not linked to Flash, so how is its code stored? The answer is our current organizational approach is that after Core1 is compiled, the binary file of Core1 will be automatically generated **sec_core_img.c** by the **bin2c.py** script, then automatically copied to the Project of Core0. So when compiling Core0, the content of Core1 image will be compiled into the **.rodata** section of Core0, as shown in the organization diagram of the memory mentioned above. When Core0 starts, it will copy the **sec_core_img.c** content of Core1 image into the ILM of Core1, and then specify the start address of Core1 as ILM and release Core1, so that Core1 runs. Generate project ---------------- - When users use Cmake to generate a Core0 project, it will automatically be associated to generate a Core1 project. - After generating the Core1 Project, it will be automatically compiled by the RISC-V GCC toolchain. This requires special attention! - After the Core1 Project is compiled, the bin file will be automatically generated **sec_core_img.c** file by the **bin2c.py** script and automatically copy it to Core0 project. - At this time, both Core0 and Core1 projects have been generated, and the Core1 project has been compiled by the RISC-V GCC toolchain. - ATTENTION: - If the associated Core1 Project fails to generate or compile, then the Core0 Project cannot be generated either. Now, users can generate or compile the Core1 Project separately to troubleshoot issues. After the problem is resolved, regenerate the Core0 Project. Compile project --------------- - Complie Core1 Project first - Due to the Core1 Project is automatically compiled by the RISC-V GCC toolchain, if users need to use the Segger Embedded Studio toolchain, they can open the Core1 Project by Segger Embedded Studio and execute the compilation. - Then, Complie Core0 Project - If users need to use the Segger Embedded Studio toolchain, they can open the Core0 Project by Segger Embedded Studio and execute the compilation. - ATTENTION: - When the files of the Core1 Project are updated, recompiling the Core1 Project will automatically update the **sec_core_img.c** file under the Core0 Project. Therefore, it is necessary to recompile the Core0 Project to update the content of the Core1 Image. Debugging the Example --------------------- - Opening the projects for Core0 and Core1 respectively. - Compile the core1 example first, then compile the core0 example. - Download the core0 example to the target and run core0 example first. - Download the core1 example to the target and run core1 example. - ATTENTION: - When debugging, users must run Core0 first and then Core1. Because Core0 will initialize the clock, power supply, etc. first. Download to Flash and Run ------------------------- - When users no need to debug, only need to download the core0 example to the target Flash, then stop debugging and reset the board. Because the **elf** file generated by **Core0** contains the content generated by **Core1** .