Projekti NXP UG10164 i.MX Yocto

Informacioni i dokumentit

Mbiview

• Ky dokument përshkruan se si të ndërtoni një imazh për një tabelë i.MX duke përdorur një mjedis ndërtimi Yocto Project. Ai përshkruan shtresën e lëshimit të i.MX dhe përdorimin specifik të i.MX.
• Projekti Yocto është një bashkëpunim me burim të hapur i fokusuar në zhvillimin e integruar të Linux OS. Për më shumë informacion mbi Yocto Project, shihni faqen e Projektit Yocto: www.yoctoproject.org/  Në faqen kryesore të Projektit Yocto ka disa dokumente që përshkruajnë në detaje se si të përdoret sistemi. Për të përdorur Yocto-n bazë.
• Projektoni pa shtresën e lëshimit të i.MX, ndiqni udhëzimet në Fillimin e Shpejtë të Projektit Yocto që gjendet në https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html
• Komuniteti i Projektit FSL Yocto BSP (që gjendet në freescale.github.io) është një komunitet zhvillimi jashtë NXP që ofron mbështetje për bordet i.MX në mjedisin e Projektit Yocto. i.MX iu bashkua komunitetit të Projektit Yocto, duke ofruar një version të bazuar në kornizën e Projektit Yocto. Informacion specifik për përdorimin e BSP të komunitetit FSL është i disponueshëm në komunitet. web faqe. Ky dokument është një shtesë e dokumentacionit të BSP të komunitetit.
• FileAto që përdoren për të ndërtuar një imazh ruhen në shtresa. Shtresat përmbajnë lloje të ndryshme personalizimesh dhe vijnë nga burime të ndryshme. Disa nga files në një shtresë quhen receta. Recetat e Yocto Project përmbajnë mekanizmin për të marrë kodin burimor, për të ndërtuar dhe paketuar një komponent. Listat e mëposhtme tregojnë shtresat e përdorura në këtë version.

Shtresa e lëshimit i.MX

• meta-imx
  • meta-imx-bsp: përditësime për shtresat meta-freescale, poky dhe meta-openembedded
  • meta-imx-sdk: përditësime për meta-freescale-distros
  • meta-imx-ml: Receta për të mësuarit automatik
  • meta-imx-v2x: Recetat V2X përdoren vetëm për i.MX 8DXL
  • meta-imx-cockpit: Receta për kabinën e pilotit për i.MX 8QuadMax

Shtresat e komunitetit të projektit Yocto

• meta-freescale: Ofron mbështetje për bazën dhe për tabelat referuese i.MX Arm.
• meta-freescale-3rdparty: Ofron mbështetje për bordet e palëve të treta dhe partnerëve.
• meta-freescale-distro: Artikuj shtesë për të ndihmuar në zhvillimin dhe aftësitë e bordit të ushtrimeve.
• fsl-community-bsp-base: Shpesh riemërohet në bazë. Ofron konfigurimin bazë për BSP të Komunitetit FSL.
• meta-openembedded: Koleksion shtresash për universin OE-core. Shih layers.openembedded.org/.
• poky: Artikujt bazë të projektit Yocto në Poky. Shikoni Poky README për detaje.
• meta-shfletuesi: Ofron disa shfletues.
• meta-qt6: Ofron Qt 6.
• meta-timesys: Ofron mjete Vigiles për monitorimin dhe njoftimin e dobësive të BSP (CVE).

Referencat për shtresat e komunitetit në këtë dokument janë për të gjitha shtresat në projektin Yocto përveç meta-imx. Bordet i.MX janë konfiguruar në shtresat meta-imx dhe meta-freescale. Kjo përfshin U-Boot, kernelin Linux dhe detaje specifike të bordit të referencës.
i.MX ofron një shtresë shtesë të quajtur Versioni i i.MX BSP, i quajtur meta-imx, për të integruar një version të ri të i.MX me BSP-në e Komunitetit të Projektit FSL Yocto. Shtresa meta-imx synon të publikojë recetat dhe konfigurimet e reja të Projektit Yocto të përditësuara dhe të reja për versionet e reja që nuk janë ende të disponueshme në shtresat ekzistuese meta-freescale dhe meta-freescale-distro në Projektin Yocto. Përmbajtja e shtresës së Versionit të i.MX BSP janë recetat dhe konfigurimet e makinës. Në shumë raste testimi, shtresa të tjera zbatojnë receta ose përfshijnë files dhe shtresa e lëshimit i.MX ofron përditësime të recetave ose duke i bashkangjitur një recete aktuale, ose duke përfshirë një komponent dhe duke përditësuar me arna ose vendndodhje burimi. Shumica e recetave të shtresës së lëshimit i.MX janë shumë të vogla sepse ato përdorin atë që ka ofruar komuniteti dhe përditësojnë atë që nevojitet për çdo version të ri të paketës që nuk është i disponueshëm në shtresat e tjera.

• Shtresa i.MX BSP Release ofron gjithashtu receta imazhi që përfshijnë të gjithë komponentët e nevojshëm për nisjen e një imazhi të sistemit, duke e bërë më të lehtë për përdoruesin. Komponentët mund të ndërtohen individualisht ose përmes një recete imazhi, e cila tërheq të gjithë komponentët e kërkuar në një imazh në një proces ndërtimi.
• Versionet e bërthamës i.MX dhe U-Boot aksesohen përmes depove publike të GitHub të i.MX. Megjithatë, disa komponentë publikohen si paketa në pasqyrën e i.MX. Recetat e bazuara në paketa tërheqin files nga pasqyra i.MX në vend të një vendndodhjeje Git dhe gjeneroni paketën e nevojshme.
• Të gjitha paketat që lëshohen si binare janë ndërtuar me pikë lëvizëse harduerike të aktivizuar siç përcaktohet nga DEFAULTTUNE e përcaktuar në çdo konfigurim të makinës file. Paketat e softuerit me pikë lundruese nuk ofrohen duke filluar me lëshimet jethro.
• Versioni LF6.12.20_2.0.0 është publikuar për Yocto Project 5.2 (Walnascar). Të njëjtat receta për Yocto Project 5.2 do të përditësohen dhe do të bëhen të disponueshme në versionin e ardhshëm të Yocto Project. Cikli i publikimit të Yocto Project zgjat afërsisht gjashtë muaj.
• Recetat dhe patch-et në meta-imx do të transmetohen në shtresat e komunitetit. Pasi të bëhet kjo për një komponent të caktuar, files në meta-imx nuk nevojiten më dhe Komuniteti i Projektit FSL Yocto BSP do të ofrojë mbështetje. Komuniteti mbështet bordet e referencës i.MX, bordet e komunitetit dhe bordet e palëve të treta.

Marrëveshja e licencës së përdoruesit fundor
Gjatë procesit të konfigurimit të mjedisit të NXP Yocto Project BSP, shfaqet Marrëveshja e Licencës së Përdoruesit Fundor NXP (EULA). Për të vazhduar përdorimin e softuerit të pronarit i.MX, përdoruesit duhet të pajtohen me kushtet e kësaj licence. Marrëveshja për kushtet lejon që projekti Yocto të ndërtojë paketat nga pasqyra i.MX.

Shënim:
Lexoni me kujdes këtë marrëveshje licence gjatë procesit të konfigurimit, sepse pasi të pranohet, e gjithë puna e mëtejshme në mjedisin e i.MX Yocto Project është e lidhur me këtë marrëveshje të pranuar.

Referencat
i.MX ka familje të shumta të mbështetura në softuer. Më poshtë janë listuar familjet dhe SoC-të e listuara për familje. Shënimet e Versionit të i.MX Linux përshkruajnë se cili SoC mbështetet në versionin aktual. Disa SoC të lëshuara më parë mund të jenë të ndërtueshme në versionin aktual, por jo të validuara nëse janë në nivelin e validuar më parë.

• Familja i.MX 6: 6QuadPlus, 6Quad, 6DualLite, 6SoloX, 6SLL, 6UltraLite, 6ULL, 6ULZ
• Familja i.MX 7: 7Dual, 7ULP
• Familja i.MX 8: 8QuadMax, 8QuadPlus, 8ULP
• Familja i.MX 8M: 8M Plus, 8M Quad, 8M Mini, 8M Nano
• Familja i.MX 8X: 8QuadXPlus, 8DXL, 8DXL OrangeBox, 8DualX
• Familja i.MX 9: i.MX 91, i.MX 93, i.MX 95, i.MX 943

Ky publikim përfshin referencat e mëposhtme dhe informacione shtesë.

• Shënime për Versionin e i.MX Linux (RN00210) – Ofron informacionin e versionit.
• Udhëzuesi i përdoruesit i.MX Linux (UG10163) – Ofron informacion mbi instalimin e U-Boot dhe sistemit operativ Linux dhe përdorimin e tij.
  i. Karakteristikat specifike të MX.
• Udhëzuesi i Përdoruesit të Projektit i.MX Yocto (UG10164) – Përshkruan paketën e mbështetjes së bordit për sistemet e zhvillimit NXP duke përdorur Projektin Yocto për të konfiguruar hostin, për të instaluar zinxhirin e mjeteve dhe për të ndërtuar kodin burimor për të krijuar imazhe.
• Udhëzuesi i Portimit të i.MX (UG10165) – Jep udhëzime për portim të BSP-së në një pllakë të re.
• Udhëzuesi i përdoruesit për të mësuarit automatik i.MX (UG10166) – Ofron informacion mbi të mësuarit automatik.
• Udhëzuesi i përdoruesit të i.MX DSP (UG10167) – Ofron informacion mbi DSP për i.MX 8.
• Udhëzuesi i Kamerës dhe Ekranit i.MX 8M Plus (UG10168) – Ofron informacion mbi API-në e Ndërfaqes së Sensorit të Pavarur ISP për i.MX 8M Plus.
• Aktivizimi i Ndarjes së Pajisjeve të Kabinës Dixhitale i.MX për i.MX 8QuadMax (UG10169) – Ofron zgjidhjen harduerike të Kabinës Dixhitale i.MX për i.MX 8QuadMax.
• Udhëzuesi i përdoruesit për grafikën i.MX (UG10159) – Përshkruan veçoritë e grafikës.
• Udhëzuesi i përdoruesit të Harpoon (UG10170) – Prezanton versionin Harpoon për familjen e pajisjeve i.MX 8M.
• Manuali i Referencës për Linux i.MX (RM00293) – Ofron informacion mbi drajverët Linux për i.MX.
• Manuali i Referencës Linux për Ndërfaqen e Programimit të Aplikacionit i.MX VPU (RM00294) – Jep informacionin referues mbi API-n VPU në i.MX 6 VPU.
• EdgeLock Enclave Hardware Security API (RM00284) – Ky dokument është një përshkrim referencë softueri i API-së i ofruar nga zgjidhjet i.MX 8ULP, i.MX 93 dhe i.MX 95 Hardware Security Module (HSM) për Enklava EdgeLock ( ELE) Platformë.

