In Wince, you can easily view the system startup process.
During OEM development, you need to write some initial code. The initial code must be consistent with the hardware action layer in the kernel. When the oemedia Hardware Platform builds a system, Haland wince's internal cores are connected through a static chain to generate nk.exe.
In fact, when OEM Porting is a new Wince platform, they write far more code than HAL. They also need to write thin layer Code Under Graphics processing wing and Event Subsystem (GWES) to connect to some basic drivers used by GWE. In addition, the OEM must also write a series of device drivers, including display screen, keyboard, touchpad, serial port, and audio devices. HAL and drivers are usually called OEMs
Adaptation Layer, that is, OAL (OEM Adaptation Layer ).
The following uses the Reset process to analyze the startup process:
1. After the system resets, the CPU jumps to the endpoint address of nk.exe, that is, the address of the kernel module of Wince. The code at the entry point is usually written by OEMs rather than Microsoft. this part of the code is usually written in assembly. It is generally named as "Startup", and he is mainly responsible for initializing the CPU so that the inner nuclear energy can operate on him. Because most of the CPUs used in Wince are embedded CPUs, and such CPUs usually have a large number of registers, these registers must be set so as to configure the system speed and so on. Sometimes you also need to configure the base address of the register. Startup is also often used to initialize some caches to ensure that the system is in an uncached, flat addressing mode.
After Startup completes the task, it will jump to the kernel entry point-KernelStart. This is the code written by Microsoft for NK. KernelStart starts to configure the Virtual Memory Manager, initializes the interrupt vector list of the default handler, and calls the OEM layer at the lower layer to initialize the debug serial port.
2.
Then, KernelStart uses KernelRelocate to copy the initialized heap data from the ROM to RAM to initialize its local heap. Now the metadata Stack has been initialized for nk.exe, and the code action is more like a program than Loader. Then the kernel calls back the HAL OEMInit program. OEMInit is usually written in C. Its job is to initialize all OEM hardware. It mainly includes hooking interrupts, initializing timers, and testing memory.
3.
The system makes some initial configurations for the integrated peripheral devices, and then places them as dumb until their drivers can be loaded. During startup, OEMInit usually draws some flashpoints on the display screen. When OEMIint returns, the kernel callback enters HAL and asks whether the system has available RAM. When creating a ROM Image, the OEM should estimate the RAM size and position and define their size and allocation. The OEM uses the program OEMGetExtensionDRAM to tell the kernel whether there is available RAM. Once OEMGetExtensionDRAM returns, the inner nuclear power is interrupted and the scheduler is called to schedule the first thread of the system. Check the file named filesys.exe and start the application. System loader (used to load EXEs and dllsto the memory and locate filesys.exe according to a specific sequence.
The kernel can determine whether to connect the system to the debugging station through expansion. Debugging station is the PC that runs the specific debugging software.
4.
The PC and Wince systems can be connected through serial ports, parallel ports, or dedicated Ethernet. If the system finds such a link, when the system requires a file to be loaded, the loader will find this module (EXEs or DLLs) on the PC ). The common technique is that we can seamlessly expand the Windows/Windows Directory of Wince to include modules under a specific directory on any Debugging PC. In this way, the system will load modules that are not loaded during the BOOT process. Then, when the system starts running, you can directly load the modules on the PC without copying them to the target storage area of Wince. FileSys is used to manage file systems, database functions, and registration. When FileSys is loaded, it searches for the initialized File System in RAM. If yes, it uses the initialized file system and allows the Wince device to store data to the RAM file system. If not, an empty RAM file system that can be integrated with files in the ROM will be created. FileSys uses a built-in list of ROM images to know which files exist in the ROM. (ROM Image is generated by ROM builder program. ROM builder program can combine all separate programs into an Image ). FileSys reads the default directory structure of the system through a file stored on the ROM. The entry to the directory structure is recommended by Microsoft. In addition to initializing the file system, FileSys also creates the default database Images and default registry. The default database and Registry's images initialization are also defined by Microsoft and OEM in the ROM file. This file driver's initialization process allows OEMs to customize the file system's images initialization.
Once the file system initialization is complete, the system initialization will continue. However, at this time, the kernel needs to wait because it needs data from the Registry to continue the startup process. In particular, the kernel will look for the values under [HKEY_LOCAL_MACHINE] \ Init in the registry. The values under this key provide, name, order, and some dependencies. The processes that can be started are specified through Launchxx, where xx is a number of the startup sequence. An optional value, Dependxx, is used to start a dependency application, that is, its startup depends on the specified XX, where XX is earlier than him in the ordered queue.
For example:
Value Data Comments
Launch10 SHELL. EXE
Launch20 DEVICE. EXE
Launch30 GWES. EXE
Depend30 0014 Depends on Device (0x14 = 20)
Launch50 EXPLORER. EXE
Depend50 0014 001E Depends on Device and GWE
The kernel starts these applications in the order of numbers following their Lannch. The kernel needs to load each listed application. After the application is successfully initialized, it sends a successful initialization signal to the kernel through the SignalStarted function, and also transmits XX to the kernel. Through the call of these applications to SignalStarted, the kernel can know that any related process can be started now. This launch list is usually used by OEMs. You can insert other applications to this list. You only need to ensure that your application is loaded in advance. For example, you can write an application and load it after the Device and before GWES, as long as your application does not call any window manager or the graphics functions before the GWES is initialized. Note: If you start an application with a standard user interface before Explorer, you will have trouble with the Explorer Code, unless you need to start an application to support system services, otherwise, you should use Explorer in StartUp to start your application. In addition, you cannot independently start applications that depend on the assumerole, because the assumer.exe does not call SignalStarted during initialization.
Shell.exe
Shell is an interesting application, because it is not even in ROM in most systems. Shell.exe is the Wince part of CESH and the command line monitor. Because the Shell is not in the ROM, it can be loaded only after the system is connected to the PC debugging station. Generally, it is automatically loaded.
CESH uses the kernel to connect to the debugging PC to communicate with programmers. CESH opens a console session on the PC, which can replace a file that is being opened on the PC. The CESH debugger provides OEM with a large number of useful functions. First, he gave the OEM developer a command line SHELL, which can start an application on the PC, query the system status, read and write the system memory, and so on.
The CESH debugger also allows developers to conveniently operate the debugging information of Wince debug zones. Debugging information output is useful when you develop it. The debugging information in Wince is sent through the serial port. In this way, there is often a lot of irrelevant information that bothers you to find useful information. Debug zones allows developers to selectively Open and Close debugging message output from code by using macros. This allows you to track code execution without suspending the operating system. Each piece of information is assigned to one of 16 debug zones. Therefore, developers can use CESH to enable or disable each of the 16 zones.
