Portierung von BSP Win CE 5.0 bis 6.0

20 Juni 2017

BSP (Board Support Package) ist eine Software, implementiert und unterstützt ein Betriebssystem auf einem Standard-Entwicklungsplattform (SDB – Standard Development Board). In der Regel besteht aus einem Bootloader (Bootloader) OAL (OEM Adaptation Layer genannt), Treiber und Konfigurationsdateien, um das System-Image zu booten.

Windows Embedded CE 6.0 verfügt über eine komplett überarbeitete Kernel die Einführung einer Reihe neuer, wichtiger Elemente wie zwei Modi der Gerätetreiber (Kernel-Modus und Benutzermodus), System-APIs (Application Programming Interface) verschoben (mit ihren eigenen Prozesse unter Benutzer) in Bibliotheken die im Kernel-Modus arbeiten, und auch eine neue Speicherarchitektur, die bisherigen Begrenzung entfernt (jetzt kann gleichzeitig bis zu 32.000 Prozesse der Adressraum von 2 GB virtuellen Speicher für jeden Prozess).

Darüber hinaus werden die Code OAL (nk. exe) und der Code des Betriebssystem-Kernel (kernel.dll) nun getrennt und miteinander nur durch genau definierte Schnittstellen kommunizieren.

Besondere Eigenschaften:

BSP-Verlagerung für „RMI Alchemy ™ DBAu1550 ™ Development Board“ (von der BSQUARE Corporation) mit Windows CE 5.0 ist CE 6.0.

RMI Alchemy™ DBAu1550™ Development Board
Au1550 ™ Prozessor der Netzwerksicherheit auf der Basis der MIPS32 Architektur
Das neue BSP auf Basis von:
- Einer der vorhandenen BSP für Win CE 6.0 CPU MIPSII
- Eines bestehenden BSP für „RMI Alchemy ™ DBAu1550 ™ Development Board“ für Win CE 5.0
Der Prozess der Migration von CE 5.0 auf CE 6.0 und die neue IDE (Microsoft Visual Studio 2005 mit Ergänzungen Platform Builder für CE 6.0)
Trennung von Code OAL-Schicht und dem Betriebssystem-Kernel
Überprüfung des Boomanager und Gerätetreiber in Bezug auf die neuen Anforderungen der CE 6.0.

Veränderungen in den Hauptmodulen

Kode der OAL-Schicht (nk.exe) und Kode des Kerns vom Betriebssystem (kernel.dll) sind getrennt
Um die Effizienz zu vergrößern, wurden die API-Funktionen aus der eigenen Prozesse in der Benutzerweise herausgenommen und in den Bibliotheken der Kernel–Modus versetzt:
- filesys.dll – Register, Dateisystem und Datenbasis
- gwes.dll – graphische Interface, Ereignisbediengung
- device.dll – Verwaltung der Gerätetreiber in der Kernweise
Bediengungsmanager besteht aus einem Host-Prozess-System-Dienstleistungen (servicesd.exe) und Befehlszeilenschnittstelle für Dienste (services.exe)
Neues, separates Prozess, das die Gerätetreiber in der Benutzerweise verwaltet (udevice.exe)

Neue Architektur des Arbeitsspeichers

Neue Architektur des Arbeitsspeichers, der die bisherigen Beschränkungen entfernt

Jeder Prozess erhält eine eigene, sehr privaten Adressraum (keiner Applikationsprozess kann nicht„einen Blick“ in den Adressraum eines anderen Prozesses der Applikation)
Das theoretische Maximum von 32 K gleichzeitig betriebenn Prozessen (statt 32)
Größerer Adressraum – 2 GB virtuellen Speicher für jeden Prozess (statt 32 MB).

Handeln in der Kernweise

Der Prozessor muss zwei Ebenen von Privilegien unterstützt: Kernweise (höhere) und Benutzerweise (untere)
Nur eine gemischte Betriebsmodus wird unterstützt – alle Applikationen werden in den Adressraum des Benutzers geladen, und alle Komponenten der Adressraum des Kernbetriebssystem(dies ist langsamer als der Betrieb des gesamten Systems in der Kernweise aber dank der ganzen Gemeinde arbeitet stabiler und sicherer)
Manche System-Bibliotheken gibt es in beiden Versionen (für Benutzerweise und Kernweise) um die Kosten für den Aufruf einer Funktion durch den gebundenen Ebenen der Vorzug zu minimieren (z.B. System-Bibliothek Kern –. Coredll.dll und k.coredll.dll).

Zwei Betriebsmodi der Gerätstreiber

Kernweisetreiber – Funktionalität des alten device.exe wurde in den Kern bewegt, um dir Systemleistung zu verbessern. Diese Treiber müssen sehr gut getestet werden und stabil sein, um eine Störung des Kernes und des ganzen Systems nicht zu verursachen.
Benutzerweisetreiber – neuer, besser geschützter Prozess für das Benutzergerät (udevice.exe), der die Stabilität und die Sicherheit vergrößt – entsprechender für den nicht vertrauten Treiber der Drittfirmen oder Instabilität der Treiber, die die Testen in der Benutzerweise fordern, bevor sie in der Kernweise gestellt werden. Jeder einzelner Treiber der Benutzerweise (oder ihre Gruppe) kann auf der getrennten Instanz udevice.exe gestartet werden.

Beschränkung des neuen API

