Udhëzues përdorimi i projektit NXP IMXLXYOCTOUG i.MX Yocto

Informacion	përmbajtja
Fjalë kyçe	i.MX, Linux, LF6.6.3_1.0.0
Abstrakt	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.

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/. Ka disa dokumente në faqen kryesore të Yocto Project që përshkruajnë në detaje se si të përdoret sistemi. Për të përdorur projektin bazë Yocto pa shtresën e lëshimit i.MX, ndiqni udhëzimet në Fillimin e Shpejtë të Projektit Yocto që gjendet në https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html.
Komuniteti FSL Yocto Project BSP (gjendet në Komuniteti FSL BSP (freescale.github.io)) është një komunitet zhvillimi jashtë NXP që ofron mbështetje për bordet i.MX në mjedisin Yocto Project. i.MX iu bashkua komunitetit të projektit Yocto duke ofruar një version të bazuar në kornizën e projektit Yocto. Informacioni 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-bsp: përditësime për shtresat me shkallë të lirë, poky dhe meta-të hapura
– meta-sdk: përditësime për shpërndarjet meta-freescale
– meta-ml: Receta të mësimit të makinës
– meta-v2x: Recetat V2X përdoren vetëm për i.MX 8DXL
– meta-kabinë: Receta të kabinës 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. Shiko 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 i.MX BSP Release, e quajtur meta-imx, për të integruar një version të ri i.MX me BSP të Komunitetit të Projektit FSL Yocto. Shtresa meta-imx synon të lëshojë recetat dhe konfigurimet e makinerive të përditësuara dhe të reja të projektit Yocto për publikimet e reja që nuk janë ende të disponueshme në shtresat ekzistuese meta-shkallë të lirë dhe meta-shkallë të lirë-shpërndarje në Projektin Yocto. Përmbajtja e i.MX BSP
Shtresa e lëshimit 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.
Lëshimet e kernelit i.MX dhe U-Boot arrihen përmes serverëve publikë Git i.MX. Megjithatë, disa komponentë lëshohen si paketa në pasqyrën i.MX. Recetat e bazuara në paketë 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.
Publikimi LF6.6.3_1.0.0 është lëshuar për Yocto Project 4.3 (Nanbield). Të njëjtat receta për Yocto Project 4.3 do të transmetohen dhe do të vihen në dispozicion në versionin tjetër të versionit Yocto Project. Cikli i lëshimit të Yocto Project zgjat afërsisht gjashtë muaj.
Recetat dhe arnimet në meta-imx janë ngjitur në shtresat e komunitetit. Pas kësaj është bërë për një komponent të veçantë, 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.

1.1 Marrëveshja e licencës së përdoruesit përfundimtar
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.

1.2 Referenca
i.MX ka shumë familje të mbështetura në softuer. Më poshtë janë familjet e listuara dhe SoC-të për familje. Shënimet e lëshimit 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ë vërtetuara nëse janë në nivelin e mëparshëm të vërtetuar.

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
Familja i.MX 9: i.MX 93, i.MX 95

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

i.MX Linux Release Notes (IMXLXRN) – Ofron informacionin e lëshimit.

Udhëzuesi i përdoruesit i.MX Linux (IMXLUG) – Ofron informacion mbi instalimin e U-Boot dhe Linux OS dhe përdorimin e veçorive specifike të i.MX.
Udhëzuesi i përdoruesit i.MX Yocto Project (IMXLXYOCTOUG) – Përshkruan paketën mbështetëse të bordit për sistemet e zhvillimit NXP duke përdorur Yocto Project për të konfiguruar hostin, instaluar zinxhirin e veglave dhe për të ndërtuar kodin burimor për të krijuar imazhe.

i.MX Machine Learning's Guide's User's (IMXMLUG) – Ofron informacionin e mësimit të makinës.
Manuali i Referencës i.MX Linux (IMXLXRM) – Ofron informacion mbi drejtuesit e Linux për i.MX.

Udhëzuesi i përdorimit të i.MX Graphics (IMXGRAPHICUG) – Përshkruan veçoritë grafike.
i.MX Porting Guide (IMXXBSPPG) – Ofron udhëzime për transferimin e BSP në një bord të ri.

Manuali i referencës Linux i ndërfaqes së programimit të aplikacionit i.MX VPU (IMXVPUAPI) – Ofron informacionin e referencës mbi API-në VPU në i.MX 6 VPU.
Udhëzuesi i përdoruesit të Harpoon (IMXHPUG) – Paraqet lëshimin e Harpoon për familjen e pajisjeve i.MX 8M.

Aktivizimi i ndarjes së harduerit të kabinës dixhitale i.MX për i.MX 8QuadMax (IMXDCHPE) – Ofron zgjidhjen e harduerit i.MX Digital Cockpit për i.MX 8QuadMax.
Udhëzuesi i përdoruesit i.MX DSP (IMXDSPUG) – Ofron informacionin mbi DSP për i.MX 8.

Udhëzuesi i kamerës dhe ekranit i.MX 8M Plus (IMX8MPCDUG) – Siguron informacionin mbi API-në e ndërfaqes së sensorit të pavarur të ISP-së për i.MX 8M Plus.
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.

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 93 është në nxp.com/imx93.
Informacioni i.MX 95 është në nxp.com/imx95.

Veçoritë

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

Receta e kernelit Linux
– Receta e kernelit qëndron në dosjen recipes-kernel dhe integron një kernel i.MX nga burimi i shkarkuar nga serveri i.MX Git. Kjo bëhet automatikisht nga recetat në projekt.
– LF6.6.3_1.0.0 është një kernel Linux i lëshuar për Projektin Yocto.

