Podręcznik użytkownika jądra trybu Falcon Fast Boot NXP AN14093

Rodzina i.MX 9 (i.MX 93 LPDDR4 EVK) Cele tego dokumentu są następujące:
Optymalizacje bootloadera
Optymalizacje jądra Linuksa i przestrzeni użytkownika
Porównanie domyślnego i ulepszonego czasu uruchamiania na wszystkich platformach

Środowisko oprogramowania

Zakłada się, że jest to komputer z systemem Ubuntu 20.04. W procesie optymalizacji używany jest pakiet obsługi płyty głównej Linux (BSP) w wersji 6.1.22_2.0.0.

Używane są następujące obrazy wstępne:

i.MX 8M Mini: imx-image-full-imx8mmevk.wic
i.MX 8M Nano: imx-image-full-imx8mnevk.wic
i.MX 8M Plus: imx-image-full-imx8mpevk.wic
i.MX 93: imx-image-full-imx93evk.wic

Zapisz gotowy obraz na karcie SD, używając poniższego polecenia:
$ sudo dd if=.wic of=/dev/sd bs=1M status=postęp konv=fsync

Notatka: Sprawdź partycję czytnika kart i zamień SD na odpowiednią partycję.

Konfiguracja sprzętu i wyposażenie

Rozwój zestaw NXP i.MX 8MM EVK LPDDR4
Rozwój zestaw NXP i.MX 8MN EVK LPDDR4
Rozwój zestaw NXP i.MX 8MP EVK LPDDR4
Rozwój zestaw NXP i.MX 93 EVK do 11×11 mm LPDDR4

Karta microSD: SanDisk Ultra 32 GB micro Secure Digital High Pojemność (SDHC) I Klasa 10 została użyta do
aktualny eksperyment
Kabel micro-USB (i.MX 8M) lub Type-C (i.MX 93) do portu debugowania

Opis ogólny

W tej sekcji opisano overview typowych modyfikacji wymaganych do uzyskania krótszych czasów uruchamiania.

Skróć czas bootloadera
Możesz wybrać jeden z dwóch poniższych sposobów skrócenia czasu ładowania programu ładującego.

Usuń opóźnienie rozruchu — Oszczędza około dwóch sekund w porównaniu z konfiguracją domyślną, wymagając jednocześnie minimalnych zmian. Prowadzi to do tego, że U-Boot pomija oczekiwanie na naciśnięcie klawisza stage podczas uruchamiania.
Zaimplementuj tryb Falcona — Oszczędność około czterech sekund w porównaniu z konfiguracją domyślną. Umożliwia drugiemu programowi ładującemu (SPL), będącemu częścią U-Boot, bezpośrednie ładowanie jądra, pomijając pełny U-Boot.

Skróć czas uruchamiania jądra Linuksa

Zmniejsz liczbę komunikatów konsoli — Oszczędność około trzech sekund. Dodaj ciszę do wiersza poleceń jądra.
Odchudź jądro, usuwając sterowniki i filesystemy — Domyślnie obraz jądra zawiera wiele sterowników i filesystemów (np. UBIFS), aby umożliwić większość funkcjonalności obsługiwanych przez płytkę. Lista dołączonych sterowników i filesystemy można przycinać w zależności od przypadku użycia.

Skróć czas uruchamiania w przestrzeni użytkownika

Zmień kolejność uruchamiania w skryptach systemowych inicjalizacji — Oszczędza około 600 ms. Uruchom żądany proces tak szybko, jak to możliwe, biorąc pod uwagę jego zależności

Pomiary

Zakres pomiarów mieści się pomiędzy płytką POR (Power-On Reset) a rozpoczęciem procesu INIT.

Konfiguracja zastosowana do poniższych pomiarów jest opisana w dokumencie Metodologia pomiarów czasu rozruchu.

Tabela 1. Zmierzone interwały

Punkt czasowy	Odstęp między impulsami	Lokalizacja pulsu	Butytages
Pamięć ROM-owa	nRST -> przed ddr_init()	tablica/freescale/ /spl.c/board_init_ f()	SPL
Inicjalizacja DDR	przed ddr_init() -> po ddr_init()	tablica/freescale/ /spl.c/board_init_ f()
Inicjalizacja SPL + Załaduj obraz U-Boot	po ddr_init() -> przed image_entry()	common/spl/spl.c/jump_to_image_no_ args()
Inicjalizacja U-Boota (init_sequence_f)	przed image_entry() -> rozpocznij init_ sekwencję_ r	common/board_r.c/board_init_r()	U BOOT
Inicjalizacja U-Boota (init_sequence_r)	uruchom init_sequence_r -> u-boot main_ pętla	wspólne/główne.c
Sekwencja rozruchowa	u-boot main_loop -> przed załadowaniem_obrazu	zawiera/configs/ .H
Ładowanie obrazu jądra	przed obrazem_ładowania -> po obrazie_ładowania	zawiera/configs/ .H
Uruchomienie jądra do czasu procesu INIT	po załadowaniu obrazu -> /sbin/init	uzyskać czasamp podczas uruchamiania jądra	Jądro

Wymagania wstępne

W tej sekcji opisano oprogramowanie potrzebne do skompilowania U-Boota i jądra Linuksa w samodzielnym środowisku.

Zainstaluj wymagane zależności

Ten przewodnik wymaga szeregu zależności, w tym kompilatora krzyżowego ARM64.
$ sudo apt install flex bison libssl-dev gcc-aarch64-linux-gnu u-boot-tools libncurses5-dev libncursesw5-dev uuid-dev gnutls-dev

Następnie pobierz wymagane źródła. Umieść je wszystkie w tym samym katalogu.

Pobierz plik imx-mkimage

obraz mk to narzędzie, które łączy oprogramowanie SPL, właściwy U-Boot, ATF i DDR w jeden obraz, w wyniku czego obraz U-Boot jest flashowany na karcie SD.

$ git klonuj https://github.com/nxp-imx/imx-mkimage
$ cd imx-mkimage
$ git kasa lf-6.1.22-2.0.0

Pobierz ATF-a

$ git klonuj https://github.com/nxp-imx/imx-atf
$ cd imx-atf
$ git kasa lf-6.1.22-2.0.0

Pobierz U-Boota

$ git klonuj https://github.com/nxp-imx/uboot-imx
$ cd uboot-imx
$ git kasa lf-6.1.22-2.0.0

Pobierz jądro Linuksa

$ git klonuj https://github.com/nxp-imx/linux-imx
$ cd linux-imx
$ git kasa lf-6.1.22-2.0.0

Pobierz oprogramowanie sprzętowe o podwójnej szybkości transmisji danych (DDR).

$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.20.bin
$ chmod +x firmware-imx-8.20.bin
$ ./firmware-imx-8.20.bin

[Tylko dla i.MX 93] Pobierz oprogramowanie sprzętowe EdgeLock Secure Enclave (ELE).

$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.9.bin
$ chmod +x oprogramowanie-sentinel-0.9.bin
$ ./firmware-sentinel-0.9.bin

Buduj obrazy

