Developing a Windows CE OAL.ppt

Developing a Windows CE
OAL
Mr. Dhiraj Rane

Management
Tools
Communications
& Messaging
Device Update Agent
Software Update Services
Live Communications Server
Exchange Server
Internet Security and Acceleration Server
Speech Server
Image Update
Location Services
Multimedia
MapPoint
DirectX
Windows Media
Visual Studio 2005
Development Tools
MFC 8.0, ATL 8.0
Win32
Native
Managed
Server Side
Lightweight
Relational
SQL Server 2005 Express Edition
EDB
D
ata
P
rogramming
M
odel
Device Building
Tools
Hardware/Drivers
Windows XP DDK
Windows Embedded
Studio
Platform Builder
OEM/IHV Supplied
BSP
(ARM, SH4, MIPS)
OEM Hardware and
Standard Drivers
Standard PC
Hardware and Drivers
SQL Server 2005
SQL Server 2005 Mobile Edition
ASP.NET Mobile Controls ASP.NET
.NET Compact Framework .NET Framework
Microsoft Operations Manager
Systems Management Server

Agenda
Windows CE 5.0 BSPs and Kernels
Development Process
OAL
Architecture and Design
Boot Sequence and Required OAL Functions
Kernel and KITL
Optional OAL Functions
Building
Power Management
OAL Testing – Greg Prier
MEDC Call to Action
Questions?
Additional Information
Best Practices/Recommendations

Windows CE 5.0 BSPs
Windows CE 5.0 BSPs/CSPs
Family BSP/CSP Kernel
ARM
Intel Mainstone II ARMV4I
Samsung SMDK-2410 ARMV4I
CSP Only - Intel Xscale Lubbock ARMV4I
MIPS
AMD DBAu1000 MIPSII
AMD DBAu1100 MIPSII
AMD DBAu1500 MIPSII
NEC Solution Gear2 Vr4131 MIPSII (MIPS16)
NEC Solution Gear2 Vr5500 MIPSII & II_PF, MIPSIV & IV_FP
Broadcom VoIP Reference MIPSII
SH SH4 Aspen SH4
x86
x86 (CEPC) x86
x86 Emulator x86
Geode x86
Intel Assabet and Lubbock (use Mainstone II)
ARM Integrator (use Samsung SMDK2410)
SH3 Keywest (deprecated)
BSPs NO LONGER
SUPPORTED

Windows CE 5.0 Kernels
Kernels & OS builds in 4.2 = 9
ARMV4, ARMV4I, ARMV4T
MIPSIIB/16, MIPSII, MIPSII_FP, MIPSIV, MIPSIV_FP
SH3, SH4
x86
Kernels & OS builds in 5.0 = 7
ARMV4I, ARMV4
MIPSII, MIPSII_FP, MIPSIV, MIPSIV_FP
SH4, SH3
x86

BSP Development Process
Test Hardware,
Rom Monitor
Develop
Boot Loader
Clone Reference
BSP
Power
Management
Develop OAL
(Minimal Kernel)
Add
Device Drivers
Package
(CEC/MSI)

Boot Loader Architecture
A typical development boot loader
blcommon
OEM code
eboot
…
NE2000
RTL8139
DP83815
bootpart
flash FMD
EDBG drivers

Bootloader Architecture
Blcommon – generic boot loader framework
OEM code – general board init and extensions
Eboot – Ethernet functions (UDP, DHCP, TFTP)
EDBG drivers – Ethernet drivers
3Com 3C90x, AMD AM79C97x, CS8900A, NS
DP83815, NE2000, RealTek RTL8139, SMSC9000 &
SMSC100
Bootpart – storage partition management
FMD – flash management driver
Samsung/Sandisk (NAND), Intel StrataFlash (NOR)

Windows CE 5.0 BSPs
Reduce OS “bring-up” time on OEM hardware
Avoid changing the "public" OAL interface
Provide production features (power management, performance
optimizations, IOCTLs, etc.)
Maximize code re-use (and testing)
Provide a consistent OAL architecture that can be easily
extended/customized
Increase BSP coverage in-the-box
One BSP for each supported CPU
Integrate BSPs into the IDE Catalog
Integrate BSPs into the Platform Wizard
Enable third parties to create BSPs easily
Ship CSP drivers for many CPUs and SOCs
PB Tools - BSP Wizard and IDE tools
Enables faster, easier porting to OEM devices

PQOAL Design
Collection of OAL software libraries organized by CPU architecture (or
model) and by OAL “function”
Common Code Directory Structure
BSP configuration files are located in a single location
(platform<BSP>srcinc)
Chip/set Support Package (CSP) drivers share include files that define
hardware registers and layout
RTC
Cache
Library
Interrupt
Library
IOCTL
Library
Startup
Library
RTC
Library
KITL
Library
OS
Timer
Library
Timers Caches
Serial
port
Ethernet
port
USB
port
OAL
Kernel
Hardware

Directory Structure Example
platformcommonsrc
inc
ARM
common
cache
memory
ARM720T
ARM920T
Intel
Samsung
S3C2410
inc
interrupt
power
RTC
startup
timer
MIPS, SHx, x86
common
platform<BSP_name>
cesysgen
files
intltrns
0409
…
src
bootloader
kernel
OAL
kern
kernkitl
kernkitlprof
inc
common
debug
drivers
PCMCIA
Common code directory BSP code directory

BSP Configuration Files
BSP configuration files are located in a single
location (platform<BSP>srcinc)
Simplifies porting/customization work
Consistent file naming scheme
args.h – bootloader-OAL shared memory structure
bsp.h – master bsp include file
bsp_base_regs.h – board-level address definitions
bsp_cfg.h – general BSP configs (device name, clock
settings,…)
image_cfg.h – memory layout address definitions
ioctl_cfg.h – definitions used by BSP IOCTL routines
ioctl_tab.h – IOCTL function table
kitl_cfg.h – KITL transport name/device/driver table
oemaddrtab_cfg.inc – (ARM/x86) VA-PA mapping table

Shared Design
Chip/set Support Package (CSP) drivers will share include files
that define hardware registers and layout
publiccommonoakcsparmsamsungs3c2410xinc:
s3c2410x.h
s3c2410x.inc
s3c2410x_adc.h
s3c2410x_base_regs.h
s3c2410x_base_regs.inc
s3c2410x_clkpwr.h
s3c2410x_dma.h
s3c2410x_iicbus.h
s3c2410x_iisbus.h
s3c2410x_intr.h
s3c2410x_ioport.h
s3c2410x_lcd.h
s3c2410x_memctrl.h
s3c2410x_nand.h
s3c2410x_pwm.h
s3c2410x_rtc.h
s3c2410x_sdi.h
s3c2410x_spi.h
s3c2410x_uart.h
s3c2410x_usbd.h
s3c2410x_wdog.h

Creating A BSP
BSP wizard
IDE Tool to clone BSP or create a BSP definition
Can add/remove drivers to a BSP definition
Export wizard
IDE Tool to export feature components from the IDE Catalog to
other PB users
Creates a MS Windows Installer (MSI) file
CEC editor
IDE Tool to create and/or edit .CEC files
A .CEC file defines the properties of an object/component in the
IDE catalog
No more .bsp files
Two methods to create a BSP
Use the command line method
Use the BSP Wizard
Both methods rely on cloning a sample BSP

Creating An OAL
Create directory for OAL code in the BSP
platform<BSPname>kerneloal
Add <dirname> to “dirs” file to build OAL with BSP
Required OAL functions
Startup
Debug serial
OEMInit
System timer
Interrupt processing
Kernel input/output, KITL
Optional OAL functions (Platform Dependent)
Real-time clock and timer
Parallel port I/O code
Ethernet port debug
More information in PB docs
“How-to Create an OEM adaptation layer”