Udhëzuesit e fillimit të shpejtë përmbajnë informacion bazë në tabelë dhe konfigurimin e tij. Ata janë në NXP webfaqe.

• Udhëzues për fillimin e shpejtë të platformës SABER (IMX6QSDPQSG)
• Udhëzuesi i nisjes së shpejtë i.MX 6UltraLite EVK (IMX6ULTRALITEQSG)
• Udhëzuesi i nisjes së shpejtë i.MX 6ULL ​​EVK (IMX6ULLQSG)
• Udhëzuesi i nisjes së shpejtë i.MX 7Dual SABRE-SD (SABRESDBIMX7DUALQSG)
• Udhëzues për nisjen e shpejtë të kompletit të vlerësimit të katërfishtë i.MX 8M (IMX8MQUADEVKQSG)
• Udhëzues për nisjen e shpejtë të kompletit të vlerësimit i.MX 8M Mini (8MMINIEVKQSG)
• Udhëzues për nisjen e shpejtë të kompletit të vlerësimit Nano i.MX 8M (8MNANOEVKQSG)
• Udhëzues për nisjen e shpejtë të kompletit të aktivizimit shumëndjesor i.MX 8QuadXPlus (IMX8QUADXPLUSQSG)
• Udhëzues për nisjen e shpejtë të kompletit të aktivizimit shumëndjesor i.MX 8QuadMax (IMX8QUADMAXQSG)
• Udhëzues për nisjen e shpejtë të kompletit të vlerësimit i.MX 8M Plus (IMX8MPLUSQSG)
• Udhëzuesi i fillimit të shpejtë i.MX 8ULP EVK (IMX8ULPQSG)
• Udhëzues për fillimin e shpejtë i.MX 8ULP EVK9 (IMX8ULPEVK9QSG)
• Udhëzuesi i nisjes së shpejtë i.MX 93 EVK (IMX93EVKQSG)
• Udhëzuesi i nisjes së shpejtë i.MX 93 9×9 QSB (93QSBQSG)

Dokumentacioni është i disponueshëm në internet në nxp.com

• Informacioni i.MX 6 është në nxp.com/iMX6series
• Informacioni i.MX SABER është në nxp.com/imxSABRE
• Informacioni i.MX 6UltraLite është në nxp.com/iMX6UL
• Informacioni i.MX 6ULL ​​është në nxp.com/iMX6ULL
• i.MX 7 Informacioni i dyfishtë është në nxp.com/iMX7D
• Informacioni i.MX 7ULP është në nxp.com/imx7ulp
• Informacioni i.MX 8 është në nxp.com/imx8
• Informacioni i.MX 6ULZ është në nxp.com/imx6ulz
• Informacioni i.MX 91 është në nxp.com/imx91
• Informacioni i.MX 93 është në nxp.com/imx93
• Informacioni i.MX 943 është në nxp.com/imx94

Veçoritë

Shtresat i.MX Yocto Project Release kanë karakteristikat e mëposhtme:

• Receta e kernelit Linux
  • Receta e kernelit ndodhet në dosjen recipes-kernel dhe integron një burim të kernelit i.MX Linux linux-imx.git të shkarkuar nga depoja i.MX GitHub. Kjo bëhet automatikisht nga recetat në projekt.
  • LF6.12.20_2.0.0 është një kernel Linux i lëshuar për Projektin Yocto.
• Receta U-Boot
  • Receta e U-Boot ndodhet në dosjen recipes-bsp dhe integron një burim të i.MX U-Boot uboot-imx.git të shkarkuar nga depoja i.MX GitHub.
  • Versioni i i.MX LF6.12.20_2.0.0 për pajisjet i.MX 6, i.MX 7, i.MX 8, i.MX 91, i.MX 93, i.MX 943 dhe i.MX 95 përdor një version të përditësuar v2025.04 i.MX U-Boot. Ky version nuk është përditësuar për të gjithë harduerin i.MX.
  • BSP-ja e Komunitetit të Projektit i.MX Yocto përdor u-boot-fslc nga linja kryesore, por kjo mbështetet vetëm nga komuniteti U-Boot dhe nuk mbështetet me kernelin L6.12.20.
  • BSP-ja e Komunitetit të Projektit i.MX Yocto përditëson shpesh versionet e U-Boot, kështu që informacioni i mësipërm mund të ndryshojë ndërsa versionet e reja të U-Boot integrohen në shtresat meta-freescale dhe përditësimet nga versionet e i.MX u-boot-imx integrohen në linjën kryesore.
• Receta grafike
  • Recetat grafike ndodhen në dosjen receta-graphics.
  • Recetat grafike integrojnë versionin e paketës grafike i.MX.
    Për SoC-të i.MX që kanë një harduer GPU Vivante, recetat imx-gpu-viv paketojnë komponentët grafikë për secilën shpërndarje: buffer-in e kornizave (FB), XWayland, backend-in Wayland dhe kompozitorin Weston (Weston). Vetëm i.MX 6 dhe i.MX 7 mbështesin buffer-in e kornizave.
  • Për SoC-të i.MX që kanë një harduer GPU Mali, recipetat mali-imx paketojnë komponentët grafikë për shpërndarjen backend XWayland dhe Wayland. Kjo veçori është vetëm për i.MX 9.
  • Xorg-driver integron xserver-xorg.
• Recetat e paketave i.MX
  firmware-imx, fimrware-upower, imx-sc-fimrware dhe paketa të tjera ndodhen në recipes-bsp dhe tërhiqen nga pasqyra i.MX për t'i ndërtuar dhe paketuar në imazhe recipes.
• Receta multimediale
  • Recetat multimediale ndodhen në dosjen receta-multimedia.
  • Paketat pronësore si imx-codec dhe imx-parser kanë burimin e tërheqjes së recetave nga pasqyra publike e i.MX për t'i ndërtuar dhe paketuar ato në imazhet e recetave.
  • Paketat me burim të hapur kanë recetat që tërheqin burimin nga depot publike të Git në GitHub.
  • Disa receta ofrohen për kodekët që kanë licencë të kufizuar. Paketat për këto nuk janë në pasqyrën publike të i.MX. Këto paketa janë të disponueshme veçmas. Kontaktoni përfaqësuesin tuaj të marketingut në i.MX për t'i marrë këto.
• Recetat kryesore
  Disa receta për rregulla, të tilla si udev, ofrojnë rregulla të përditësuara i.MX që do të vendosen në sistem. Këto receta janë zakonisht përditësime të politikës dhe përdoren vetëm për personalizim. Publikimet ofrojnë përditësime vetëm nëse është e nevojshme.
• Receta demo
  Recetat demonstruese ndodhen në direktorinë meta-imx-sdk. Kjo shtresë përmban receta imazhesh dhe receta për personalizim, siç është kalibrimi me prekje ose receta për aplikacione demonstruese.
• Receta të mësimit të makinës
  Recetat e të mësuarit automatik ndodhen në direktorinë meta-imx-ml. Kjo shtresë përmban receta të të mësuarit automatik për paketa, të tilla si tensorflow-lite dhe onnx.
• Recetat e kabinës
  Recetat e kabinës së pilotit ndodhen në meta-imx-cockpit dhe mbështeten në i.MX 8QuadMax duke përdorur konfigurimin e makinës imx-8qm-cockpit-mek.
• Receta GoPoint
  Recetat demo të GoPoint ndodhen në shtresën meta-nxp-demo-experience. Përfshihen më shumë receta demonstrimi dhe mjetesh. Kjo shtresë përfshihet në të gjitha imazhet e plota të publikuara.

Konfigurimi i hostit

Për të arritur sjelljen e pritur të Projektit Yocto në një makinë pritëse Linux, instaloni paketat dhe shërbimet e përshkruara më poshtë. Një konsideratë e rëndësishme është hapësira e diskut të ngurtë që kërkohet në makinën pritëse. Për shembullampKështu, kur ndërtoni në një makinë që funksionon Ubuntu, hapësira minimale e kërkuar në hard disk është rreth 50 GB. Rekomandohet që të sigurohet të paktën 120 GB, e cila është e mjaftueshme për të përpiluar të gjitha backend-et së bashku. Për ndërtimin e komponentëve të mësimit të makinerisë, rekomandohet të paktën 250 GB.
Versioni minimal i rekomanduar i Ubuntu është 22.04 ose më i ri.

1. Doker
   i.MX tani po publikon skripte të konfigurimit të docker në imx-docker. Ndiqni udhëzimet në readme për të konfiguruar një makinë ndërtimi host duke përdorur docker.
   Për më tepër, docker on board aktivizohet me manifestin standard duke përfshirë shtresën e meta-virtualizimit vetëm në i.MX 8. Kjo krijon një sistem pa kokë për instalimin e kontejnerëve docker nga qendrat e jashtme docker.
2. Paketat e hostit
   Një ndërtim i Projektit Yocto kërkon instalimin e paketave specifike për ndërtimin që janë dokumentuar në Projektin Yocto. Shkoni te Fillimi i Shpejtë i Projektit Yocto dhe kontrolloni për paketat që duhet të instalohen për makinën tuaj të ndërtimit.
   Paketat kryesore pritëse të Yocto Project janë:

sudo apt-get install build-essential chrpath cpio debianutils diffstat file shikues
gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3- jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xzutilszstd efitools
Mjeti i konfigurimit përdor versionin e parazgjedhur të grep që është në makinën tuaj të ndërtimit. Nëse ka një version të ndryshëm të grep në rrugën tuaj, kjo mund të shkaktojë dështimin e ndërtimit. Një zgjidhje alternative është të riemërtoni versionin special në diçka që nuk përmban grep.

Konfigurimi i programit Repo
Repo është një mjet i ndërtuar mbi Git që thjeshton menaxhimin e projekteve që përmbajnë depo të shumta, edhe nëse ato janë të hostuara në servera të ndryshëm. Repo plotëson shumë mirë natyrën e shtresuar të Projektit Yocto, duke e bërë më të lehtë për përdoruesit të shtojnë shtresat e tyre në BSP.

Për të instaluar programin "repo", ndiqni hapat e mëposhtëm:

1. Krijoni një dosje koshi në drejtorinë kryesore.
   • mkdir ~/bin (ky hap mund të mos jetë i nevojshëm nëse dosja bin ekziston tashmë)
   • curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
   • chmod a+x ~/bin/repo
2. Për të siguruar që dosja ~/bin është në variablin tuaj PATH, shtoni rreshtin e mëposhtëm në .bashrc file. eksporto PATH=~/bin:$PATH

Konfigurimi i projektit Yocto

Drejtoria e lëshimit të projektit i.MX Yocto BSP përmban një drejtori burimesh, e cila përfshin recetat e përdorura për të ndërtuar një ose më shumë drejtori ndërtimi, së bashku me një grup skriptesh të përdorura për të konfiguruar mjedisin.
Recetat e përdorura për të ndërtuar projektin vijnë si nga versionet e komunitetit ashtu edhe nga versionet e i.MX BSP. Shtresat e Projektit Yocto shkarkohen në direktorinë e burimeve. Ky hap siguron që të gjitha recetat e nevojshme të jenë konfiguruar për të ndërtuar projektin.
Ish-i i mëposhtëmamptregon se si të shkarkoni shtresat e recetës së i.MX Yocto Project Linux BSP. Për këtë shembullample, një direktori e quajtur imx-yocto-bsp është krijuar për projektin. Në vend të këtij mund të përdoret çdo emër.

Shënim:
https://github.com/nxp-imx/imx-manifest/tree/imx-linux-walnascar ka një listë të të gjitha manifesteve files mbështetur në këtë version.
Kur ky proces përfundon, BSP-ja kontrollohet në direktorinë imx-yocto-bsp/sources.

Ndërtimi i imazhit

• i.MX 6
  • imx6qpsabresd
  • imx6ulevk
  • imx6ulz-14×14-evk
  • imx6ull14x14evk
  • imx6ull9x9evk
  • imx6dlsabresd
  • imx6qsabresd
  • imx6solosabresd
  • imx6sxsabresd
  • imx6sllevk
• i.MX 7
  • imx7dsabresd
• i.MX 8
  • imx8qmmek
  • imx8qxpc0mek
  • imx8mqevk
  • imx8mm-lpddr4-evk
  • imx8mm-ddr4-evk
  • imx8mn-lpddr4-evk
  • imx8mn-ddr4-evk
  • imx8mp-lpddr4-evk
  • imx8mp-ddr4-evk
  • imx8dxla1-lpddr4-evk
    imx8dxlb0-lpddr4-evk
  • imx8dxlb0-ddr3l-evk
  • imx8mnddr3levk
  • imx8ulp-lpddr4-evk
  • imx8ulp-9×9-lpddr4x-evk
• i.MX 9
  • imx91-11×11-lpddr4-evk
  • imx91-9×9-lpddr4-qsb
  • imx93-11×11-lpddr4x-evk
  • imx93-14×14-lpddr4x-evk
  • imx93-9×9-lpddr4-qsb
  • imx943-19×19-lpddr5-evk
  • imx943-19×19-lpddr4-evk
  • imx95-19×19-lpddr5-evk
  • imx95-15×15-lpddr4x-evk
  • imx95-19×19-verdin

Çdo dosje ndërtimi duhet të konfigurohet në një mënyrë të tillë që të përdorë vetëm një shpërndarje. Sa herë që ndryshohet variabli DISTRO_FEATURES, nevojitet një dosje ndërtimi e pastër. Konfigurimet e shpërndarjes ruhen në local.conf. file në cilësimin DISTRO dhe shfaqen kur bitbake është duke u ekzekutuar. Në versionet e kaluara, ne përdorëm shpërndarjen poky dhe versionet dhe ofruesit e personalizuar në layer.conf tonë, por një shpërndarje e personalizuar është një zgjidhje më e mirë. Kur përdoret shpërndarja poky e parazgjedhur, përdoret konfigurimi i parazgjedhur i komunitetit. Si një version i.MX, ne preferojmë të kemi një sërë konfigurimesh që NXP mbështet dhe ka qenë duke i testuar.
Ja lista e konfigurimeve të DISTRO-s. Vini re se fsl-imx-fb nuk mbështetet në i.MX 8 ose i.MX 9, dhe fsl-imx-x11 nuk mbështetet më.

• fsl-imx-wayland: Grafika e pastër Wayland.
• fsl-imx-xwayland: Grafika Wayland dhe X11. Aplikacionet X11 që përdorin EGL nuk mbështeten.
• fsl-imx-fb: Grafika Frame Buffer – pa X11 ose Wayland. Frame Buffer nuk mbështetet në i.MX 8 dhe i.MX 9.

Nëse nuk ka shpërndarje file Nëse specifikohet, shpërndarja XWayland është konfiguruar si parazgjedhje. Përdoruesit janë të mirëpritur të krijojnë shpërndarjen e tyre. file bazuar në njërën prej tyre për të personalizuar mjedisin e tyre pa përditësuar local.conf për të vendosur versionet dhe ofruesit e preferuar.
Sintaksa për skriptin imx-setup-release.sh tregohet më poshtë:

Ku,

• SHPËRNDARJE= është shpërndarja, e cila konfiguron mjedisin e ndërtimit dhe ruhet në meta-imx/meta-imx-sdk/conf/distro.
• MAKINË= është emri i makinës, i cili tregon për konfigurimin file në conf/machine në meta-freescale dhe meta-imx.
• -b specifikon emrin e direktorisë së ndërtimit të krijuar nga skripti imx-setup-release.sh.
• Kur skripti ekzekutohet, ai e kërkon përdoruesin të pranojë EULA. Pasi të pranohet EULA, pranimi ruhet në local.conf brenda çdo dosje ndërtimi dhe pyetja e pranimit EULA nuk shfaqet më për atë dosje ndërtimi.
• Pas ekzekutimit të skriptit, drejtoria e punës është ajo që sapo është krijuar nga skripti, e specifikuar me opsionin -b. Është krijuar një dosje conf që përmban files bblayers.conf dhe local.conf.
• Të /conf/bblayers.conf file përmban të gjitha shtresat meta të përdorura në versionin e Projektit i.MX Yocto.
• Lokalja.konf file përmban specifikimet e makinës dhe shpërndarjes:
• MAKINA ??= 'imx7ulpevk'
• DISTRO ?= 'fsl-imx-xwayland'
• ACCEPT_FSL_EULA = "1"
  Ku,
• Konfigurimi MACHINE mund të ndryshohet duke e modifikuar këtë file, nëse është e nevojshme.
• ACCEPT_FSL_EULA në lokalin.conf file tregon se ju keni pranuar kushtet e EULA.
• Në shtresën meta-imx, ofrohen konfigurime të konsoliduara të makinave (imx6qpdlsolox.conf dhe imx6ul7d.conf) për makinat i.MX 6 dhe i.MX 7. i.MX i përdor këto për të ndërtuar një imazh të përbashkët me të gjitha pemët e pajisjeve në një imazh për testim. Mos i përdorni këto makina për asgjë tjetër përveç testimit.

Zgjedhja e një imazhi të projektit i.MX Yocto
Projekti Yocto ofron disa imazhe që janë të disponueshme në shtresa të ndryshme. Recetat e imazheve rendisin imazhe të ndryshme kryesore, përmbajtjen e tyre dhe shtresat që ofrojnë recetat e imazheve.

Tabela 1. Imazhe të projektit i.MX Yocto

Ndërtimi i një imazhi
Ndërtimi i Projektit Yocto përdor komandën bitbake. Për shembullample, bitbake ndërton komponentin e emërtuar. Çdo ndërtim i komponentit ka detyra të shumta, të tilla si marrja, konfigurimi, përpilimi, paketimi dhe vendosja në rrënjët e synuara. Ndërtimi i imazhit bitbake mbledh të gjithë komponentët e kërkuar nga imazhi dhe ndërton sipas varësisë për detyrë. Ndërtimi i parë është zinxhiri i veglave së bashku me mjetet e nevojshme për ndërtimin e komponentëve.

Komanda e mëposhtme është një shembullampse si të ndërtoni një imazh:

• bitbake imx-image-multimedia

Opsionet e Bitbake
Komanda bitbake e përdorur për të ndërtuar një imazh është bitbake. Parametra shtesë mund të përdoren për aktivitete specifike të përshkruara më poshtë. Bitbake ofron mundësi të ndryshme të dobishme për zhvillimin e një të vetme
komponent. Për të ekzekutuar me një parametër BitBake, komanda duket kështu:

bitbake
Ku, është një paketë ndërtimi e dëshiruar. Tabela e mëposhtme ofron disa opsione të BitBake.

Tabela 2. Opsionet e BitBake