Opcjonalnie, aby sprawdzić, czy źródła i wymagania wstępne zostały pobrane poprawnie, wykonaj następujące kroki. W przeciwnym razie pomiń na razie i zastosuj Sekcja 7 „Optymalizacja programu ładującego” i Sekcja 8 „Optymalizacja przestrzeni jądra”.

Zbuduj oprogramowanie sprzętowe Arm Trusted

$ CROSS_COMPILE=aarch64-linux-gnu-make PLAT= bl31 Gdzie może przyjmować następujące wartości: imx8mn, imx8mm, imx8mp lub imx93.
Wygenerowany plik binarny znajduje się w katalogu build//release/.

Zbuduj U-Boota

Skopiuj bl31.bin z ATF (build//release/) do ix-mkimage//
Skopiuj wszystko lpddr4* files z firmware/ddr/synopsys/ pakietu firmware-imx do imxmkimage//.
[Tylko dla i.MX 93] Skopiuj obraz kontenera oprogramowania układowego ELE mx93a0-ahab-container.img z oprogramowania sprzętowego-sentinel do ix-mkimage/iMX9/.
Skompiluj U-Boota.
$ cd uboot-imx $ make distclean
$ ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-make
$ CROSS_COMPILE=aarch64-linux-gnu-make -j
$(nproc –wszystko)
Aby zbudować U-Boota bez obsługi Falcona (domyślny tryb rozruchu sprawdzający, czy wszystko się kompiluje), użyj następującego pliku .
1. imx8mm_evk_defconfig dla i.MX 8MM
2. imx8mn_evk_defconfig dla i.MX 8MN
3. imx8mp_evk_defconfig dla i.MX 8MP
4. imx93_11x11_evk_defconfig dla i.MX 93 Dla trybu Falcon jest (użyj tego defconfig file dopiero po Sekcji 7.3 „Implementacja trybu Falcon”).
5. imx8mm_evk_falcon_defconfig dla i.MX 8MM
6. imx8mn_evk_falcon_defconfig dla i.MX 8MN
7. imx8mp_evk_falcon_defconfig dla i.MX 8MP
8. imx93_11x11_evk_falcon_defconfig dla i.MX 93
Skopiuj u-boot*.bin i spl/u-boot-spl*.bin do imx-mkimage//.
Skopiuj imx8mm-evk.dtb (dla i.MX 8M Mini LPDDR4 EVK) lub imx8mn-evk.dtb (dla i.MX 8M Nano LPDDR4 EVK) lub imx8mp-evk.dtb (dla i.MX 8M Plus LPDDR4 EVK) lub imx93 -11×11-evk.dtb dla (i.MX 93 11×11 LPDDR4 EVK) z uboot-imx/arch/arm/dts/ do ix-mkimage//.
Skopiuj mkimage z uboot-imx/tools/ do ix-mkimage//, zmieniając nazwę na mkimage_uboot.
$ cp uboot-imx/tools/mkimage imx-mkimage//mkimage_uboot
Wygeneruj pełny obraz U-Boota: flash.bin.
$ cd imx-mkimage # dla i.MX 8M*
$ make SOC= flash_evk # dla i.MX 93
$ make SOC=iMX9 flash_singleboot
Gdzie mogą przyjmować następujące wartości: iMX8MM, iMX8MN, iMX8MP.

Zbuduj jądro Linuksa

$ cd linux-imx
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make imx_v8_defconfig
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j $(nproc –all) wszystko

Wynikowy obraz binarny znajduje się w katalogu arch/arm64/boot.

Zapisz pliki binarne na karcie SD

Aby sprawdzić, czy kompilacja jest poprawna, zapisz wynikowe pliki binarne na karcie SD i uruchom płytkę.

Napisz obraz U-Boota:
$ sudo dd if=flash.bin of=/dev/sd bs=1k search= conv=fsync
Gdzie jest:
32 – dla i.MX 8M Nano, i.MX 8M Plus i i.MX 93
33 – dla i.MX 8M Mini
Napisz jądro Linuksa:
$ sudo mount /dev/sd1 /mnt
$ cp Obraz /mnt
$ kwota / mnt

Optymalizacje bootloadera

W tym rozdziale znajdują się następujące informacje.

Sekcja 7.1 „Domyślny tryb rozruchu”
Sekcja 7.2 „Tryb Sokoła”
Sekcja 7.3 „Implementacja trybu Falcon”
Sekcja 7.4 „Mapa pamięci”
Sekcja 7.5 „Wywołania funkcji w trybie Falcon”

Domyślny tryb rozruchu

Rysunek 1 opisuje domyślną sekwencję rozruchową. Po włączeniu lub zresetowaniu i.MX 8M uruchamia Boot ROM (główny moduł ładujący programy), przechowywany w jego pamięci tylko do odczytu (ROM).

Boot ROM konfiguruje system na chipie (SoC), wykonując podstawowe inicjalizacje urządzeń peryferyjnych, takie jak pętle fazowe (PLL), konfiguracje zegara, inicjalizacja pamięci (SRAM). Następnie znajduje urządzenie rozruchowe, z którego ładuje obraz programu ładującego, który może zawierać następujące komponenty: U-Boot SPL, ATF, U-Boot i tak dalej.

Typowy obraz U-Boota nie mieści się w wewnętrznej pamięci SRAM i dlatego jest podzielony na dwie części: dodatkowy moduł ładujący programy (SPL) i właściwy U-Boot.

SPL jest pierwszym stage bootloadera, mniejszego, wstępnie załadowanego, który ma takie same źródła jak U-Boot, ale z minimalnym zestawem kodu mieszczącym się w SRAM. SPL jest ładowany do SRAM. Konfiguruje i inicjuje niektóre urządzenia peryferyjne oraz, co najważniejsze, dynamiczną pamięć o dostępie swobodnym (DRAM). Później ładuje właściwy ATF i U-Boot do pamięci DRAM. Ostatnim krokiem jest przeskoczenie do ATF, który z kolei przeskoczy do właściwego U-Boota.

Zaufane oprogramowanie sprzętowe Arm (ATF), dołączony niedawno do rodziny i.MX8*, zapewnia referencyjną bazę zaufanego kodu dla architektury Armv8. Implementuje różne standardy interfejsu Arm, w tym interfejs koordynacji stanu zasilania (PSCI). Plik binarny jest zazwyczaj zawarty w pliku binarnym programu ładującego. Rozpoczyna się na początku stages U-Boota. Bez ATF jądro nie może skonfigurować usług, które muszą być wykonywane w środowisku Secure World.

Prawidłowy U-Boot to drugie stagprogram ładujący. Oferuje elastyczny sposób ładowania i uruchamiania jądra Linuksa. Zapewnia także minimalny zestaw narzędzi do interakcji ze sprzętem na płycie za pośrednictwem interfejsu wiersza poleceń. Działa z pamięci DRAM i inicjuje dodatkowe urządzenia sprzętowe. Na przykładampplik, sieć, USB i DSI/CSI. Następnie ładuje i przygotowuje drzewo urządzeń (FDT). Głównym zadaniem U-Boota jest ładowanie i uruchamianie samego obrazu jądra.

Jądro Linuxa działa z pamięci DRAM i całkowicie przejmuje kontrolę nad systemem. Od tego momentu U-Boot nie ma już kontroli nad systemem.

Tryb Sokoła
Tryb Falcon to funkcja w U-Boot, która umożliwia szybkie uruchamianie, umożliwiając SPL uruchomienie jądra Linuksa.
Całkowicie pomija ładowanie i inicjalizację U-Boota, co skutkuje skróceniem czasu spędzanego w bootloaderze.

Rysunek 2 ilustruje sekwencję uruchamiania trybu Falcon.

Aby zaimplementować ten tryb, wykonaj następujące czynności:

Aktywuj określone konfiguracje dla Falcona.
Przygotuj wcześniej spłaszczone drzewo urządzeń (FDT).
Skonfiguruj ATF, aby przejść do jądra.
Wygeneruj obraz drzewa spłaszczonego obrazu jądra (FIT) zawierający plik ATF i obraz jądra.

Implementacja trybu Falcon

Dla ułatwienia wdrożenia przygotowano szereg poprawek umożliwiających włączenie trybu Falcon.
Pobierz powiązane oprogramowanie AN14093SW.zip, aby pobrać poprawki i wykonaj następujące kroki.

Zastosuj łatkę U-Boot:
$ cd uboot-imx
$ git am 0001-Enable-Fast-Boot-on-i.MX-8M-Family-and-i.MX-93.patch

Ta poprawka tworzy konfigurację Falcona files dla każdej platformy (i.MX 8M i i.MX 93), które można znaleźć w katalogu uboot-imx/configs/ pod nazwą: _falcon_ defconfig. Konfiguracja files są oparte na domyślnych _defconfig, do których dodano obsługę Falcona w następujący sposób.

Włączone parametry [=y]

CONFIG_SPL_SERIAL
CONFIG_CMD_SPL — Włącza polecenie eksportu spl w U-Boot; wymagane dla kroku 15.
CONFIG_SPL_MMC — Umożliwia SPL odczyt z MMC przy użyciu API SPL MMC.

CONFIG_MMC_BROKEN_CD [tylko dla i.MX 93]
CONFIG_SPL_FS_FAT — Umożliwia SPL odczyt z partycji FAT.
CONFIG_SPL_LOAD_FIT
KONFIG_FIT
CONFIG_SPL_OS_BOOT — Aktywuje tryb Sokoła.
KONFIG_SPL_MMC_IO_VOLTAGE i CONFIG_SPL_MMC_UHS_SUPPORT — Włącz szybki transfer MMC dla SPL, używany do skrócenia czasu ładowania obrazu jądra (*nie działa dla i.MX 8MM
ponieważ SPL DM nie jest obsługiwany ze względu na ograniczenie rozmiaru OCRAM).
CONFIG_LTO [tylko dla i.MX 8MN] — Zmniejsza rozmiar pliku binarnego poprzez dodanie optymalizacji czasu łącza. Wymagane w i.MX 8M Nano, aby zapewnić dopasowanie obrazu SPL z obsługą FAT.
Wyłączony parametr [=n]
CONFIG_SPL_BOOTROM_SUPPORT
Ustaw parametry
CONFIG_SYS_SPL_ARGS_ADDR
Z:
0x43000000 dla i.MX 8MN, i.MX 8MM i i.MX 8MP
0x83000000 dla i.MX 93
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME z u-boot.itb
CONFIG_SPL_FS_LOAD_KERNEL_NAME z Image.itb
CONFIG_SPL_FS_LOAD_ARGS_NAME z:

imx8mm-evk-falcon.dtb dla i.MX 8MM
imx8mn-evk-falcon.dtb dla i.MX 8MN
imx8mp-evk-falcon.dtb dla i.MX 8MP
imx93-11×11-evk-falcon.dtb dla i.MX 93
CONFIG_CMD_SPL_WRITE_SIZE z 0xC000
CONFIG_FIT_EXTERNAL_OFFSET=0x3000 [tylko dla i.MX 93]
Dodatkowo łatka implementuje funkcję spl_start_uboot(), znajdującą się w pliku uboot-imx/board/freescale//spl.c, gdzie znajduje się: imx8mm_evk, imx8mn_evk, imx8mp_evk lub imx93_evk. Ta funkcja sprawdza, czy SPL powinien uruchomić jądro, czy U-Boot. Jeśli podczas uruchamiania zostanie naciśnięty klawisz „c”, funkcja zwróci wartość 1, co oznacza, że należy uruchomić U-Boot. W przeciwnym razie SPL powinien uruchomić jądro. Aby przywrócić go do stanu operacyjnego, w którym Ethernet MAC może współdziałać z PHY, należy zresetować PHY z SPL dla rodziny i.MX 8M. Jest to również dodawane podczas stosowania łatki U-Boot. PHY jest resetowany w funkcji board_init_r(), znajdującej się w pliku uboot-imx/common/spl/spl.c file.

Zastosuj łatkę ATF:
$ cd imx-atf
$ git am 0001-Dodaj-obsługę-przeskoku-do-jądra-bezpośrednio-z-ATF.patch
Łatka dodaje obsługę przeskakiwania bezpośrednio do jądra. Ponieważ ATF nie obsługuje bezpośredniego przeskakiwania do jądra na platformach NXP, adres FDT musi zostać przekazany jako argument w funkcji bl31_early_platform_setup2(), znajdującej się w imx-atf/plat/imx/imx8m// _bl31_setup.c dla i.MX8M Family i imx-atf/plat/imx/imx93/imx93_bl31_setup.c dla i.MX93.

Zastosuj łatkę mkimage:

$ cd imx-mkimage
$ git am 0001-Add-scripts-for-Fast-Boot-implementation-for-i.MX8M-.patch

Ta poprawka dodaje właściwość „os” do węzła uboot-1 źródła obrazu U-Boot FIT (u-boot.its). Ta właściwość jest wymagana podczas ładowania U-Boot (przypadek, gdy spl_start_uboot() zwraca 1), podczas gdy Falcon Tryb jest włączony. W przeciwnym razie U-Boot nie uruchomi się.
Dodatkowo patch dodaje skrypt generujący obraz U-Boot FIT dla i.MX 93 (ponieważ w tej wersji nie istnieje): imx-mkimage/iMX9/mkimage_fit_atf.sh.
Drugi skrypt dodany przez tę łatkę to ten służący do generowania obrazu FIT jądra (ATF + jądro) – potrzebnego do implementacji trybu Falcon. Ten skrypt jest używany zarówno w rodzinie i.MX 8M, jak i i.MX 93.

Zbuduj ATF zgodnie z opisem w Rozdział 5.1. Skopiuj zmodyfikowany plik binarny ATF do ix-mkimage//.
Zbuduj obraz bootloadera zgodnie z opisem w Sekcji 5.2 – Tryb Falcon. Zapisz wynikowy plik binarny U-Boota zgodnie z sekcją 6.
[Tylko dla i.MX93] Wygeneruj obraz U-Boot FIT. Podczas budowania obrazu flash.bin obraz FIT u-boot.itb nie jest tworzony automatycznie dla i.MX93, ponieważ nie istnieje żaden skrypt, który go generuje.
$ CD imx-mkimage/iMX9
$ DEK_BLOB_LOAD_ADDR=0x80400000 TEE_LOAD_ADDR=0x96000000
ATF_LOAD_ADDR=0x204e0000 ./mkimage_fit_atf.sh imx93-11×11-evk.dtb > u-boot.its
$ ./mkimage_uboot -E -p 0x3000 -f u-boot.its u-boot.itb

Skopiuj plik binarny u-boot.itb znajdujący się w imx-mkimage/ na pierwszej partycji (FAT) karty SD.
Przed zbudowaniem jądra Linuksa możesz je zoptymalizować zgodnie z sekcją 8.2 „Usuń niepotrzebne sterowniki i file systemy”. Zbuduj jądro Linuksa zgodnie z sekcją 5.3 „Budowanie jądra Linuksa”.
Wygeneruj obraz FIT jądra. Obraz FIT zawiera ATF i obraz jądra. Jest to ładowane w trybie Falcon przez SPL. Ponieważ SPL nie ładuje obrazu ATF w trybie Falcon, ATF musi zostać uwzględniony w obrazie FIT.
Do przygotowania obrazu FIT (Image.itb) wykorzystywany jest skrypt mkimage_fit_atf_kernel.sh. Skopiuj obraz jądra do katalogu imx-mkimage//:
$ cp linux-imx/arch/arm64/boot/Obraz imx-mkimage/
Wygeneruj obraz FIT:
- Dla i.MX8M
  $ CD imx-mkimage/iMX8M
  # dla i.MX8MM
  $ ATF_LOAD_ADDR=0x00920000 KERNEL_LOAD_ADDR=0x40200000 ../mkimage_fit_atf_kernel.sh
  > Obraz.it
  # dla i.MX8MN
  $ ATF_LOAD_ADDR=0x00960000 KERNEL_LOAD_ADDR=0x40200000 ../mkimage_fit_atf_kernel.sh
  > Obraz.it
  # dla i.MX8MP
  $ ATF_LOAD_ADDR=0x00970000 KERNEL_LOAD_ADDR=0x40200000 ../mkimage_fit_atf_kernel.sh
  > Obraz.it
  # Aby wygenerować przebieg binarny FIT:
  $ ./mkimage_uboot -E -p 0x3000 -f Obraz.jego obraz.itb
- Dla i.MX93
  $ CD imx-mkimage/iMX9
  $ ATF_LOAD_ADDR=0x204e0000 KERNEL_LOAD_ADDR=0x80200000 ../
  mkimage_fit_atf_kernel.sh > Image.its
  # Aby wygenerować przebieg binarny FIT:
  $ ./mkimage_uboot -E -p 0x3000 -f Obraz.jego obraz.itb
Skopiuj wynikowy plik Image.itb file na pierwszą partycję (FAT) karty SD.

Przygotuj spłaszczone drzewo urządzeń i zapisz je na karcie SD. Podczas uruchamiania w trybie Falcon kluczowym krokiem jest przygotowanie drzewa urządzeń. Zwykle U-Boot wykonuje poprawki FDT podczas uruchamiania systemu Linux. Oznacza to, że do początkowego drzewa urządzeń U-Boot dodaje między innymi argumenty jądra i węzeł pamięci. Argumenty te można znaleźć w jednej z konfiguracji files: uboot-imx/configs/_evk.h, pod nazwą bootargs. Określają parametry konsoli i mówią jądru, gdzie znaleźć katalog główny file system. Gdzie jest: imx8mm, imx8mn, imx8mp lub imx93. Istnieją dwie metody generowania spłaszczonego drzewa urządzeń:
- Metoda 1: Dodając ręcznie wymagane poprawki do drzewa urządzeń
- Metoda 2: Pozwalając U-Bootowi na dokonanie poprawek i zapisanie wynikowego drzewa urządzeń, Metoda 2 jest bardziej ogólna i wymaga mniej wiedzy, ale jest również dłuższa i obejmuje kilka innych kroków.
  Metoda 1: Możesz spróbować wygenerować FDT ręcznie, dodając bootargs i węzeł pamięci do drzewa urządzeń jądra. Na przykładample, dla i.MX 93 utwórz plik imx93-11×11-evk-falcon.dts file w linuximx/arch/arm64/boot/dts/freescale i dodaj linie kodu poniżej. Węzeł pamięci jest kopiowany z DTS U-Boota. Dołączone drzewo urządzeń można zmienić w zależności od przypadku użycia. W tym przypadku używamy domyślnego drzewa urządzeń jądra.
  #include „imx93-11×11-evk.dts” / { pamięć { reg = <0x00 0x80000000 0x00 0x80000000>; typ_urządzenia = „pamięć”; }; wybrane { bootargs = „console=ttyLP0,115200 Earlycon root=/dev/mmcblk1p2 rootwait rw”; }; };
  Skompiluj ponownie jądro, aby wygenerować plik binarny powiązanego drzewa urządzeń i skopiuj wynikowy plik imx93-11×11-
  evk-falcon. dtb file do pierwszej partycji karty SD.
  Jeśli wybierzesz pierwszą metodę, następnym krokiem będzie uruchomienie płyty i tryb Falcon powinien działać.
  Metoda 2: FDT można przygotować za pomocą polecenia eksportu spl w programie U-Boottagmi. Aby wejść do U-Boota, przytrzymaj klawisz C. Polecenie jest równoznaczne z uruchomieniem boomu do czasu naprawienia drzewa urządzeń
  zrobione. Drzewo urządzeń w pamięci jest tym, które jest potrzebne do trybu Falcon. Ten obraz należy zapisać na partycji rozruchowej karty SD.
  [Wymagania wstępne]
  a. Zbuduj dziedzictwo jądra u Image file z obrazu.
  Obraz jest obrazem szczególnym file który dodaje 64-bajtowy nagłówek przed rzeczywistym obrazem jądra, gdzie znajduje się moduł ładujący
  określone są informacje (adres ładowania, punkt wejścia, typ systemu operacyjnego itd.).
  Ten typ obrazu jest potrzebny poleceniu spl do wygenerowania spłaszczonego drzewa urządzeń.
- Dla i.MX 8M
  $ CD linux-imx/arch/arm64/boot
  $ mkimage -A ramię -O linux -T jądro -C brak -a 0x43FFFFC0
  -e 0x44000000 -n „Jądro Linuksa” -d Obraz uImage
  Nazwa obrazka: Jądro Linuksa
  Utworzono: środa 26 lipca 14:12:09 2023
  Typ obrazu: Obraz jądra ARM Linux (nieskompresowany)
  Rozmiar danych: 31072768 bajtów = 30344.50 KiB = 29.63 MiB
  Załaduj adres: 43ffffc0
  Punkt wejścia: 44000000
- Dla i.MX 93
  $ CD linux-imx/arch/arm64/boot
  $ mkimage -A ramię -O linux -T jądro -C brak -a 0x83FFFFC0
  -e 0x84000000 -n „Jądro Linuksa” -d Obraz uImage
  Nazwa obrazka: Jądro Linuksa
  Utworzono: środa 26 lipca 14:14:09 2023
  Typ obrazu: Obraz jądra ARM Linux (nieskompresowany)
  Rozmiar danych: 31072768 bajtów = 30344.50 KiB = 29.63 MiB
  Załaduj adres: 83ffffc0
  Punkt wejścia: 84000000
  Gdzie:
  - A [Architektura]: Aby ustawić architekturę.
  - O [os]: Aby ustawić system operacyjny.
  - T [typ obrazu]: Aby ustawić typ obrazu.
  - C [typ kompresji]: Aby ustawić typ kompresji.
  - n [nazwa obrazu]: Aby ustawić nazwę obrazu na nazwę obrazu.
  - d [dane obrazu file]: Aby użyć danych obrazu z danych obrazu file.
  - a [adres ładowania]: Aby ustawić adres ładowania w postaci liczby szesnastkowej.
  - e [punkt wejścia]: Aby ustawić punkt wejścia za pomocą liczby szesnastkowej.
- b. Skopiuj jądro uImage na partycję EXT2 karty SD.
  sudo zamontuj /dev/sd2 /mnt
  $ sudo mkdir -p /mnt/home/root/.falcon
  $ sudo cp uImage /mnt/home/root/.falcon
  $ sudo umount /mnt
  Aby przygotować FDT za pomocą polecenia eksportu spl, wykonaj następujące kroki.
  1. Uruchom płytę w U-Boot i zatrzymaj ją tuż przed wejściem w sekwencję automatycznego rozruchu. Aby wejść do U-Boot, podczas uruchamiania należy nacisnąć klawisz „c”. W tym momencie tryb Falcon nie działa, ponieważ na karcie SD nie ma przygotowanego FDT dla jądra Linuksa.
  2. [Opcjonalnie] Jeśli potrzebujesz innego FDT niż domyślny, najpierw uruchom następujące polecenie. The file musi znajdować się na partycji FAT na karcie SD.
    u-boot=> setenv fdtfile .dtb
  3. Załaduj FDT do pamięci RAM.
    u-boot=> uruchom Loadfdt
    43801 bajtów odczytanych w 15 ms (2.8 MiB/s)
  4. Załaduj jądro uImage do pamięci RAM.
    u-boot=> ext2load mmc 1:2 ${loadaddr} /home/root/.falcon/uImage
    31072832 bajtów odczytanych w 387 ms (76.6 MiB/s)
  5. Jeśli potrzebujesz także optymalizacji czasu rozruchu jądra, uruchom polecenia z Sekcji 8.1 „Dodaj cichy”, krok 2, przed następnym krokiem.
  6. Załaduj argumenty rozruchowe jądra.
    u-boot=> spl eksport fdt ${loadaddr} – ${fdt_addr_r}
    ## Uruchamianie jądra ze starszego obrazu pod adresem 80400000…
    Nazwa obrazka: Jądro Linuksa
    Utworzono: 2023-07-19 6:57:40 UTC
    Typ obrazu: Obraz jądra ARM Linux (nieskompresowany)
    Rozmiar danych: 31072768 bajtów = 29.6 MiB
    Załaduj adres: 83ffffc0
    Punkt wejścia: 84000000
    Weryfikowanie sumy kontrolnej… OK
    ## Spłaszczony obiekt drzewa urządzeń w punkcie 83000000
    Rozruch przy użyciu blobu fdt pod adresem 0x83000000
    Roboczy FDT ustawiony na 83000000
    Ładowanie obrazu jądra
    Korzystanie z drzewa urządzeń w miejscu 0000000083000000, koniec 000000008300db18
    Roboczy FDT ustawiony na 83000000
    podkomenda nie powiodła się (err=-1)
    podkomenda nie powiodła się (err=-1)
    Korzystanie z drzewa urządzeń na miejscu pod adresem 0000000083000000, koniec 0000000083010b18
    Roboczy FDT ustawiony na 83000000
    Obraz argumentu znajduje się teraz w pamięci RAM: 0x0000000083000000
    Notatka: Różnica pomiędzy adresem początkowym i końcowym zaznaczonym pogrubioną czcionką powyżej to rozmiar poprawionego FDT w pamięci. Skopiuj wynikowy FDT z pamięci RAM na partycję FAT karty SD, podając jako ostatni parametr właściwy rozmiar kopii. W byłymample powyżej, będzie to 0x83010b18 – 0x83000000 = 0x10b18.
    # dla i.MX 93
    u-boot=> fatwrite mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} imx93-11×11-
    evk-falcon.dtb 0x10b18
    Notatka: Nazwa zapisanego FDT musi być zgodna z nazwą ustawioną w pliku
    Zmienna CONFIG_SPL_FS_LOAD_ARGS_NAME w kroku 1 z rozdziału 7.3 „Tryb Falcon”
    realizacja". W przeciwnym razie SPL nie ładuje drzewa urządzeń do pamięci DRAM i płyta nie uruchamia się.