CE 5.0 Boot Sequence
Boot loader startup sequence
Startup()
EbootMain()
BootloaderMain()
OEMDebugInit()
OEMPlatformInit()
OEMPreDownload()
Download Occurs
OEMLaunch()
Kernel startup sequence
Startup(
)
KernelStart()
ARMInit()
OEMInitDebugSerial()
OEMInit()
KernelInit()
HeapInit()
InitMemoryPool()
ProcInit()
SchedInit()
FirstSchedule()
SystemStartupFunc()
IOCTL_HAL_POSTINIT

Required OAL Functions
Startup
Debug Serial
OEMInit
System Timer
Interrupt Processing
Kernel Input/Output
Example: Custom Kernel IOCTL
KITL

StartUp
First function called when target device boots
Purpose is to initialize CPU to known state and
to call the kernel initialization function
(KernelInitialize for x86 and KernelStart on all
other platforms)
ARM
example
LEAF_ENTRY StartUp
. . .
; Initialize CPU to a known state
; Set up OEMAddressTable for KernelStart
. . .
bl KernelStart
. . .
; KernelStart should never return

Debug Serial
OEMInitDebugSerial()
Configures Speed, Parity, Stop bit length
OEMReadDebugByte()
Retrieves a byte from the debug monitor
port
OEMWriteDebugByte()
Outputs a byte to the debug monitor port
OEMWriteDebugString()
Writes a string to the debug monitor port

OEMInit
Required task is to set up hardware
and register interrupt for the
system tick
ISRs and HookInterrupt
Setting Up the Interrupt Map
Define a mapping of Interrupt IDs
Mapping can be dynamic at driver load time
Interrupt IDs’ are returned by the ISRs to
the kernel and are used to link an
incoming IRQ with a software IST

OEMInit: An Example
Void OEMInit() {
SetUpInterruptMap();
PCIInitBusInfo();
InitDebugEther();
OEMParallelPortInit()
InitPICs();
InitClock();
if (MainMemoryEndAddress == CEPC_EXTRA_RAM_START)
{
MainMemoryEndAddress += IsDRAM(MainMemoryEndAddress,
CEPC_EXTRA_RAM_SIZE);
}
pKDIoControl = OEMKDIoControl;
}

OEMInterruptEnable()
Performs hardware operations necessary to allow
a device to generate the specified interrupt
Includes
Setting a hardware priority for the device
Setting a hardware interrupt enable port
Clearing any pending interrupt conditions from the device
OEMInterruptDisable()
Disables the specified hardware interrupt
OEMInterruptDone()
Unmasked and reenables of interrupt processing

OEMGetInterrupt()
Used by the any device wanting and IRQ. Example
PCI bus
OEMRequestSysIntr()
Used in the OEMIoControl routine to implement
IOCTL_HAL_TRANSLATE_IRQ and
IOCTL_HAL_REQUEST_SYSINTR
OEMTranslateIrq()
Used by the main ISR to translate a non-shareable
IRQ into a SYSINTR
OEMTranslateSysIntr()
Translates a SYSINTR to its corresponding IRQ

System Timer
Make sure the system timer interrupt is
registered with the ISR
Program the system timer to generate
an interrupt every 1ms
Can also support variable tick
In the system timer ISR, update the
global system tick counter CurMSec
and CurTicks. If reschedule time is
expired then return SYSINTR_Resched
else SYSINTR_NOP

Kernel Libraries
Library Description
kern.exe kernkitl.exe kernkitlprof.exe
basickernel
kernel w/ dbg
suppt
kernel w/
profiling suppt
Nk.lib Microprocessor-specific
Kernel code that MS supplies X X
Hal.lib OAL that you implement for
target HW X X X
NkProf.lib Profile version of the MS
Kernel code X
KITL.lib Kernel Independent
Transport Layer (KITL)
debugging services X X
SMC9000 Sample Ethernet debugging
driver. Must have for KITL
suppt X X X
FullLibc Microsoft C Run-Time Library X X X

