ARM Overview: Difference between revisions

m
→‎Memory Detection: fixed a typo (double word)
[unchecked revision][unchecked revision]
m (→‎Memory Detection: fixed a typo (double word))
 
(8 intermediate revisions by 7 users not shown)
Line 15:
* Cortex-R cores, used for real-time devices
* Cortex-A cores, used for applications in multifunctional devices like smartphones, TVs or maybe computers.
Apple machines use custom ARM cores, and so do some Nvidia boards.
 
==Overview==
Line 68 ⟶ 69:
 
The 'Undefined' Mode is switched to on the encounter by the CPU of an undefined exception. However, based on the tone used in the ARMv4 manual, and the fact that they blatantly imply this, the exception mode was really meant for the kernel to emulate instructions for the usermode process, and then return.
 
=== Note regarding the 'Spectre' exploit ===
 
ARM have recently added a new CPU instruction to their specification that mitigates cache speculation side-channel exploits. You can read more about this design patch and recommended action to take regarding Spectre (https://developer.arm.com/-/media/Files/pdf/Cache_Speculation_Side-channels.pdf?revision=8b5a5f33-c686-4b00-8186-187dd2910355 here).
 
{| class="wikitable"
Line 81 ⟶ 86:
Unlike the x86, important operating registers are clearly visible through general use registers. For example, r15 is 'pc', or the 'program counter', and r13 is the 'stack pointer', or 'sp'.
 
Along with the general purpose registers, there is also the CPSR register, or, the 'Current Program Status Register'. This registers keeps track of the current operating mode, whether interrupts are enabled or not, etc. The operating system can read and write to this register using the MSR\MRS instructions. ([http://www.arm.com/support/faqdev/1472.html See Here]) There are several other system registers which can be used to [[Detecting_Raspberry_Pi_Board|detect the ARM board]] for example.
 
{| class="wikitable"
Line 252 ⟶ 257:
Memory detection is much different if you are coming from a background in the x86/x64 architecture. The ARM cores are used in many embedded applications and therefore the system board which the core resides on does not need to be overly complicated in order to be compatible with others boards. This is because almost any production board with an ARM core on it was likely custom designed just for that purpose. It is quite possible to use some generic board, but for lots of embedded applications there may not even be an operating system.
 
Therefore memory detection mechanisms may be non-existent and instead your operating system may opt for a value to be encoded into it at compile for for a specific system (board) which is known to have a certain amount of memory, or you may have a specific driver that your operating system loads just for that board (or is compiled in) where the driver can be queried by your kernel for the amount of memory installed. There are lots of ways and these were just two ideas, but the important part is to understand that unlike the x86/x64 compatible systems you will likely find absolutely no mechanisms to ''properly'' poll the amount of memory.
 
It may however be possible to probe memory and recover using processor exceptions. This still may not provide information about if a region of memory is FLASH, memory-mapped I/O, RAM, or ROM depending on how the system board was designed as I do suspect it could be quite possible for some ROM to be external to the core and allow writes to silently fail, and this coupled with the possibility of a region of memory to need a special unlock sequence in order to write to it will render your memory auto-detection code into a potential corner-case.
Line 548 ⟶ 553:
| [[ARM_Integrator-CP_ITPTMME_Main|ELK Pages (Thin ARM)]]
| The experimental learning kernel pages aimed to take someone gradually through the process of building a functional kernel using possibly (in later part of series) experimental designs and implementations that differ from the standard and conventional design in certain areas.
|-
| [[ARM_RaspberryPi]]
| Description and details on the commonly used Raspberry Pi boards
|-
| [[User:Pancakes/ARM_QEMU_REALVIEW-PB-A|QEMU realview-pb-a board]]
Line 554 ⟶ 562:
 
==Highly Useful External Resources==
*[http://infocenter.arm.com/help/index.jsp ArmARM Infocenter]
*[http://www.arm.com/documentation/Software_Development_Tools/ More ARM Documentation]
*[http://www.coranac.com/tonc/text/asm.htm Whirlwind Tour of ARM Assembly]
*[http://re-eject.gbadev.org/files/GasARMRef.pdf GasGAS ARM Reference]
*[http://re-eject.gbadev.org/files/armref.pdf ARM Instruction Reference]
*[http://www.arm.com/miscPDFs/9658.pdf ArmARM Assembly Language Programming]
*[http://infocenter.arm.com/help/topic/com.arm.doc.dui0159b/DUI0159B_integratorcp_1_0_ug.pdf Integrator/CP Reference Manual]
*[http://www.amazon.com/ARM-System-Developers-Guide-Architecture/dp/1558608745 Amazon: ARM System Developer's Guide: Designing and Optimizing System Software]
Line 565 ⟶ 573:
 
[[Category:ARM]]
[[Category:Instruction Set Architecture]]
[[de:ARM]]
Anonymous user