Po ponownym uruchomieniu płyta domyślnie uruchomi się w trybie Falcon.

Mapa pamięci

Rysunek 3 to mapa pamięci w trybie Falcon dla i.MX93.
BootROM ładuje SPL, a SPL działa z wbudowanej pamięci RAM (OCRAM – wewnętrzna pamięć procesora). SPL inicjuje dynamiczną pamięć RAM (DDR), ładuje ATF do OCRAM, następnie ładuje drzewo urządzeń jądra i obraz jądra do DDR. SPL ma zarezerwowaną przestrzeń pamięci w DDR dla malloc. Obszar ten nie może być nadpisywany w trybie SPL

Tabela 2 wyświetla adresy rodziny i.MX 8M.

Tabela 2. Adresy rodziny i.MX 8M}

Platforma	SPL	ATF	Obraz jądra	Jądro DTB
i.MX 8M Mini	0x007e1000	0x00920000	0x40200000	0x43000000
i.MX 8M Nano	0x00912000	0x00960000	0x40200000	0x43000000
i.MX 8M Plus	0x00920000	0x00970000	0x40200000	0x43000000

Wywołania funkcji w trybie Falcon
Rysunek 4 zawiera listę ważnych funkcji wywoływanych w trybie SPL Falcon

Optymalizacje przestrzeni jądra