Kernel Input/Output
OEMIoControl is called by the kernel when a device driver or
application program calls the KernelIoControl function
Extend the Ethernet Debugging Interface
BOOL OEMIoControl(. . .)
{
switch (dwIoControlCode) {
case IOCTL_HAL_SET_DEVICE_INFO :
case IOCTL_HAL_REBOOT:
. . .
default:
return FALSE;
}
return TRUE;
}

Example: Custom
Kernel IOCTL
#define IOCTL_MY_CONTROL1
CTL_CODE(FILE_DEVICE_HAL, 2048,
METHOD_NEITHER, FILE_ANY_ACCESS)
BOOL OEMIoControl(. . .) {
switch (dwIoControlCode)
{
case IOCTL_MY_CONTROL1:
. . .
}
RetCode = KernelIoControl( IOCTL_MY_CONTROL1 ,
. . . );

KITL
Kernel Independent Transport Layer
Designed to provide an easy
way for you to support any
debug service
OEM Function to implement
is OEMKitlINit
Including the KITL support
in the operating
system image
Vmini not always necessary.
EDBG driver can talk directly
to desktop
Passive KITL also available

Optional OAL Functions
Real-time Clock and Timer
OEMGetExtensionDRAM()

Real-time Clock And Timer
OEMGetRealTime()
Called by the kernel to get the time from the real-
time clock
OEMSetRealTime()
Sets the real time clock
OEMSetAlarmTime()
Sets the alarm time
OEMQueryPerformanceCounter()
Retrieves the current value of the high-resolution
performance counter, if one exists
OEMQueryPerformanceFrequency()
Retrieves the frequency of the high-resolution
performance counter, if one exists

OEMGetExtensionDRAM()
pNKEnumExtensionDRAM AND
OEMEnumExtensionDRAM
Example 2
Extended
4MB DRAM
available at
0x81800000
Example 1
No extension
DRAM
available
BOOL OEMGetExtensionDRAM(LPDWORD lpMemStart,
LPDWORD lpMemLen)
{
return FALSE; // no extension DRAM
}
BOOL OEMGetExtensionDRAM(LPDWORD lpMemStart,
LPDWORD lpMemLen)
{
*lpMemStart = 0x81800000;
*lpMemLen = 0x00400000; // 4MB
return TRUE;
}

Building OAL and Kernel
No longer necessary to SYSGEN OAL libraries
Shared OAL code is built just before the BSP directory
(platformcommon)
BSP kernel (kern.exe) sources file:
TARGETLIBS=
$(_COMMONOAKROOT)lib$(_CPUDEPPATH)nk.lib
$(_TARGETPLATROOT)lib$(_CPUDEPPATH)oal.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_startup_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_abort_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_cache_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_memory_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUDEPPATH)oal_io_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_intr_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_timer_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_rtc_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_ioctl_s3c2410x.lib
$(_PLATCOMMONLIB)$(_CPUDEPPATH)oal_other.lib
$(_PLATCOMMONLIB)$(_CPUDEPPATH)oal_log.lib
$(_COMMONOAKROOT)lib$(_CPUINDPATH)ddk_io.lib
$(_COMMONOAKROOT)lib$(_CPUDEPPATH)kitl.lib
$(_COMMONOAKROOT)lib$(_CPUINDPATH)fulllibc.lib
$(_PLATCOMMONLIB)$(_CPUINDPATH)oal_ethdrv_cs8900a.lib

OAL Power
Management Functions
OAL Power Management Functions
OEMIdle – Puts the CPU in reduced power mode
OEMPowerOff – Puts the CPU in suspend mode
Device Drivers Power Management Functions
xxx_PowerDown, xxx_PowerUp for stream
interface drivers
Device-specific functions for other drivers
SetInterruptEvent

OAL Tests
Available in CE 5.0
Timers/Clock support
Caches
IOCTLs
Future Tests
Interrupts
Memory Configuration
KITL and VMINI
Bootloader
Etc.