Receta U-Boot
– Receta U-Boot ndodhet në dosjen recipes-bsp dhe integron një i.MX uboot-imx.git nga burimi i shkarkuar nga serveri i.MX Git.
– Lëshimi i i.MX LF6.6.3_1.0.0 për pajisjet i.MX 6, i.MX 7, i.MX 8, i.MX 93 dhe i.MX 95 përdor një v2023.04 i.MX U- të përditësuar Versioni i nisjes. Ky version nuk është përditësuar për të gjithë pajisjet i.MX.
– I.MX Yocto Project Community BSP 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.6.3.
– I.MX Yocto Project Community BSP përditëson shpesh versionet U-Boot, kështu që informacioni i mësipërm mund të ndryshojë pasi versionet e reja U-Boot janë integruar në shtresat me shkallë të lirë dhe përditësimet nga lëshimet i.MX uboot-imx janë integruar në linjë kryesore.
Receta grafike
– Recetat grafike qëndrojnë në dosjen receta-grafike.
– Recetat grafike integrojnë lëshimin e paketës grafike i.MX. Për bordet i.MX që kanë një GPU, recetat imx-gpu-viv paketojnë komponentët grafikë për çdo DISTRO: buffer-i i kornizës (FB), XWayland, prapavija e Wayland dhe kompozitori Weston (Weston). Vetëm i.MX 6 dhe i.MX 7 mbështesin Frame Buffer.
– Xorg-driver integron xserver-xorg.

Recetat e paketave i.MX firmware-imx, imx-sc-fimrware dhe paketa të tjera qëndrojnë në recipes-bsp dhe tërhiqen nga pasqyra i.MX për të ndërtuar dhe paketuar në receta imazhi.
Receta multimediale
– Recetat multimediale qëndrojnë në receta-multimedia.
– Paketat e pronarit si imx-codec dhe imx-parser kanë receta që tërhiqen nga pasqyra i.MX për të ndërtuar dhe paketuar në receta imazhi.
– Paketat me burim të hapur kanë receta që tërhiqen nga Git Repos publike në GitHub.
– Janë dhënë disa receta për kodekët që janë të kufizuar. Paketat për këto nuk janë në pasqyrën i.MX.
Këto paketa janë të disponueshme veçmas. Kontaktoni përfaqësuesin tuaj të marketingut i.MX për t'i blerë 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 e demonstrimit gjenden në drejtorinë meta-sdk. Kjo shtresë përmban receta imazhi dhe receta për personalizim, të tilla si kalibrimi me prekje ose receta për aplikacione demonstruese.
Receta të mësimit të makinës
Recetat e mësimit të makinerisë gjenden në drejtorinë meta-ml. Kjo shtresë përmban receta të mësimit të makinerive për paketa si tensorflow-lite, onnx, etj.
Recetat e kabinës
Recetat e kabinës qëndrojnë në meta-kabinë dhe mbështeten në i.MX 8QuadMax duke përdorur konfigurimin e makinës imx-8qmcockpit-mek.
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ë lëshuara.

Konfigurimi i hostit

Për të marrë sjelljen e pritur të projektit Yocto në një makineri pritëse Linux, duhet të instalohen paketat dhe shërbimet e përshkruara më poshtë. Një konsideratë e rëndësishme është hapësira në hard disk që kërkohet në makinën pritës. 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ë 20.04 ose më i ri. Lëshimi i fundit mbështet Chromium v91, i cili kërkon një rritje në kufirin (numri i hapur files) deri në 4098.

3.1 Doker
i.MX tani po lëshon skriptet e konfigurimit të docker-it GitHub – nxp-imx/imx-docker: i.MX Docker. Ndiqni udhëzimet në readme për konfigurimin e një makinerie të ndërtimit të hostit duke përdorur docker.
Përveç kësaj, docker në bord është aktivizuar 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 doker nga qendrat e jashtme të dokerit.

3.2 Paketat pritëse
Një ndërtim i projektit Yocto kërkon që të instalohen paketa specifike për ndërtimin që janë të dokumentuara në kuadër të Projektit Yocto. Shkoni në 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 instaloni gawk wget git diffstat unzip texinfo gcc build-thelbësore \chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils \iputils-ping python3-git python3-devijl python2-jindmes limon1-jindja. subunit mesa-common-dev zstd liblz1.2-tool file lokale -y
$ sudo locale-gen en_US.UTF-8

Mjeti i konfigurimit përdor versionin e paracaktuar të grep që është në makinën tuaj të ndërtimit. Nëse ka një version tjetër të grep në rrugën tuaj, mund të shkaktojë dështimin e ndërtimeve. Një rrugëdalje është të riemërtoni versionin special në diçka që nuk përmban "grep".

3.3 Vendosja e programit Repo
Repo është një mjet i ndërtuar në krye të Git që e bën më të lehtë menaxhimin e projekteve që përmbajnë depo të shumta, të cilat nuk kanë nevojë të jenë në të njëjtin server. Repo plotëson shumë mirë natyrën e shtresave 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", kryeni këto hapa:

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

Konfigurimi i projektit Yocto

Së pari, sigurohuni që Git të jetë konfiguruar siç duhet me komandat e mëposhtme:
$ git config – global user.name “Emri juaj”
$ git config – global user.email “Email juaj”
$ git config –lista