W tej sekcji wymieniono kroki opisane w Sekcji 8.1 „Dodaj cichy” i Sekcji 8.2 „Usuń niepotrzebne sterowniki i file „systemy”.

Dodaj ciszę
Aby skrócić czas działania jądra o około połowę, dodaj cichy argument w botargos jądra. Pomija komunikaty debugowania podczas sekwencji uruchamiania systemu Linux.

Notatka: Drzewo urządzeń należy zregenerować z nowymi bootargami za pomocą polecenia eksportu spl.

Aby wejść do U-Boot, przytrzymaj klawisz C podczas uruchamiania.
Edytuj parametr mmcargs, dodając ciszę.
u-boot=> edytuj mmcargs
edycja: setenv bootargs ${jh_clk} konsola=${console} root=${mmcroot} cicho
u-boot=>zapiszenv
Zapisywanie środowiska do MMC… Zapis do MMC(1)… OK

Zregeneruj i zapisz drzewo urządzeń na karcie SD jak w Sekcja 7.3 „Implementacja trybu Falcon”, krok 14.

Usuń niepotrzebne sterowniki i file systemy
W zależności od przypadku użycia możesz odchudzić jądro, usuwając niepotrzebne sterowniki i file systemy.
Możesz analizować funkcje jądra podczas rozruchu za pomocą biografii, funkcji jądra, która pozwala na wykreślenie tego, co dzieje się w jądrze podczas inicjalizacji.

