OAL bit by bit (i)

OAL (OEM adaptation Layer) is an OEM adaptation layer, logically located between the Windows CE kernel and the hardware, physically OAL each module code is linked to the creation of Windows by the compilation (. lib) and other kernel libraries Ce's kernel executable file Nk.exe. The Windows CE kernel exposes a large number of functions and global variables to the OAL layer, using these functions and global variables OEMs to write interrupt processing, RTC, power management, debug ports, Common I/O control codes, and more. Figure 1 is a more intuitive description of the structure of the OAL. Ce installation directory subdirectory contains the OAL part of the source code, most of the developers to OAL as long as the modification can be, even without modification. By reading this article, developers can understand the structure of OAL, the function of exposed interface, can realize or even enhance OAL function on this basis.

Fig. 1 OAL structure diagram

Since most of the OAL layer code is related to the system initialization when the CE starts, this article takes the starting sequence of CE as a clue. Other OAL knowledge is explained in the next post.

First, in the boot loader decompression CE core image file (Nk.bin) began to jump to startup (), the startup function belongs to the OAL layer, at this time the CE OS core has not run. The startup function has two main functions, one is to initialize the CPU to a known state, the other is to invoke the kernel initialization function (the x86 platform is kernelinitialize and the other platform is Kernelstart). Initializing CPU work varies by CPU, if it is ARM series, including setting CPU to administrator mode, prohibiting IRQ and Fiq, prohibiting MMU, emptying instructions and data buffering, detecting startup reason, configuring Gpio and memory controller, initializing RTC, Save oemaddresstable address and so on. Call Kernetstart when execution is complete. If it is the x86 series, it includes setting up the CPU as protection mode, initializing the memory controller, saving the oemaddresstable address, and so on. Call Kernetinitialize when execution is complete.

Second, the function of the kernel initialization function also because of different CPU, but some functions are the same, such as initializing the serial port (in order to output debugging information), call the Oeminit function. For the x86 series, initialization work includes reading oemaddresstable content, determining paging size, kernel relocation, initializing interrupt allocation tables, initializing paging tables, memory initialization, and other initialization in addition to the above features. Refer to the CE Help documentation for other series CPUs.

Serial Debugging:

Serial debugging functions include Oeminitdebugserial, Oemreaddebugbyte, oemwritedebugbyte, etc. From the source of oeminitdebugserial can be seen, the system from the boot_arg_ptr_location-headed address structure to determine the current connection of the serial port is which, and then configure the serial port. If your device's serial I/O address set and CE default consistency, you can get CPU control in the CE core to start the completion of this period of time through the serial port to get debugging information.

Oeminit

All peripheral hardware is typically initialized in Oeminit, the system clock is initialized (systems tick) and the RTC (Real Time Clock), and the initialization kitl (Kernel Independent, transport Layer). For example, the Oeminit function of the I486 platform, which associates all IRQ and interrupt IDs first, then initializes the PCI bus, network adapter, power management, PIC (programmable interrupt Controller), system clock, and finally detects extended memory. In addition, if the OEM is to enhance functionality by OAL exposed function pointers or global variables, it is implemented in this function (explained in detail below).

Detecting extended memory

We all know that the total amount of RAM in the CE system is set in the Config.bib configuration file (if you don't know please refer to my article Platform Builder), note that the total amount of RAM is not the total physical memory size. The PB-compiled kernel contains a variable ulramend that will give Ulramend the starting address of the RAM defined in the Config.bib + RAM size and assignment. In the process of starting the CE kernel, the value of Ulramend is assigned to the global variable Mainmemoryendaddress,ce kernel to obtain the total information of RAM by accessing the mainmemoryendaddress. If the CE-based device is attached with RAM, and the Mainmemoryendaddress value does not include this additional RAM, the CE kernel cannot know that the RAM is already attached. In order for the CE kernel to understand additional RAM information, OEMs should write a function to detect the total amount of RAM and assign the total value to mainmemoryendaddress. OAL exposes a function pointer pnkenumextensiondram,oem should assign the written function address to this function pointer. You can also invoke Oemgetextensiondram if the OEM is not prepared to write its own memory detection function. From the help document to see Oemgetextensiondram This function can detect the total amount of memory, but the CE for the X86 platform of the source code does not specifically write this function of the implementation codes (see%_winceroot%\public\common\oak\csp\ I486\OAL\CFWPC.C). That is, the call to Oemgetextensiondram on the X86 platform does not detect RAM. If the OEM is interested in writing a function that detects total RAM, you can call ready-made function Isdram. This function is also stored in CFWPC.C.