ARM Microprocessor (Windows Embedded CE 6.0)
1/5/2010
The following issues should be noted when using an ARM kernel:
- The ARM kernel does not restrict your use of registers.
In addition, you can use C code as well as assembler code when you are developing your interrupt service routines (ISRs). However, be aware that the ISR should be as small and fast as possible. - You can specify mapping of physical resources to the statically mapped (direct-mapped) virtual addresses of the kernel in 1-MB blocks.
In an ARM-specific OAL, create an OEMAddressTable table that defines the mapping from the 4-GB physical address space to the kernel's 512-MB, statically mapped spaces. Each entry in the table consists of the following entries:- Virtual base address to which to map
- Physical base address from which to map
- Number of MB to map
Although the order of the values in the table is arbitrary, DRAM should be placed first for optimal performance.
Because the table is zero-terminated, the last entry must be all zeroes.
The kernel creates two ranges of virtual addresses from this table: - One region, from 0x80000000 to 0x9FFFFFFF, will have caching and buffering enabled.
- The other region, from 0xA0000000 to 0xBFFFFFFF, will have caching and buffering disabled.
- The OEMInterruptHandlerFIQ function must be part of the OAL for any ARM build to succeed, even if it is just a stub.
- Nested interrupts.
The ARM CPU architecture supports two interrupts: one hardware interrupt request (IRQ) and one fast interrupt request.
The OEM must choose a nesting scheme and perform the appropriate masking of the interrupt register in OEMInterruptHandler before re-enabling interrupts. To do so, call INTERRUPTS_ON once the lower priority interrupts have been masked.
OEMInterruptHandler might call INTERRUPTS_OFF again if it requires non-reentrant code, but this call is not required because the kernel handles it when returning from OEMInterruptHandler. - By default, when a process calls GetSystemInfo, the dwProcessorType member returned in the SYSTEM_INFO structure does not return the correct microprocessor type.
To work around this issue, OEMs should initialize the kernel global variable CEProcessorType to either PROCESSOR_ARM720, PROCESSOR_ARM920, or PROCESSOR_ARM7TDMI in OEMInit. The kernel uses the value of CEProcessorType to initialize dwProcessorType. The choice to use PROCESSOR_ARM720, PROCESSOR_ARM920, or PROCESSOR_ARM7TDMI depends upon your microprocessor. For more information, see CEProcessorType.
See Also
Tasks
How to Develop an OEM Adaptation Layer