Aby utworzyć bootgraf, wykonaj następujące kroki:

Dodaj initcall_debug do botargos jądra.
a. Aby wejść do U-Boot, przytrzymaj klawisz C podczas uruchamiania,
b. Edytuj parametr mmcargs, dodając plik initcall_debug
u-boot=> edytuj mmcargs
edycja: setenv bootargs ${jh_clk} konsola=${console} root=${mmcroot} cicho
initcall_debug
u-boot=>zapiszenv
Zapisywanie środowiska do MMC… Zapis do MMC(1)… OK

Zregeneruj i zapisz drzewo urządzeń na karcie SD jak w Sekcji 7.3 „Implementacja trybu Falcon”, krok 14.
Uruchom płytę i pobierz dziennik jądra
root@imx8mn-lpddr4-evk:~# dmesg > boot.log
Plik boot.log file zawiera dane takie jak poniższy dziennik. Dane można analizować pod kątem czasu spędzanego przez każdą funkcję podczas uruchamiania jądra.
[2.583922] initcall deferred_probe_initcall+0x0/0xb8 zwróciło 0 po 895357
[2.583955] wywołanie genpd_power_off_unused+0x0/0x98 @ 1
[2.583977] initcall genpd_power_off_unused+0x0/0x98 zwróciło 0 po 12 użyciach
[2.583984] wywołanie genpd_debug_init+0x0/0x90 @ 1
[2.584312] initcall genpd_debug_init+0x0/0x90 zwróciło 0 po 321 użyciach
[2.584333] wywołanie ubi_init+0x0/0x23c @ 1
[2.584627] initcall ubi_init+0x0/0x23c zwróciło 0 po 286 użyciach
Skopiuj wynikowy plik boot.log file na komputerze głównym. Wróć na komputer-host i utwórz wykres, używając następujących poleceń.
$ cd linux-imx/scripts
$ ./bootgraph.pl boot.log > boot.svg
Możesz uzyskać coś takiego i przeanalizować, w jaki sposób wykorzystywany jest czas rozruchu jądra.

