RISC-V XIP Support Queued Ahead Of Linux 5.13 To "eXecute In Place"
It looks like the Linux 5.13 kernel will be supporting an interesting RISC-V feature this spring.
Queued up now in RISC-V's "for-next" branch as of this week is support for XIP, or eXecute In Place. RISC-V XIP allows for code to be executed directly from non-volatile storage that is directly addressable by the CPU. RISC-V XIP allows for executing code directly off CPU-addressable storage like QSPI NOR flash memory without first having to load it into system RAM.
A RISC-V XIP kernel can be run directly from flash but requires the kernel not to be compressed and MMU support must be present and enabled.
More details via this commit in RISC-V for-next ahead of the Linux 5.13 cycle.
Queued up now in RISC-V's "for-next" branch as of this week is support for XIP, or eXecute In Place. RISC-V XIP allows for code to be executed directly from non-volatile storage that is directly addressable by the CPU. RISC-V XIP allows for executing code directly off CPU-addressable storage like QSPI NOR flash memory without first having to load it into system RAM.
A RISC-V XIP kernel can be run directly from flash but requires the kernel not to be compressed and MMU support must be present and enabled.
"Kernel Execute-In-Place from ROM"
Execute-In-Place allows the kernel to run from non-volatile storage directly addressable by the CPU, such as NOR flash. This saves RAM space since the text section of the kernel is not loaded from flash to RAM. Read-write sections, such as the data section and stack, are still copied to RAM. The XIP kernel is not compressed since it has to run directly from flash, so it will take more space to store it. The flash address used to link the kernel object files, and for storing it, is configuration dependent.
More details via this commit in RISC-V for-next ahead of the Linux 5.13 cycle.
1 Comment