Konfigurimi i U-Boot
Konfigurimet e U-Boot përcaktohen në konfigurimin e makinës kryesore file. Konfigurimi specifikohet duke përdorur cilësimet UBOOT_CONFIG. Kjo kërkon vendosjen e UBOOT_CONFIG në local.conf. Përndryshe, ndërtimi i U-Boot përdor si parazgjedhje boot SD.
Këto mund të ndërtohen veçmas duke përdorur komandat e mëposhtme (ndryshoni MACHINE në objektivin e saktë). Konfigurime të shumëfishta të U-Boot mund të ndërtohen me një komandë duke vendosur hapësira midis konfigurimeve të U-Boot.
Më poshtë janë konfigurimet e U-Boot për secilën pllakë. Pllakat i.MX 6 dhe i.MX 7 mbështesin SD pa OP-TEE dhe me OP-TEE:

• uboot_config_imx95evk=”sd fspi”
• uboot_config_imx943evk=”sd xspi”
• uboot_config_imx93evk=”sd fspi”
• uboot_config_imx91evk=”sd nand fspi etj”
• uboot_config_imx8mpevk=”sd fspi ecc”
• uboot_config_imx8mnevk=”sd fspi”
• uboot_config_imx8mmevk=”sd fspi”
• uboot_config_imx8mqevk=”sd”
• uboot_config_imx8dxlevk=”sd fspi”
• uboot_conifg_imx8dxmek=”sd fspi”
• uboot_config_imx8qxpc0mek=”sd fspi”
• uboot_config_imx8qxpmek=”sd fspi”
• uboot_config_imx8qmmek=”sd fspi”
• uboot_config_imx8ulpevk=”sd fspi”
• uboot_config_imx8ulp-9×9-lpddr4-evk=”sd fspi”
• uboot_config_imx6qsabresd=”sd sata sd-optee”
• uboot_config_imx6qsabreauto=”sd sata eimnor spinor dhe sd-optee”
• uboot_config_imx6dlsabresd=”sd epdc sd-optee”
• uboot_config_imx6dlsabreauto=”sd eimnor spinor dhe sd-optee”
• uboot_config_imx6solosabresd=”sd sd-optee”
• uboot_config_imx6solosabreauto=”sd eimnor spinor dhe sd-optee”
• uboot_config_imx6sxsabresd=”sd emmc qspi2 m4fastup sd-optee”
• uboot_config_imx6sxsabreauto=”sd qspi1 dhe sd-optee”
• uboot_config_imx6qpsabreauto=”sd sata eimnor spinor dhe sd-optee”
• uboot_config_imx6qpsabresd=”sd sata sd-optee”
• uboot_config_imx6sllevk=”sd epdc sd-optee”
• uboot_config_imx6ulevk=”sd emmc qspi1 sd-optee”
• uboot_config_imx6ul9x9evk=”sd qspi1 sd-optee”
• uboot_config_imx6ull14x14evk=”sd emmc qspi1 dhe sd-optee”
• uboot_config_imx6ull9x9evk=”sd qspi1 sd-optee”
• uboot_config_imx6ulz14x14evk=”sd emmc qspi1 dhe sd-optee”
• uboot_config_imx7dsabresd=”sd epdc qspi1 dhe sd-optee”
• uboot_config_imx7ulpevk=”sd emmc sd-optee”

Me vetëm një konfigurim U-Boot:

• echo “UBOOT_CONFIG = \”eimnor\”” >> conf/local.conf

Me konfigurime të shumta U-Boot:

• echo “UBOOT_CONFIG = \”sd eimnor\”” >> conf/local.conf
• MAKINË= bitbake -c vendos u-boot-imx

Ndërtoni skenarë
Më poshtë janë skenarët e konfigurimit të ndërtimit për konfigurime të ndryshme.
Vendosni manifestin dhe mbushni burimet e shtresës së Yocto Project me këto komanda:

• mkdir imx-yocto-bsp
• cd imx-yocto-bsp
• init i depos -u https://github.com/nxp-imx/imx-manifest\-linux-walnascar -m imx-6.12.20-2.0.0.xml sinkronizim i depove

Seksionet e mëposhtme japin disa p.shamples. Zëvendësoni emrat e makinerive dhe pjesët mbështetëse të specifikuara për të personalizuar komandat.

i.MX 8M Plus EVK me backend grafikësh XWayland

• DISTRO=fsl-imx-xwayland MACHINE=imx8mpevk burimi imx-setup-release.sh -b build-xwayland bitbake imx-image-full
• Kjo ndërton një imazh XWayland me Qt 6 dhe veçoritë e mësimit të makinerive. Për të ndërtuar pa Qt 6 dhe mësimin e makinerive, përdorni imx-image-multimedia.

Imazh i.MX 8M Quad EVK me backend grafik Walyand

• DISTRO=fsl-imx-wayland MACHINE=imx8mqevk burimi imx-setup-release.sh -b buildwayland
• bitbake imx-image-multimedia
  Kjo krijon një imazh të Weston Wayland me multimedia pa Qt 6.

Imazh i.MX 6QuadPlus SABRE-AI me prapavijë grafike Frame Buffer

• DISTRO=fsl-imx-fb MACHINE=imx6qpsabresd burimi imx-setup-release.sh –b buildfb
• bitbake imx-image-multimedia
• Kjo ndërton një imazh multimedial me një fund të tamponit të kornizës.

Rinisja e një mjedisi ndërtimi
Nëse hapet një dritare e re terminali ose makina riniset pasi të jetë konfiguruar një direktori ndërtimi, skripti i mjedisit të konfigurimit duhet të përdoret për të konfiguruar variablat e mjedisit dhe për të ekzekutuar përsëri një ndërtim. Skedari i plotë imx-setup-release.sh nuk është i nevojshëm.

mjedisi i konfigurimit të burimit

Shfletuesi Chromium në Wayland
Komuniteti Yocto Project ka receta Chromium për versionin Wayland Chromium Browser për i.MX SoC me pajisje GPU. NXP nuk mbështet ose teston arna nga komuniteti. Ky seksion përshkruan se si të integroni Chromium në rrënjët tuaja dhe të mundësoni paraqitjen e përshpejtuar të harduerit të WebGL. Shfletuesi Chromium kërkon shtresa shtesë si meta-shfletuesi i shtuar në skriptin imx-release-setup.sh automatikisht.

Shënim:

• X11 nuk mbështetet.
• Mbështetja për i.MX 6 dhe i.MX 7 është e vjetruar në këtë version dhe do të hiqet në versionin tjetër. Në local.conf, shtoni Chromium në imazhin tuaj.

CORE_IMAGE_EXTRA_INSTALL += "krom-ozon-rrugë"
Shtoni shtresën e Chromium në ndërtimin tuaj.
shtesa e shtresave bitbake ../sources/meta-browser/meta-chromium

Qt 6 dhe QtWebShfletuesit e motorit
Qt 6 ka si licencë komerciale ashtu edhe licencë me burim të hapur. Kur ndërtohet në Yocto Project, licenca me burim të hapur
Licenca është parazgjedhja. Sigurohuni që të kuptoni ndryshimet midis këtyre licencave dhe të zgjidhni siç duhet. Pasi të ketë filluar zhvillimi i personalizuar i Qt 6 në licencën me burim të hapur, ajo nuk mund të përdoret me licencën komerciale. Punoni me një përfaqësues ligjor për të kuptuar ndryshimet midis këtyre licencave.

Shënim:
Ndërtesa QtWebMotori nuk është i pajtueshëm me shtresën e meta-kromit të përdorur nga lëshimi.

• Nëse po përdorni konfigurimin e ndërtimit NXP, hiqni meta-chromium nga bblayers.conf:
• # Komentuar për shkak të papajtueshmërisë me qtwebmotorri
• #BBLAYERS += "${BSPDIR}/sources/meta-browser/meta-chromium"
• Ka katër shfletues Qt 6 në dispozicion. QtWebShfletuesit e motorit mund të gjenden në:
• /usr/share/qt6/examples/webminiaplikacionet e motorit/shfletuesi StyleSheet
• /usr/share/qt6/examples/webpajisje motorike/Shfletues i thjeshtë
• /usr/share/qt6/examples/webminiaplikacionet e motorit/shfletuesi i kukive
• /usr/share/qt6/examples/webmotori/nashfletuesi i shpejtë

Të tre shfletuesit mund të ekzekutohen duke shkuar te drejtoria e mësipërme dhe duke ekzekutuar ekzekutuesin që gjendet atje.
Ekrani me prekje mund të aktivizohet duke shtuar parametrat -plugin evdevtouch:/dev/input/event0 në skedarin ekzekutues. ./quicknanobrowser -plugin evdevtouch:/dev/input/event0 QtWebmotori funksionon vetëm në SoC me pajisje grafike GPU në i.MX 6, i.MX 7, i.MX 8 dhe i.MX 9.
Për të përfshirë Qtwebmotori në imazh, vendosni sa më poshtë në local.conf ose në recetën e imazhit.
IMAGE_INSTALL:append = ”packagegroup-qt6-webmotor"

Mësimi automatik i NXP eIQ

• Shtresa meta-ml është integrimi i mësimit të makinerive NXP eIQ, i cili më parë u lëshua si një shtresë e veçantë mësimore meta-imx-makine dhe tani është e integruar në imazhin standard BSP (imx-image-plotë).
• Shumë nga veçoritë kërkojnë Qt 6. Në rast se përdorni konfigurime të tjera përveç imx-image-full, vendosni sa vijon në local.conf:
• IMAGE_INSTALL:append = "packagegroup-imx-ml"
• Për të instaluar paketat NXP eIQ në SDK, vendosni sa më poshtë në local.conf:
• TOOLCHAIN_TARGET_TASK:append = ” tensorflow-lite-dev onnxruntime-dev”

Shënim:
Variabli TOOLCHAIN_TARGET_TASK_append instalon paketat vetëm në SDK, jo në imazh.
Për të shtuar konfigurimet e modelit dhe të dhënat hyrëse për demonstrimet OpenCV DNN, vendosni sa vijon në local.conf:
PACKAGECONFIG:append:pn-opencv_mx8 = "teston testet-imx"