Aby wyłączyć sterownik lub funkcję, zaktualizuj konfigurację jądra.
Na przykładample, wyłączyliśmy debugowanie z jądra (które zmniejsza rozmiar obrazu) i UBI file system.
a. Uruchom następujące polecenia, aby wejść do minicontig jądra.
$ cd linux-imx
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make imx_v8_defconfig
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-make minikontig
W menuconfig wyłącz CONFIG_UBIFS_FS i CONFIG_DEBUG_KERNEL, podobnie jak
Sekcja 7.3 „Implementacja trybu Falcon”. Wynikowy plik .config file zawiera następujące wiersze.
# CONFIG_UBIFS_FS nie jest ustawione
# CONFIG_DEBUG_KERNEL nie jest ustawiony
b. Zbuduj nowy obraz jądra.
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- zrób wszystko
c. Zregeneruj obraz FIT jądra zgodnie z sekcją 7.3 „Implementacja trybu Falcon”, krok 13 i skopiuj go
na partycję rozruchową karty SD (FAT).
d. [Opcjonalnie] Jeśli chcesz używać zmodyfikowanego jądra podczas normalnego rozruchu, skopiuj nowy plik binarny obrazu na pierwszą partycję rozruchową karty SD.

Optymalizacja przestrzeni użytkownika

W tej sekcji wymieniono kroki z sekcji „Uruchamianie aplikacji przed systememd” i sekcji „Zmiana zależności jednostki systemowej”.

Uruchom aplikację przed systememd
W razie potrzeby program można uruchomić przed systememd.

Utwórz skrypt /home/root/newinit.sh, który uruchomi twój program przed systemd. Poniżej znajduje się proste
exampplik pokazujący, jak uruchomić program przed systememd. Zamień linię echa na żądaną aplikację.
#!/bin/sh
echo „Wczesny start” > /dev/kmsg
exec /lib/systemd/systemd
Ustaw skrypt jako wykonywalny.
$ chmod +x newinit.sh
Połącz /sbin/init ze swoim skryptem newinit.sh.
$ ln -sf /home/root/newinit.sh /sbin/init
Notatka: Aby powrócić do konfiguracji początkowej, użyj następującego polecenia.
$ ln -sf /lib/systemd/systemd /sbin/init
Zrestartuj płytę i sprawdź log jądra. Przeszukanie ciągu „Early start” w dmesg pokazuje, że skrypt newinit.sh jest wykonywany przed procesem init.

Zmień zależności jednostki systemowej
Najprostszym sposobem na skrócenie czasu spędzanego w przestrzeni użytkownika jest zmiana kolejności uruchamiania aplikacji.
Aby uruchomić usługę wcześniej należy zmienić zależności z którymi współpracuje System.
Na płycie otwórz plik /lib/systemd/system/.service file i zmień zależności jednostek. Na przykładampLe,
zaczynając przed local-fs-pre.target.
[Jednostka]
…
Przed=lokalny-fs-pre.target
Domyślne zależności=nie

Jeśli zostanie wywołane polecenie system-analyze z argumentem obwiniania, Systemd udostępnia także narzędzie o nazwie systemd-analyze, które wypisuje usługi i czas ich rozpoczęcia.
Wina $ systemd-analysis

Aby wyłączyć usługę, możesz użyć polecenia systemctl Disable. Aby wyłączyć niektóre usługi (zwłaszcza te udostępniane przez systemd), użyj polecenia systemctl mask. Należy jednak zachować ostrożność podczas wyłączania usług, ponieważ prawidłowe działanie systemu może być od nich zależne.

Wyniki

Tabela 3. Początkowe pomiary czasu rozruchu

	SPL			U-Boot				Jądro
Tablica	Pamięć ROM-owa	NRDinicjalizacja	SPLinicjalizacje+ Załaduj obraz U-Boota	U-Boot inicjalizacje (init_sekwencja_ f)	U-Boot inicjalizacje (init_sekwencja_ r)	Uruchomić sekwencja	Jądro obraz obciążenie	ATF + rozruch jądra do procesu INIT	Całkowity czas
	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)
i.MX 8MN	161	241	162	363	790	2894	333	3506	8450
i.MX 8MP	162	301	175	373	1726	4181	345	3627	10890
i.MX 8MM	142	265	117	412	812	2970	396	5002	10116
i.MX 93	369	111	117	628	1172	3271	412	3090	9170

Tabela 4. Zoptymalizowane pomiary czasu rozruchu

	SPL				Jądro
Tablica	Pamięć ROM-owa	Inicjalizacja DDR	Inicjalizacja SPL	Ładowanie obrazu jądra^[1]	ATF + rozruch jądra do procesu INIT^[2]	Całkowity czas
	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)