Direktoria i.MX Yocto Project BSP Release përmban një direktori burimesh, e cila përmban recetat e përdorura për të ndërtuar një ose më shumë drejtori ndërtimi dhe një grup skriptesh të përdorura për të konfiguruar mjedisin.
Recetat e përdorura për të ndërtuar projektin vijnë si nga komuniteti ashtu edhe nga i.MX. Shtresat e Projektit Yocto shkarkohen në drejtorinë e burimeve. Kjo përcakton recetat që përdoren për të ndërtuar projektin.
Ish-i i mëposhtëmamptregon se si të shkarkohen shtresat e recetave të komunitetit i.MX Yocto Project BSP. Për këtë ishample, një direktori e quajtur imx-yocto-bsp është krijuar për projektin. Në vend të këtij mund të përdoret çdo emër.
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ repo init -u https://github.com/nxp-imx/imx-manifest
-b imx-linux-nanbield -m imx-6.6.3-1.0.0.xml
sinkronizimi i repove $

Shënim:
https://github.com/nxp-imx/imx-manifest/tree/imx-linux-nanbield ka një listë të të gjitha manifesteve files mbështetur në këtë version.
Kur ky proces të përfundojë, kodi burim kontrollohet në direktorinë imx-yocto-bsp/sources.
Ju mund të kryeni sinkronizimin e Repo, me komandën repo sync, në mënyrë periodike për t'u përditësuar në kodin më të fundit.
Nëse ndodhin gabime gjatë inicializimit të Repo, provoni të fshini direktorinë .repo dhe të ekzekutoni sërish komandën e inicializimit të Repo.
Fillimi i repos është konfiguruar për arnimet më të fundit në linjë. Ndiqni udhëzimet në indeks: imx-manifest.git për të marrë GA origjinale. Përndryshe, arnimet GA plus merren si parazgjedhje. Për të marrë botimet e mëparshme nga baza e Zeusit, shtoni -m (emri i manifestit të lëshimit) në fund të linjës së inicializimit të Repo dhe ai do të marrë lëshimet e mëparshme. p.shampato janë dhënë në README file në lidhjen e dhënë më sipër.

Ndërtimi i imazhit

Ky seksion ofron informacion të detajuar së bashku me procesin për ndërtimin e një imazhi.

5.1 Ndërtimi i konfigurimeve
i.MX ofron një skript, imx-setup-release.sh, që thjeshton konfigurimin për makinat i.MX. Për të përdorur skriptin, duhet të specifikohet emri i makinës specifike që do të ndërtohet, si dhe prapavija e dëshiruar grafike.
Skripti krijon një drejtori dhe konfigurimin files për makinën dhe backendin e specifikuar.
Në shtresën meta-imx, i.MX ofron konfigurime të reja ose të përditësuara të makinës që mbivendosin konfigurimet e makinerive metafreescale. Këto files kopjohen në direktorinë meta-freescale/conf/machine nga skripti imx-setup-release.sh. Më poshtë janë konfigurimi i makinës i.MX files që mund të zgjidhen. Kontrolloni ose shënimet e lëshimit ose drejtorinë e makinës për shtesat më të fundit.

i.MX 6	i.MX 7	i.MX 8	i.MX 9
• imx6qpsabresd • imx6ulevk • imx6ulz-14x14evk • imx6ull14x14evk • imx6ull9x9evk • imx6dlsabresd • imx6qsabresd • imx6solosabresd • imx6sxsabresd • imx6sllevk	• imx7dsabresd • imx7ulpevk	• 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-lpddr4evk	• imx93evk • imx93-11x11lpddr4x-evk • imx93-9×9-lpddr4qsb • imx93-14x14lpddr4x-evk

Çdo dosje ndërtimi duhet të konfigurohet në atë mënyrë që të përdorin vetëm një shpërndarje. Sa herë që ndryshohet ndryshorja DISTRO_FEATURES, nevojitet një dosje e pastër ndërtimi. Çdo kornizë grafike Frame Buffer, Wayland dhe XWayland kanë secili një konfigurim distro. Nëse jo DISTRO file është specifikuar, distro XWayland është vendosur si parazgjedhje. Konfigurimet distro ruhen në local.conf file në cilësimin DISTRO dhe shfaqen kur bitbake është në punë. Në versionet e kaluara, ne përdorëm shpërndarjen poky dhe versionet dhe ofruesit e personalizuar në layer.conf, por një shpërndarje e personalizuar është një zgjidhje më e mirë. Kur përdoret shpërndarja e paracaktuar poky, përdoret konfigurimi i parazgjedhur i komunitetit. Si një version i.MX, ne preferojmë të kemi një grup konfigurimesh që NXP i mbështet dhe i ka testuar.
Këtu është lista e konfigurimeve DISTRO. Vini re se fsl-imx-fb nuk mbështetet në i.MX 8 dhe fsl-imxx11 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.

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ë:
$ DISTRO= MAKINË= burim imx-setup-release.sh -b

DISTRO= është distro, e cila konfiguron mjedisin e ndërtimit dhe ruhet në meta-imx/meta-sdk/conf/distro.
MAKINË= është emri i makinës që tregon konfigurimin file në conf/machine në meta-freescale dhe meta-imx.
-b specifikon emrin e drejtorisë 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 metalike të përdorura në lëshimin e i.MX Yocto Project.
Lokalja.konf file përmban specifikimet e makinës dhe shpërndarjes:

MAKINA ??= 'imx7ulpevk'
DISTRO ?= 'fsl-imx-xwayland'
ACCEPT_FSL_EULA = "1"

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, konfigurimet e konsoliduara të makinës (imx6qpdlsolox.conf dhe imx6ul7d.conf) ofrohen 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 pajisjes në një imazh për testim. Mos i përdorni këto makina për asgjë tjetër përveç testimit.

