ARM Overview: Difference between revisions
| [unchecked revision] | [unchecked revision] |
Content deleted Content added
m GCC (Chars Not Signed): fixed link typo |
m →Memory Detection: fixed a typo (double word) |
||
| (74 intermediate revisions by 19 users not shown) | |||
Line 1:
ARM is a family of instruction set architectures based on RISC architecture developed by a single company - ARM Holdings.
Because ARM is a
When you look at a device with ARM processing unit (term processing unit is more accurate because ARM can be found in microcontrollers as well as in microprocessors), there are two things that matter: architecture and core.
So far (Q3 2014) there have been 8 ARM architectures released or announced (where some of them have their extended versions), 7 of them being 32-bit, and the last one being 64-bit, but user-space compatibile with 32-bit instruction set (therefore making it possible to run 32-bit user processes, yet not 32-bit operating systems without virtualization). Very broadly said, with every new architecture version there have been added some new features to all cores (with exceptions) which had been already tried in some cores of a previous architecture. Not all features of previous architecture must be again available in the next one, and not all new versions of technologies added in previous architectures must be compatibile with the old ones. The simplest reason for this one could think of is that designing processors isn't like writing software: when a program decides whether to process old file format or a new one, it makes its decision and then exectues only one code, but backward compatibility of (for example instruction) formats may mean more transistors and more transistors usually (always?) result in more heat.
You must know you can't buy an ARM processor just like you would buy Intel abc or AMD xyz. ARM Holdings is a company that designs architecture, writes an '''Architecture Reference Manual''', then designs a core and writes a '''Technical Reference Manual'''. Finally, it sells designed core to a chip-making-company and releases manuals to public. From there, a chip-making-company designs a processing unit - a microcontroller (MCU), a System On a Chip (SoC), an FPGA, whatever - and it may manufacture the silicon itself or order n-thousands of chips from a semiconductor manufacturer.
All of processors you'll see in tablets or smartphones are SoCs which act as sort of motherboard with a processor. They contain logic for driving peripherals (ethernet, USB, SD/MMC cards, SPI, I2C, audio), they may contain GPU for graphics coprocessing or FPGA for custom logic.
Many uses means either few multifunctional (and theferefore complex and power-consuming) devices, or many simple devices suited just for that kind of operation. ARM processors as RISC devices chose simplicity over complexity, and therefore they are way too many cores with different instructions used. To have just ''one assembler to rule them all'', ARM defined Unified Assembly Language which can be translated for '''any''' of ARM cores.
ARM cores are divided in lastest versions to three main lines:
* Cortex-M cores, used for really small devices, usually with on-chip memory and simpler operations
* 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 55 ⟶ 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"
! Page
! Description
|-
| http://www.embedded.com/design/prototyping-and-development/4006695/How-to-use-ARM-s-data-abort-exception || Good article on the data and instruction ABORT exceptions
|}
==Registers==
Line 61 ⟶ 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 102 ⟶ 127:
|}
Each mode shares some registers with other modes. Normally registers are specified in ARM instructions they use 4 bits. Which can represent 16 registers. As you can see there are exactly 16 registers which you can reference using instructions in each mode. The
across the top header as R0 through R15. An alias to R13, R14, and R15 is
specified in
is the same as using the
using these 4 bits for each
internally the processor maps R13 (SP) to a different address in it's register file
=== Calling Convention Cheat Sheets ===
Here is a quick overview of common calling conventions. Note that the calling conventions are usually more complex than represented here (for instance, how is a large struct returned? How about a struct that fits in two registers? How about va_list's?). Look up the specifications if you want to be certain. It may be useful to write a test function and use gcc -S to see how the compiler generates code, which may give a hint of how the calling convention specification should be interpreted.
{| {{wikitable}}
! Return Value
! Parameter Registers
! Additional Parameters
! Stack Alignment
! Scratch Registers
! Preserved Registers
! Return address
|-
| R0, R1 || R0, R1, R2, R3 || stack (R13) || 8 byte<sup>[[#Note1|1]]</sup> || R0, R1, R2, R3, R12 || R4, R5, R6, R7, R8, R9, R10, R11, R13 || R14
|}
<small id="Note1">Note 1: Stack is 8 byte aligned at all times outside of prologue/epilogue of non-leaf function. Leaf functions can have 4 byte aligned stacks. 8 byte alignment is required for ldrd/strd to function on the stack, which mostly only comes into play when using varargs with 64-bit integers. Care must be taken in interrupts and exceptions to align the stack to 8 byte before calling C code.</small>
For details look at the [http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf EABI specs].
==Instructions==
Line 128 ⟶ 172:
|}
Loading of large immediate values into registers can be interestingly different from
Example, of machine code produced by GCC to load a register with a 32-bit value. As you can note the immediate value is technically outside of the instruction stream. On the
value would have been encoded into the instruction. Also, take note how each instruction is constant in length. The instruction doing the work is LDR using the PC register and a immediate offset in order to place the value 0x12345678 into the register R3.
<pre>
Line 154 ⟶ 198:
Almost all
Here are the conditional codes for example:
{| class="wikitable"
|-
! Mnemonic
! Binary
! Description
Line 197 ⟶ 241:
==Memory==
Many ARM processors come equipped with [[MMU]]s,
===== Paging =====
The paging scheme used by ARM processors uses a 2 level page table. The first level page table has 16kB size and each entry covers a region of 1MB (sections) and can be mapped directly or point to a second level page table. The second level page tables have 1kB size and each entry covers a region of 4KB (pages). The TLB also supports 16MB sections and 64kB pages. For those the right bits in the first or second level page table entries have to be set and the entry repeated 16 times. A hardware page table walk for any of the repeated entry then adds a TLB entry for the larger size. On ARMv4 and ARMv5 pages might also be divided into what the manual calls 'subpages', of, for a 4KB page, 1KB subpages, and for a 64KB page, 16KB subpages. (I assume you realize the fact that the subpages in both cases are 1/4 the size of the main page size). This is deprecated on ARMv6 and an alternate page table format can be configured that does not have subpages but has a extra access permission bits and provisions for physical address extentions (for more than 4GB physical memory) instead.
The ARM processor supports 2 independent page tables. The first page table can be abreviated from the full 16kB down to 128 byte in powers of 2 and is used for the lower part of the virtual address space. The second page table is always 16KB in size and is used for addresses beyond the end of the first page table. If the first page table already covers all of the virtual addres space, is already full size (16kB), then the second page table is never used and can be left unset.
The Architecture Reference Manuals propose to use the abreviated first page table for processes individual address space and having the second level page table static for the kernel. For small processes (using 2GB or less) this results in a smaller page tables and therefore less overhead per process.
Note: The ARMv6 Architecture Reference Manuals state clearly, multiple times, that subpages are deprecated and should not be used. Subpages have been removed in the ARMv7 Architecture Reference Manuals and are no longer available. So for maximum portability, you may decide to stick to 4KB and 64KB page sizes.
Or you can have two sets of abstractions for your ARM Memory Manager port: One MM for ARMv4 and v5, and one for ARMv6 and up. It's all up to you.
===== Memory Detection =====
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 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.
But, if you ''think'' you can do it -- then by all means try because you might figure out a way. This section is just to give you a good general feeling of what you may be getting into and I do not mean to keep any good ideas you may have from becoming something valuable.
==Exceptions==
''Note: For some reason, the ARM people use the terms 'interrupt' and 'exception' as if they were the same.''
For exceptions, ARM uses a table similar to the IVT of the real mode x86. The table consists of a number of 32-bit entries. Each entry is an instruction (ARM instructions are
Take note of that, and understand the design impact it imposes: On x86, the hardware vector table holds the addresses of handler routines. On ARM, the hardware vector table holds actual instructions. These instructions must fit into 4 bytes. This is actually not a big deal since all ARM instructions (assuming ARM mode and not Thumb, or Jazelle) are actually
Also used are various devices to ''vector'' interrupts. Two such are the Generic Interrupt Controller and the Vectored Interrupt Controller.
==Coding Gotchas==
===== Heap Pointers Needs To Be Aligned =====
I can not state at this time how many processors support unaligned memory access natively, but from what I know unaligned memory access is more expensive than aligned. And, a good many structures which have fields greater than one byte in size a lot of times are allocated on the heap. So from this you can see how big of a performance hit you could take. Not to mention the bug that would be introduced if running under a processor which does not even handle unaligned memory access gracefully, and by that I meant at the very least raising an exception of some sort so the code can crash and show the problem.
===== Missing Division Functions (__aeabi_uidivmod, __aeabi_idiv)/No Division Support =====
This is caused by using GCC and not linking with ''libgcc''. You ''NEED TO'' link with ''libgcc'' when using GCC. For information about why you should link and information about ''libgcc'', read [[Libgcc]] and [[GCC_Cross-Compiler]].
You must also make sure you use the ''libgcc'' that has been compiled for your target machine/architecture/platform. See [[Libgcc]] for more information. You can produce the correct library for GCC by reading [[GCC_Cross-Compiler]].
====== This section is just if you want a more in depth explanation and discussion. ======
This issue is actually complicated because different CPUs may not support hardware division, support it only through the floating point operations, in thumb mode, in native mode, or a combination. Also, in certain situations you may find it faster or more compact to use different methods because you may be interested in code size or performance. The ''libgcc'' will handle all of these situations and provide the needed symbols, however here are some various sources of information that can give you a more in-depth understanding:
<pre>
The following links talk about different methods in handling this problem:
http://forum.osdev.org/viewtopic.php?f=1&t=23857&p=212244
http://stackoverflow.com/questions/8348030/how-does-one-do-integer-signed-or-unsigned-division-on-arm
Also, some extra information that maybe useful:
http://www.linkedin.com/groups/ARM-cores-hardware-division-85447.S.242517259
A discussion about this section, and also at the end an example of libgcc's version of the divide function:
http://forum.osdev.org/viewtopic.php?f=8&t=27767
The source for libgcc and source of the division emulation function:
https://github.com/mirrors/gcc/blob/master/libgcc/udivmodsi4.c
https://github.com/mirrors/gcc/blob/master/libgcc/
</pre>
===== Unaligned Memory Access And Byte Order =====
{| border="1px"
| style="background-color: #eeeeee;" | Various newer ARM cores supposedly support unaligned memory access, but a specific bit or two have to be set and unset in the program control registers. I have not checked if QEMU's emulation of the ARMv7 supports this. So keep this in mind.
|}
Also, it is recommended to have a look at this article on [http://en.wikipedia.org/wiki/Endianess#Atomic_element_size_16-bit Endianness] which will help clarify and potentially gives a second source of information.
Let us imagine we have a board with 8 bytes of RAM, as depicted below:
{| class="wikitable"
! Value
| A || B || C || D || E || F || G || H
|-
! Address
| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7
|}
A ''little endian'' machine reads the least significant byte (LSB) first. So, if we made a 32-bit (word sized) read at address ''0'' on the memory above, that would yield "DCBA". On a ''big endian'' machine, which reads the most significant byte (MSB) first, you would get "ABCD". It all depends on how you visualize memory addresses - whether they flow to the right (big endian), or towards the left (little endian).
Some CPU platforms even support either mode. For example, the ARM7TDMI-S has a pin BIGEND to switch from little to big endian. (Although I could not find the QEMU option to enable this feature.)
ARM cores have two other differences from x86/x64:
* They do not handle unaligned memory accesses in any defined manner. It is specified on ''4-32 ARM7TDMI-S Data Sheet'' that if bit ''0'' for the memory address on a half-word access is ''high'' then the results are '''undefined'''.
* Accessing half-words in little endian mode will swap the half-words in the word.
An example for the latter:
<pre>
uint32 *a;
uint16 *b;
a = (uint32*)0;
b = (uint16*)0;
a[0] = 0x12345678;
printf("%#04x --> %#04x\n", b[0], b[1]);
</pre>
This gives ''0x5678 --> 0x1234'', while in big endian mode you would get ''0x1234 --> 0x5678''.
{| class="wikitable"
! colspan="8" | Little Endian Word Size (32-bit)
|-
| ED || CB || A9 || 87 || 78 || 9A || BC || DE
|-
! colspan="4" | Offset
! colspan="2" | Register(LittleEndian)
! colspan="2" | Register(BigEndian)
|-
! colspan="4" | 00
| colspan="2" | 0x87A9CBED
| colspan="2" | 0xEDCBA987
|-
! colspan="4" | 01
| colspan="4" | UNALIGNED - UNDEFINED
|-
! colspan="4" | 10
| colspan="4" | UNALIGNED - UNDEFINED
|-
! colspan="4" | 11
| colspan="4" | UNALIGNED - UNDEFINED
|}
{| class="wikitable"
! colspan="8" | Little Endian Half-Word Size (16-bit)
|-
| ED || CB || A9 || 87 || 78 || 9A || BC || DE
|-
! colspan="4" | Offset
! colspan="2" | Register(LittleEndian)
! colspan="2" | Register(BigEndian)
|-
! colspan="4" | 00
| colspan="2" | 0xA987
| colspan="2" | 0xEDCB
|-
! colspan="4" | 01
| colspan="4" | UNALIGNED - UNDEFINED
|-
! colspan="4" | 10
| colspan="2" | 0xEDCB
| colspan="2" | 0xA987
|-
! colspan="4" | 11
| colspan="4" | UNALIGNED - UNDEFINED
|}
{| class="wikitable"
! colspan="8" | Byte Size (8-bit)
|-
| ED || CB || A9 || 87 || 78 || 9A || BC || DE
|-
! colspan="4" | Offset
! colspan="2" | Register(LittleEndian)
! colspan="2" | Register(BigEndian)
|-
! colspan="4" | 00
| colspan="2" | 0xED
| colspan="2" | 0xED
|-
! colspan="4" | 01
| colspan="2" | 0xCB
| colspan="2" | 0xCB
|-
! colspan="4" | 10
| colspan="2" | 0xA9
| colspan="2" | 0xA9
|-
! colspan="4" | 11
| colspan="2" | 0x87
| colspan="2" | 0x87
|}
''From reading the data sheet it appears that if operating in big endian mode the half-word access would be reversed to be more natural as you would expect on the x86/x64 architecture. But, since I can not actually test it at the moment I am hoping I got it right.''
''The word access with offset of ''10b (0x2)'' may be defined, but I am not sure because it does not really state. However, it may employ some of the mechanisms for loading half-words. (Need someone to come through and correct this if it is wrong)''
The reason memory access has to be aligned is because unaligned access requires additional access cycles, due to the way memory modules work (see DDR datasheet below), and would increase the complexity of load / store operations (and the processor core).
You could simulate an unaligned memory access on the ARM7TDMI-S, but you would have to make separate loads from two memory locations. A compiler could probably emit code to do this automatically, but the checks whether an access is unaligned or not would slow down ''all'' memory accesses. Some code is provided in the ''ARM7TDMI-S Data Sheet'' on page ''4-35'' for such "checked" memory access, when you do not know if the address will be aligned or non-aligned.
* http://lists.gnu.org/archive/html/qemu-devel/2004-12/msg00206.html - patch for QEMU to support big-endian ARM
* http://download.micron.com/pdf/datasheets/dram/ddr/256MBDDRx4x8x16.pdf Datasheet for DDR memory
===== Branch Instruction In Vector Table =====
Keep in mind when working with the ARMv4 and compatible cores that in the vector table each entry is 32-bits -- and that the value in each slot is ''not'' the address of where the CPU should jump too.
Instead it is an instruction. This can be a little confusing when you first start out because it seems like it makes sense for it to be an address, but instead it is an actual 32-bit instruction. It can be any instruction, but common usage is a ''LDR'' (data load) instruction which loads an immediate into PC from with-in 4K bytes of the instruction, or a ''B'' (branch) which uses a 26-bit signed offset.
Also, if you use a ''B'' instruction. Remember, its relative to the instruction pointer. So for each ''index'' in the table subtract ''index*4'' from it. Then subtract an extra ''8'' from that so you have ''index*4+8'' subtracted. This ''8'' is from the prefetch (pipeline having been filled).
Failure to realize this can lead to some service routines that work long enough for you to think they are working then bug out days down the road and leave you looking through a lot of added code.
<pre>
#define ARM4_XRQ_RESET 0x00
#define ARM4_XRQ_UNDEF 0x01
#define ARM4_XRQ_SWINT 0x02
#define ARM4_XRQ_ABRTP 0x03
#define ARM4_XRQ_ABRTD 0x04
#define ARM4_XRQ_RESV1 0x05
#define ARM4_XRQ_IRQ 0x06
#define ARM4_XRQ_FIQ 0x07
/*
Will install a branch instruction for the
interrupt vector for the ARM platform.
*/
void arm4_xrqinstall(uint32 ndx, void *addr)
{
uint32 *v;
v = (uint32*)0x0;
v[ndx] = 0xEA000000 | (((uintptr)addr - 8 - (4 * ndx)) >> 2);
}
</pre>
''It can be a wise idea to populate all entries of the table. If the table is populated with zeros each vector will hold the instruction "andeq r0, r0, r0" which does nothing. Meaning if the CPU jumps to an unpopulated vector it will effectively execute a NOP and move to the next vector which can cause a confusing bug in your code. At least point any unused vectors to a dummy function that will notify you an unhandled exception has occured!''
===== Specifying CPSR using AS (Binutils/GCC) Syntax =====
You have to use ''cpsr'' not ''%%cpsr'' or any other form.
<pre>uint32 arm4_cpsrget()
{
uint32 r;
asm("mrs %[ps], cpsr" : [ps]"=r" (r));
return r;
}
void arm4_cpsrset(uint32 r)
{
asm("msr cpsr, %[ps]" : : [ps]"r" (r));
}
/* Bit 7 and 6 have to be logic-low/unset/zero/cleared to enable the interrupt type. */
void arm4_xrqenable_fiq()
{
arm4_cpsrset(arm4_cpsrget() & ~(1 << 6));
}
void arm4_xrqenable_irq()
{
arm4_cpsrset(arm4_cpsrget() & ~(1 << 7));
}
</pre>
===== GCC (Chars Not Signed) =====
Line 254 ⟶ 513:
5c: e0823003 add r3, r2, r3
</pre>
The
ARM you may be surprised to find that ''char'' is treated as ''unsigned char''. You must specify ''signed''
before ''char'', and then the compiler will generate code to correct perform the addition.
Line 267 ⟶ 526:
*[http://softgun.sourceforge.net/ Softgun]
*[http://skyeye.sourceforge.net/index.shtml Skyeye]
== Targeting Multiple ARM Based Devices ==
For information about targeting multiple ARM based devices see, [[ARM_TargetingMultipleDevices|here]].
==Tutorials And Starting Points ==
Line 274 ⟶ 536:
! Brief Description
|-
| [[ARM_Beagleboard|
| Tutorial on bare-metal [OS] development on the Texas Instruments
|-
| [[ARM_Integrator-CP_Bare_Bones|Integrator Barebones]]
Line 282 ⟶ 544:
| [[ARM_Integrator-CP_PL110_Dirty|Integrator-CP QEMU PL110 16-Bit Color Example]]
| Quick, dirty, and to the point on getting the QEMU PL110 16-Bit Color frame buffer working. Will likely not work on the real hardware, but will be very close. This is just to get someone started. Formed as a tutorial, but very short one.
|-
| [[PL050_PS/2_Controller|PL050 PS/2 Controller]]
| Information about interfacing a PS/2 device specifically the mouse, and starts with using the PL050. See links at bottom if PL050 is not of interest.
|-
| [[ARM_Integrator-CP_IRQTimerAndPIC|IRQ, Timer, And PIC]]
| This demonstrates using exceptions (specifically the IRQ exception), Timer, And PIC. It also provides a decent base for hacking with the ARM and/or QEMU.
|-
| [[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]]
| This page gives you some information about programming for the realview-pb-a board under QEMU. Actual hardware ''could''be different. It also contains a link to the datasheet (which might be hard to find).
|}
==Highly Useful External
*[http://infocenter.arm.com/help/index.jsp
*[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
*[http://re-eject.gbadev.org/files/armref.pdf ARM Instruction Reference]
*[http://www.arm.com/miscPDFs/9658.pdf
*[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-
*[http://www.embedded-bits.co.uk/2011/mmucode/ Turning on an ARM MMU and Living to tell the tale: The code]
[[Category:ARM]]
[[Category:Instruction Set Architecture]]
[[de:ARM]]
| |||