i.MX 8MN	203	240	86	376	1185	2090
i.MX 8MP	187	301	97	382	1237	2204
i.MX 8MM^[3]	139	265	63	1336	2956^[3]	4759
i.MX 93	374	111	89	366	1391	2330

CONFIG_DEBUG_KERNEL wyłączone, co skutkuje mniejszym rozmiarem obrazu jądra => zmniejsza ładowanie obrazu jądra.
Komunikaty dziennika jądra są pomijane przy użyciu funkcji cichej.
i.MX 8M Mini EVK nie jest wyposażony w zintegrowany moduł Wi-Fi podłączony do portu PCIe (w przeciwieństwie do i.MX 8M Plus). Dlatego inicjalizacja PCIe PHY pochłania czas oczekiwania na aktywne łącze. Jeśli do interfejsu PCIe podłączony jest moduł Wi-Fi, czas rozruchu jądra zmniejsza się do 1215 ms, więc całkowity czas rozruchu wynosi 3018 ms.

Uwaga dotycząca kodu źródłowego w dokumencie

Byłyampkod pliku pokazany w tym dokumencie jest objęty następującymi prawami autorskimi i licencją BSD-3-Clause:

Przy redystrybucji kodu źródłowego należy zachować powyższą informację o prawach autorskich, niniejszą listę warunków oraz poniższe wyłączenie odpowiedzialności.
Redystrybucje w formie binarnej muszą zawierać powyższą informację o prawach autorskich, niniejszą listę warunków oraz poniższe wyłączenie odpowiedzialności w dokumentacji i/lub innych materiałach dostarczonych wraz z dystrybucją.

Ani nazwisko właściciela praw autorskich, ani nazwiska jego współautorów nie mogą być używane do popierania lub promowania produktów wywodzących się z tego oprogramowania bez uprzedniej pisemnej zgody.

NINIEJSZE OPROGRAMOWANIE JEST DOSTARCZANE PRZEZ WŁAŚCICIELI PRAW AUTORSKICH I WSPÓŁPRACOWNIKÓW „TAK JAK JEST” ORAZ WSZELKIE
WYRAŻONE LUB DOROZUMIANE GWARANCJE, W TYM M.in. DOROZUMIANE GWARANCJE WARTOŚCI HANDLOWEJ I PRZYDATNOŚCI DO OKREŚLONEGO CELU, SĄ WYŁĄCZONE. W ŻADNYM WYPADKU POSIADACZ PRAW AUTORSKICH LUB WSPÓŁPRACOWCY NIE BĘDĄ ODPOWIEDZIALNI ZA JAKIEKOLWIEK BEZPOŚREDNIE, POŚREDNIE, PRZYPADKOWE, SPECJALNE, PRZYKŁADOWE LUB WYNIKOWE SZKODY (W TYM M.in. ZAKUPIENIE TOWARÓW LUB USŁUG ZAMIENNYCH, UTRATA UŻYTKOWANIA, DANYCH LUB ZYSKÓW; LUB PRZERWY W DZIAŁALNOŚCI) JAKICHKOLWIEK SPOWODOWANEJ I NA KAŻDEJ TEORII ODPOWIEDZIALNOŚCI, CZY TO UMOWNEJ, ŚCIŚŁEJ LUB DELIKTUJNEJ (W TYM ZANIEDBANIA LUB INNEGO), WYNIKAJĄCEJ W JAKIKOLWIEK SPOSÓB Z KORZYSTANIA Z TEGO OPROGRAMOWANIA, NAWET W PRZYPADKU POWIADOMIENIA O MOŻLIWOŚCI WYSTĄPIENIA TAKICH SZKÓD.

Historia rewizji

Tabela 5. Historia zmian

Numer wersji	Data rewizji	Opis
1	09 października 2023	Pierwsze wydanie

Informacje prawne

Definicje
Wersja robocza — status wersji roboczej dokumentu wskazuje, że jego treść jest nadal poddawana wewnętrznej weryfikacji.view i podlega formalnej akceptacji, co może skutkować modyfikacjami lub uzupełnieniami. NXP Semiconductors nie składa żadnych oświadczeń ani gwarancji co do dokładności lub kompletności informacji zawartych w wersji roboczej dokumentu i nie ponosi odpowiedzialności za konsekwencje wykorzystania takich informacji.

Zastrzeżenia
Ograniczona gwarancja i odpowiedzialność — Informacje zawarte w tym dokumencie są uważane za dokładne i wiarygodne. Firma NXP Semiconductors nie udziela jednak żadnych oświadczeń ani gwarancji, wyraźnych lub dorozumianych, co do dokładności lub kompletności takich informacji i nie ponosi odpowiedzialności za konsekwencje wykorzystania takich informacji. Firma NXP Semiconductors nie ponosi odpowiedzialności za zawartość tego dokumentu, jeśli została dostarczona przez źródło informacji spoza firmy NXP Semiconductors.

W żadnym wypadku firma NXP Semiconductors nie ponosi odpowiedzialności za jakiekolwiek szkody pośrednie, przypadkowe, karne, specjalne lub wynikowe (w tym – bez ograniczeń – utracone zyski, utracone oszczędności, przerwy w działalności, koszty związane z usunięciem lub wymianą jakichkolwiek produktów lub opłatami za przeróbkę), niezależnie od tego, czy lub nie, takie odszkodowania są oparte na czynie niedozwolonym (w tym zaniedbaniu), gwarancji, naruszeniu umowy lub jakiejkolwiek innej teorii prawnej.

Niezależnie od jakichkolwiek szkód, które klient może ponieść z jakiegokolwiek powodu, łączna i skumulowana odpowiedzialność firmy NXP Semiconductors wobec klienta za produkty opisane w niniejszym dokumencie jest ograniczona zgodnie z Warunkami sprzedaży komercyjnej NXP Semiconductors.

Prawo do wprowadzania zmian — NXP Semiconductors zastrzega sobie prawo do wprowadzania zmian w informacjach opublikowanych w tym dokumencie, w tym między innymi w specyfikacjach i opisach produktów, w dowolnym czasie i bez powiadomienia. Niniejszy dokument zastępuje i zastępuje wszystkie informacje dostarczone przed publikacją niniejszego dokumentu.

Przydatność do użycia — Produkty NXP Semiconductors nie są projektowane, autoryzowane ani objęte gwarancją, aby były odpowiednie do użytku w systemach lub sprzęcie podtrzymującym życie, krytycznych dla życia lub bezpieczeństwa, ani w zastosowaniach, w których można racjonalnie oczekiwać, że awaria lub nieprawidłowe działanie produktu NXP Semiconductors spowoduje obrażenia ciała, śmierć lub poważne szkody materialne lub środowiskowe. Firma NXP Semiconductors i jej dostawcy nie ponoszą odpowiedzialności za włączenie i/lub wykorzystanie produktów NXP Semiconductors w takim sprzęcie lub zastosowaniach, a zatem takie włączenie i/lub użycie odbywa się na własne ryzyko klienta.