5.2 Zgjedhja e një imazhi të projektit i.MX Yocto
Projekti Yocto ofron disa imazhe që janë të disponueshme në shtresa të ndryshme. Poky ofron disa imazhe, meta-freescale dhe meta-freescale-distro ofrojnë të tjera dhe receta shtesë imazhesh ofrohen në shtresën meta-imx. Tabela e mëposhtme liston imazhe të ndryshme kryesore, përmbajtjen e tyre dhe shtresat që ofrojnë recetat e imazheve.

Tabela 1. Imazhet e projektit i.MX Yocto

Emri i imazhit	Synimi	Ofrohet nga shtresa
bërthamë-imazh-minimal	Një imazh i vogël që lejon vetëm një pajisje të niset.	i mprehtë
bërthamë-imazh-bazë	Një imazh vetëm i konsolës që mbështet plotësisht harduerin e pajisjes së synuar.	i mprehtë
bërthamë-imazh-sato	Një imazh me Sato, një mjedis celular dhe stil vizual për pajisjet celulare. Imazhi mbështet një temë Sato dhe përdor aplikacionet Pimlico. Ai përmban një terminal, një redaktues dhe një file menaxher.	i mprehtë
imx-image-core	Një imazh i.MX me aplikacione testimi i.MX që do të përdoret për backend-et e Wayland. Ky imazh përdoret nga testimi ynë kryesor i përditshëm.	meta-imx/meta-sdk
fsl-image-machine- test	Një imazh thelbësor i komunitetit FSL i.MX me mjedis konsolë – pa ndërfaqe GUI.	meta-freescale-distro
imx-image-multimedia	Ndërton një imazh i.MX me një GUI pa ndonjë përmbajtje Qt.	meta-imx/meta-sdk
imx-imazh-plotë	Ndërton një imazh Qt 6 me burim të hapur me veçoritë e Mësimit të Makinerisë. Këto imazhe mbështeten vetëm për i.MX SoC me grafikë harduerike. Ato nuk mbështeten në i.MX 6UltraLite, i.MX 6UltraLiteLite, i.MX 6SLL, [MX 7Dual, i.MX 8MNanoLite, ose i.MX 8DXL	meta-imx/meta-sdk

5.3 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

5.4 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 opsione të ndryshme të dobishme për zhvillimin e një komponenti të vetëm. Për të ekzekutuar me një parametër BitBake, komanda duket si kjo: bitbake është një paketë ndërtimi e dëshiruar.
Tabela e mëposhtme ofron disa opsione të BitBake.

Tabela 2. Opsionet e BitBake

Parametri BitBake	Përshkrimi
-c marr	Merr nëse gjendja e shkarkimeve nuk është shënuar si e kryer.
-c pastroj të gjithë	Pastron të gjithë drejtorinë e ndërtimit të komponentit. Të gjitha ndryshimet në drejtorinë e ndërtimit janë humbur. Rrënjët dhe gjendja e komponentit gjithashtu pastrohen. Komponenti hiqet gjithashtu nga direktoria e shkarkimit.
-c vendos	Vendos një imazh ose komponent në rootfs.
-k	Vazhdon ndërtimin e komponentëve edhe nëse ndodh një ndërprerje ndërtimi.
-c përpiloj -f	Nuk rekomandohet që kodi burimor nën drejtorinë e përkohshme të ndryshohet drejtpërdrejt, por nëse është, Projekti Yocto mund të mos e rindërtojë atë nëse nuk përdoret ky opsion. Përdoreni këtë opsion për të detyruar një ripërpilim pasi imazhi të vendoset.
-g	Liston një pemë varësie për një imazh ose komponent.
-DDD	Aktivizon korrigjimin e 3 niveleve të thella. Çdo D shton një nivel tjetër të korrigjimit.
-s, –show-versionet	Tregon versionet aktuale dhe të preferuara të të gjitha recetave.

5.5 Konfigurimi 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 duhur).
Konfigurime të shumta 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 tabelë. Pllakat i.MX 6 dhe i.MX 7 mbështesin SD pa OPTEE dhe me OP-TEE:

uboot_config_imx93evk=”sd fspi”
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”

Për të ndërtuar me çdo konfigurim U-Boot, kryeni hapat e mëposhtëm.
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
$ MAKINA= bitbake -c vendos u-boot-imx
Shënim: i.MX 8 përdor imx-boot që tërheq U-Boot.

5.6 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
$ repo init -u https://github.com/nxp-imx/imx-manifest
-b imx-linux-nanbield -m imx-6.6.3-1.0.0.xml
sinkronizimi i repove $
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.

5.6.1 Imazhi i buferit të kornizës në i.MX 6QuadPlus SABRE-AI
$ DISTRO=fsl-imx-fb MACHINE=imx6qpsabreauto burim imx-setup-release.sh –b build-fb
$ bitbake imx-image-multimedia
Kjo ndërton një imazh multimedial me një fund të tamponit të kornizës.

5.6.2 Imazhi XWayland në i.MX 8QuadXPlus MEK
$ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek burim imx-setup-release.sh -b build-xwayland
$ bitbake imx-image-plotë
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.

5.6.3 Imazhi i Wayland në i.MX 8M Quad EVK
$ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk burim imx-setup-release.sh -b buildwayland
$ bitbake imx-image-multimedia
Kjo krijon një imazh të Weston Wayland me multimedia pa Qt 6.

5.6.4 Rinisja e një mjedisi ndërtimi
Nëse hapet një dritare e re terminali ose pajisja rindizet pas konfigurimit të një drejtorie 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. Imxsetup-release.sh i plotë nuk është i nevojshëm.
konfigurimi-mjedisi i burimit $

5.6.5 Shfletuesi Chromium në XWayland dhe 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.
Në local.conf për XWayland ose Wayland, shtoni Chromium në imazhin tuaj. X11 nuk mbështetet.
CORE_IMAGE_EXTRA_INSTALL += "krom-ozon-rrugë"

