Difference between revisions of "CM-T3530: WinCE: OSDesign Configuration"
(→WinCE Image Customization) |
(→Integrating Silverlight into the runtime image) |
||
Line 125: | Line 125: | ||
The KITL transport and kernel mode debuggers are activated, when VS 2005 is attached to a target platform for kernel mode debugging. This prevents the activation of the application debugger. In order to run the application debugger while the kernel mode debugger is still active and connected to a target platform, you must load a separate instance of VS 2005. That instance can then connect to the target platform using the configured transport and activate its application debugger. Break points may be set in both the application and kernel mode debuggers running in separate instances of the VS 2005. However, if a break point hits in the kernel debugger and the CE kernel remains halted for too long, the application debugger might disconnect from the target platform. | The KITL transport and kernel mode debuggers are activated, when VS 2005 is attached to a target platform for kernel mode debugging. This prevents the activation of the application debugger. In order to run the application debugger while the kernel mode debugger is still active and connected to a target platform, you must load a separate instance of VS 2005. That instance can then connect to the target platform using the configured transport and activate its application debugger. Break points may be set in both the application and kernel mode debuggers running in separate instances of the VS 2005. However, if a break point hits in the kernel debugger and the CE kernel remains halted for too long, the application debugger might disconnect from the target platform. | ||
+ | |||
+ | |||
+ | === Integrating PowerVR into the runtime image=== | ||
+ | [[CM-T3x:_WinCE:_PowerVR_Support|PowerVR support for CM-T3x]] | ||
+ | |||
+ | === Integrating Silverlight into the runtime image === | ||
+ | [[WinCE:_Silverlight_Sample | Silverlight for CM-T3530]] | ||
== See Also == | == See Also == |
Latest revision as of 07:13, 6 July 2011
Contents
- 1 BSP Package Installation
- 2 Building the Platform Project
- 3 Setup Target for CM-T3530 Image Evaluation
- 4 WinCE Image Customization
- 4.1 Managing BSP components with Platform Builder Catalog
- 4.2 Advanced BSP customization using batch files
- 4.3 RAM-Based Registry support
- 4.4 Platform Debugging over Ethernet
- 4.5 Kernel Mode vs. Application Debugging
- 4.6 Integrating PowerVR into the runtime image
- 4.7 Integrating Silverlight into the runtime image
- 5 See Also
BSP Package Installation
- Close the Platform Builder Application.
- Copy the CM_T35_BSP directory into \WINCE600\Platform.
- Copy the CM_T35_CE6 directory into \WINCE600\OSDesigns.
- Launch VS2005 and open \WINCE600\OSDesigns\CM_T35_CE6\CM_T35_CE6.sln
Building the Platform Project
The CM-T3530 Platform Project is used to build CompuLab’s WinCE demo image. It includes many components and is highly recommended as a starting point. The demo image size is relatively large, ~35 MB. A custom Windows CE image built for a specific application is typically much smaller and in most cases does not exceed 5-10MB.
In order to build the CM-T3530 platform, select the "Open >Project/Solution" command from the File menu of the VS2005 and select the \WINCE600\OSDesigns\CM_T35_CE6\CM_T35_CE6.sln file. The Platform Project and the workspace will be opened.
Make sure that the project is configured for Release mode(the full debug image is very large and it is not recommended to build it). Perform "Rebuild Solution" from the "Build" menu (alternatively you can perform "Build-Advanced Build Commands->Clean Sysgen"). The build process takes about 15-20 minutes.
Build Options
- Use Build->Advanced Build Commands->Sysgen when you add/remove Platform Builder components (Catalog items) to/from the project.
- Use Build->Advanced Build Commands-> Build Current BSP and Subprojects when you add/remove CompuLab BSP Platform Builder components to/from the project or perform changes in BSP files.
Setup Target for CM-T3530 Image Evaluation
Ensure that you have a serial terminal connected to the CM-T3530 evaluation platform as described in Console setup. Also, ensure that the CM-T3530 Ethernet port (connector P18 on the SB-T35) is connected to your local network.
Perform the following steps to setup a connection between the CM-T3530 evaluation platform and Platform Builder 6.0 :
- In Platform Builder, go to Target >> Connectivity Options.
- Click on Add Device and provide a device name (e.g. CM-T3530).
- In Kernel Service Map, select Ethernet for Download and Transport options and KdStub for the Debugger.
- Press Download settings and at the same time, boot the target device and press "SPACE" in the device console to get Eboot main menu.
- In the Eboot menu:
- Type "2". The "Select Boot Device" menu appears.
- Type "1" to choose LAN9115 MAC as your boot device.
- Type "0" to start the download (results in a broadcast of BOOT ME messages).
- Platform Builder will show the target device unique name (e.g. CM-T35-28674) in the "Active Devices" area.
- Press Transport settings and select "Use device name from bootloader".
Once the connection is configured, you can download and launch the newly created WinCE image:
- In Platform Builder Target toolbar, select the configured device and then select "Target" >> "Attach Device".
- Ensure that Eboot is ready for download (i.e. sends "BOOT ME" messages).
WinCE Image Customization
There are two ways to customize the Windows CE image:
- Recommended method: Add or remove BSP components from the demo CM_T35_CE6 project.
- Create a new platform project and then manually add all the necessary BSP components as described in the Platform Builder documentation. Refer to Windows CE OSDesign Development page.
Managing BSP components with Platform Builder Catalog
You can select the BSP components you want to include in the run-time image by using the Platform Builder Catalog GUI. In case no significant BSP modifications are required, this is the easiest way to configure the image.
Device driver removal from the image is illustrated by the following example:
- Open catalog view in Platform Builder.
- Expand CM_T35_CE6->"Third Party"->BSP->CM_T35_BSP:ARMV4I in "Catalog Items View".
- Clear the component you want to remove. In this example the Keypad driver will not be included in the run-time image
- Once the components selection is complete, rebuild the BSP (clean build) in order for the changes to take effect.
Advanced BSP customization using batch files
Each CM_T35_BSP component can be enabled with BSP_<Component Name> and disabled with BSP_NO<Component Name> environment variables.
The BSP_<Component Name> variables are set in Platform Builder Catalog. BSP_NO<Component Name> variables in the CM_T35_BSP\CM_T35_BSP.bat file.
For example, in order to include the keypad driver in the BSP, set the BSP_KEYPAD variable (by choosing the Keypad Driver catalog item) and ensure that the BSP_NOKEYPAD variable is cleared.
Environment variables defined in CM_T35_BSP\CM_T35_BSP.bat override the variables defined in Platform Builder project |
The following table lists the supported BSP_NO environment variables:
BSP_NOKEYBD | No Keypad driver and no support for keyboard |
BSP_NODISPLAY | No Graphics |
BSP_NONAND | No NAND Flash driver |
BSP_NOSDHC | No SDIO card driver |
BSP_NOSDHC1 | No SDIO card driver port 1 |
BSP_NOSDHC2 | No SDIO card driver port 2 |
BSP_NOI2CPROXY | No I2C driver |
BSP_NOI2CPROXY1 | No I2C driver port 1 |
BSP_NOI2CPROXY2 | No I2C driver port 2 |
BSP_NOI2CPROXY3 | No I2C driver port 3 |
BSP_NOUSB | No USB driver |
BSP_NOAUDIO | No Audio driver |
BSP_NOTOUCH | No Touch screen driver |
BSP_NODSPLINK | No Hardware acceleration driver |
BSP_NOSPI | No SPI driver |
BSP_NOSPI1 | No SPI port 1 |
BSP_NOSPI2 | No SPI port 2 |
BSP_NOSPI3 | No SPI port 3 |
BSP_NOSPI4 | No SPI port 4 |
BSP_NOETHERNET | No Ethernet driver |
RAM-Based Registry support
Default BSP configuration enables HIVE-based registry with lazy flushing. In order to support a RAM-Based registry, you should:
- Add the “RAM-based Registry” (SYSGEN_FSREGRAM) component to your project.
- Add the “RAM and ROM File System” (SYSGEN_FSRAMROM) component to your project.
- Perform a Clean Sysgen by using Build->Advanced Build Commands->Clean Sysgen.
Platform Debugging over Ethernet
- Choose the following platform options for the debug:
- Enable kernel debugger.
- Enable KITL.
- Ensure that the regular (release) options are selected:
- Enable Eboot Space in memory.
- Perform Build->Advanced Build Commands ->Rebuild Current BSP and Subprojects.
Run-time image built with the Kernel debugger and KITL dedicates CM-T3530 Ethernet port to debug communication. This port cannot be used for application Ethernet traffic. |
- Start the debug session as outlined in Setup Target for CM-T3530 Image Evaluation.
Kernel Mode vs. Application Debugging
Visual Studio 2005 provides two distinct types of debuggers.
The kernel mode debugger allows debugging of CE device drivers and kernel mode code. The kernel debugger can set breakpoints in the code that is automatically loaded at startup. This debugger utilizes the KITL protocol and supports various types of physical transports (Ethernet, USB and serial). The kernel debugger can be used to debug native code applications. It cannot be used to debug .NET managed code applications.
The VS 2005 application debugger allows .NET managed code debugging. This debugger is activated automatically whenever managed code runs.
The KITL transport and kernel mode debuggers are activated, when VS 2005 is attached to a target platform for kernel mode debugging. This prevents the activation of the application debugger. In order to run the application debugger while the kernel mode debugger is still active and connected to a target platform, you must load a separate instance of VS 2005. That instance can then connect to the target platform using the configured transport and activate its application debugger. Break points may be set in both the application and kernel mode debuggers running in separate instances of the VS 2005. However, if a break point hits in the kernel debugger and the CE kernel remains halted for too long, the application debugger might disconnect from the target platform.