Set AP[2:0] and XN flags based on page attributes.
PXN is not implemented as it seems to be available only
in L1 descriptors on ARMv7.
Set TEX, B, C flags based on memoryType:
* B_MTR_UC is mapped to Strongly Ordered (TEX=0, B=0, C=0)
* B_MTR_WC is mapped to Shareable Device Memory (TEX=0, B=1, C=0)
* B_MTR_WT is mapped to Outer and Inner Write-Through, no Write-Allocate (TEX=0, B=0, C=1)
* B_MTR_WB is mapped to Outer and Inner Write-Back, no Write-Allocate (TEx=0, B=1, C=1)
* B_MTR_WP has no direct equivalent on the ARM so it's mapped as B_MTR_WB
* default is Write-Back
Implement ARMPagingMethod32Bit::AttributesToPageTableEntryFlags()
for mapping from page attributes to AP[2:0] and XN flags.
Implement ARMPagingMethod32Bit::PageTableEntryFlagsToAttributes()
for the reverse mapping used in Query() and QueryInterrupt()
i.e. recover page attributes from AP[2:0] and XN flags.
Implement ARMPagingMethod32Bit::MemoryTypeToPageTableEntryFlags()
fr mapping from memoryType to TEX, B, C flags.
Implement ARMVMTranslationMap32Bit::Protect() which used to be commented out.
Accessed and modified flags are not implemented yet, so no such
flags are returned from Query() and QueryInterrupt().
Also because of this, we just invalidate TLB on any call to Protect()
without checking whether the page has been accessed.
Change-Id: I027af5c02bd6218d9f92a58044aeb26373e1956b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5236
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Bootloader:
* set permissions to kernel read/write, no user access
for initially mapped memory areas
* set permissions to kernel read/write, no execute,
no user access for UART
Kernel:
* physical memory mapper uses kernel read/write mapping
with no-execute bit enabled
* all other pages are mapped as read/write/execute for
kernel and user
* proper access permissions and memory types to be
implemented later
Enforce memory access permissions by setting DACR to
client mode for domain #0, no access for other domains.
see ARM Architecture Reference Manual, section B3.7 Memory access control
and in particular the following subsections:
B3.7.1 Access permissions
B3.7.2 Execute-never restrictions on instruction fetching
B3.7.3 Domains, Short-descriptor format only
Change-Id: I8127b4c72dc516d013cb9751d80d6f3a9ec835e6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5233
Reviewed-by: Adrien Destugues <[email protected]>
Exception handler stacks used to be defined in the text segment
which doesn't work very well once we enable memory access permissions
as the text segment is read-only.
Change-Id: I6b28bae09507f23293ede80034db81f5344de4c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5231
Reviewed-by: Fredrik Holmqvist <[email protected]>
Map physical memory by default as Normal Memory,
Outer and Inner Write-Back, no Write-Allocate
This corresponds to the following flags:
TEX=0, B=1, C=1
AP flags are not filled in at this point
as access permissions are not enforced.
see also ARM Architecture Reference Manual, section B3.8.2,
Short-descriptor format memory region attributes, without TEX remap
Change-Id: I90bc95a8feb9f22583d41135f4cbd03489fd1b72
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5230
Reviewed-by: Fredrik Holmqvist <[email protected]>
arch_vm_set_memory_type() seems to be x86-specific (cf. MTRR) and
on other architectures it's enough to respect memoryType argument
passed to Map() and Protect()
Change-Id: Ic898b0659c73552d705593dbc3f315dbf504013d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5217
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
config_manager_scan_hardcoded() is never invoked
and there's nothing else in config_manager_arch.c
Change-Id: Iddd0648efa15ffe4a1621b74dbdd1db16039bfe8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5206
Reviewed-by: Fredrik Holmqvist <[email protected]>
config_manager_scan_hardcoded() is never invoked
and there's nothing else in config_manager_arch.c
Change-Id: Id3ec90f670de3517cfc9c1d6710c0fa688e5d48b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5205
Reviewed-by: Fredrik Holmqvist <[email protected]>
ARM ABI has different alignment requirements based on parameter size:
* parameters not larger than 4 bytes are aligned on 4 bytes
* parameters larger than 4 bytes are aligned on 8 bytes
see:
Procedure Call Standard for the Arm Architecture
sections 5.1, Fundamental Data Types
and 6.5, Parameter Passing
Therefore the following changes are introduced in gensyscalls tool:
* new optional define SYSCALL_LONG_PARAMETER_ALIGNMENT_TYPE is introduced
* it's defined only on ARM
* on other architectures it takes on the value of SYSCALL_PARAMETER_ALIGNMENT_TYPE as a default
* constants kLongParameterAlignmentType and kLongParameterAlignmentSize are introduced
* Syscall::AddParameter uses this value for aligning parameters larger than 4 bytes
Change-Id: I7e766e0ea9d07001643e813722b462b1f044921a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5112
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Set bits 12 and 2 in SCTLR to enable i-cache and d-cache.
Set cacheability flags in TTBR0 to enable coherent page table walks.
Change-Id: I7f62255b9e49035524ecf87bed12a60dd405f3c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5178
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
see Devicetree Specification,
section 2.3.5 #address-cells and #size-cells
The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed.
The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
If missing, a client program should assume a default value of 2
for #address-cells, and a value of 1 for #size-cells.
Change-Id: Iafed49358540f8ac7aa673c3dc0191c9b580250b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5144
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
* move common SMP initialization code to x86/arch_smp.cpp
* factor out arch-specific SMP initialization to
arch_smp_32.cpp resp arch_smp_64.cpp
* implement smp_trampoline for x86 32-bit EFI loader
* rename SMP trampoline for x86_64 to long_smp_trampoline
* add new argument virtKernelArgs to arch_smp_boot_other_cpus
as the kernel args are not identity mapped on 32-bit architectures
Change-Id: I30d0bb1fa9bfb08f6784a2af34eb83d6b64afa57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4869
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
Use the User Read-only Thread ID Register aka TPIDRURO to store
TLS pointer.
The User Read-only Thread ID Register is read-only in User mode,
and read/write in privileged modes.
see: ARMv7 Architecture Reference Manual,
section B3.12.46 CP15 c13 Software Thread ID registers
Change-Id: I7bff2fd66f41d7bf1a8a247151bcd02b32733c1b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4994
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
gcc generates binaries with segments aligned on 0x10000
because this is the max page size defined in bfd
This change allows runtime_loader to load ARM binaries
without complaining for unreasonable amount of space
between segments.
Change-Id: Iec345980ca7ff72786173772a6deb40f5ca0b0ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4974
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This file is used only by the u-boot raw bootloader and
it has identical content to platform/u-boot/mmu.h.
Therefore we can use mmu.h in the u-boot loader and remove
this header.
EFI platform has its own arch_mmu.h in
headers/private/kernel/boot/platform/efi
Change-Id: Ie77774fbcf4855f9bc643176c179670f6169b3b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4929
Reviewed-by: Adrien Destugues <[email protected]>
Conversion from pointer to phys_addr_t (i.e. uint64) results
in a sign extension on x86.
Therefore we first convert to addr_t and then convert from
addr_t to phys_addr_t.
Change-Id: Id9d9db03d9940a11ea3892841c271e12fad3975a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4872
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
UEFI specification states that on IA-32 paging may or may not be
enabled during startup. If paging is enabled, PAE might be active.
During jump to kernel and early kernel initialiation we use paging
without PAE.
Therefore the following initialization sequence is introduced:
* disable paging
* disable PAE
* load page directory
* enable paging
Change-Id: Ife9a631b914dd5867f6673713e20e8abfce1ea44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4919
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* Use TRACE() for logging
* Use B_PRI format strings
* Reformat local variables and function arguments to use camelCase
* Remove comment related to ConvertPointer
* Fix indentation for switch statements
* Remove variable sFirstPageTable as it's not really used
Change-Id: Iace275e5a3311f13a5018f497c3132e472a20848
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4885
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
First try to allocate a page below 2GB.
If it fails, try to allocate a physical page at the address
returned by get_next_virtual_address so that we get an address
that is available in both virtual and physical space.
Finally try to allocate any available page. At this point
it's highly likely that it will be above 0x88000000 so it can be
used for trampoline code.
Change-Id: I3100a3e09efcd938bc630a52dcce74dc5f24beb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4878
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
All the regions allocated via platform_allocate_region() are mapped to a
high virtual address so there's no need to do identity mapping for them
any more.
Copy kernel_args to a region allocated via platform_allocate_region() so it
will be mapped similarly.
Identity mapping is still needed for trampoline code for jumping to the kernel
Change-Id: I844a7a789b440a38521db49adc077bb77e658ddf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4865
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
EFI runtime service memory areas are remapped to a high virtual address
allocated with get_next_virtual_address() to avoid any address space
collision.
They are also added to virtual_ranges_to_keep so that the kernel knows
that these ranges should be reserved.
Change-Id: I63e1a2450fceff3b2404154907a2cf59dd1b373b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4863
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
Remove the dependency on identity mapping for the initial page tables
used in MapEarly / _EarlyQuery.
The initial page tables have to satisfy the following conditions instead:
* the inital page tables shall be allocated in the same region as the initial page directory
* this region shall be mapped contiguously
* the page tables shall be mapped at a higher address than the page directory
Change-Id: I34854ef93826aa48f5d90582b52905e553f3d275
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4857
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
arch_elf is reused between the kernel and boot loader
No change for kernel mode compilation.
How to select 32-bit or 64-bit when building boot loader:
* build both when building BIOS loader
* build only 32-bit when building 32-bit EFI loader
* build only 64-bit when building 64-bit EFI loader
Change-Id: I9caa1248c7eb24318911a0c369137cedb638e4e4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4817
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: Fredrik Holmqvist <[email protected]>
Build both when building BIOS loader.
Build only 32-bit ELF support for 32-bit EFI loader.
Build only 64-bit ELF support for 64-bit EFI loader.
Change-Id: I88bb287fbb9a4b6618b365b2d03f85f64021f499
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4818
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
David Karoly