5.6.6 Qt 6 dhe QtWebShfletuesit e motorit
Qt 6 ka një licencë komerciale dhe një burim të hapur. Kur ndërtoni në Yocto Project, licenca me burim të hapur është e paracaktuar. Sigurohuni që të kuptoni ndryshimet midis këtyre licencave dhe zgjidhni siç duhet. Pasi të ketë filluar zhvillimi i personalizuar i Qt 6 në licencën me burim të hapur, ai 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ë ekzekutuesin.
./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"

5.6.7 Mësimi i makinerive 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"

5.6.8 Sistemuar
Systemd është aktivizuar si menaxheri i paracaktuar i inicializimit. Për të çaktivizuar systemd si parazgjedhje, shkoni te fsl-imxpreferred-env.inc dhe komentoni seksionin systemd.

5.6.9 Aktivizimi Multilib
Për i.MX 8, ndërtimi i aplikacioneve 32-bit në OS 64-bit mund të mbështetet duke përdorur konfigurimin multilib. Multilib ofron mundësinë për të ndërtuar biblioteka me optimizime të ndryshme të synimeve ose formate të arkitekturës dhe për t'i kombinuar këto së bashku në një imazh të sistemit. Multilib aktivizohet duke shtuar deklaratën MULTILIB, DEFAULTTUNE dhe IMAGE_INSTALL në local.conf tuaj file. Multilib nuk mbështetet me menaxhimin e paketës debian. Kërkon sistemin RPM. Komentoni dy linjat e menaxhimit të paketave në local.conf për të shkuar te RPM e paracaktuar.
Deklarata MULTILIBS është zakonisht lib32 ose lib64 dhe duhet të përcaktohet në
Ndryshore MULTILIB_GLOBAL_VARIANTS si më poshtë:

MULTILIBS = "multilib:lib32"
DEFAULTTUNE duhet të jetë një nga vlerat AVAILTUNES për këtë lloj bibliotekë alternative si më poshtë:
DEFAULTTUNE:virtclass-multilib-lib32 = "armv7athf-neon"
IMAGE_INSTALL do t'i shtohet imazhit, bibliotekat 32-bit të kërkuara nga aplikacioni specifik si më poshtë:
IMAGE_INSTALL:append = "lib32-bash"
Për rastin në i.MX 8, ndërtimi i një mbështetjeje aplikacioni 32-bit do të kërkonte deklaratat e mëposhtme në local.conf. Ky konfigurim specifikon një makinë 64-bit si llojin kryesor të makinës dhe shton multilib:lib32, ku ato biblioteka kompilohen me melodinë armv7athf-neon, dhe më pas përfshin në të gjitha imazhet paketat lib32.
MAKINË = imx8mqevk
# Përcaktoni objektivin multilib
kërkojnë conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE:virtclass-multilib-lib32 = "armv7athf-neon"
# Shtoni paketat multilib në imazh
IMAGE_INSTALL:append = ” lib32-glibc lib32-libgcc lib32-libstdc++”
Çaktivizo paketimin deb për të shmangur çdo gabim në përpunim. Kontrolloni në local.conf dhe komentoni nëse ka:
PACKAGE_CLASSES = "pako_deb"
EXTRA_IMAGE_FEATURES += "menaxhimi i paketës"

5.6.10 Aktivizimi 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 meta-imx/meta-bsp/conf/layer.conf file dhe komentoni shtojcën DISTRO_FEATURES_për OP-TEE dhe hiqni komentin e linjës së hequr.

5.6.11 Ndërtimi i burgut
Jailhouse është një Hipervisor statik i ndarjes i bazuar në Linux OS. Mbështetet në bordet i.MX 8M Plus, i.MX 8M Nano, i.MX 8M Quad EVK dhe i.MX 8M Mini EVK.

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 jh_netboot ose jh_mmcboot. Ai ngarkon DTB-në e dedikuar për përdorimin e Jailhouse. Marrja e i.MX 8M Quad si ishample, pasi Linux OS të niset:
#insmod jailhouse.ko
#./jailhouse aktivizo imx8mq.cell

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

5.6.12 Menaxhimi i paketës
Menaxhimi i parazgjedhur i paketës me Yocto Project është rpm. Shpërndarja i.MX tani mundëson debian si menaxhimin e paketës. Kjo mund të çaktivizohet lehtësisht duke shtuar ACKAGE_CLASSES të vendosur në package_rpm në local.conf, ose duke krijuar një shpërndarje të personalizuar pa furnizimin e paketës debian PACKAGE_CLASSES = "package_deb" .
Me shtimin e furnizimit të paketës debian, një sources.list mund të shtohet në /etc/apt që lidhet në furnizimin e paketave të Debian. Kjo i lejon përdoruesit të instalojnë paketa që nuk janë dhënë në imazh pa pasur nevojë t'i shtojnë ato në një imazh Yocto. Për shkak se ky furnizim i paketës nuk gjenerohet nga procesi i ndërtimit i.MX Yocto, nuk ka asnjë garanci se çdo paketë do të funksionojë me varësitë e duhura, por lejon që të ofrohen mjete më të thjeshta.
Softueri që është kompleks dhe ka më shumë varësi nga versione specifike mund të ketë probleme me furnizimin e jashtëm të paketave.

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.

6.1 Ndezja e një imazhi 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 ndezjen, shihni seksionin "Përgatitja e një karte SD/MMC për të nisur" në Udhëzuesin e Përdoruesit të i.MX Linux (IMXLUG). Për aplikacionet e mësimit të makinerisë 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ë local.conf file përpara procesit të ndërtimit të Yocto. Shihni Mega-Manual i 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.

