| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Force use of addresses that would be translated by TTBR1 to cause a
translation fault. RTEMS on AArch64 does not use TTBR1 and so attempted
translation of that address range could cause unexpected behavior in the
form of other exception types since TTBR1 is never set.
|
|
|
|
|
|
| |
To ensure data consistency, the cache much be flushed before disabling
the MMU. When the MMU is disabled, all accesses are treated as
non-cachced and thus will bypass the cache.
|
|
|
|
|
|
|
|
|
| |
In the original implementation, level -1 was unused and all levels could
have block-like descriptors (level 2 block descriptors are called page
descriptors). When support for level -1 page tables was added the
constraint on level -1 block descriptors was not honored. This prevents
block descriptors from being mapped at level -1 since the hardware will
not map them properly.
|
|
|
|
|
|
|
|
|
| |
This alters the AArch64 page table generation and mapping code and MMU
configuration to use page table level 0 in addition to levels 1, 2, and
3. This allows the mapping of up to 48 bits of memory space and is the
maximum that can be mapped without relying on additional processor
extensions. Mappings are restricted based on the number of physical
address bits that the CPU supports.
|
|
|
|
|
| |
This section was added recently and must be mapped to be accessed
without generating an exception.
|
|
|
|
|
|
|
|
|
| |
There were two bugs with MMU page use that were partially hiding each
other. The linker script page table section was 4x the size it needed to
be and the page table allocation routine was allocating pages PTRSIZE
times larger than it needed to. On ILP32, this resulted in incorrect but
functional allocation. On LP64, this resulted in allocation failures
earlier than expected.
|
|
|
|
|
| |
- Any page tables need to be flushed if the cache is enabled.
Disabling the cache may only be available in secure mode.
|
|
|
|
|
|
| |
This adds support for libdebugger under AArch64 using software
breakpoints and the single-step execution mode present in all AArch64
CPUs.
|
|
|
|
|
|
|
| |
Certain input parameters for MMU mapping operations could cause an
infinite recursion if block end boundaries didn't align to 4k. This
ensures that recursion descent does not exceed 2 levels and instead
rounds up to the nearest 4k block if necessary.
|
|
|
|
|
|
| |
This moves the AArch64 MMU memory type definitions into cpukit for use
by libdebugger since remapping of memory is required to insert software
breakpoints.
|
|
|
|
| |
This adds SMP support for AArch64 in cpukit and for the ZynqMP BSPs.
|
|
Currently, the AArch64 BSPs have a hard time running on real hardware
without building the toolchain and the bsps with -mstrict-align in
multiple places. Configuring the MMU on these chips allows for unaligned
memory accesses for non-device memory which avoids requiring strict
alignment in the toolchain and in the BSPs themselves.
In writing this driver, it was found that the synchronous exception
handling code needed to be rewritten since it relied on clearing SCTLR_EL1 to
avoid thread stack misalignments in RTEMS_DEBUG mode. This is now
avoided by exactly preserving thread mode stack and flags and the new
implementation is compatible with the draft information provided on the
mailing list covering the Exception Management API.
|