Systemd
Systemd është aktivizuar si menaxheri i parazgjedhur i inicializimit. Për ta çaktivizuar systemd si parazgjedhje, shkoni te fs-imxbase inc dhe komentoni seksionin systemd.

Aktivizimi i OP-TEE
OP-TEE kërkon tre komponentë: OP-TEE OS, klient OP-TEE dhe test OP-TEE. Përveç kësaj, kerneli dhe U-Boot kanë konfigurime. Sistemi operativ OP-TEE ndodhet në ngarkuesin, ndërsa klienti dhe testi OP-TEE qëndrojnë në rootfs.
OP-TEE është aktivizuar si parazgjedhje në këtë version. Për të çaktivizuar OP-TEE, shkoni te skedari meta-imx/meta-imx-bsp/conf/layer.conf file dhe komentoni shtojcën DISTRO_FEATURES_për OP-TEE dhe hiqni komentin e linjës së hequr.

Ndërtimi i burgut
Jailhouse është një Hypervisor me ndarje statike i bazuar në sistemin operativ Linux. Mbështetet në pllakat i.MX 8M Plus, i.MX 8M Nano, i.MX 8M Quad EVK, i.MX 8M Mini EVK, i.MX 93, i.MX 95 dhe i.MX 943.

Për të aktivizuar ndërtimin e Jailhouse, shtoni rreshtin e mëposhtëm në local.conf:

• DISTRO_FEATURES:append = "burghouse"
• Në U-Boot, ekzekutoni komandën run jh_netboot ose jh_mmcboot. Kjo ngarkon DTB-në e dedikuar për përdorim në Jailhouse. Duke përdorur i.MX.
• 8M Quad si ish-ample, pasi Linux OS të niset:
• #insmod jailhouse.ko
• #./jailhouse aktivizo imx8mq.cell

Për më shumë detaje rreth Jailhouse në i.MX 8 dhe i.MX 9, shihni Udhëzuesin e Përdoruesit të i.MX Linux (UG10163).

Vendosja e imazhit

Kompletuar fileimazhet e sistemit vendosen në /tmp/deploy/images. Një imazh është, në pjesën më të madhe, specifik për pajisjen e vendosur në konfigurimin e mjedisit. Çdo ndërtim imazhi krijon një U-Boot, një kernel dhe një lloj imazhi bazuar në IMAGE_FSTYPES të përcaktuara në konfigurimin e makinës file. Shumica e konfigurimeve të makinës ofrojnë një imazh të kartës SD (.wic) dhe një imazh rootfs (.tar). Imazhi i kartës SD përmban një imazh të ndarë (me U-Boot, kernel, rootfs, etj.) të përshtatshme për nisjen e harduerit përkatës.

Duke shfaqur një imazh të kartës SD
Një imazh i kartës SD file .wic përmban një imazh të ndarë (me U-Boot, kernel, rootfs, etj.) të përshtatshme për të nisur harduerin përkatës. Për të ndezur një imazh të kartës SD, ekzekutoni komandën e mëposhtme:
zstdcat .wic.zst | sudo dd e=/dev/sd bs=1M conv=fsync

Për më shumë informacion mbi flashimin, shihni Seksionin “Përgatitja e një karte SD/MMC për nisje” në Udhëzuesin e Përdoruesit të i.MX Linux (UG10163). Për aplikacionet e të mësuarit automatik NXP eIQ, kërkohet një hapësirë ​​shtesë e lirë në disk.
(afërsisht 1 GB). Përcaktohet duke shtuar variablin IMAGE_ROOTFS_EXTRA_SPACE në skedarin local.conf. file para procesit të ndërtimit të Yocto-s. Shihni Mega-Manualin e Projektit Yocto.

Përshtatje

Ekzistojnë tre skenarë për të ndërtuar dhe personalizuar në i.MX Linux OS:

• Ndërtimi i i.MX Yocto Project BSP dhe vërtetimi në një tabelë referimi i.MX. Udhëzimet në këtë dokument përshkruajnë këtë metodë në detaje.
• Personalizimi i kernelit dhe krijimi i një bordi dhe peme pajisjesh të personalizuara me kernel dhe U-Boot. Për më shumë detaje se si të ndërtoni një SDK dhe të konfiguroni një makinë pritëse për ndërtimin e kernelit dhe vetëm U-Boot jashtë mjedisit të ndërtimit të Projektit Yocto, shihni Seksionin "Si të ndërtoni U-Boot dhe Kernel në mjedis të pavarur" në Udhëzuesin e Përdoruesit të i. MX Linux (UG10163).
• Personalizimi i një shpërndarjeje duke shtuar ose hequr paketimin nga BSP i parashikuar për lëshimet i.MX Linux duke krijuar një shtresë të personalizuar Yocto Project. i.MX ofron demo të shumta ishamples për të treguar një shtresë të personalizuar sipër një versioni të i.MX BSP. Seksionet e mbetura në këtë dokument ofrojnë udhëzime për krijimin e një konfigurimi të personalizuar të DISTRO-s dhe të bordit.

Krijimi i një shpërndarjeje të personalizuar
Një shpërndarje e personalizuar mund të konfigurojë një mjedis ndërtimi të personalizuar. Distro files publikoi fsl-imx-wayland, fsl-imx-xwayland dhe fsl-imx-fb, të gjitha tregojnë konfigurime për backend-e grafike specifike. Shpërndarjet mund të përdoren gjithashtu për të konfiguruar parametra të tjerë si kerneli, U-Boot dhe GStreamer. Shpërndarja i.MX filejanë të vendosur për të krijuar një mjedis ndërtimi të personalizuar të nevojshëm për testimin e versioneve tona të i.MX Linux OS BSP.
Rekomandohet që secili klient të krijojë shpërndarjen e tij file dhe përdorni atë për vendosjen e ofruesve, versioneve dhe konfigurimeve të personalizuara për mjedisin e tyre të ndërtimit. Një shpërndarje krijohet duke kopjuar një shpërndarje ekzistuese file, ose
duke përfshirë një si poky.conf dhe duke shtuar ndryshime shtesë, ose duke përfshirë një nga shpërndarjet i.MX dhe duke e përdorur atë si pikënisje.

Krijimi i një konfigurimi të personalizuar të bordit
Shitësit që po zhvillojnë tabela referimi mund të duan ta shtojnë tabelën e tyre në BSP-në e Komunitetit FSL. Mbështetja e makinës së re nga BSP-ja e Komunitetit FSL e bën të lehtë ndarjen e kodit burimor me komunitetin dhe lejon marrjen e reagimeve nga komuniteti.
Projekti Yocto e bën të lehtë krijimin dhe ndarjen e një BSP për një bord të ri të bazuar në i.MX. Procesi i transmetimit në rrjedhën e sipërme duhet të fillojë kur një kernel OS Linux dhe një ngarkues i ngarkimit janë duke punuar dhe testuar për atë makinë. Është shumë e rëndësishme të kesh një kernel dhe bootloader të qëndrueshëm Linux (për shembullample, U-Boot) për t'u treguar në konfigurimin e makinës file, të jetë ai i parazgjedhur i përdorur për atë makinë.
Një hap tjetër i rëndësishëm është përcaktimi i një mbajtësi për makinën e re. Mbajtësi është ai që është përgjegjës për mbajtjen e grupit të paketave kryesore që funksionojnë për atë bord. Mbajtësi i makinës duhet të mbajë të përditësuar kernelin dhe ngarkuesin, dhe paketat e hapësirës së përdoruesit të testohen për atë makinë.

Hapat e nevojshëm janë renditur më poshtë. 

1. Personalizo konfigurimin e kernelit files sipas nevojës. Konfigurimi i kernelit file është vendndodhja në arch/arm/configs dhe receta e kernelit të shitësit duhet të personalizojë një version të ngarkuar përmes recetës së kernelit.
2. Personalizoni U-Boot sipas nevojës. Shihni Udhëzuesin e Portimit të i.MX (UG10165) për detaje mbi këtë.
3. Caktoni mbajtësin e bordit. Ky mirëmbajtës sigurohet që files përditësohen sipas nevojës, kështu që ndërtimi funksionon gjithmonë.
4. Konfiguroni ndërtimin e Projektit Yocto siç përshkruhet në udhëzimet e komunitetit të Projektit Yocto, siç tregohet më poshtë. Përdorni degën kryesore të komunitetit.
   • Shkarkoni paketën e nevojshme të hostit, në varësi të shpërndarjes suaj të sistemit operativ Linux, nga Yocto Project Quick Start.
   • Shkarkoni Repo me komandën:
   • curl https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
   • Krijo një drejtori për të mbajtur gjithçka brenda. Mund të përdoret çdo emër drejtorie. Ky dokument përdor imxcommunity-bsp.
   • mkdir imx-community-bsp
     Ekzekutoni komandën e mëposhtme:
   • cd imx-community-bsp
   • Inicializoni Repo-n me degën master të Repo-s.
   • init i depos -u https://github.com/Freescale/fsl-community-bsp-platform-bmaster
   • Merrni recetat që do të përdoren për të ndërtuar.
   • sinkronizimi i repos
   • Konfiguroni mjedisin me komandën e mëposhtme:
   • ndërtimi i mjedisit të konfigurimit të burimit
5. Zgjidhni një makinë të ngjashme file në fsl-community-bsp/sources/meta-freescale-3rdparty/conf/machine dhe kopjojeni atë, duke përdorur një emër që tregon bordin tuaj. Redaktoni tabelën e re file me informacionin për bordin tuaj. Ndryshoni të paktën emrin dhe përshkrimin. Shto MACHINE_FEATURE.
   Testoni ndryshimet tuaja me degën më të fundit master të komunitetit, duke u siguruar që gjithçka të funksionojë mirë. Përdorni të paktën core-image-minimal.
   bitbake core-image-minimal
6. Përgatitni copëzat. Ndiqni Udhëzuesin e Stilit të Recetave dhe Seksionin "Kontributi" nën github.com/Freescale/meta-freescale/blob/master/README.md.
7. Në rrjedhën e sipërme në meta-freescale-party e tretë. Për në rrjedhën e sipërme, dërgoni arna te meta-freescale@yoctoproject.org