Përshtatja e kernelit dhe krijimi i një peme të personalizuar të bordit dhe pajisjes me kernel dhe U-Boot. Për më shumë detaje se si të ndërtoni një SDK dhe të konfiguroni një makinë pritës për ndërtimin e kernelit dhe U-Boot vetëm jashtë mjedisit të ndërtimit të Yocto Project, shihni Kapitullin "Si të ndërtoni U-Boot dhe Kernel në mjedis të pavarur" në i .MX Udhëzuesi i Përdoruesit (IMXLUG).
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ë shfaqur një shtresë të personalizuar në krye të një lëshimi i.MX BSP. Seksionet e mbetura në këtë dokument ofrojnë udhëzime për krijimin e një DISTRO të personalizuar dhe konfigurimit të tabelës.

7.1 Krijimi i një shpërndarjeje të personalizuar
Një shpërndarje e personalizuar mund të konfigurojë një mjedis ndërtimi të personalizuar. Distro fileFsl-imx-wayland, fslimx-xwayland dhe fsl-imx-fb të lëshuara të gjitha shfaqin konfigurime për prapavijë specifike grafike. Distros mund të përdoren gjithashtu për të konfiguruar parametra të tjerë si kernel, U-Boot dhe GStreamer. Distro i.MX files janë vendosur të krijojnë një mjedis ndërtimi të personalizuar që kërkohet 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.

7.2 Krijimi i një konfigurimi të personalizuar të bordit
Shitësit që po zhvillojnë borde referimi mund të dëshirojnë të shtojnë bordin e tyre në BSP të Komunitetit FSL.
Mbështetja e pajisjes së re nga Komuniteti FSL BSP e bën të lehtë ndarjen e kodit burimor me komunitetin dhe mundëson reagime 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ë.

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.
Personalizojeni U-Boot sipas nevojës. Shihni udhëzuesin e transferimit të i.MX BSP (IMXBSPPG) për detaje mbi këtë.

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ë.
Vendosni ndërtimin e projektit Yocto siç përshkruhet në udhëzimet e komunitetit të Projektit Yocto siç tregohet më poshtë.
Përdorni degën master të komunitetit.
a. Shkarkoni paketën e nevojshme të hostit, në varësi të shpërndarjes së OS Linux të hostit, nga Fillimi i shpejtë i projektit Yocto.
b. Shkarkoni Repo me komandën:
$ curl https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
c. Krijo një direktori për të mbajtur gjithçka brenda. Mund të përdoret çdo emër direktoriumi. Ky dokument përdor imxcommunity-bsp.
$ mkdir imx-community-bsp
d. Ekzekutoni komandën e mëposhtme:
$ cd imx-community-bsp
e. Inicializoni Repon me degën kryesore të Repos.
$ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b mjeshtër
f. Merrni recetat që do të përdoren për të ndërtuar.
sinkronizimi i repove $
g. Vendosni mjedisin me komandën e mëposhtme:
$ konfigurimi i burimit-ndërtimi i mjedisit
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
Përgatitni arna. Ndiqni Udhëzuesin e stilit të recetës dhe git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/ tree/README në seksionin me titull Kontributi.
Në rrjedhën e sipërme në meta-freescale-party e tretë. Për në rrjedhën e sipërme, dërgoni arna te metafreescale@yoctoproject.org.

7.3 Monitorimi i dobësive të sigurisë në BSP-në tuaj
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

7.3.1 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”

7.3.2 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.

Pyetjet e bëra më shpesh

8.1 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ë.

$: mkdir ~/bin
$: curl https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
$: chmod a+x ~/bin/repo
$: PATH=${PATH}:~/bin

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
$: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-nanbield m imx-6.6.3-1.0.0.xml
: sinkronizimi i repove
Shënim:
https://github.com/nxp-imx/imx-manifest/tree/imx-linux-nanbield 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:
$: DISTRO=fsl-imx-fb MAKINA= burim imx-setup-release.sh -b build-fb
Konfigurimi për Wayland:
$: DISTRO=fsl-imx-wayland MACHINE= burim imx-setup-release.sh -b build-wayland
Konfigurimi për XWayland:
$: DISTRO=fsl-imx-xwayland MAKINA= burim imx-setup-release.sh -b build-xwayland

Ndërtimi për të gjitha Backends
Ndërtoni pa Qt
$: bitbake imx-image-multimedia
Ndërtoni me Qt 6 dhe veçoritë e mësimit të makinerive
$: bitbake imx-image-plotë

8.2 Akordimi i konfigurimit lokal
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 e prekjes. Pastaj ekzekutoni komandën bitbake:
bitbake .
Për më shumë informacion, shihni Manuali i Referencës së Projektit Yocto — Dokumentacioni i Projektit Yocto ® 5.0.1.

8.3 receta
Ç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.

8.4 Si të zgjidhni paketat shtesë
Pako shtesë mund të shtohen në imazhe nëse ka një recetë të dhënë për atë paketë. Një listë e kërkueshme 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.

8.4.1 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 sistemi.
Rrënja 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.

8.4.2 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.

8.4.3 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, janë vendosur versionet e preferuara për të gjitha recetat për të siguruar 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.

8.4.4 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ë shumë ofrues. 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"

8.4.5 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 renditet në familjet i.MX 6 dhe i.MX 6DualLite SoC. i.MX 6Solo Sabre-auto renditet në familjet i.MX 6 dhe i.MX 6Solo SoC. Disa ndryshime mund të synohen në një familje specifike SoC në local.conf për të anashkaluar një ndryshim në konfigurimin e makinës file. Më poshtë është një ishampnjë ndryshim në një cilësim të kernelit mx6dlsabresd.
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.