Funktionen werden schon nicht mehr unterstützt – SetKMode, SetProcPermissions / GetCurrentPermissions, MapCallerPtr, MapPtrToProcess
VirtualCopy-Funktion – im Fall vom VirtualCopy-Abruf in den Treiber von Benutzerweise, werden die Adresse überprüft, um sich zu sichern, dass der Treiber das Recht zu der verlangten physischen Adresse hat
OAL-Schicht kann nur aus diesen Kernfunktionen nutzt, die exportiert wurden

Einfluss des neuen CE 6.0

Einfluss des neuen CE 6.0 auf die schon bestehenden Treibern und Software

Die binäre Kompatibilität für Applikation – die gut geschriebenen Applikationen sollen nach den kleinen / keinen Veräderungen funktionieren. (das Gedächtnis wird mit den gleichen API-Funktionen untergebracht, und die Daten sind immer noch mit dem Gebrauch von 32-Bit Anzeiger der virtuellen Gedächtnis bewahrt). Große Datenblöcke werden mit der VirtualAlloc-unktion statt des anderen Gedächtnises mit den früheren CE-Versionen (z.B. MapViewOfFile) untergebracht
Durch CoreDLL aufbewahrte Kompatibilität mit dem minimalisierten Einfluss auf API Win32 und den Veränderungen, die in den API-Bibliotheken versteckt sind
Applikationen, die aus der nicht dokumentierten Techniken nutzen (solche wie die Überlieferung der Henkel oder der Anzeiger zwischen der Prozesse) müssen höchstwahrscheinlich modifiziert werden
Die Änderungen betreffen vor allem Treiber und Service:
- In den meisten Fällen werden die Treiber mit dem Arbeitsaufwand übertragen
- Im Fall der kundenspezifischen Software-Lösungen, oder wenn die nicht dokumentierte Funktionen genutzt werden, kann notwendig sein, um die innere Struktur oderSchnittstellencontroller wieder aufzubauen
- Treiber, die den Zugang zu den Daten in der Adressraum der Anwendung benötigen(Verarbeitung / Aufzeichnung) müssen in der Kernweise ausgeführt werden (da die Funktion SetKMode und Einstellung für den Prozess auf andere Prozesse nicht mehr unterstützt werden)
- Gerätetreiber kann in der Benutzerweise mithilfe des Managertreiberprozesses in der Benutzerweisegestartet werden – udevice.exe

Das neue BSP ist auf einer der vorhandenen BSP Prozessor MIPSII von Microsoft zusammen mit AdditivenPlatform Builder für „RMI Alchemy ™ DBAu1550 ™ Development Board“ für Win CE 5.0 zur Verfügung gestelltfür CE 6.0 auf Microsoft Visual Studio 2005 und der bestehenden BSP basiert. Der Prozess der Migration vonCE 5.0 auf CE 6.0 und die neue IDE (Microsoft Visual Studio 2005 mit Ergänzungen Platform Builder für CE 6.0) bedeckt die nachstehenden Schritte

Verlagerung der OAL-Schicht

Kopieren eines vorhandenen BSP für „RMI Alchemy ™ DBAu1550 ™ Development Board“ CE 5.0
Veränderung der Verzeichnisstruktur von OAL Schicht, die Aufteilung in Module OAL, Kittel undSystemkerne zu spiegeln
Gebrauch der neuen Namen für den ausführbare Baudateien (np. nk.exe, kitl.dll)
Verteilung nk.exe (OAL mit KITL + Kern) aus CE 5.0 für getrennte Modi:
- nk.exe – Startkode und Implemetierung der OAL-Schicht
- kernel.dll – Implementierung des Kernsystems unabhägig von OAL-Schicht, die vom Microsoft geliefert wird
- kitl.dll – Unterstützung zu KITL abhängig von Gerätsplattform
Veränderung / Hinzufägung von ein paaren Funktionen in den OAL und KITL-Schichten Dodanie kilku funkcji w warstwie OAL i KITL, die durch den Kern erforderlich sind (OEMGLOBAL-Struktur diefiniert alle Funktionen und Variablen, die die OAL-Schicht implementieren muss)
Die Schnittstelle zwischen dem Kern und der OAL-Schicht ist in den gemeinsamen Strukturen definiert und direkte Verweise auf die internen Funktionen des Kernels, OAL und Kleider nicht mehr möglichsind- man soll eine spezielle Schnittstelle mit NKStub.lib verwenden (Bibliothek, die dieSchnittstelle vom Kern bedeckt, also die exportierten Funktionen und Variablen die in der NKGLOBALStruktur definiert sind) und Funktionen KITLIoctl () OEMIoControl ().

Verlagerung der Treiberschicht

Die folgenden OEM-Treiber und spezifische für die Entwicklungsplattform (Development Board) wurden überprüft und an die Anforderungen der CE 6.0 abgestimmt:

Au1550 PSC AC97 Audio, PSC I2S Audio – Tontreiber
Alchemy ATI Rage XL, Silicon Motion Voyager – Displaytreiber
Alchemy Ethernet, Alchemy PCMCIA, Alchemy Serial, Alchemy USB (OHCD) host controller, Alchemy USB Function, Au1550 PSC SPI Controller – Gruppe von Treibern, die Kommunikationsbusse und Schnittstellen zur Kommunikation mit anderen Geräten unterstützen
Highpoint HPT371/372 IDE Controller, Au1550 NAND FLASH Controller – Treiber der Datenträger

Projekt

Programmierungskreis: Platform Development Tools integriert mit Visual Studio® 2005 (ersetzt die bisherige separate Platform Builder-Umgebung)
Programmierungssprache: C, C++ (für manche Treiber)
Größe: 5 Person-Monaten