ARM Microprocessor (Windows Embedded CE 6.0)

  • Article

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

Concepts

Microprocessor-specific Issues