Monitorimi i dobësive të sigurisë në BSP-në tuaj
Ekzistojnë dy mënyra për të monitoruar Vulnerabilitetin dhe Ekspozimet e Zakonshme (CVE): njëra është Vigjiles dhe tjetra është Yocto CVE check.

Si të monitorohet CVE me anë të mjeteve Vigiles
Monitorimi i Vulnerabilitetit të Përbashkët dhe Ekspozimeve (CVE) mund të realizohet me mjetet Vigiles të aktivizuara NXP nga Timesys. Vigiles është një mjet monitorimi dhe menaxhimi i cenueshmërisë që ofron analiza Yocto CVE në kohë të ndërtimit të imazheve të synuara. Ai e bën këtë duke mbledhur meta të dhëna rreth softuerit të përdorur në Yocto Project BSP dhe duke e krahasuar atë me një bazë të dhënash CVE që integron informacione mbi CVE nga burime të ndryshme, duke përfshirë NIST, Ubuntu dhe disa të tjerë.
Mbi një nivel të lartëview i dobësive të zbuluara kthehet dhe mund të bëhet një analizë e plotë e detajuar me informacion mbi CVE-të që prekin, ashpërsinë e tyre dhe rregullimet e disponueshme viewed online.

Për të hyrë në raport në internet, regjistrohuni për llogarinë tuaj NXP Vigiles duke ndjekur lidhjen: https://www.timesys.com/register-nxp-vigiles/

Informacione shtesë mbi konfigurimin dhe ekzekutimin e Vigiles mund të gjenden këtu:
https://github.com/TimesysGit/meta-timesys https://www.nxp.com/vigiles

Konfigurimi
Shtoni meta-timesys në conf/bblayers.conf të ndërtimit tuaj të BSP.

Ndiqni formatin e file dhe shtoni meta-timesys:

BBLAYERS += "${BSPDIR}/burime/meta-timesys"
Shtojini vigjilat në variablin INHERIT në conf/local.conf:
TRASHËGON += “vigjile”

Ekzekutimi
Pasi meta-timesys është shtuar në ndërtimin tuaj, Vigiles ekzekuton një skanim të dobësive të sigurisë sa herë që ndërtohet Linux BSP me Yocto. Nuk nevojiten komanda shtesë. Pas përfundimit të çdo ndërtimi, informacioni i skanimit të dobësive ruhet në drejtorinë imx-yocto-bsp/ /vigjile.

Ju mundeni view detajet e skanimit të sigurisë përmes:

• Linja e komandës (përmbledhje)
• Online (detaje)
• Thjesht hapni file emërtuar -report.txt, e cila përfshin lidhjen me raportin e detajuar në internet.

Si të monitorohet CVE nga Yocto BitBake

• Projekti Yocto ka një infrastrukturë për të gjurmuar dhe adresuar dobësitë e njohura të sigurisë të parregulluara, siç gjurmohen nga baza e të dhënave publike e dobësive dhe ekspozimeve të përbashkëta (CVE).
• Për të aktivizuar një kontroll për dobësitë e sigurisë CVE duke përdorur cve-check në imazhin ose objektivin specifik që po ndërtoni, shtoni cilësimet e mëposhtme në konfigurimin tuaj në conf/local.conf: INHERIT += “cve-check”
• Klasa cve-check kërkon CVE-të e njohura (Cështje dhe Ekspozime të Zakonshme) gjatë ndërtimit me BitBake.
• Për më shumë detaje, shihni manualin e Yocto Mega: https://docs.yoctoproject.org/singleindex.html#cve-check

Pyetjet e bëra më shpesh

Fillimi i shpejtë
Ky seksion përmbledh se si të konfiguroni Projektin Yocto në një makinë Linux dhe të ndërtoni një imazh. Shpjegimet e hollësishme se çfarë do të thotë kjo janë në seksionet e mësipërme.

Instalimi i programit "repo".
Për të marrë BSP ju duhet të keni të instaluar "repo". Kjo duhet të bëhet vetëm një herë.

Shkarkimi i Mjedisit të Projektit BSP Yocto
Përdorni emrin e saktë për lëshimin e dëshiruar në opsionin -b për init repo. Kjo duhet të bëhet një herë për çdo lëshim dhe vendos shpërndarjen për drejtorinë e krijuar në hapin e parë. Sinkronizimi i repove mund të ekzekutohet për të përditësuar recetat sipas burimeve në më të fundit.

• : mkdir imx-yocto-bsp
• : cd imx-yocto-bsp
• : init i repos -u https://github.com/nxp-imx/imx-manifest-bimx-linux-walnascar
  -m imx-6.12.20-2.0.0.xml
• : sinkronizimi i repove
• Shënim: https://github.com/nxp-imx/imx-manifest/tree/imx-linux-walnascar ka një listë të të gjitha manifesteve files mbështetur në këtë version.

Konfigurimi për Backends specifike

i.MX 8 dhe i.MX 9 Framebuffer nuk mbështetet. Përdorni këto vetëm për i.MX 6 dhe i.MX 7 SoC.

Konfigurimi për Framebuffer

Akordimi lokal i konfigurimit
Një ndërtim i Yocto Project mund të marrë burime të konsiderueshme ndërtimi si në kohë ashtu edhe në përdorimin e diskut, veçanërisht kur ndërtohet në drejtori të shumta ndërtimi. Ka metoda për ta optimizuar këtë, p.shample, përdorni një memorie të përbashkët sstate (e ruan gjendjen e ndërtimit) dhe direktorinë e shkarkimeve (mban paketat e shkarkuara). Këto mund të vendosen të jenë në çdo vend në local.conf file duke shtuar deklarata si këto:

DL_DIR=”/opt/imx/yocto/imx/download” SSTATE_DIR=”/opt/imx/yocto/imx/sstate-cache”

• Drejtoritë duhet të ekzistojnë tashmë dhe të kenë lejet e duhura. Gjendja e përbashkët ndihmon kur vendosen drejtori të shumta ndërtimi, secila prej të cilave përdor një memorie të përbashkët për të minimizuar kohën e ndërtimit. Një direktori e përbashkët e shkarkimit minimizon kohën e marrjes. Pa këto cilësime, Yocto Project vendos si parazgjedhje në drejtorinë e ndërtimit për cache-në dhe shkarkimet e shtetit.
• Çdo paketë e shkarkuar në direktorinë DL_DIR shënohet me një .e kryer. Nëse rrjeti juaj ka një problem me marrjen e një pakete, mund të kopjoni manualisht versionin rezervë të paketës në drejtorinë DL_DIR dhe të krijoni një .e kryer file me komandën touch. Pastaj ekzekutoni komandën bitbake: bitbake .
• Për më shumë informacion, shihni Manualin e Referencës së Projektit Yocto.

Recetat
Çdo komponent është ndërtuar duke përdorur një recetë. Për komponentët e rinj, duhet të krijohet një recetë për të treguar burimin (SRC_URI) dhe për të specifikuar arna, nëse ka. Mjedisi Yocto Project ndërtohet nga një markëfile në vendndodhjen e specifikuar nga SRC_URI në recetë. Kur një ndërtim krijohet nga mjetet automatike, një recetë duhet të trashëgojë veglat automatike dhe pkgconfig. Bënifiles duhet të lejojë që CC të anashkalohet nga mjetet Cross Compile për të marrë paketën e ndërtuar me Yocto Project.
Disa komponentë kanë receta, por kanë nevojë për arna ose përditësime shtesë. Kjo mund të bëhet duke përdorur një recetë bbappend. Kjo i shtohet një recete ekzistuese detaje rreth burimit të përditësuar. Për shembullampLe, një recetë bbappend për të përfshirë një copë toke të re duhet të ketë përmbajtjen e mëposhtme:

FILESEXTRAPATHS:prepend := “${THISDIR}/${PN}:” SRC_URI += file:// .arnim
FILESEXTRAPATHS_prepend i thotë Yocto Project të shikojë në drejtorinë e listuar për të gjetur patch-in e listuar në SRC_URI.

Shënim:
Nëse një recetë bbappend nuk merret, view regjistri i marrjes file (log.do_fetch) nën dosjen e punës për të kontrolluar nëse arnimet përkatëse janë përfshirë apo jo. Ndonjëherë një version Git i recetës po përdoret në vend të versionit në bbappend files.

Si të zgjidhni paketa shtesë
Paketa shtesë mund të shtohen në imazhe nëse ofrohet një recetë për atë paketë. Një listë e kërkueshme
Një listë e recetave të ofruara nga komuniteti mund të gjendet në layers.openembedded.org/. Mund të kërkoni për të parë nëse një aplikacion ka tashmë një recetë të Projektit Yocto dhe të gjeni se nga mund ta shkarkoni atë.

Përditësimi i një imazhi
Një imazh është një grup paketash dhe konfigurimi i mjedisit.
Një imazh file (të tilla si imx-image-multimedia.bb) përcakton paketat që futen brenda file sistem. Rrënjë file sistemet, kernelet, modulet dhe binari U-Boot janë në dispozicion në build/tmp/deploy/images/ .

Shënim:
Ju mund të ndërtoni paketa pa e përfshirë atë në një imazh, por duhet ta rindërtoni imazhin nëse dëshironi që paketa të instalohet automatikisht në një rootfs.

Grupi i paketave
Një grup paketash është një grup paketash që mund të përfshihen në çdo imazh.
Një grup paketash mund të përmbajë një grup paketash. Për shembullampLe, një detyrë multimediale mund të përcaktojë, sipas makinës, nëse paketa VPU është ndërtuar apo jo, kështu që zgjedhja e paketave multimediale mund të automatizohet për çdo tabelë të mbështetur nga BSP, dhe vetëm paketa multimediale përfshihet në imazh.
Paketat shtesë mund të instalohen duke shtuar rreshtin e mëposhtëm /lokale.konf.