Test Harness
CETK tests
Can also be run from the standard shell
OAL Test Requirements
Booting Tinykern
KITL connection

OAL Timer Tests
Three clocks: GTC, RTC, and QPC
The Test currently checks
Resolution
Always increasing (except rollover)
Clock drift
Compares results against thresholds

Cache Testing
Currently verify correctness,
not performance
Read and write different patterns into
the cache, exercising
boundary conditions
Allow the tester to confirm the
cache parameters

IOCTL Testing
Confirm that an errant call won’t crash
the kernel
IOCTL_HAL_GET_DEVICEID
IOCTL_HAL_GET_UUID
More to come

More Information
PB docs
Source code
Lab
Testing the Windows CE 5.0 OAL
Thursday 11:15 – 12:30

While at MEDC 2005…
Fill out an evaluation for this session
Randomly selected instant WIN prizes!
Use real technology in a lab
Instructor led Reef E/F & Breakers L
Self-paced Reef B/C
Visit the Microsoft Product Pavilion
in the Exhibit Hall Shorelines B

After The Conference…
Develop
Build
Install
Build
Join
Install
Enter
Join
Full-featured trial versions of Windows CE
and/or Windows XP Embedded
Cool stuff & tell us about it:
msdn.microsoft.com/embedded/community
Windows Embedded Partner Program:
www.mswep.com
Windows Mobile 5.0 Eval Kit including
Visual Studio 2005 Beta 2
Mobile2Market Contest and win up to $25000:
mobile2marketcontest.com
Microsoft Solutions Partner Program:
partner.microsoft.com

Tools & Resources
msdn.microsoft.com/
embedded
microsoft.public.
windowsxp.embedded
windowsce.platbuilder
windowsce.embedded.vc
blogs.msdn.com/
mikehall
Windows CE 5.0 Eval Kit
Windows XP Embedded Eval Kit
msdn.microsoft.com/
mobility
microsoft.public.
pocketpc.developer
smartphone.developer
dotnet.framework.compactframework
blogs.msdn.com/
windowsmobile
vsdteam
netcfteam
Windows Mobile 5.0 Eval Kit
Websites
Newsgroups
Blogs
Tools
Build Develop

OAL Best Practices
Enable KITL
Kernel Independent Transport Layer
Provides easy way to support any debug service
Include KITL support in the OS image
Enable Kernel Tracker (CELOG)
CELog is the Event Tracking engine that’s loaded into
the Kernel
PB ships a standard CELOG DLL
To enable event tracking, call LoadKernelLibrary with
celog.dll
Enable Ethernet sharing if single port(VMINI)
publiccommonoakdriversethdbgvbridge
publiccommonoakdriversethdbgvmini

OAL Best Practices
Implement PM Functions
OEMIdle: Puts CPU in reduced power mode
OEMPowerOff: Puts CPU in suspend mode
xxx_PowerDown, xxx_PowerUp for stream
interface drivers
Implement unique device ID for DRM use
Implement IOCTL_HAL_GET_UUID
ID based upon an OEM-defined device
hardware identifier

OAL Best Practices
Reuse the BSP code provided in CE 5.0
If the %_WINCEROOT%PlatformCommon
implementation does not meet your needs, only
copy the library that you need to replace
Reduce environment variable use
Create a different BSP directory for each variation
instead of creating just one BSP directory
Follow the layout and naming scheme for
directories and files so that code can be
located more easily

OAL Best Practices (Security)
Review your BSP code
Validate your inputs to make sure that you are only using
valid data
Make sure that the pointer being provided as data input is not NULL.
If you know what the data format should look like, make sure that you
validate the data and not use it if the format is wrong
Validate the arguments for the IOCTLs
Avoid implementing code in the IOCTL that could potentially open
your system to attacks; Always review your IOCTL code for
security concerns
Catch poorly written DMA drivers that use or overuse the
FlushDCache or OEMCacheRangeFlush functions
Overuse of these two functions in OEM calls or application calls can
slow down the system
Test your images before releasing them
Make sure that you remove code used only for development
purposes from your final code or product

