Przeniesienie BSP z Win CE 5.0 do 6.0
28 października 2016
BSP (ang. Board Support Package) to oprogramowanie które implementuje i wspiera system operacyjny na standardowej platformie rozwojowej (ang. SDB – Standard Development Board). Zazwyczaj składa się z programu rozruchowego (ang. boot loader), warstwy OAL (ang. OEM Adaptation Layer), sterowników urządzeń i plików konfiguracyjnych dla uruchomieniowego obrazu systemu.
System Windows Embedded CE 6.0 cechuje się zupełnie zreorganizowanym jądrem systemu wprowadzającym zestaw nowych, istotnych elementów takich jak dwa tryby pracy sterowników urządzeń (Tryb Jądra i Tryb Użytkownika), funkcje systemowego API (ang. Application Programming Interface) przesunięte (z ich własnych procesów w trybie użytkownika) do bibliotek pracujących w trybie jądra czy też nowa architektura pamięci operacyjnej usuwająca dotychczasowe ograniczenia (teraz możliwa jest równoczesna obsługa do 32 tysięcy procesów z przestrzenią adresową 2 GB pamięci wirtualnej dla każdego procesu).
Dodatkowo kod warstwy OAL (nk.exe) i kod jądra systemu operacyjnego (kernel.dll) są teraz rozdzielone i mogą komunikować się ze sobą tylko poprzez ściśle zdefiniowane interfejsy.
Cechy szczególne:
Przeniesienie BSP dla „RMI Alchemy™ DBAu1550™ Development Board” (dostarczone przez BSQUARE Corporation) z Windows CE 5.0 to CE 6.0.
- RMI Alchemy™ DBAu1550™ Development Board
- Au1550™ sieciowy procesor bezpieczeństwa oparty na architekturze MIPS32
- nowe BSP bazujące na:
- jednym z istniejących BSP dla Win CE 6.0 dla procesora MIPSII
- istniejącym BSP dla „RMI Alchemy™ DBAu1550™ Development Board” dla Win CE 5.0
- proces migracji z CE 5.0 do CE 6.0 i do nowego IDE (Microsoft Visual Studio 2005 z dodatkami Platform Builder dla CE 6.0)
- rozdzielenie kodu warstwy OAL i jądra systemu operacyjnego
- zweryfikowanie programu rozruchowego i sterowników urządzeń względem nowych wymagań CE 6.0.
Zmiany w Głównych Modułach
- Kod warstwy OAL (nk.exe) i kod jądra systemu operacyjnego (kernel.dll) są rozdzielone.
- Aby zwiększyć wydajność funkcje API systemowego zostały wyjęte z ich własnych procesów w trybie użytkownika i umieszczone w bibliotekach pracujących w trybie jądra:
- filesys.dll – Rejestr, system plików i bazy danych
- gwes.dll – Interfejs graficzny, obsługa zdarzeń
- device.dll – Zarządzanie sterownikami urządzeń w trybie jądra.
- Menedżer usług składa się z procesu hosta usług systemowych (servicesd.exe) i interfejsu wiersza poleceń do konfigurowania usług (services.exe).
- Nowy, oddzielny proces zarządzający sterownikami urządzeń w trybie użytkownika (udevice.exe).
Nowa Architektura Pamięci Operacyjnej
Nowa Architektura Pamięci Operacyjnej usuwająca dotychczasowe ograniczenia
- każdy proces otrzymuje własną, naprawdę prywatną przestrzeń adresową (żaden proces aplikacji nie może „zaglądnąć” do przestrzeni adresowej żadnego innego procesu aplikacji)
- teoretyczne maximum 32K procesów obsługiwanych równocześnie (zamiast 32)
- większa przestrzeń adresowa – 2 GB pamięci wirtualnej dla każdego procesu (zamiast 32 MB).
Działanie w Trybie Jądra
- Procesor musi wspierać dwa poziomy uprzywilejowania:
- Tryb Jądra (wyższy)
- Tryb Użytkownika (niższy)
- Tylko mieszany tryb działania jest wspierany. Wszystkie aplikacje są ładowane do przestrzeni adresowej użytkownika, a wszystkie komponenty systemu operacyjnego do przestrzeni adresowej jądra (jest to wolniejsze niż uruchomienie całego systemu w trybie jądra ale dzięki temu całe środowisko działa stabilniej i bezpieczniej).
- Niektóre biblioteki systemowe istnieją w obu wersjach (dla trybu użytkownika i dla trybu jądra) aby zminimalizować koszt wywoływania funkcji poprzez granicę poziomów uprzywilejowania (np. systemowa biblioteka Core – coredll.dll oraz k.coredll.dll).
Dwa Tryby Pracy Sterowników Urządzeń
- sterowniki Trybu Jądra – funkcjonalność starego device.exe została przesunięta do jądra aby zwiększyć wydajność systemu. Sterowniki te muszą być bardzo dobrze przetestowane i stabilne aby nie spowodowały awarii jądra i całego systemu
- sterowniki Trybu Użytkownika – nowy, lepiej chroniony proces dla urządzeń użytkownika (udevice.exe) zwiększający stabilność i bezpieczeństwo – odpowiedni dla niezaufanych sterowników firm trzecich albo niestabilnych sterowników wymagających testów w trybie użytkownika przed umieszczeniem ich w trybie jądra. Każdy pojedynczy sterownik trybu użytkownika (lub ich grupa) może być uruchomiony na osobnej instancji udevice.exe.
Ograniczenia nowego API
- funkcje już nie wspierane – SetKMode, SetProcPermissions / GetCurrentPermissions, MapCallerPtr, MapPtrToProcess
- funkcja VirtualCopy – w przypadku wywoływania VirtualCopy w sterownikach trybu użytkownika, sprawdzane będą adresy aby upewnić się że sterownik ma prawo dostępu do żądanego adresu fizycznego
- warstwa OAL może korzystać tylko z tych funkcji jądra systemu które zostały wyeksportowane.
Wpływ nowego CE 6.0
Wpływ nowego CE 6.0 na istniejące sterowniki i oprogramowanie
- Kompatybilność Binarna dla aplikacji, czyli dobrze napisane aplikacje powinny działać po małych / żadnych przeróbkach (pamięć jest alokowana tymi samymi funkcjami API, a dane są wciąż przechowywane z użyciem 32-bitowych wskaźników pamięci wirtualnej). Duże bloki danych alokowane funkcją VirtualAlloc zamiast funkcjami alokowania pamięci współdzielonej (np. MapViewOfFile) z wcześniejszych wersji CE.
- Kompatybilność zachowana poprzez CoreDLL ze zminimalizowanym wpływem na API Win32 i zmianami ukrytymi w bibliotekach API.
- Aplikacje korzystające z nieudokumentowanych technik (takich jak przekazywanie uchwytów albo wskaźników pomiędzy procesami) będą najprawdopodobniej musiały zostać zmodyfikowane.
- Zmiany dotkną głównie sterowniki i serwisy:
- w większości przypadków sterowniki będą przeniesione małym nakładem pracy
- w przypadku niestandardowych rozwiązań programistycznych albo w przypadku użycia nieudokumentowanych funkcji może okazać się konieczne przebudowanie wewnętrznej struktury lub interfejsu sterownika
- sterowniki które potrzebują dostępu (odczyt/zapis) do danych w przestrzeni adresowej aplikacji muszą być uruchamiane w trybie jądra (ponieważ funkcja SetKMode i ustawianie dla procesu praw dostępu do innych procesów nie są już wspierane)
- sterownik urządzenia może być uruchamiany w trybie użytkownika przy pomocy procesu menedżera sterowników w trybie użytkownika – udevice.exe.
Nowe BSP bazuje na jednym z istniejących BSP dla procesora MIPSII dostarczanego przez Microsoft razem z dodatkami Platform Builder dla CE 6.0 do Microsoft Visual Studio 2005 oraz na istniejącym BSP dla „RMI Alchemy™ DBAu1550™ Development Board” dla Win CE 5.0. Proces migracji z CE 5.0 do CE 6.0 oraz do nowego IDE (Microsoft Visual Studio 2005 z dodatkami Platform Builder dla CE 6.0) obejmował kroki przedstawione poniżej.
Przeniesienie warstwy OAL
- skopiowanie istniejącego BSP dla „RMI Alchemy™ DBAu1550™ Development Board” CE 5.0
- zmodyfikowanie struktury katalogów warstwy OAL aby odzwierciedlała podział na moduły OAL, KITL i Jądra Systemu
- użycie nowych nazw dla budowanych plików wykonywalnych (np. nk.exe, kitl.dll)
- rozdzielenie nk.exe (OAL z KITL + Jądro) z CE 5.0 na osobne moduły:
- nk.exe – kod startowy i implementacja warstwy OAL
- kernel.dll – implementacja jądra systemu niezależna od warstwy OAL dostarczona przez Microsoft
- kitl.dll – wsparcie do KITL zależne od platformy sprzętowej
- zmiana / dodanie kilku funkcji w warstwie OAL i KITL które są wymagane przez jądro (struktura OEMGLOBAL definiuje wszystkie funkcje i zmienne które warstwa OAL musi implementować)
- interfejs pomiędzy warstwą OAL a jądrem jest dobrze zdefiniowany we współdzielonych strukturach, a bezpośrednie odwołania do wewnętrznych funkcji z jądra, OAL i KITL nie są już możliwe – należy użyć dedykowany interfejs z NKStub.lib (biblioteka przykrywająca interfejs jądra, czyli wyeksportowane funkcje i zmienne zdefiniowane w strukturze NKGLOBAL) i funkcji KITLIoctl(), OEMIoControl().
Przeniesienie warstwy sterowników
Następujące sterowniki OEM i specyficzne dla platformy rozwojowej (development board) zostały zweryfikowane i dopasowane do wymagań CE 6.0:
- Au1550 PSC AC97 Audio, PSC I2S Audio – sterowniki dźwięku
- Alchemy ATI Rage XL, Silicon Motion Voyager – sterowniki wyświetlaczy
- Alchemy Ethernet, Alchemy PCMCIA, Alchemy Serial, Alchemy USB (OHCD) host controller, Alchemy USB Function, Au1550 PSC SPI Controller – grupa sterowników obsługujących magistrale komunikacyjne i interfejsy używane do komunikacji z innymi urządzeniami
- Highpoint HPT371/372 IDE Controller, Au1550 NAND FLASH Controller – sterowniki nośników danych
Projekt
- środowisko programistyczne: Platform Development Tools zintegrowane z Visual Studio® 2005 (zastępuje wcześniejsze osobne środowisko Platform Builder)
- język programowania: C, C++ (dla niektórych sterowników)
- wielkość: 5 osobo-miesięcy
Jeden z naszych zespołów w czasie pracy nad projektem:
