Commit Graph

11 Commits

Author SHA1 Message Date
Shell a00aaab2ba feat: libcpu/risc-v: unify mmu related works
These changes are designed to standardize the memory management across
'virt64' and 'c906', ensuring efficient handling of address spaces and
page tables.

Changes:
- Creation of ASID management files (`asid.c`) for both 'c906' and
  'virt64' architectures, which is essential for maintaining stability.
- Extensive updates to the MMU configuration and handling in `mmu.c` and `mmu.h` files.
- Addition of functions to manage ASID allocation and switching of page tables.
- For c906, accommodated the early memory setup to the one from virt64.

Signed-off-by: Shell <smokewood@qq.com>
2024-09-11 18:06:51 -04:00
heyuanjie87 b09a9784f9
[libcpu/c906]与virt同步 (#9095) 2024-06-26 12:16:37 +08:00
Shell 65c9947225
[libcpu] rv64: support for ARCH_REMAP_KERNEL (#9067)
* [libcpu] support for ARCH_REMAP_KERNEL

These changes introduce support for the ARCH_REMAP_KERNEL configuration,
which isolates kernel space in high virtual address regions. This feature
is necessary to enhance memory protection and management by segregating
user and kernel spaces more effectively.

Changes:
- Updated conditional macros to check for ARCH_REMAP_KERNEL instead of
  ARCH_KERNEL_IN_HIGH_VA in board initialization files to reflect the new
  configuration option.
- Modified qemu-virt64-riscv Kconfig and SConstruct files to include and
  utilize ARCH_REMAP_KERNEL.
- Created a new linker script `link_smart.lds` for smart linking in qemu-virt64-riscv.
- Updated rtconfig.py to use a more flexible execution path setup.
- Enhanced user address space definitions in `lwp_arch.h` to support the
  new virtual address mappings.
- Adjusted kernel memory initialization and mapping logic in `c906/mmu.c`
  and `virt64/mmu.c` to account for high virtual address regions.
- Added Kconfig option to enable ARCH_REMAP_KERNEL for RISCV64 architectures.
- Enhanced memory setup functions to support new mapping scheme, including
  updates to early page table setup and address relocation logic.

These modifications ensure that the system can utilize high memory
addresses for the kernel, improving memory isolation and system stability.

Signed-off-by: Shell <smokewood@qq.com>

* fixup: CI run failed

* bsp: default config without using smart

* fixup: static checks

* restore rt_hw_mmu_kernel_map_init for D1

---------

Signed-off-by: Shell <smokewood@qq.com>
2024-06-18 11:15:59 +08:00
Yuqiang Wang c6bdee3c50
[ci] open ci check with function declaration warning (#8546) 2024-02-20 22:45:04 -05:00
Shell 1d678e5596
[smart] fixup: mmap support (#8154)
Signed-off-by: Shell <smokewood@qq.com>
2023-10-20 13:28:20 +08:00
geniusgogo ecd29fda60
Sync dfs lwp (#8123) 2023-10-17 13:07:59 +08:00
Shell 2394e75265
[libcpu/risc-v] support noncached normal memory (#7051)
* [libcpu/risc-v] support noncached normal memory

* [mm] check before dereference in _fetch_page

* [mm] add comments on ioremap

* [ioremap] report more info on failed
2023-03-16 10:26:55 +08:00
chenhy0106 9db73a47c4
为c906添加asid支持 (#6870)
* [rt-smart] asid for c906
2023-01-28 13:08:40 -05:00
Shell f0dadcb3c3
[rt-smart] porting c906 and D1s to mm (#6848)
* [rv64/bsp] porting to mm

* [mm] report more info for debugging

* [fix] code format

* [libcpu/c906] porting to RTOS

* [fix] using rtdbg api

* [fix] add return

* [fix] report more information for debugging

* [fix] use assert 0 for unrecoverable error
2023-01-16 08:24:03 +08:00
Shell 7450ef6c4d
[rt-smart] kernel virtual memory management layer (#6809)
synchronize virtual memory system works.
adding kernel virtual memory management layer for page-based MMU enabled architecture
porting libcpu MMU codes
porting lwp memory related codes
2023-01-08 21:08:55 -05:00
guo ecf2d82159
sync branch rt-smart. (#6641)
* Synchronize the code of the rt mart branch to the master branch.
  * TTY device
  * Add lwP code from rt-smart
  * Add vnode in DFS, but DFS will be re-write for rt-smart
  * There are three libcpu for rt-smart:
    * arm/cortex-a, arm/aarch64
    * riscv64

Co-authored-by: Rbb666 <zhangbingru@rt-thread.com>
Co-authored-by: zhkag <zhkag@foxmail.com>
2022-12-03 12:07:44 +08:00