Shared Interrupts
Issue/Concern – Providing a single mask for more than one interrupt may results in missed
interrupts.
Recommendation – Provide a mask for each interrupt as close to the interrupts as possible.
Issue/Concern – Mixing edge and level triggering on shared interrupts may result in missed
interrupts.
Recommendation – Don’t mix edge and level triggering on shared interrupts.
Int 1
Int 2
X
Int 1
Int 2 X
X
X = Interrupt Mask
Int 1
Int 2
X = Interrupt Mask
L
X
X
Int 1
Int 2
X
X
Int 1
Int 2
X
X
L
L

GIISR.dll
OAL ISR
Int #1
Int #n
Shared Interrupts wavedev.dll
UHCI.dll
UART.dll
X
X
X
Generic Installable ISR.
Common code keeps track
of all interrupt devices
associated with IRQ
Put highest
priority and most
often interrupts
at top
Drivers must
register
Address and
Mask to
GIISR.dll
Installable ISR Handler
Recommendation
Use GIISR.dll when sharing interrupts to keep ISR in OAL
simple, which will avoid confusion when
adding/deleting/changing interrupts
GIISR.dll allows drivers to be plugged in dynamically

** Current Macallan plans are to support up to 64
Total SYSINTR; TBD on the number of those to be
user SYSINTR
UART2.dll
UART3.dll
UART1.dll
X
X
X
ISR
SYSINTR
IST
Sharing
SYSINTR Design
Issue/Concern
Windows CE provides for 16 reserved and 24 user SYSINTR; As
SOC’s (for example) become more and more prevalent, the need for
more than 24 user SYSINTR is needed
Recommendation
Use IST sharing to minimize the number of SYSINTR needed by
the design

CPU Host Bridge
Device
PCI Bus
RAM
DMA
IOCTL_HAL_REBOOT
Recommendation
Implement IOCTL_HAL_REBOOT to be able to reset all board logic; Make sure
board level reset reinitializes to boot time state
This IOCTL supports a warm boot of the target device; A request to perform a
warm boot is made by calling the OEMIoControl function with
IOCTL_HAL_REBOOT
If a device calls for a reboot and it uses DMA, IOCTL_HAL_REBOOT takes care of
memory issues to make sure that RAM doesn’t continue to be updated through DMA
from the device

CPU
Host Bridge
Device
PCI Bus
RAM
Aperture Registers
PCI Host Bridge Aperture Registers
Issue/Concern
There is typically not enough space in the memory aperture
range in the host bridge
Recommendation
Use PCI cards with a suitable amount of memory for the for
the system selected
Example – Perm3 requires 128kb of PCI memory from the PCI
bus. Some PCI busses on have 128kb of memory; This
starves all other PCI devices

CPU
PCI/PCMCIA
Bridge
PCI Bus
RAM
LCD Host Bridge
802.11b
PCI Bus Mastering (DMA)
Issue/Concern
There are typically issues in the way that the PCI bus arbitrates
devices that are on the bus; Poor arbitration design can lead to
starving other devices, system resources, or hanging the device
Recommendation
Use proper bus arbitration to allow other devices to use system
resources when needed
Example – PCMCIA 802.11b card owning the bus too long can
lead to starving of the LCD because the 802.11b card is taking up
all CPU time

CPU
Host Bridge
Device
PCI Bus
RAM
DMA
DMA Routines in CEDDK
Recommendation
Utilize the CEDDK DMA Routines. CEDDK is an essential tool for creating
platform independent device drivers
Abstraction of Bus Architectures
Abstraction of I/O mechanisms
Abstraction of DMA buffer allocation
HalTranslateSystemAddress()
Translates a system wide address to a bus relative address
Default implementation is a 1:1 mapping on PCI only
Assumes PCI buses all have access to full RAM space via host bridge
HalAllocateCommonBuffer()
Allocates a buffer of contiguous physical memory for DMA usage
Does NOT allocate DMA channels
CEDDK does not provide any abstraction for DMA controllers at this point
HalFreeCommonBuffer()
Releases a buffer allocated with HalAllocateCommonBuffer()
Normally only used when the driver is unloading

