ARM Microprocessor (Windows CE 5.0)
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
How to Develop an OEM Adaptation Layer | Microprocessor-specific Issues
Send Feedback on this topic to the authors