CORE_IMAGE_EXTRA_INSTALL: shtoj = ” ”

Ka shumë grupe paketash. Ato janë në nëndrejtori të emërtuara grupi i paketave ose grupet e paketave.

Versioni i preferuar
Versioni i preferuar përdoret për të specifikuar versionin e preferuar të një recete për t'u përdorur për një komponent specifik. Një komponent mund të ketë receta të shumta në shtresa të ndryshme dhe një version i preferuar tregon për një version specifik për t'u përdorur.

Në shtresën meta-imx, në layer.conf, versionet e preferuara caktohen për të gjitha recetat për të ofruar një sistem statik për një mjedis prodhimi. Këto cilësime të versionit të preferuar përdoren për lëshimet formale të i.MX, por nuk janë
thelbësore për zhvillimin e ardhshëm.
Versionet e preferuara ndihmojnë gjithashtu kur versionet e mëparshme mund të shkaktojnë konfuzion se cila recetë duhet të përdoret.
Për shembullample, recetat e mëparshme për imx-test dhe imx-lib përdorën një version në muaj, i cili ka ndryshuar në versionimi. Pa një version të preferuar, një version më i vjetër mund të merret. Recetat që kanë versione _git zakonisht zgjidhen mbi recetat e tjera, përveç rasteve kur vendoset një version i preferuar. Për të vendosur një version të preferuar, vendosni sa vijon në local.conf.

PREFERRED_VERSION_ : = " ”

Shihni manualet e projektit Yocto për më shumë informacion mbi përdorimin e versioneve të preferuara.

Ofruesi i preferuar
Ofruesi i preferuar përdoret për të specifikuar ofruesin e preferuar për një komponent specifik.
Një komponent mund të ketë ofrues të shumtë. Për shembullampLe, kerneli Linux mund të sigurohet nga i.MX ose nga kernel.org dhe ofruesi i preferuar deklaron ofruesin që duhet përdorur.
Për shembullample, U-Boot ofrohet nga komuniteti përmes denx.de dhe i.MX. Ofruesi i komunitetit është specifikuar nga u-boot-fslc. Ofruesi i.MX specifikohet nga u-boot-imx. Për të deklaruar një ofrues të preferuar, vendosni sa vijon në local.conf:

PREFERRED_PROVIDER_ : = “ "PREFERRED_PROVIDER_u-boot_mx6 = "u-boot-imx""

Familja SoC
Familja SoC dokumenton një klasë ndryshimesh që zbatohen për një grup specifik të çipave të sistemit. Në çdo konfigurim të makinës file, makina është e listuar me një familje specifike SoC. Për shembullample, i.MX 6DualLite Sabre-SD është listuar nën familjet SoC i.MX 6 dhe i.MX 6DualLite. i.MX 6Solo Sabre-auto është listuar nën i.MX 6 dhe
Familjet SoC të i.MX 6Solo. Disa ndryshime mund të synojnë një familje specifike SoC në local.conf për të anashkaluar një ndryshim në konfigurimin e një makine. file. Më poshtë është një ishample e një ndryshimi në një kernel mx6dlsabresd
vendosjen.

KERNEL_DEVICETREE:mx6dl = "imx6dl-sabresd.dts"

Familjet SoC janë të dobishme kur bëjnë një ndryshim që është specifik vetëm për një klasë të harduerit. Për shembullample, i.MX 28 EVK nuk ka një njësi të përpunimit video (VPU), kështu që të gjitha cilësimet për VPU duhet të përdorin i.MX 5 ose i.MX 6 për të qenë specifike për klasën e saktë të çipave.

Regjistrat e BitBake

• BitBake regjistron proceset e ndërtimit dhe paketimit në direktorinë e përkohshme në tmp/work/ / /temp.
• Nëse një komponent nuk arrin të marrë një paketë, regjistri që tregon gabimet është në file log.bëj_fetch.
  Nëse një komponent dështon të përpilohet, regjistri që tregon gabimet është në file log.bëj_përpiloj.