CPU
PCI/PCMCIA
Bridge
PCI Bus
Host Bridge
Device
Byte Enable Lines
Device
CPU Byte Enable Lines
Issue/Concern
Variable width transfer bus needs to enable byte lines on
reads and writes; Current designs only provide for bytes
lanes on writes, which will cause problems with destructive
read operations
Recommendation
Enable byte lines on buses with variable width transfers for
reads and writes

Multiple Hardware Timers
Issue/Concern
System that provide a single timer for multiple
functions can lead to clock error issues
Recommendation
Provide a single timer that is used for the system
1ms TIC.
Provide additional timers for profilers and other
OS, Bus, Multimedia needs
Fixed interval timers should be avoided in mobile
battery-powered systems as there is no way for
the kernel to conserve power with OEMIdle

Peripheral Devices
Recommendations
USB Function controller should be able perform disconnect
signal and then connect signal either by reset or by program;
If these signals are not connected, Windows XP may not be
able to determine what state the device is in and ignore the
device during device initialization or suspend/resume; USB
cable may need to be physically disconnect and reconnected
to resolve
Ethernet MAC – Provide a default MAC address for all
peripheral devices and make sure that they all have unique
subnet addresses; MAC addresses located in flash can be
erased; We recommend locating the MAC address in a read
only location
Ethernet MAC – Provide DMA support in Ethernet Controllers

OEMAddressTable
Issue/Concern
Set up the OEMAddressTable efficiently
Recommendation
Don’t overlap Address
Make sure most commonly used components at top of list
Make sure design is consistent with config.bib
he data must be declared in a READONLY section and there must be at least one non-zero
entry for the structure to be valid
For x86 platforms, the first entry must identify RAM, and it must start at 0x80000000
For ARM platforms, 0x80000000 can be mapped to anything
The Size must be a multiple of 4MB for x86 platforms and a multiple of 1MB for ARM; The
last entry of the table must be zeroed. You can leave holes between ranges but you cannot
have overlapping ranges
The only valid virtual memory mapping range is from 0x80000000 to 0x9FFFFFFF; For every
entry created in the table, the kernel creates two virtual address ranges; One exists in the
virtual address range from 0x80000000 to 0x9FFFFFFF and is memory that has caching and
buffering enabled; The second exists in the virtual address range from 0xA0000000 to
0xBFFFFFFF and has caching and buffering disabled
Any memory that is not mapped at boot time cannot be directly accessed by an interrupt
service routine (ISR) without first calling CreateStaticMapping to map the address

OEMCacheRangeFlush
Recommendation
Implement OEMCacheRangeFlush correctly and efficiently
Use pre-configured OEMCacheRangeFlush style
OEMCacheRangeFlush replaces calls to FlushDCache, FlushICache,
and TLBClear in Windows CE .NET 4.2 and later.
If you are implementing this function you should perform TLB
flushes at the end of the function. For example, if
dwFlags==(CACHE_SYNC_DISCARD|CACHE_SYNC_FLUSH_TLB,
the cache discard operation is usually performed before the TLB
flush
Some of the CSP routines reference global variables containing
cache and TLB size information; Your platform must resolve these
variables. You can further optimize such CSP implementations by
hard-coding variables in a private implementation of
OEMCacheRangeFlush in your platform; If you want to modify or
override CSP implementations of caching code, you must put the
relevant source files in the KernelBuildexe directory and modify
each of the source files in its subdirectories to build the file

Developing a Windows CE OAL.ppt

Recommended

Recommended

More Related Content

Similar to Developing a Windows CE OAL.ppt

Similar to Developing a Windows CE OAL.ppt (20)

Recently uploaded

Recently uploaded (20)

Developing a Windows CE OAL.ppt

Editor's Notes