8.4.6 Regjistrat e BitBake
BitBake regjistron proceset e ndërtimit dhe të paketës në direktorinë temp 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ç pritej. Kontrolloni drejtoritë nën drejtorinë e komponentëve të ndërtimit (tmp/work/ / ). Kontrolloni drejtoritë e paketës, paketave-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).

8.4.7 Si të shtoni një mekanizëm për monitorimin dhe njoftimin e CVE
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 -b kirkstone
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: https://www.timesys.com/registernxp-vigiles/). Hyni në Preferencat tuaja dhe krijoni një të Re
Celës. Shkarkoni çelësin file në mjedisin tuaj të zhvillimit. 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 tabelat i.MX" në Udhëzuesin e Përdoruesit të i.MX Linux (IMXLUG).

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 (IMXLUG).
Për mënyrën e konfigurimit të një karte SD/MMC, shihni seksionin “Përgatitja e një karte SD/MMC për të nisur” në Udhëzuesin e Përdoruesit të i.MX Linux (IMXLUG).

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 2024 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:

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.
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.
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 Softuer OFROHET NGA MBAJTËSIT DHE KONTRIBUESIT E TË DREJTAVE TË AUTORIT "SIÇ ËSHTË" DHE ÇDO GARANCI TË SHPREHTA APO TË ËSHTRUARA, PËRFSHIRË, POR JO KUFIZUARA NË, GARANCITË E KUFIZUARA TË KUFIZIMIT TË PARAQITURËS TË TREGTISË . NË ASNJË RAST TË DREJTAT E TË DREJTAVE TË AUTORIT APO KONTRIBUESIT NUK DUHET TË PËRGJEGJËSIN PËR NDONJË DËM TË DIREKT, INDIREKT, TË VEÇANTË, SHEMBULL APO PAJISËR (POR JO TË KUFIZUARA TË KUFIZUARA; PËRDORIMI, TË DHËNAT APO FITIMET; OSE NDËRPRERJE TË BIZNESIT) SIDO TË SHKAKTUAR DHE PËR ÇDO TEORI PËRGJEGJËSORE NË KONTRATË, PËRGJEGJËSI TË RRETË, OSE DETYRIMI (përfshirë neglizhencën APO TË NDRYSHME) QË NDRYSHET NË GJITHË MËNYRË NË KONTRATË, PËRGJEGJËSIA E RRETË, OSE F MUNDËSIA E DËMIMIT TË TIJ.

Historia e rishikimit

Kjo tabelë ofron historinë e rishikimeve.
Historia e rishikimit