• Ndonjëherë një komponent nuk vendoset siç pritet. Kontrolloni drejtoritë nën komponentin e ndërtimit.
  direktoria (tmp/punë/ / Kontrolloni direktoritë package, packages-split dhe sysroot* të secilës recetë për të parë nëse files janë vendosur aty (ku janë staged para se të kopjohet në direktorinë e vendosjes).

Si të shtoni një mekanizëm për monitorimin dhe njoftimin e CVE-së
Mekanizmi i gjurmimit CVE mund të merret nga GitHub. Navigoni te drejtoria imx-yocto-bsp/sources.

Ekzekutoni komandën e mëposhtme:

klon git https://github.com/TimesysGit/meta-timesys.git-bmaster

Kjo komandë do të shkarkojë një metalayer shtesë që ofron skriptet për gjenerimin e manifestit të imazhit të përdorur për monitorimin dhe njoftimin e sigurisë si pjesë e ofertës së produktit Vigiles nga NXP dhe Timesys. Ndiqni seksionin 7.3 se si të përdorni zgjidhjen.
Marrja e aksesit në raportimin e plotë të CVE kërkon një çelës licence LinuxLink. Pa çelësin në mjedisin tuaj të zhvillimit, Vigiles vazhdon të ekzekutohet në modalitetin Demo, duke prodhuar vetëm raporte përmbledhëse.
Hyni në llogarinë tuaj Vigiles në LinuxLink (ose krijoni një nëse nuk keni një të tillë): https://www.timesys.com/register-nxp-vigiles/ Hyni te Preferencat tuaja dhe gjeneroni një Çelës të Ri. Shkarkoni çelësin file për zhvillimin tuaj
mjedis. Specifikoni vendndodhjen e çelësit file në konf/lokal.conf të Yocto-s tuaj file me deklaratën e mëposhtme:

VIGILES_KEY_FILE = "/tools/timesys/linuxlink_key"

Referencat

• Për detaje mbi çelësat e nisjes, shihni Seksionin "Si të nisni pllakat i.MX" në Udhëzuesin e Përdoruesit të i.MX Linux (UG10163).
• Për mënyrën e shkarkimit të imazheve duke përdorur U-Boot, shihni Seksionin “Shkarkimi i Imazheve duke përdorur U-Boot” në Udhëzuesin e Përdoruesit të i.MX Linux (UG10163).
• Për mënyrën e konfigurimit të një karte SD/MMC, shihni Seksionin “Përgatitja e një karte SD/MMC për nisje” në Udhëzuesin e Përdoruesit të i.MX Linux (UG10163).

Shënim rreth kodit burimor në dokument

ExampKodi le i treguar në këtë dokument ka të drejtën e autorit dhe licencën e mëposhtme BSD-3-Clause:
E drejta e autorit 2025 NXP Rishpërndarja dhe përdorimi në forma burimore dhe binare, me ose pa modifikim, lejohen me kusht që të plotësohen kushtet e mëposhtme:

1. Rishpërndarja e kodit burimor duhet të ruajë njoftimin e mësipërm për të drejtën e autorit, këtë listë të kushteve dhe mohimin e mëposhtëm.
2. Rishpërndarjet në formë binare duhet të riprodhojnë njoftimin e mësipërm të të drejtës së autorit, këtë listë të kushteve dhe mohimin e mëposhtëm në dokumentacionin dhe/ose materialet e tjera të ofruara me shpërndarjen.
3. As emri i mbajtësit të së drejtës së autorit dhe as emrat e kontribuesve të tij nuk mund të përdoren për të miratuar ose promovuar produkte që rrjedhin nga ky program pa leje specifike paraprake me shkrim.

KY PROGRAME OFROHET NGA MBAJTËSIT E TË DREJTAVE TË AUTORIT DHE KONTRIBUTORËT "SIÇ ËSHTË" DHE ÇDO GARANCI E SHPREHUR OSE E NËNKUPTUAR, DUKE PËRFSHIRË, POR PA U KUFIZUAR NË, GARANCITË E NËNKUPTUARA TË TREGTUESHMËRISË DHE PËRSHTATSHMËRISË PËR NJË QËLLIM TË CAKTUAR, MOHOHET. NË ASNJË RAST MBAJTËSI I TË DREJTAVE TË AUTORIT APO KONTRIBUTORËT NUK DO TË JENË PËRGJEGJËS PËR ASNJË DËM TË DREJTPËRDREJTË, INDIREKT, AKSIDENTAL, TË VEÇANTË, SHEMBULLOR APO PASOJOR (PËRFSHIRË, POR PA U KUFIZUAR NË, BLERJEN E MALLRAVE APO SHËRBIMEVE ZËVENDËSUESE; HUMBJEN E PËRDORIMIT, TË TË DHËNAVE APO FITIMEVE; APO NDËRPRERJEN E BIZNESIT) SIDOQOFTO TË SHKAKTUAR DHE NË BAZË TË ÇDO TEORIE PËRGJEGJËSIE, QOFTË NË KONTRATË, PËRGJEGJËSI TË RREGULLT APO DELIKAT (PËRFSHIRË PAKUJDESINË APO NDRYSHIM TJETËR) QË LIND NË ÇFARËDO MËNYRE NGA PËRDORIMI I KËTIJ PROGRAMI, EDHE NËSE JANË NJOFTUAR PËR MUNDËSINË E NJË DËMI TË TILLA.

Historia e rishikimit

Kjo tabelë ofron historikun e rishikimeve. Historia e rishikimeve

Informacion ligjor

Përkufizimet
Draft - Një status i draftit në një dokument tregon se përmbajtja është ende nën rishikim të brendshëmview dhe subjekt i miratimit formal, i cili mund të rezultojë
në modifikime ose shtesa. NXP Semiconductors nuk jep asnjë përfaqësim ose garanci për saktësinë ose plotësinë e informacionit të përfshirë në një version draft të një dokumenti dhe nuk ka asnjë përgjegjësi për pasojat e përdorimit të një informacioni të tillë.

Mohim përgjegjësish
Garancia dhe përgjegjësia e kufizuar — Informacioni në këtë dokument besohet të jetë i saktë dhe i besueshëm. Megjithatë, NXP Semiconductors nuk jep asnjë përfaqësim ose garanci, të shprehur ose të nënkuptuar, në lidhje me saktësinë ose plotësinë e një informacioni të tillë dhe nuk do të ketë asnjë përgjegjësi për pasojat e përdorimit të këtij informacioni. NXP Semiconductors nuk mban asnjë përgjegjësi për përmbajtjen në këtë dokument nëse ofrohet nga një burim informacioni jashtë NXP Semiconductors.

Në asnjë rast, gjysmëpërçuesit NXP nuk do të jenë përgjegjës për ndonjë dëm të tërthortë, të rastësishëm, ndëshkues, të veçantë ose pasues (përfshirë – pa kufizim – fitimet e humbura, kursimet e humbura, ndërprerjen e biznesit, kostot që lidhen me heqjen ose zëvendësimin e ndonjë produkti ose tarifat e ripërpunimit) pavarësisht nëse ose jo, këto dëme bazohen në dëmshpërblim (përfshirë neglizhencën), garanci, shkelje të kontratës ose ndonjë teori tjetër ligjore.
Pavarësisht nga dëmtimet që mund të pësojë klienti për çfarëdo arsye, përgjegjësia totale dhe kumulative e NXP Semiconductors ndaj klientit për produktet e përshkruara këtu do të kufizohet në përputhje me Termat dhe kushtet e shitjes komerciale të NXP Semiconductors.

• E drejta për të bërë ndryshime — NXP Semiconductors rezervon të drejtën të bëjë ndryshime në informacionin e publikuar në këtë dokument, duke përfshirë pa kufizim specifikimet dhe përshkrimet e produktit, në çdo kohë dhe pa paralajmërim. Ky dokument zëvendëson dhe zëvendëson të gjithë informacionin e dhënë përpara publikimit të tij.
• Përshtatshmëria për përdorim — Produktet NXP Semiconductors nuk janë të dizajnuara, të autorizuara ose të garantuara që të jenë të përshtatshme për t'u përdorur në mbështetje për jetën, sisteme ose pajisje kritike për jetën ose sigurinë, as në aplikacione ku mund të pritet në mënyrë të arsyeshme dështimi ose mosfunksionimi i një produkti NXP Semiconductors të rezultojë në lëndime personale, vdekje ose dëmtime të rënda pronësore ose mjedisore. NXP Semiconductors dhe furnitorët e tij nuk pranojnë asnjë përgjegjësi për përfshirjen dhe/ose përdorimin e produkteve NXP Semiconductors në pajisje ose aplikacione të tilla dhe për këtë arsye përfshirja dhe/ose përdorimi i tillë është në rrezikun e klientit.
• Aplikacionet — Aplikacionet që përshkruhen këtu për cilindo prej këtyre produkteve janë vetëm për qëllime ilustruese. NXP Semiconductors nuk jep asnjë përfaqësim ose garanci që aplikacione të tilla do të jenë të përshtatshme për përdorimin e specifikuar pa testime ose modifikime të mëtejshme.
  Klientët janë përgjegjës për projektimin dhe funksionimin e aplikacioneve dhe produkteve të tyre duke përdorur produktet NXP Semiconductors dhe NXP Semiconductors nuk pranon asnjë përgjegjësi për asnjë ndihmë me aplikacionet ose dizajnimin e produktit të klientit. Është përgjegjësi e vetme e klientit të përcaktojë nëse produkti NXP Semiconductors është i përshtatshëm dhe i përshtatshëm për aplikacionet e klientit dhe produktet e planifikuara, si dhe për aplikimin dhe përdorimin e planifikuar të klientëve të palëve të treta të klientit. Konsumatorët duhet të ofrojnë masa mbrojtëse të përshtatshme për dizajnin dhe funksionimin për të minimizuar rreziqet që lidhen me aplikacionet dhe produktet e tyre.
• NXP Semiconductors nuk pranon asnjë përgjegjësi në lidhje me ndonjë parazgjedhje, dëmtim, kosto ose problem që bazohet në ndonjë dobësi ose parazgjedhje në aplikacionet ose produktet e klientit, ose aplikimin ose përdorimin nga klientët e palëve të treta të klientit. Klienti është përgjegjës për kryerjen e të gjitha testeve të nevojshme për aplikacionet dhe produktet e klientit duke përdorur produktet NXP Semiconductors në mënyrë që të shmanget një parazgjedhje e aplikacioneve dhe produkteve ose e aplikacionit ose përdorimi nga klientët e palëve të treta të klientit. NXP nuk pranon asnjë përgjegjësi në këtë drejtim.
• Termat dhe kushtet e shitjes komerciale — Produktet e NXP Semiconductors shiten duke iu nënshtruar kushteve të përgjithshme të shitjes komerciale, të publikuara në https://www.nxp.com/profile/terms përveç nëse është rënë dakord ndryshe në një marrëveshje individuale të vlefshme me shkrim. Në rast të lidhjes së një marrëveshjeje individuale do të zbatohen vetëm termat dhe kushtet e marrëveshjes përkatëse. NXP Semiconductors shprehimisht kundërshton zbatimin e termave dhe kushteve të përgjithshme të klientit në lidhje me blerjen e produkteve të NXP Semiconductors nga klienti.
• Kontrolli i eksportit — Ky dokument si dhe artikujt e përshkruar këtu mund t'i nënshtrohen rregulloreve të kontrollit të eksportit. Eksporti mund të kërkojë një autorizim paraprak nga autoritetet kompetente.
• Përshtatshmëria për t'u përdorur në produkte jo të kualifikuara për automobila — Nëse ky dokument nuk thotë shprehimisht se ky produkt specifik NXP Semiconductors është i kualifikuar për automobila, produkti nuk është i përshtatshëm për përdorim automobilistik. Nuk është as i kualifikuar dhe as i testuar në përputhje me kërkesat e testimit të automobilave ose aplikimit. NXP Semiconductors nuk pranon asnjë përgjegjësi për përfshirjen dhe/ose përdorimin e produkteve jo të kualifikuara për automobila në pajisjet ose aplikacionet e automobilave.
• Në rast se klienti përdor produktin për dizajnim dhe përdorim në aplikacionet e automobilave sipas specifikimeve dhe standardeve të automobilave, klienti (a) do të përdorë produktin pa garancinë e produktit nga NXP Semiconductors për aplikime, përdorim dhe specifikime të tilla automobilistike, dhe (a) b) sa herë që klienti përdor produktin për aplikime automobilistike përtej specifikimeve të NXP Semiconductors, ky përdorim do të jetë vetëm në rrezik të klientit dhe (c) klienti dëmshpërblen plotësisht NXP Semiconductors për çdo përgjegjësi, dëmtim ose pretendim të dështuar të produktit që rezulton nga dizajni i klientit dhe përdorimi i produkti për aplikimet e automobilave përtej garancisë standarde të NXP Semiconductors dhe specifikimeve të produktit të NXP Semiconductors.
• Publikime HTML - Një version HTML, nëse disponohet, i këtij dokumenti ofrohet si mirësjellje. Informacioni përfundimtar gjendet në dokumentin e aplikueshëm në formatin PDF. Nëse ka një mospërputhje midis dokumentit HTML dhe dokumentit PDF, dokumenti PDF ka përparësi.
• Përkthime - Një version jo-anglisht (i përkthyer) i një dokumenti, duke përfshirë informacionin ligjor në atë dokument, është vetëm për referencë. Versioni në anglisht do të mbizotërojë në rast të ndonjë mospërputhjeje midis versionit të përkthyer dhe atij në anglisht.

• Siguria — Klienti e kupton që të gjitha produktet NXP mund t'i nënshtrohen dobësive të paidentifikuara ose mund të mbështesin standardet ose specifikimet e vendosura të sigurisë me kufizime të njohura. Klienti është përgjegjës për projektimin dhe funksionimin e aplikacioneve dhe produkteve të tij gjatë gjithë ciklit të jetës së tij për të reduktuar efektin e këtyre dobësive në aplikacionet dhe produktet e klientit. Përgjegjësia e klientit shtrihet edhe në teknologji të tjera të hapura dhe/ose të pronarit të mbështetura nga produktet NXP për përdorim në aplikacionet e klientit. NXP nuk pranon asnjë përgjegjësi për ndonjë cenueshmëri. Klienti duhet të kontrollojë rregullisht përditësimet e sigurisë nga NXP dhe të ndjekë siç duhet.
• Klienti duhet të zgjedhë produkte me karakteristika sigurie që plotësojnë më së miri rregullat, rregulloret dhe standardet e aplikacionit të synuar dhe të marrë vendimet përfundimtare të projektimit në lidhje me produktet e tij dhe është i vetëm përgjegjës për pajtueshmërinë me të gjitha kërkesat ligjore, rregullatore dhe të sigurisë në lidhje me produktet e tij, pavarësisht për çdo informacion ose mbështetje që mund të ofrohet nga NXP.
• NXP ka një ekip të reagimit ndaj incidentit të sigurisë së produktit (PSIRT) (i arritshëm në PSIRT@nxp.com që menaxhon hetimin, raportimin dhe lëshimin e zgjidhjeve për dobësitë e sigurisë të produkteve NXP.
• NXP B.V. — NXP B.V. nuk është një kompani operuese dhe nuk shpërndan apo shet produkte.

Markat tregtare
Shënim: Të gjitha markat e referuara, emrat e produkteve, emrat e shërbimeve dhe markat tregtare janë pronë e pronarëve të tyre përkatës.
NXP — marka e fjalës dhe logoja janë marka tregtare të NXP BV

© 2025 NXP BV Të gjitha të drejtat e rezervuara.

Dokumentet / Burimet

Projekti NXP UG10164 i.MX Yocto [pdfUdhëzuesi i përdoruesit LF6.12.20_2.0.0, UG10164 i.MX Yocto Project, UG10164, i.MX Yocto Project, Yocto Project, Project

Referencat

• Manuali i Përdoruesit