Aplikacje - Zastosowania opisane w niniejszym dokumencie dla któregokolwiek z tych produktów służą wyłącznie celom ilustracyjnym. Firma NXP Semiconductors nie gwarantuje ani nie gwarantuje, że takie zastosowania będą odpowiednie do określonego zastosowania bez dalszych testów lub modyfikacji. Klienci są odpowiedzialni za projektowanie i działanie swoich aplikacji i produktów wykorzystujących produkty NXP Semiconductors, a NXP Semiconductors nie przyjmuje żadnej odpowiedzialności za jakąkolwiek pomoc w zakresie aplikacji lub projektowania produktów klienta. Klient ponosi wyłączną odpowiedzialność za ustalenie, czy produkt NXP Semiconductors jest odpowiedni i nadaje się do zastosowań klienta i planowanych produktów, jak również do planowanego zastosowania i użytkowania przez klientów będących osobami trzecimi. Klienci powinni zapewnić odpowiednie zabezpieczenia projektowe i operacyjne, aby zminimalizować ryzyko związane z ich aplikacjami i produktami.

NXP Semiconductors nie ponosi żadnej odpowiedzialności związanej z jakimkolwiek uchybieniem, szkodami, kosztami lub problemami wynikającymi z jakichkolwiek słabości lub uchybień w aplikacjach lub produktach klienta, bądź w zastosowaniu lub użytkowaniu przez klientów zewnętrznych klienta. Klient jest odpowiedzialny za wykonanie wszystkich niezbędnych testów swoich aplikacji i produktów przy użyciu produktów NXP Semiconductors, aby uniknąć nieprawidłowego działania aplikacji i produktów, aplikacji lub użytkowania przez klientów zewnętrznych klienta. NXP nie ponosi żadnej odpowiedzialności w tym zakresie.

Warunki sprzedaży komercyjnej — Produkty NXP Semiconductors są sprzedawane zgodnie z ogólnymi warunkami sprzedaży komercyjnej opublikowanymi pod adresem http://www.nxp.com/profile/warunki, chyba że w ważnej pisemnej umowie indywidualnej ustalono inaczej. W przypadku zawarcia umowy indywidualnej obowiązują wyłącznie warunki danej umowy. NXP Semiconductors niniejszym wyraźnie sprzeciwia się stosowaniu ogólnych warunków klienta w odniesieniu do zakupu produktów NXP Semiconductors przez klienta. Kontrola eksportu — niniejszy dokument, jak również elementy w nim opisane, mogą podlegać przepisom dotyczącym kontroli eksportu. Eksport może wymagać uprzedniego zezwolenia właściwych organów.

Przydatność do stosowania w zakwalifikowanych produktach niezwiązanych z branżą motoryzacyjną — O ile w tym dokumencie wyraźnie nie stwierdzono, że ten konkretny produkt NXP Semiconductors jest zakwalifikowany do zastosowań motoryzacyjnych, produkt ten nie nadaje się do użytku w motoryzacji. Nie jest kwalifikowany ani testowany zgodnie z wymaganiami testów motoryzacyjnych lub aplikacji. NXP Semiconductors nie ponosi żadnej odpowiedzialności za włączenie i/lub wykorzystanie zakwalifikowanych produktów innych niż motoryzacyjne w sprzęcie lub zastosowaniach motoryzacyjnych.

W przypadku, gdy klient używa produktu do projektowania i użytkowania w zastosowaniach motoryzacyjnych zgodnie ze specyfikacjami i standardami motoryzacyjnymi, klient (a) będzie używał produktu bez gwarancji NXP Semiconductors na produkt do takich zastosowań motoryzacyjnych, użytkowania i specyfikacji oraz ( b) za każdym razem, gdy klient używa produktu do zastosowań motoryzacyjnych wykraczających poza specyfikacje NXP Semiconductors, takie użytkowanie odbywa się wyłącznie na własne ryzyko klienta oraz (c) klient w pełni zwalnia firmę NXP Semiconductors z wszelkiej odpowiedzialności, szkód lub roszczeń dotyczących nieudanego produktu wynikających z zaprojektowania i użytkowania przez klienta produkt do zastosowań motoryzacyjnych poza standardową gwarancją NXP Semiconductors i specyfikacjami produktów NXP Semiconductors.

Tłumaczenia — Nieanglojęzyczna (przetłumaczona) wersja dokumentu, w tym zawarte w nim informacje prawne, służy wyłącznie jako odniesienie. Wersja angielska ma pierwszeństwo w przypadku jakichkolwiek rozbieżności między wersją przetłumaczoną a wersją angielską.

Bezpieczeństwo - Klient rozumie, że wszystkie produkty NXP mogą zawierać niezidentyfikowane luki w zabezpieczeniach lub mogą obsługiwać ustalone standardy lub specyfikacje bezpieczeństwa ze znanymi ograniczeniami. Klient jest odpowiedzialny za projektowanie i działanie swoich aplikacji i produktów przez cały cykl ich życia, aby ograniczyć wpływ tych luk na aplikacje i produkty klienta. Odpowiedzialność klienta rozciąga się także na inne otwarte i/lub zastrzeżone technologie obsługiwane przez produkty NXP do wykorzystania w aplikacjach klienta. NXP nie ponosi żadnej odpowiedzialności za jakiekolwiek luki w zabezpieczeniach. Klient powinien regularnie sprawdzać aktualizacje zabezpieczeń oferowane przez NXP i podejmować odpowiednie działania następcze. Klient wybierze produkty posiadające zabezpieczenia, które najlepiej odpowiadają zasadom, przepisom i standardom zamierzonego zastosowania oraz podejmie ostateczne decyzje projektowe dotyczące swoich produktów i ponosi wyłączną odpowiedzialność za zgodność ze wszystkimi wymogami prawnymi, regulacyjnymi i związanymi z bezpieczeństwem dotyczącymi swoich produktów, niezależnie od wszelkie informacje lub wsparcie, które może zapewnić NXP.

NXP posiada Zespół Reagowania na Incydenty Bezpieczeństwa Produktu (PSIRT) (dostępny pod adresem PSIRT@nxp.com), który zarządza badaniami, raportowaniem i wydawaniem rozwiązań dotyczących luk w zabezpieczeniach produktów NXP.

NXP BV — NXP BV nie jest spółką operacyjną i nie zajmuje się dystrybucją ani sprzedażą produktów.

Znaki towarowe

Ogłoszenie: Wszystkie wymienione marki, nazwy produktów, nazwy usług i znaki towarowe są własnością ich odpowiednich właścicieli.
NXP — znak słowny i logo są znakami towarowymi NXP BV
Blokada krawędzi — jest znakiem towarowym NXP BV
i.MX — jest znakiem towarowym NXP BV
Microsoft, Azure i ThreadX — są znakami towarowymi grupy firm Microsoft.

Dokumenty / Zasoby

Jądro trybu Falcon szybkiego rozruchu NXP AN14093 [plik PDF] Instrukcja użytkownika
AN14093 Jądro trybu Fast Boot Falcon, AN14093, Jądro trybu Fast Boot Falcon, Jądro trybu Boot Falcon, Jądro trybu Falcon, Jądro trybu

Odniesienia

Instrukcja obsługi

Wstęp