ID e dokumentit	Data	Ndryshimet thelbësore
IMXLXYOCTOUG v.LF6.6.3_1.0.0	29 2024 mars	Përmirësuar në kernel 6.6.3, hoqi i.MX 91P dhe shtoi i.MX 95 si Alpha Quality.
IMXLXYOCTOUG v.LF6.1.55_2.2.0	12/2023	Përmirësuar në kernel 6.1.55.
IMXLXYOCTOUG v.LF6.1.36_2.1.0	09/2023	Përmirësuar në kernel 6.1.36 dhe shtoi I.MX 91P.
IMXLXYOCTOUG v.LF6.1.22_2.0.0	06/2023	Përmirësuar në kernel 6.1.22.
IMXLXYOCTOUG v.LF6.1.1_1.0.0	04/2023	Korrigjimi i gabimit në linjat e komandës në seksionin 3.2.
IMXLXYOCTOUG v.LF6.1.1_1.0.0	03/2023	Përmirësuar në kernel 6.1.1.
IMXLXYOCTOUG v.LF5.15.71_2.2.0	12/2022	Përmirësuar në kernel 5.15.71.
IMXLXYOCTOUG v.LF5.15.52_2.1.0	09/2022	Përmirësuar në kernelin 5.15.52 dhe shtoi i.MX 93.
IMXLXVOCTOUG v.LF5.15.32_2.0.0	06/2022	Përmirësuar në kernelin 5.15.32, U-Boot 2022.04 dhe Kirkstone Yocto.
IMXLXYOCTOUG v.LF5.15.5_1.0.0	03/2022	Përmirësuar në kernelin 5.15.5, Honister Yocto dhe Qt6.
IMXLXYOCTOUG v.LF5.10.72_2.2.0	12/2021	Përmirësoi kernelin në 5.10.72 dhe përditësoi BSP.
IMXLXYOCTOUG v.LF5.10.52_2.1.0	09/2021	Përditësuar për i.MX GULP Alpha dhe kerneli u përditësua në 5.10.52.
IMXLXYOCTOUG v.LF5.10.35_2.0.0	06/2021	Përmirësuar në kernel 5.10.35.
IMXLXYOCTOUG v.LF5.10.9_1.0.0	04/2021	Korrigjuar një gabim shtypi në linjat e komandës në seksionin 3.1 'Paketat pritëse.
IMXLXYOCTOUG v.LF5.10.9_1.0.0	03/2021	Përmirësuar në kernel 5.10.9.
IMXLXYOCTOUG v.L5.4.70_2.3.0	01/2021	Përditësoi linjat e komandës në seksionin "Drejtimi i imazhit të krahut Cortex-M4".
IMXLXYOCTOUG v.L5.4.70_2.3.0	12/2020	i.MX 5.4 GA i konsoliduar për lëshimin e pllakave i.MX duke përfshirë i. MX 8M Plus dhe i.MX 8DXL.
IMXLXYOCTOUG v.L5.4.47_2.2.0	09/2020	Lëshimi i I.MX 5.4 Beta2 për i.MX 8M Plus, Beta për 8DXL dhe GA i konsoliduar për bordet I.MX të lëshuara.
IMXLXYOCTOUG v.L5.4.24_2.1.0	06/2020	Publikimi i i.MX 5.4 Beta për i.MX 8M Plus, Aipha2 për 8DXL dhe GA i konsoliduar për bordet i.MX të lëshuar.
IMXLXYOCTOUG v.L5.4.3_2.0.0	04/2020	Lëshimi i i.MX 5.4 Alpha për bordet i.MX 8M Plus dhe 8DXL EVK.
IMXLXYOCTOUG v.LF5A.3_1.0.0	03/2020	Përmirësimet e projektit I.MX 5.4 Kernel dhe Yocto.
IMXLXYOCTOUG v.L4.19.35_1.1.0	10/2019	Përmirësimet e projektit I.MX 4.19 Kernel dhe Yocto.
IMXLXYOCTOUG v.L4.19.35_1.0.0	07/2019	I.MX 4.19 Beta Kernel dhe Përmirësimet e Projektit Yocto.
IMXLXYOCTOUG v.L4.14.98_2.0.0_ga	04/2019	Përmirësimi i kernelit dhe përditësimet e bordit i.MX 4.14.
IMXLXYOCTOUG v.L4.14.78_1.0.0_ga	01/2019	Publikimi i GA i familjes I.MX 6, i.MX 7, i.MX 8.
IMXLXYOCTOUG v14.14.62_1.0.0_ beta	11/2018	Përmirësimi i kernelit i.MX 4.14, përmirësimi i Yocto Project Sumo.
IMXLXYOCTOUG v14.9.123_2.3.0_ 8 mm	09/2018	Publikimi i i.MX 8M Mini GA.
IMXLXYOCTOUG v14.9.88_2.2.0_ 8qxp-beta2	07/2018	Publikimi i i.MX 8QuadXPlus Beta2.
IMXLXYOCTOUG v14.9.88_2.1.0_ 8mm-alfa	06/2018	Publikimi i i.MX 8M Mini Alpha.
IMXLXYOCTOUG v14.9.88_2.0.0-ga	05/2018	Publikimi i i.MX 7ULP dhe i.MX 8M Quad GA.
IMXLXYOCTOUG v14.9.51_imx8mq- ga	03/2018	U shtua i.MX 8M Quad GA.
IMXLXYOCTOUG v14.9.51_8qm- beta2/8qxp-beta	02/2018	U shtuan i.MX 8QuadMax Beta2 dhe i.MX 8QuadXPlus Beta.
IMXLXYOCTOUG v.L4.9.51_imx8mq- beta	12/2017	U shtua i.MX 8M Quad.
IMXLXYOCTOUG v14.9.51_imx8qm- beta 1	12/2017	U shtua i.MX 8QuadMax.
IMXLXYOCTOUG v14.9.51_imx8qxp- alfa	11/2017	Lëshimi fillestar.

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 zyrtar, 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
Garanci dhe përgjegjësi 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ëmtim indirekt, 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) nëse ose këto dëme nuk 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 për të bërë 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 për t'u përdorur në mbështetje të jetës, sisteme ose pajisje kritike për jetën ose sigurinë, as në aplikime ku dështimi ose mosfunksionimi i një produkti NXP Semiconductors mund të pritet në mënyrë të arsyeshme 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 nga këto produkte janë vetëm për qëllime ilustruese. NXP Semiconductors nuk jep asnjë përfaqësim ose garanci se 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 të vlefshme individuale 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 artikulli(et) 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 përdorim në produkte jo të kualifikuara automobilistike — Përveç nëse ky dokument 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 në automobil. 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.
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ë tyre jetësor 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 dhe logoja janë marka tregtare të NXP BV

AMBA, Arm, Arm7, Arm7TDMI, Arm9, Arm11, Artisan, big.LITTLE, Cordio, CoreLink, CoreSight, Cortex, DesignStart, DynamIQ, Jazelle, Keil, Mali, Mbed, Mbed Enabled, NEON, POP, RealView, SecurCore, Socrates, Thumb, TrustZone, ULINK, ULINK2, ULINK-ME, ULINKPLUS, ULINKpro, μVision, Versatile — janë marka tregtare dhe/ose marka të regjistruara të Arm Limited (ose filialeve ose filialeve të saj) në SHBA dhe/ose gjetkë. Teknologjia përkatëse mund të mbrohet nga ndonjë ose të gjitha patentat, të drejtat e autorit, dizajnet dhe sekretet tregtare. Të gjitha të drejtat e rezervuara.
EdgeLock — është një markë tregtare e NXP BV
eIQ — është një markë tregtare e NXP BV
i.MX — është një markë tregtare e NXP BV

IMXLXYOCTOUG
All information provided në këtë dokument është subjekt i mohimeve ligjore.
© 2024 NXP BV Të gjitha të drejtat e rezervuara.
Rev. LF6.6.3_1.0.0 - 29 mars 2024

Dokumentet / Burimet

Projekti NXP IMXLXYOCTOUG i.MX Yocto [pdfUdhëzuesi i përdoruesit
IMXLXYOCTOUG i.MX Yocto Project, i.MX Yocto Project, Yocto Project, Project

Referencat

Manuali i Përdoruesit

Projekti IMXLXYOCTOUG i.MX Yocto

Mbiview

Veçoritë

Konfigurimi i hostit

Konfigurimi i projektit Yocto

Ndërtimi i imazhit

Vendosja e imazhit

Përshtatje

Pyetjet e bëra më shpesh

Referencat

Shënim rreth kodit burimor në dokument

Historia e rishikimit

Informacion ligjor

Dokumentet / Burimet

Referencat

Lini një koment

Anulo përgjigjen