NXP - ლოგო

IMXLXYOCTOG
i.MX Yocto Project მომხმარებლის სახელმძღვანელო
Rev. LF6.6.3_1.0.0 — 29 წლის 2024 მარტი
NXP ნახევარგამტარები
მომხმარებლის სახელმძღვანელო

შინაარსი დამალვა
1 IMXLXYOCTOUG i.MX Yocto Project
2 დასრულდაview
3 მახასიათებლები
4 ჰოსტის დაყენება
5 Yocto პროექტის დაყენება
6 გამოსახულების აგება
7 გამოსახულების განლაგება
8 მორგება
9 ხშირად დასმული კითხვები
10 ცნობები
11 შენიშვნა დოკუმენტის წყაროს კოდის შესახებ
12 გადასინჯვის ისტორია
13 იურიდიული ინფორმაცია
14 დოკუმენტები / რესურსები
14.1 ცნობები
15 დაკავშირებული პოსტები

IMXLXYOCTOUG i.MX Yocto Project

დოკუმენტის ინფორმაცია

ინფორმაცია შინაარსი
საკვანძო სიტყვები i.MX, Linux, LF6.6.3_1.0.0
აბსტრაქტი ეს დოკუმენტი აღწერს, თუ როგორ უნდა ავაშენოთ სურათი i.MX დაფისთვის Yocto Project build გარემოს გამოყენებით. იგი აღწერს i.MX გამოშვების ფენას და i.MX-ს სპეციფიკურ გამოყენებას.

დასრულდაview

ეს დოკუმენტი აღწერს, თუ როგორ უნდა ავაშენოთ სურათი i.MX დაფისთვის Yocto Project build გარემოს გამოყენებით. იგი აღწერს i.MX გამოშვების ფენას და i.MX-ს სპეციფიკურ გამოყენებას.
Yocto Project არის ღია კოდის თანამშრომლობა, რომელიც ორიენტირებულია ჩაშენებული Linux OS-ის განვითარებაზე. დამატებითი ინფორმაციისთვის Yocto Project-ის შესახებ იხილეთ Yocto Project გვერდი: www.yoctoproject.org/. Yocto Project-ის მთავარ გვერდზე არის რამდენიმე დოკუმენტი, რომელიც დეტალურად აღწერს სისტემის გამოყენებას. იმისათვის, რომ გამოიყენოთ ძირითადი Yocto Project i.MX გამოშვების ფენის გარეშე, მიჰყევით Yocto Project Quick Start-ის ინსტრუქციას https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html.
FSL Yocto Project Community BSP (იპოვება აქ FSL Community BSP (freescale.github.io)) არის განვითარების საზოგადოება NXP-ს გარეთ, რომელიც უზრუნველყოფს i.MX დაფების მხარდაჭერას Yocto Project გარემოში. i.MX შეუერთდა Yocto Project-ის საზოგადოებას, რომელიც უზრუნველყოფს გამოშვებას Yocto Project ჩარჩოზე დაყრდნობით. ინფორმაცია, რომელიც სპეციფიკურია FSL ​​საზოგადოების BSP გამოყენებისთვის, ხელმისაწვდომია საზოგადოებაში web გვერდი. ეს დოკუმენტი არის საზოგადოების BSP დოკუმენტაციის გაფართოება.
Fileგამოსახულების შესაქმნელად გამოყენებული s ინახება ფენებად. ფენები შეიცავს სხვადასხვა სახის პერსონალიზაციას და მოდის სხვადასხვა წყაროდან. Ზოგიერთი fileს ფენაში რეცეპტებს უწოდებენ. Yocto Project რეცეპტები შეიცავს მექანიზმს წყაროს კოდის აღდგენის, კომპონენტის აშენებისა და შეფუთვისთვის. შემდეგი სიები აჩვენებს ამ გამოშვებაში გამოყენებულ ფენებს.

i.MX გამოშვების ფენა

  • მეტა-იმქს
    – მეტა-ბსპ: განახლებები მეტა-თავისუფალმასშტაბიანი, პოკი და მეტა-გახსნილი ფენებისთვის
    – meta-sdk: განახლებები meta-freescale-დისტროსთვის
    – მეტა-მლ: მანქანათმცოდნეობის რეცეპტები
    – meta-v2x: V2X რეცეპტები გამოიყენება მხოლოდ i.MX 8DXL-ისთვის
    – მეტა-კაბინა: კაბინის რეცეპტები i.MX 8QuadMax-ისთვის

Yocto Project საზოგადოების ფენები

  • მეტა თავისუფალი მასშტაბი: უზრუნველყოფს ბაზისა და i.MX Arm საცნობარო დაფების მხარდაჭერას.
  • meta-freescale-3rdparty: უზრუნველყოფს მე-3 მხარისა და პარტნიორების დაფების მხარდაჭერას.
  • meta-freescale-distro: დამატებითი ელემენტები, რათა დაეხმაროს განვითარებისა და სავარჯიშო დაფის შესაძლებლობებს.
  • fsl-community-bsp-base: ხშირად ეწოდებოდა ბაზას. გთავაზობთ საბაზისო კონფიგურაციას FSL Community BSP-სთვის.
  • meta-openembedded: ფენების კოლექცია OE-core სამყაროსთვის. იხ layers.openembedded.org/.
  • poky: ძირითადი Yocto Project ელემენტები Poky-ში. იხილეთ Poky README დეტალებისთვის.
  • მეტა-ბრაუზერი: გთავაზობთ რამდენიმე ბრაუზერს.
  • meta-qt6: უზრუნველყოფს Qt 6.
  • meta-timesys: გთავაზობთ Vigiles ინსტრუმენტებს BSP მოწყვლადობის მონიტორინგისა და შეტყობინებისთვის (CVEs).

ამ დოკუმენტის თემის ფენებზე მითითებები განკუთვნილია Yocto Project-ის ყველა ფენისთვის, გარდა meta-imx. i.MX დაფები კონფიგურირებულია meta-imx და meta-freescale ფენებში. ეს მოიცავს U-Boot-ს, Linux-ის ბირთვს და საცნობარო დაფის სპეციფიკურ დეტალებს.
i.MX უზრუნველყოფს დამატებით ფენას სახელწოდებით i.MX BSP Release, სახელად meta-imx, ახალი i.MX გამოშვების ინტეგრირებისთვის FSL Yocto Project Community BSP-თან. meta-imx ფენა მიზნად ისახავს გამოუშვას განახლებული და ახალი Yocto Project რეცეპტები და მანქანების კონფიგურაციები ახალი გამოშვებებისთვის, რომლებიც ჯერ არ არის ხელმისაწვდომი Yocto Project-ის არსებულ მეტა-თავისუფალ მასშტაბებზე და მეტა-თავისუფალი მასშტაბის-დისტრო ფენებზე. i.MX BSP-ის შინაარსი
გამოშვების ფენა არის რეცეპტები და მანქანების კონფიგურაციები. ბევრ ტესტის შემთხვევაში, სხვა ფენები ახორციელებენ რეცეპტებს ან მოიცავს files და i.MX გამოშვების ფენა უზრუნველყოფს რეცეპტების განახლებებს მიმდინარე რეცეპტის მიმატებით, ან კომპონენტის ჩათვლით და განახლებით პატჩებით ან წყაროს მდებარეობებით. i.MX-ის გამოშვების ფენის რეცეპტების უმეტესობა ძალიან მცირეა, რადგან ისინი იყენებენ იმას, რაც საზოგადოებამ მოგვაწოდა და განაახლებს იმას, რაც საჭიროა ყოველი ახალი პაკეტის ვერსიისთვის, რომელიც მიუწვდომელია სხვა ფენებში.
i.MX BSP Release ფენა ასევე უზრუნველყოფს გამოსახულების რეცეპტებს, რომლებიც მოიცავს ყველა იმ კომპონენტს, რომელიც საჭიროა სისტემის გამოსახულების ჩატვირთვისთვის, რაც ამარტივებს მომხმარებლისთვის. კომპონენტები შეიძლება აშენდეს ინდივიდუალურად ან გამოსახულების რეცეპტის საშუალებით, რომელიც აერთიანებს სურათზე საჭირო ყველა კომპონენტს ერთ აგების პროცესში.
i.MX kernel და U-Boot გამოშვებები ხელმისაწვდომია i.MX საჯარო Git სერვერების მეშვეობით. თუმცა, რამდენიმე კომპონენტი გამოშვებულია პაკეტების სახით i.MX სარკეზე. შეფუთვაზე დაფუძნებული რეცეპტები იზიდავს files i.MX სარკედან Git მდებარეობის ნაცვლად და გენერირება საჭირო პაკეტი.
ყველა პაკეტი, რომელიც გამოდის ორობითი სახით, აგებულია ტექნიკის მცურავი წერტილით, როგორც ეს მითითებულია DEFAULTTUNE-ში, რომელიც განსაზღვრულია თითოეულ აპარატის კონფიგურაციაში. file. პროგრამული უზრუნველყოფის მცურავი წერტილის პაკეტები არ არის მოწოდებული ჯეტროს გამოშვებით დაწყებული.
გამოშვება LF6.6.3_1.0.0 გამოვიდა Yocto Project 4.3-ისთვის (Nanbild). Yocto Project 4.3-ის იგივე რეცეპტები იქნება გაშვებული და ხელმისაწვდომი იქნება Yocto Project გამოშვების შემდეგ გამოშვებაში. Yocto Project-ის გამოშვების ციკლი გრძელდება დაახლოებით ექვსი თვე.
რეცეპტები და პატჩები meta-imx-ში გადადის საზოგადოების ფენებში. ამის შემდეგ კეთდება კონკრეტული კომპონენტისთვის files in meta-imx აღარ არის საჭირო და FSL ​​Yocto Project Community BSP უზრუნველყოფს მხარდაჭერას. საზოგადოება მხარს უჭერს i.MX საცნობარო დაფებს, საზოგადოების დაფებს და მესამე მხარის დაფებს.

1.1 საბოლოო მომხმარებლის სალიცენზიო ხელშეკრულება
NXP Yocto Project BSP-ის დაყენების გარემოს პროცესის დროს ნაჩვენებია NXP საბოლოო მომხმარებლის სალიცენზიო შეთანხმება (EULA). i.MX საკუთრების პროგრამული უზრუნველყოფის გამოყენების გასაგრძელებლად, მომხმარებლები უნდა დაეთანხმონ ამ ლიცენზიის პირობებს. პირობების შეთანხმება საშუალებას აძლევს Yocto Project-ს შექმნას პაკეტები i.MX სარკედან.
შენიშვნა:
ყურადღებით წაიკითხეთ ეს სალიცენზიო ხელშეკრულება დაყენების პროცესში, რადგან მიღების შემდეგ, i.MX Yocto Project გარემოში შემდგომი მუშაობა დაკავშირებულია ამ მიღებულ შეთანხმებასთან.

1.2 ცნობარი
i.MX-ს აქვს მრავალი ოჯახი, რომელიც მხარდაჭერილია პროგრამულ უზრუნველყოფაში. ქვემოთ მოცემულია ჩამოთვლილი ოჯახები და SoC-ები თითო ოჯახზე. i.MX Linux-ის გამოშვების შენიშვნები აღწერს რომელი SoC არის მხარდაჭერილი მიმდინარე გამოშვებაში. ზოგიერთი ადრე გამოშვებული SoC შეიძლება იყოს აშენებული მიმდინარე გამოშვებაში, მაგრამ არ არის დადასტურებული, თუ ისინი წინა დადასტურებულ დონეზეა.

  • i.MX 6 ოჯახი: 6QuadPlus, 6Quad, 6DualLite, 6SoloX, 6SLL, 6UltraLite, 6ULL, 6ULZ
  • i.MX 7 ოჯახი: 7Dual, 7ULP
  • i.MX 8 ოჯახი: 8QuadMax, 8QuadPlus, 8ULP
  • i.MX 8M ოჯახი: 8M Plus, 8M Quad, 8M Mini, 8M Nano
  • i.MX 8X ოჯახი: 8QuadXPlus, 8DXL
  • i.MX 9 ოჯახი: i.MX 93, i.MX 95

ეს გამოცემა მოიცავს შემდეგ მითითებებს და დამატებით ინფორმაციას.

  • i.MX Linux გამოშვების შენიშვნები (IMXLXRN) – გვაწვდის ინფორმაციას გამოშვების შესახებ.
  • i.MX Linux მომხმარებლის სახელმძღვანელო (IMXLUG) – გვაწვდის ინფორმაციას U-Boot და Linux OS ინსტალაციისა და i.MX-ის სპეციფიკური ფუნქციების გამოყენების შესახებ.
  • i.MX Yocto Project მომხმარებლის სახელმძღვანელო (IMXLXYOCTOUG) – აღწერს დაფის მხარდაჭერის პაკეტს NXP განვითარების სისტემებისთვის Yocto Project-ის გამოყენებით ჰოსტის დასაყენებლად, ხელსაწყოების ჯაჭვის დასაყენებლად და გამოსახულების შესაქმნელად წყაროს კოდის შესაქმნელად.
  • i.MX Machine Learning მომხმარებლის სახელმძღვანელო (IMXMLUG) – გვაწვდის მანქანური სწავლების ინფორმაციას.
  • i.MX Linux Reference Manual (IMXLXRM) – გვაწვდის ინფორმაციას Linux დრაივერების შესახებ i.MX-ისთვის.
  • i.MX Graphics მომხმარებლის სახელმძღვანელო (IMXGRAPHICUG) – აღწერს გრაფიკულ მახასიათებლებს.
  • i.MX Porting Guide (IMXXBSPPG) – გთავაზობთ ინსტრუქციებს BSP-ის ახალ დაფაზე გადატანის შესახებ.
  • i.MX VPU აპლიკაციის პროგრამირების ინტერფეისი Linux Reference Manual (IMXVPUAPI) – გვაწვდის საცნობარო ინფორმაციას VPU API-ზე i.MX 6 VPU-ზე.
  • Harpoon-ის მომხმარებლის სახელმძღვანელო (IMXHPUG) – წარმოგიდგენთ Harpoon-ის გამოშვებას i.MX 8M მოწყობილობების ოჯახისთვის.
  • i.MX Digital Cockpit Hardware Partitioning Enabled for i.MX 8QuadMax (IMXDCHPE) – გთავაზობთ i.MX Digital Cockpit აპარატურულ გადაწყვეტას i.MX 8QuadMax-ისთვის.
  • i.MX DSP მომხმარებლის სახელმძღვანელო (IMXDSPUG) – გვაწვდის ინფორმაციას DSP-ის შესახებ i.MX 8-ისთვის.
  • i.MX 8M Plus კამერისა და ეკრანის სახელმძღვანელო (IMX8MPCDUG) – გვაწვდის ინფორმაციას ISP დამოუკიდებელი სენსორის ინტერფეისის API-ზე i.MX 8M Plus-ისთვის.
  • EdgeLock Enclave Hardware Security Module API (RM00284) – ეს დოკუმენტი არის API-ს პროგრამული საცნობარო აღწერა, რომელიც მოწოდებულია i.MX 8ULP, i.MX 93 და i.MX 95 Hardware Security Module (HSM) გადაწყვეტილებების მიერ EdgeLock Enclave-ისთვის ( ELE) პლატფორმა.

სწრაფი დაწყების სახელმძღვანელო შეიცავს ძირითად ინფორმაციას დაფაზე და მის დაყენებაზე. ისინი NXP-ზე არიან webსაიტი.

დოკუმენტაცია ხელმისაწვდომია ონლაინ მისამართზე nxp.com.

მახასიათებლები

i.MX Yocto Project Release ფენებს აქვთ შემდეგი მახასიათებლები:

  • Linux-ის ბირთვის რეცეპტი
    – ბირთვის რეცეპტი განთავსებულია recipes-kernel საქაღალდეში და აერთიანებს i.MX ბირთვს i.MX Git სერვერიდან გადმოწერილი წყაროდან. ეს ხდება ავტომატურად პროექტში მოცემული რეცეპტებით.
    – LF6.6.3_1.0.0 არის Linux ბირთვი, რომელიც გამოვიდა Yocto Project-ისთვის.
  • U-Boot რეცეპტი
    – U-Boot რეცეპტი განთავსებულია recipes-bsp საქაღალდეში და აერთიანებს i.MX uboot-imx.git-ს i.MX Git სერვერიდან გადმოწერილი წყაროდან.
    – i.MX გამოშვება LF6.6.3_1.0.0 i.MX 6, i.MX 7, i.MX 8, i.MX 93 და i.MX 95 მოწყობილობებისთვის იყენებს განახლებულ v2023.04 i.MX U- ჩატვირთვის ვერსია. ეს ვერსია არ განახლებულა ყველა i.MX ტექნიკისთვის.
    – i.MX Yocto Project Community BSP იყენებს u-boot-fslc-ს მთავარი ხაზიდან, მაგრამ ეს მხარდაჭერილია მხოლოდ U-Boot საზოგადოების მიერ და არ არის მხარდაჭერილი L6.6.3 ბირთვით.
    – i.MX Yocto Project Community BSP ხშირად აახლებს U-Boot ვერსიებს, ამიტომ ზემოაღნიშნული ინფორმაცია შეიძლება შეიცვალოს, რადგან ახალი U-Boot ვერსიები ინტეგრირებულია მეტა-თავისუფალ შრეებში და i.MX uboot-imx გამოშვებების განახლებები ინტეგრირებულია მთავარი ხაზი.
  • გრაფიკული რეცეპტები
    - გრაფიკული რეცეპტები ინახება რეცეპტები-გრაფიკულ საქაღალდეში.
    – გრაფიკული რეცეპტები აერთიანებს i.MX გრაფიკული პაკეტის გამოშვებას. i.MX დაფებისთვის, რომლებსაც აქვთ GPU, imx-gpu-viv რეცეპტები აფუჭებს გრაფიკულ კომპონენტებს თითოეული DISTRO-სთვის: ჩარჩო ბუფერი (FB), XWayland, Wayland backend და Weston compositor (Weston). მხოლოდ i.MX 6 და i.MX 7 მხარს უჭერს Frame Buffer.
    – Xorg-driver აერთიანებს xserver-xorg-ს.
  • i.MX პაკეტის რეცეპტები firmware-imx, imx-sc-fimrware და სხვა პაკეტები განთავსებულია recipes-bsp-ში და ამოიღეთ i.MX სარკედან, რათა შექმნათ და შეფუთოთ გამოსახულების რეცეპტებში.
  • მულტიმედიური რეცეპტები
    - მულტიმედიური რეცეპტები დგას რეცეპტებში-მულტიმედიაში.
    – საკუთრების პაკეტებს, როგორიცაა imx-codec და imx-parser, აქვთ რეცეპტები, რომლებიც ამოღებულია i.MX სარკედან, რათა შეიქმნას და შეფუთოს გამოსახულების რეცეპტებში.
    – ღია წყაროს პაკეტებს აქვთ რეცეპტები, რომლებიც იღებენ GitHub-ის საჯარო Git Repos-ს.
    - ზოგიერთი რეცეპტი მოცემულია კოდეკებისთვის, რომლებიც შეზღუდულია. ამ პაკეტები არ არის i.MX სარკეზე.
    ეს პაკეტები ხელმისაწვდომია ცალკე. მათ შესაძენად დაუკავშირდით თქვენს i.MX მარკეტინგის წარმომადგენელს.
  • ძირითადი რეცეპტები
    წესების ზოგიერთი რეცეპტი, როგორიცაა udev, გთავაზობთ განახლებულ i.MX წესებს, რომლებიც უნდა განთავსდეს სისტემაში. ეს რეცეპტები, როგორც წესი, არის პოლიტიკის განახლებები და გამოიყენება მხოლოდ პერსონალიზაციისთვის. რელიზები მხოლოდ საჭიროების შემთხვევაში იძლევა განახლებებს.
  • დემო რეცეპტები
    საჩვენებელი რეცეპტები განთავსებულია meta-sdk დირექტორიაში. ეს ფენა შეიცავს გამოსახულების რეცეპტებს და პერსონალიზაციის რეცეპტებს, როგორიცაა შეხების კალიბრაცია ან საჩვენებელი აპლიკაციების რეცეპტები.
  • მანქანათმცოდნეობის რეცეპტები
    მანქანათმცოდნეობის რეცეპტები განთავსებულია meta-ml დირექტორიაში. ეს ფენა შეიცავს მანქანური სწავლების რეცეპტებს პაკეტებისთვის, როგორიცაა tensorflow-lite, onnx და ა.შ.
  • კაბინის რეცეპტები
    კაბინის რეცეპტები განთავსებულია მეტა-კაბინაში და მხარდაჭერილია i.MX 8QuadMax-ზე imx-8qmcockpit-mek აპარატის კონფიგურაციის გამოყენებით.
    ფენაში meta-nxp-demo-experience, მეტი დემონსტრირება და ხელსაწყოების რეცეპტები შედის. ეს ფენა შედის ყველა გამოშვებულ სრულ სურათში.

ჰოსტის დაყენება

Yocto Project-ის მოსალოდნელი ქცევის მისაღებად Linux-ის მასპინძელ მანქანაში, უნდა იყოს დაინსტალირებული ქვემოთ აღწერილი პაკეტები და კომუნალური პროგრამები. მნიშვნელოვანი განხილვა არის მყარ დისკზე საჭირო ადგილი მასპინძელ მანქანაში. მაგampასევე, Ubuntu-ზე მომუშავე აპარატზე აშენებისას, მყარ დისკზე საჭირო მინიმალური ადგილი არის დაახლოებით 50 GB. რეკომენდებულია მინიმუმ 120 GB მოწოდება, რაც საკმარისია ყველა ბექენდის ერთად შედგენისთვის. მანქანათმცოდნეობის კომპონენტების შესაქმნელად რეკომენდებულია მინიმუმ 250 GB.

რეკომენდებული მინიმალური Ubuntu ვერსია არის 20.04 ან უფრო ახალი. უახლესი გამოშვება მხარს უჭერს Chromium v91-ს, რომელიც მოითხოვს ულმიტამდე გაზრდას (ღიაების რაოდენობა fileს) 4098-მდე.

3.1 დოკერი
i.MX ახლა ავრცელებს დოკერის დაყენების სკრიპტებს GitHub – nxp-imx/imx-docker: i.MX Docker. მიჰყევით readme-ში მოცემულ ინსტრუქციას დოკერის გამოყენებით მასპინძლის კონსტრუქციის აპარატის დასაყენებლად.
გარდა ამისა, ბორტზე დოკერი ჩართულია სტანდარტული მანიფესტის საშუალებით მხოლოდ i.MX 8-ზე მეტა-ვირტუალიზაციის ფენის ჩათვლით. ეს ქმნის უთავო სისტემას დოკერის კონტეინერების დასაყენებლად გარე დოკერ ჰაბებიდან.

3.2 ჰოსტის პაკეტები
Yocto Project build მოითხოვს კონკრეტული პაკეტების დაინსტალირებას, რომლებიც დოკუმენტირებულია Yocto Project-ის ფარგლებში. Წადი Yocto Project სწრაფი დაწყება და შეამოწმეთ პაკეტები, რომლებიც უნდა იყოს დაინსტალირებული თქვენი build-ის აპარატისთვის.
Yocto Project ძირითადი მასპინძელი პაკეტებია:
$ sudo apt დააინსტალირე gawk wget git diffstat unzip texinfo gcc build-essential \chrpath socat cpio python3 python3-pip python3-pext xz-utils debianutils \iputils-ping python3-git python3-devinth lips2-devsl python1-jindja. ქვედანაყოფი mesa-common-dev zstd liblz1.2-tool file ლოკალები -y
$ sudo locale-gen en_US.UTF-8

კონფიგურაციის ინსტრუმენტი იყენებს grep-ის ნაგულისხმევ ვერსიას, რომელიც თქვენს build მანქანაზეა. თუ თქვენს გზაზე არის grep-ის სხვა ვერსია, ამან შეიძლება გამოიწვიოს build-ების წარუმატებლობა. ერთი გამოსავალი არის სპეციალური ვერსიის გადარქმევა რაიმეზე, რომელიც არ შეიცავს "grep".

3.3 Repo კომუნალური პროგრამის დაყენება
Repo არის Git-ის თავზე აგებული ხელსაწყო, რომელიც აადვილებს პროექტების მართვას, რომლებიც შეიცავს მრავალ საცავს, რომლებიც არ არის საჭირო ერთ სერვერზე. Repo ძალიან კარგად ავსებს Yocto Project-ის ფენოვან ბუნებას, რაც მომხმარებლებს უადვილებს BSP-ში საკუთარი ფენების დამატებას.

"რეპო" კომუნალური პროგრამის დასაყენებლად, შეასრულეთ შემდეგი ნაბიჯები:

  1. შექმენით bin საქაღალდე სახლის დირექტორიაში.
    $ mkdir ~/bin (ეს ნაბიჯი შეიძლება არ იყოს საჭირო, თუ bin საქაღალდე უკვე არსებობს)
    $ გurl https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
    $ chmod a+x ~/bin/repo
  2. დაამატეთ შემდეგი ხაზი .bashrc-ს file იმის უზრუნველსაყოფად, რომ ~/bin საქაღალდე თქვენს PATH ცვლადშია.
    ექსპორტი PATH=~/bin:$PATH

Yocto პროექტის დაყენება

პირველ რიგში, დარწმუნდით, რომ Git სწორად არის დაყენებული ქვემოთ მოცემული ბრძანებებით:
$ git config – გლობალური user.name „თქვენი სახელი“
$ git config –global user.email “Your Email”
$ git კონფიგურაცია – სია

i.MX Yocto Project BSP Release დირექტორია შეიცავს წყაროების დირექტორიას, რომელიც შეიცავს რეცეპტებს, რომლებიც გამოიყენება ერთი ან მეტი build დირექტორიის შესაქმნელად და სკრიპტების ნაკრები, რომლებიც გამოიყენება გარემოს დასაყენებლად.
პროექტის ასაგებად გამოყენებული რეცეპტები მომდინარეობს როგორც საზოგადოებისგან, ასევე i.MX-ისგან. Yocto Project ფენები ჩამოტვირთულია წყაროების დირექტორიაში. ეს ადგენს რეცეპტებს, რომლებიც გამოიყენება პროექტის შესაქმნელად.
შემდეგი ყოფილიampგვიჩვენებს, თუ როგორ უნდა ჩამოტვირთოთ i.MX Yocto Project Community BSP რეცეპტის ფენები. ამისთვის ყოფილიample, პროექტისთვის იქმნება დირექტორია სახელწოდებით imx-yocto-bsp. ამის ნაცვლად ნებისმიერი სახელის გამოყენება შეიძლება.
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ repo init -u https://github.com/nxp-imx/imx-manifest
-b imx-linux-nanbild -m imx-6.6.3-1.0.0.xml
$ რეპო სინქრონიზაცია

შენიშვნა:
https://github.com/nxp-imx/imx-manifest/tree/imx-linux-nanbield აქვს ყველა მანიფესტის სია files მხარს უჭერს ამ გამოცემას.
როდესაც ეს პროცესი დასრულდება, წყაროს კოდი შემოწმებულია დირექტორიაში imx-yocto-bsp/sources.
თქვენ შეგიძლიათ განახორციელოთ რეპო სინქრონიზაცია, ბრძანებით repo sync, პერიოდულად განაახლოთ უახლეს კოდზე.
თუ შეცდომა მოხდა Repo ინიციალიზაციის დროს, სცადეთ წაშალოთ .repo დირექტორია და კვლავ გაუშვათ Repo ინიციალიზაციის ბრძანება.
სარეპო ინიციტი კონფიგურირებულია ხაზის უახლესი პატჩებისთვის. მიჰყევით ინდექსში მითითებებს: imx-manifest.git ორიგინალური GA-ს მისაღებად. წინააღმდეგ შემთხვევაში, GA plus პატჩები აირჩევა ნაგულისხმევად. ზევსის ბაზიდან წინა გამოშვებების ასაღებად, დაამატეთ -m (გამოშვების მანიფესტის სახელი) Repo ინიციალიზაციის ხაზის ბოლოს და ის მოიძიებს წინა გამოშვებებს. მაგamples მოცემულია README-ში file ზემოთ მოცემულ ბმულზე.

გამოსახულების აგება

ამ განყოფილებაში მოცემულია დეტალური ინფორმაცია გამოსახულების შექმნის პროცესთან ერთად.

5.1 ააშენეთ კონფიგურაციები
i.MX გთავაზობთ სკრიპტს, imx-setup-release.sh, რომელიც ამარტივებს i.MX აპარატების დაყენებას. სკრიპტის გამოსაყენებლად საჭიროა მითითებული იყოს კონკრეტული აპარატის დასახელება, რომლისთვისაც უნდა აშენდეს, ასევე სასურველი გრაფიკული ბექენდი.
სკრიპტი ადგენს დირექტორიას და კონფიგურაციას files მითითებული აპარატისთვის და ბექენდისთვის.
meta-imx ფენაში, i.MX უზრუნველყოფს მანქანის ახალ ან განახლებულ კონფიგურაციებს, რომლებიც გადაფარავს მეტაფრის მასშტაბის აპარატის კონფიგურაციას. ესენი files კოპირებულია meta-freescale/conf/machine დირექტორიაში imx-setup-release.sh სკრიპტით. ქვემოთ მოცემულია i.MX აპარატის კონფიგურაცია files რომელიც შეიძლება შეირჩეს. შეამოწმეთ ან გამოშვების შენიშვნები ან მანქანის დირექტორია უახლესი დამატებებისთვის.

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

თითოეული build საქაღალდე უნდა იყოს კონფიგურირებული ისე, რომ გამოიყენოს მხოლოდ ერთი დისტრო. ყოველ ჯერზე, როდესაც იცვლება ცვლადი DISTRO_FEATURES, საჭიროა სუფთა build საქაღალდე. თითოეულ გრაფიკულ უკანა მხარეს Frame Buffer, Wayland და XWayland თითოეულს აქვს დისტრო კონფიგურაცია. თუ არა DISTRO file მითითებულია, XWayland დისტრო დაყენებულია ნაგულისხმევად. Distro კონფიგურაციები ინახება local.conf-ში file DISTRO პარამეტრში და ნაჩვენებია, როდესაც bitbake მუშაობს. წინა გამოშვებებში ჩვენ ვიყენებდით poky დისტროს და მორგებულ ვერსიებსა და პროვაიდერებს ჩვენს layer.conf-ში, მაგრამ მორგებული დისტრო უკეთესი გამოსავალია. როდესაც გამოიყენება ნაგულისხმევი poky distro, გამოიყენება ნაგულისხმევი საზოგადოების კონფიგურაცია. როგორც i.MX გამოშვება, ჩვენ გვირჩევნია გვქონდეს კონფიგურაციების ნაკრები, რომელსაც NXP მხარს უჭერს და ამოწმებდა.
აქ არის DISTRO კონფიგურაციების სია. გაითვალისწინეთ, რომ fsl-imx-fb არ არის მხარდაჭერილი i.MX 8-ზე და fsl-imxx11 აღარ არის მხარდაჭერილი.

  • fsl-imx-wayland: სუფთა Wayland გრაფიკა.
  • fsl-imx-xwayland: Wayland გრაფიკა და X11. X11 აპლიკაციები EGL-ის გამოყენებით არ არის მხარდაჭერილი.
  • fsl-imx-fb: Frame Buffer გრაფიკა – არა X11 ან Wayland. Frame Buffer არ არის მხარდაჭერილი i.MX 8-ზე და i.MX 9-ზე.

მომხმარებლებს შეუძლიათ შექმნან საკუთარი დისტრო file ერთ-ერთ მათგანზე დაყრდნობით მათი გარემოს მორგება ადგილობრივი.conf-ის განახლების გარეშე სასურველი ვერსიებისა და პროვაიდერების დასაყენებლად.
imx-setup-release.sh სკრიპტის სინტაქსი ნაჩვენებია ქვემოთ:
$ DISTRO= მანქანა= წყარო imx-setup-release.შ -ბ

DISTRO= არის დისტრო, რომელიც აკონფიგურირებს build გარემოს და ის ინახება meta-imx/meta-sdk/conf/distro-ში.
მანქანა= არის მანქანის სახელი, რომელიც მიუთითებს კონფიგურაციაზე file conf/machine-ში მეტა-თავისუფალ მასშტაბში და meta-imx-ში.
-ბ განსაზღვრავს imx-setup-release.sh სკრიპტით შექმნილი build დირექტორიას სახელს.
როდესაც სკრიპტი გაშვებულია, ის მომხმარებელს მოუწოდებს მიიღოს EULA. მას შემდეგ რაც EULA მიიღება, მიღება ინახება local.conf-ში თითოეული build საქაღალდეში და EULA მიღების მოთხოვნა აღარ არის ნაჩვენები ამ build საქაღალდისთვის.
სკრიპტის გაშვების შემდეგ, სამუშაო დირექტორია არის ის, რაც ახლახან შეიქმნა სკრიპტის მიერ, მითითებული -b ოფციით. იქმნება conf საქაღალდე, რომელიც შეიცავს files bblayers.conf და local.conf.
The /conf/bblayers.conf file შეიცავს i.MX Yocto Project-ის გამოშვებაში გამოყენებულ ყველა მეტალეიერს.
ადგილობრივი.კონფ file შეიცავს მანქანისა და დისტროს სპეციფიკაციებს:

მანქანა ??= 'imx7ulpevk'
DISTRO ?= 'fsl-imx-xwayland'
ACCEPT_FSL_EULA = „1“

MACHINE-ის კონფიგურაცია შეიძლება შეიცვალოს ამის რედაქტირებით fileსაჭიროების შემთხვევაში.
ACCEPT_FSL_EULA local.conf file მიუთითებს, რომ თქვენ დაეთანხმეთ EULA-ს პირობებს.
მეტა-imx ფენაში, მანქანების კონსოლიდირებული კონფიგურაციები (imx6qpdlsolox.conf და imx6ul7d.conf) მოცემულია i.MX 6 და i.MX 7 მანქანებისთვის. i.MX იყენებს მათ, რათა ააშენოს საერთო გამოსახულება ყველა მოწყობილობის ხესთან ერთ სურათში შესამოწმებლად. არ გამოიყენოთ ეს მანქანები არაფრისთვის, გარდა ტესტირებისა.

5.2 i.MX Yocto პროექტის სურათის არჩევა
Yocto Project გთავაზობთ რამდენიმე სურათს, რომლებიც ხელმისაწვდომია სხვადასხვა ფენებზე. Poky გთავაზობთ ზოგიერთ სურათს, მეტა-თავისუფალი მასშტაბის და მეტა-თავისუფალი მასშტაბის-დისტრო გთავაზობთ სხვებს, ხოლო დამატებითი გამოსახულების რეცეპტები მოცემულია meta-imx ფენაში. შემდეგი ცხრილი ჩამოთვლის სხვადასხვა საკვანძო სურათებს, მათ შინაარსს და ფენებს, რომლებიც უზრუნველყოფენ გამოსახულების რეცეპტებს.

ცხრილი 1. i.MX Yocto პროექტის სურათები

სურათის სახელი სამიზნე მოწოდებულია ფენით
ძირითადი-იმიჯი-მინიმალური პატარა სურათი, რომელიც მხოლოდ მოწყობილობის ჩატვირთვის საშუალებას აძლევს. ჭუჭყიანი
ბირთვი-გამოსახულება-ბაზა მხოლოდ კონსოლის სურათი, რომელიც სრულად უჭერს მხარს სამიზნე მოწყობილობის აპარატურას. ჭუჭყიანი
core-image-sato სურათი სატოსთან ერთად, მობილური გარემო და ვიზუალური სტილი მობილური მოწყობილობებისთვის. სურათი მხარს უჭერს Sato თემას და იყენებს Pimlico აპლიკაციებს. იგი შეიცავს ტერმინალს, რედაქტორს და ა file მენეჯერი. ჭუჭყიანი
imx-image-core i.MX გამოსახულება i.MX სატესტო აპლიკაციებით, რომელიც გამოიყენება Wayland backend-ებისთვის. ეს სურათი გამოიყენება ჩვენი ყოველდღიური ძირითადი ტესტირებით. მეტა-იმქს/მეტა-სდკ
fsl-image-machine- ტესტი FSL Community i.MX ძირითადი სურათი კონსოლის გარემოთი – GUI ინტერფეისის გარეშე. meta-freescale-distro
imx-image-multimedia აშენებს i.MX სურათს GUI-ით Qt შინაარსის გარეშე. მეტა-იმქს/მეტა-სდკ
imx-გამოსახულება-სრული აშენებს ღია კოდის Qt 6 სურათს მანქანათმცოდნეობის ფუნქციებით. ეს სურათები მხარდაჭერილია მხოლოდ i.MX SoC-სთვის, აპარატურული გრაფიკით. ისინი არ არის მხარდაჭერილი i.MX 6UltraLite, i.MX 6UltraLiteLite, i.MX 6SLL, [MX 7Dual, i.MX 8MNanoLite, ან i.MX 8DXL მეტა-იმქს/მეტა-სდკ

5.3 სურათის აგება
Yocto Project build იყენებს bitbake ბრძანებას. მაგampლე, ბიტბაკე აშენებს დასახელებულ კომპონენტს. თითოეული კომპონენტის აშენებას აქვს მრავალი დავალება, როგორიცაა მოტანა, კონფიგურაცია, კომპილაცია, შეფუთვა და სამიზნე rootf-ებზე განლაგება. bitbake image build აგროვებს ყველა იმ კომპონენტს, რომელიც საჭიროა გამოსახულებაზე და აგებულია თითო დავალების დამოკიდებულების მიხედვით. პირველი კონსტრუქცია არის ხელსაწყოების ჯაჭვი, კომპონენტების ასაშენებლად საჭირო ინსტრუმენტებთან ერთად.
შემდეგი ბრძანება არის ყოფილიampროგორ ავაშენოთ სურათი:
$ bitbake imx-image-multimedia

5.4 Bitbake პარამეტრები
bitbake ბრძანება, რომელიც გამოიყენება გამოსახულების შესაქმნელად, არის bitbake . დამატებითი პარამეტრები შეიძლება გამოყენებულ იქნას ქვემოთ აღწერილი კონკრეტული აქტივობებისთვის. Bitbake გთავაზობთ სხვადასხვა სასარგებლო ვარიანტს ერთი კომპონენტის შესაქმნელად. BitBake პარამეტრით გასაშვებად, ბრძანება ასე გამოიყურება: bitbake არის სასურველი კონსტრუქციის პაკეტი.
შემდეგი ცხრილი გთავაზობთ BitBake-ის რამდენიმე ვარიანტს.

ცხრილი 2. BitBake პარამეტრები

BitBake პარამეტრი აღწერა
-გ მოტანა იღებს თუ ჩამოტვირთვების მდგომარეობა არ არის მონიშნული შესრულებულად.
-გ გაწმენდა ასუფთავებს მთელი კომპონენტის აწყობის დირექტორიას. build დირექტორიაში ყველა ცვლილება დაკარგულია. ასევე გასუფთავებულია კომპონენტის ფესვები და მდგომარეობა. კომპონენტი ასევე ამოღებულია ჩამოტვირთვის დირექტორიადან.
-გ განლაგება ავრცელებს სურათს ან კომპონენტს rootfs-ში.
-k აგრძელებს კომპონენტების მშენებლობას მაშინაც კი, თუ აშენდება შესვენება.
-c შედგენა -f არ არის რეკომენდირებული, რომ დროებითი დირექტორიაში არსებული წყაროს კოდი პირდაპირ შეიცვალოს, მაგრამ თუ ეს ასეა, Yocto Project-მა შესაძლოა არ აღადგინოს იგი, თუ ეს ვარიანტი არ იქნება გამოყენებული. გამოიყენეთ ეს პარამეტრი, რათა აიძულოთ ხელახალი კომპილაცია სურათის განლაგების შემდეგ.
-g ჩამოთვლის დამოკიდებულების ხეს გამოსახულების ან კომპონენტისთვის.
-დდდ რთავს გამართვის 3 დონის სიღრმეში. თითოეული D ამატებს გამართვის სხვა დონეს.
-s, -show-versions აჩვენებს ყველა რეცეპტის მიმდინარე და სასურველ ვერსიებს.

5.5 U-Boot კონფიგურაცია
U-Boot კონფიგურაციები განისაზღვრება ძირითადი აპარატის კონფიგურაციაში file. კონფიგურაცია მითითებულია UBOOT_CONFIG პარამეტრების გამოყენებით. ამისათვის საჭიროა UBOOT_CONFIG-ის დაყენება local.conf-ში. წინააღმდეგ შემთხვევაში, U-Boot build იყენებს SD ჩატვირთვას ნაგულისხმევად.
ისინი შეიძლება ცალკე აშენდეს შემდეგი ბრძანებების გამოყენებით (შეცვალეთ MACHINE სწორ სამიზნეზე).
მრავალი U-Boot კონფიგურაცია შეიძლება შეიქმნას ერთი ბრძანებით U-Boot კონფიგურაციებს შორის სივრცეების დაყენებით.
ქვემოთ მოცემულია U-Boot კონფიგურაციები თითოეული დაფისთვის. i.MX 6 და i.MX 7 დაფები მხარს უჭერს SD-ს OPTEE-ის გარეშე და 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 nand sd-optee”
  • uboot_config_imx6dlsabresd=”sd epdc sd-optee”
  • uboot_config_imx6dlsabreauto=”sd eimnor spinor nand sd-optee”
  • uboot_config_imx6solosabresd=”sd sd-optee”
  • uboot_config_imx6solosabreauto=”sd eimnor spinor nand sd-optee”
  • uboot_config_imx6sxsabresd=”sd emmc qspi2 m4fastup sd-optee”
  • uboot_config_imx6sxsabreauto=”sd qspi1 და sd-optee”
  • uboot_config_imx6qpsabreauto=”sd sata eimnor spinor nand 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 და sd-optee”
  • uboot_config_imx6ull9x9evk=”sd qspi1 sd-optee”
  • uboot_config_imx6ulz14x14evk=”sd emmc qspi1 და sd-optee”
  • uboot_config_imx7dsabresd=”sd epdc qspi1 და sd-optee”
  • uboot_config_imx7ulpevk=”sd emmc sd-optee”

ნებისმიერი U-Boot კონფიგურაციით ასაშენებლად, შეასრულეთ შემდეგი ნაბიჯები.
მხოლოდ ერთი U-Boot კონფიგურაციით:
$ echo “UBOOT_CONFIG = \”eimnor\”” >> conf/local.conf
მრავალი U-Boot კონფიგურაციით:
$ echo “UBOOT_CONFIG = \”sd eimnor\”” >> conf/local.conf
$ MACHINE= bitbake -c განლაგება u-boot-imx
შენიშვნა: i.MX 8 იყენებს imx-boot-ს, რომელიც იზიდავს U-Boot-ს.

5.6 შექმენით სცენარები
ქვემოთ მოცემულია სხვადასხვა კონფიგურაციის აგების სცენარები.
დააყენეთ manifest და შეავსეთ Yocto Project ფენის წყაროები ამ ბრძანებებით:
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ repo init -u https://github.com/nxp-imx/imx-manifest
-b imx-linux-nanbild -m imx-6.6.3-1.0.0.xml
$ რეპო სინქრონიზაცია
შემდეგ სექციებში მოცემულია რამდენიმე კონკრეტული მაგალითიamples. შეცვალეთ მანქანების სახელები და ბრძანებების პერსონალურად მორგება.

5.6.1 ჩარჩო ბუფერის სურათი i.MX 6QuadPlus SABRE-AI-ზე
$ DISTRO=fsl-imx-fb MACHINE=imx6qpsabreauto წყარო imx-setup-release.sh –b build-fb
$ bitbake imx-image-multimedia
ეს ქმნის მულტიმედია გამოსახულებას კადრის ბუფერული ფონით.

5.6.2 XWayland სურათი i.MX 8QuadXPlus MEK-ზე
$ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek წყარო imx-setup-release.sh -b build-xwayland
$ bitbake imx-სურათი-სრული
ეს ქმნის XWayland სურათს Qt 6 და მანქანათმცოდნეობის ფუნქციებით. Qt 6-ისა და მანქანური სწავლის გარეშე ასაშენებლად, ამის ნაცვლად გამოიყენეთ imx-image-multimedia.

5.6.3 Wayland გამოსახულება i.MX 8M Quad EVK-ზე
$ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk წყარო imx-setup-release.sh -b buildwayland
$ bitbake imx-image-multimedia
ეს ქმნის Weston Wayland სურათს მულტიმედიით Qt 6-ის გარეშე.

5.6.4 build გარემოს გადატვირთვა
თუ ახალი ტერმინალის ფანჯარა გაიხსნება ან მანქანა გადაიტვირთება build დირექტორიას დაყენების შემდეგ, დაყენების გარემოს სკრიპტი უნდა იქნას გამოყენებული გარემოს ცვლადების დასაყენებლად და build-ის ხელახლა გასაშვებად. სრული imxsetup-release.sh არ არის საჭირო.
$ წყაროს დაყენება-გარემო

5.6.5 Chromium ბრაუზერი XWayland-ზე და Wayland-ზე
Yocto Project საზოგადოებას აქვს Chromium-ის რეცეპტები Wayland-ის ვერსიისთვის Chromium Browser-ისთვის i.MX SoC-ისთვის GPU აპარატურით. NXP არ უჭერს მხარს და არ ამოწმებს პატჩებს საზოგადოებისგან. ეს განყოფილება აღწერს, თუ როგორ უნდა დააკავშიროთ Chromium თქვენს rootf-ებში და ჩართოთ ტექნიკის დაჩქარებული რენდერი WebGL. Chromium ბრაუზერი საჭიროებს დამატებით შრეებს, როგორიცაა მეტაბრაუზერი, რომელიც ავტომატურად დაემატება imx-release-setup.sh სკრიპტს.
local.conf-ში XWayland-ისთვის ან Wayland-ისთვის დაამატეთ Chromium თქვენს სურათს. X11 არ არის მხარდაჭერილი.
CORE_IMAGE_EXTRA_INSTALL += „ქრომი-ოზონის გზა“

5.6.6 Qt 6 და QtWebძრავის ბრაუზერები
Qt 6-ს აქვს როგორც კომერციული, ასევე ღია კოდის ლიცენზია. Yocto Project-ში მშენებლობისას ნაგულისხმევია ღია კოდის ლიცენზია. დარწმუნდით, რომ გესმით განსხვავებები ამ ლიცენზიებს შორის და აირჩიეთ სათანადოდ. მას შემდეგ, რაც საბაჟო Qt 6-ის განვითარება დაიწყო ღია კოდის ლიცენზიაზე, მისი გამოყენება კომერციული ლიცენზიით შეუძლებელია. იმუშავეთ იურიდიულ წარმომადგენელთან ამ ლიცენზიებს შორის განსხვავებების გასაგებად.
შენიშვნა:
შენობა ქWebძრავა არ არის თავსებადი მეტაქრომის ფენასთან, რომელიც გამოიყენება გამოშვებით.
თუ იყენებთ NXP build-ის დაყენებას, წაშალეთ მეტაქრომი bblayers.conf-დან:
# დატოვა კომენტარი qt-თან შეუთავსებლობის გამოwebძრავა
#BBLAYERS += „${BSPDIR}/sources/meta-browser/meta-chromium“

ხელმისაწვდომია ოთხი Qt 6 ბრაუზერი. ქტWebძრავის ბრაუზერები შეგიძლიათ იხილოთ შემდეგში:

  • /usr/share/qt6/examples/webძრავის ვიჯეტები/StyleSheetBrowser
  • /usr/share/qt6/examples/webძრავის ვიჯეტები/მარტივი ბრაუზერი
  • /usr/share/qt6/examples/webძრავის ვიჯეტები/ქუქიბრაუზერი
  • /usr/share/qt6/examples/webძრავა/სწრაფი ნანობრაუზერი

სამივე ბრაუზერის გაშვება შესაძლებელია ზემოთ მოცემულ დირექტორიაში გადასვლით და იქ ნაპოვნი შესრულებადი ფაილის გაშვებით.
სენსორული ეკრანის ჩართვა შესაძლებელია შესრულებადში პარამეტრების -plugin evdevtouch:/dev/input/event0 დამატებით.
./quicknanobrowser -მოდული evdevtouch:/dev/input/event0
QtWebძრავი მუშაობს მხოლოდ SoC-ზე GPU გრაფიკული აპარატურით i.MX 6, i.MX 7, i.MX 8 და i.MX 9.
ჩართვის Qtwebძრავა სურათზე, ჩადეთ შემდეგი local.conf-ში ან გამოსახულების რეცეპტში.
IMAGE_INSTALL:append = ”packgroup-qt6-webძრავა”

5.6.7 NXP eIQ მანქანური სწავლება
მეტა-მლ ფენა არის NXP eIQ მანქანათმცოდნეობის ინტეგრაცია, რომელიც ადრე გამოშვებული იყო როგორც ცალკე meta-imx-მანქანური სწავლის ფენა და ახლა ინტეგრირებულია სტანდარტულ BSP სურათში (imx-image-full).
ბევრი ფუნქცია მოითხოვს Qt 6-ს. იმ შემთხვევაში, თუ იყენებთ სხვა კონფიგურაციას, გარდა imx-image-full, განათავსეთ შემდეგი local.conf-ში:
IMAGE_INSTALL:append = ”packgroup-imx-ml”
NXP eIQ პაკეტების SDK-ზე დასაინსტალირებლად, განათავსეთ შემდეგი local.conf-ში:
TOOLCHAIN_TARGET_TASK:append = ”tensorflow-lite-dev onnxruntime-dev”

შენიშვნა:
TOOLCHAIN_TARGET_TASK_append ცვლადი აყენებს პაკეტებს მხოლოდ SDK-ზე და არა სურათზე.
OpenCV DNN დემოს მოდელის კონფიგურაციებისა და შეყვანის მონაცემების დასამატებლად, განათავსეთ შემდეგი local.conf-ში:
PACKAGECONFIG:append:pn-opencv_mx8 = ” ტესტირების ტესტები-imx”

5.6.8 სისტემური
Systemd ჩართულია, როგორც ინიციალიზაციის ნაგულისხმევი მენეჯერი. სისტემის ნაგულისხმევად გამოსართავად, გადადით fsl-imxpreferred-env.inc-ზე და გააკეთეთ კომენტარი systemd განყოფილებაში.

5.6.9 Multilib ჩართვა
i.MX 8-ისთვის, 32-ბიტიანი აპლიკაციების შექმნა 64-ბიტიან OS-ზე შეიძლება იყოს მხარდაჭერილი multilib კონფიგურაციის გამოყენებით. Multilib გთავაზობთ შესაძლებლობას შექმნათ ბიბლიოთეკები სხვადასხვა სამიზნე ოპტიმიზაციით ან არქიტექტურული ფორმატით და დააკავშიროთ ისინი ერთად ერთ სისტემურ სურათში. Multilib ჩართულია MULTILIB, DEFAULTTUNE და IMAGE_INSTALL დეკლარაციის დამატებით თქვენს local.conf-ზე file. Multilib არ არის მხარდაჭერილი Debian პაკეტის მენეჯმენტით. ეს მოითხოვს RPM სისტემას. დააკომენტარეთ პაკეტის მართვის ორი ხაზი local.conf-ში, რომ გადახვიდეთ ნაგულისხმევ RPM-ზე.
MULTILIBS დეკლარაცია, როგორც წესი, არის lib32 ან lib64 და უნდა განისაზღვროს
MULTILIB_GLOBAL_VARIANTS ცვლადი შემდეგნაირად:

MULTILIBS = „multilib:lib32“
DEFAULTTUNE უნდა იყოს AVAILTUNES-ის ერთ-ერთი მნიშვნელობა ამ ალტერნატიული ბიბლიოთეკის ტიპისთვის შემდეგნაირად:
DEFAULTTUNE:virtclass-multilib-lib32 = „armv7athf-neon“
IMAGE_INSTALL დაემატება სურათს, კონკრეტული აპლიკაციისთვის საჭირო 32-ბიტიანი ბიბლიოთეკები შემდეგნაირად:
IMAGE_INSTALL:append = ”lib32-bash”
i.MX 8-ის შემთხვევისთვის, 32-ბიტიანი აპლიკაციის მხარდაჭერის შექმნა დასჭირდება შემდეგ განცხადებებს local.conf-ში. ეს კონფიგურაცია განსაზღვრავს 64-ბიტიან მანქანას, როგორც აპარატის მთავარ ტიპს და ამატებს multilib:lib32, სადაც ეს ბიბლიოთეკები შედგენილია armv7athf-neon მელოდიით და შემდეგ მოიცავს ყველა სურათს lib32 პაკეტებს.
MACHINE = imx8mqevk
# განსაზღვრეთ multilib სამიზნე
მოითხოვს conf/multilib.conf
MULTILIBS = „multilib:lib32“
DEFAULTTUNE:virtclass-multilib-lib32 = „armv7athf-neon“
# დაამატეთ multilib პაკეტები სურათს
IMAGE_INSTALL:append = ” lib32-glibc lib32-libgcc lib32-libstdc++”
გამორთეთ deb შეფუთვა, რათა თავიდან აიცილოთ დამუშავების შეცდომები. შეამოწმეთ local.conf და დააკომენტარეთ, თუ არის:
PACKAGE_CLASSES = „package_deb“
EXTRA_IMAGE_FEATURES += „პაკეტის მართვა“

5.6.10 OP-TEE ჩართვა
OP-TEE მოითხოვს სამ კომპონენტს: OP-TEE OS, OP-TEE კლიენტი და OP-TEE ტესტი. გარდა ამისა, ბირთვს და U-Boot-ს აქვს კონფიგურაციები. OP-TEE OS მდებარეობს ჩამტვირთველში, ხოლო OP-TEE კლიენტი და ტესტი მდებარეობს rootfs-ში.
OP-TEE ჩართულია ნაგულისხმევად ამ გამოშვებაში. OP-TEE-ის გამოსართავად გადადით meta-imx/meta-bsp/conf/layer.conf-ზე file და დატოვეთ კომენტარი DISTRO_FEATURES_დანართზე OP-TEE-სთვის და გააუქმეთ კომენტარი წაშლილი ხაზისთვის.

5.6.11 ციხის შენობა
Jailhouse არის სტატიკური დანაყოფი Hypervisor, რომელიც დაფუძნებულია Linux OS-ზე. ის მხარდაჭერილია i.MX 8M Plus, i.MX 8M Nano, i.MX 8M Quad EVK და i.MX 8M Mini EVK დაფებზე.

Jailhouse build-ის ჩასართავად, დაამატეთ შემდეგი ხაზი local.conf-ს:
DISTRO_FEATURES: დამატება = "ციხის სახლი"
U-Boot-ში გაუშვით jh_netboot ან jh_mmcboot. ის იტვირთება გამოყოფილი DTB Jailhouse-ის გამოყენებისთვის. i.MX 8M Quad-ის მიღება, როგორც ყოფილიample, Linux OS ჩატვირთვის შემდეგ:
#insmod jailhouse.ko
#./jailhouse ჩართეთ imx8mq.cell

დამატებითი ინფორმაციისთვის Jailhouse-ის შესახებ i.MX 8-ზე იხილეთ i.MX Linux მომხმარებლის სახელმძღვანელო (IMXLUG).

5.6.12 პაკეტის მართვა
ნაგულისხმევი პაკეტის მართვა Yocto Project-ით არის rpm. i.MX დისტრო ახლა საშუალებას აძლევს Debian-ს, როგორც პაკეტის მენეჯმენტს. ამის მარტივად გამორთვა შესაძლებელია ACKAGE_CLASSES დაყენებული package_rpm-ზე დამატებით local.conf-ში, ან მორგებული დისტროს შექმნით დებიანის პაკეტის არხის გარეშე PACKAGE_CLASSES = „package_deb“ .
Debian პაკეტის არხის დამატებით, sources.list შეიძლება დაემატოს /etc/apt-ს, რომელიც უკავშირდება Debian-ის პაკეტის არხს. ეს საშუალებას აძლევს მომხმარებლებს დააინსტალირონ პაკეტები, რომლებიც არ არის გათვალისწინებული სურათზე, მათი Yocto სურათზე დამატების გარეშე. იმის გამო, რომ პაკეტის ეს არხი არ არის გენერირებული i.MX Yocto-ს აგების პროცესით, არ არსებობს გარანტია, რომ თითოეული პაკეტი იმუშავებს სწორ დამოკიდებულებებთან, მაგრამ ის იძლევა უფრო მარტივი ხელსაწყოების მოწოდების საშუალებას.
პროგრამულ უზრუნველყოფას, რომელიც კომპლექსურია და უფრო მეტად არის დამოკიდებული კონკრეტულ ვერსიებზე, შესაძლოა პრობლემები ჰქონდეს გარე პაკეტის არხთან.

გამოსახულების განლაგება

სრული fileსისტემის სურათები განლაგებულია /tmp/deploy/images. გამოსახულება, უმეტესწილად, სპეციფიკურია აპარატისთვის, რომელიც დაყენებულია გარემოს დაყენებაში. თითოეული სურათის აგება ქმნის U-Boot-ს, ბირთვს და გამოსახულების ტიპს, რომელიც დაფუძნებულია აპარატის კონფიგურაციაში განსაზღვრულ IMAGE_FSTYPES-ზე. file. აპარატის კონფიგურაციის უმეტესობა უზრუნველყოფს SD ბარათის სურათს (.wic) და rootfs სურათს (.tar). SD ბარათის სურათი შეიცავს დანაწევრებულ სურათს (U-Boot, kernel, rootfs და ა.შ.), რომელიც შესაფერისია შესაბამისი აპარატურის ჩატვირთვისთვის.

6.1 SD ბარათის სურათის ციმციმი
SD ბარათის სურათი file .wic შეიცავს დანაწევრებულ სურათს (U-Boot, kernel, rootfs და ა.შ.), რომელიც შესაფერისია შესაბამისი აპარატურის ჩატვირთვისთვის. SD ბარათის გამოსახულების გასანათებლად, შეასრულეთ შემდეგი ბრძანება:
zstdcat .wic.zst | sudo dd of=/dev/sd bs=1M კონვ=fsync
ციმციმის შესახებ დამატებითი ინფორმაციისთვის იხილეთ სექცია „SD/MMC ბარათის ჩასატარებლად მომზადება“ i.MX Linux-ის მომხმარებლის სახელმძღვანელოში (IMXLUG). NXP eIQ მანქანური სწავლების აპლიკაციებისთვის საჭიროა დამატებითი თავისუფალი ადგილი დისკზე (დაახლოებით 1 გბ). ის განისაზღვრება local.conf-ში IMAGE_ROOTFS_EXTRA_SPACE ცვლადის დამატებით file იოქტოს მშენებლობის პროცესამდე. იხილეთ Yocto Project Mega-Manual.

მორგება

i.MX Linux OS-ზე აშენებისა და მორგების სამი სცენარი არსებობს:

  • i.MX Yocto Project BSP-ის აგება და i.MX საცნობარო დაფაზე დადასტურება. ამ დოკუმენტის ინსტრუქციები დეტალურად აღწერს ამ მეთოდს.
  • ბირთვის მორგება და მორგებული დაფის და მოწყობილობის ხის შექმნა ბირთვით და U-Boot-ით. დამატებითი ინფორმაციისთვის, თუ როგორ უნდა ააშენოთ SDK და დააყენოთ მასპინძელი მანქანა ბირთვისა და U-Boot-ის შესაქმნელად მხოლოდ Yocto Project build გარემოს გარეთ, იხილეთ თავი „როგორ ავაშენოთ U-Boot და ბირთვი დამოუკიდებელ გარემოში“ i. .MX მომხმარებლის სახელმძღვანელო (IMXLUG).
  • დისტრიბუციის მორგება, BSP-დან შეფუთვის დამატება ან ამოღება, რომელიც გათვალისწინებულია i.MX Linux-ის გამოშვებებისთვის, მორგებული Yocto Project ფენის შექმნით. i.MX გთავაზობთ მრავალჯერადი დემო მაგალითსamples რათა აჩვენოს მორგებული ფენა i.MX BSP გამოშვების თავზე. ამ დოკუმენტის დარჩენილი სექციები გვაწვდის ინსტრუქციებს მორგებული DISTRO და დაფის კონფიგურაციის შესაქმნელად.

7.1 პერსონალური დისტრიბუციის შექმნა
საბაჟო დისტროს შეუძლია დააკონფიგურიროს მორგებული build გარემო. დისტრო fileგამოშვებული fsl-imx-wayland, fslimx-xwayland და fsl-imx-fb ყველა აჩვენებს კონფიგურაციას კონკრეტული გრაფიკული სარეზერვო სისტემებისთვის. Distros ასევე შეიძლება გამოყენებულ იქნას სხვა პარამეტრების კონფიგურაციისთვის, როგორიცაა kernel, U-Boot და GStreamer. i.MX დისტრო files შექმნილია შექმნას მორგებული build გარემო, რომელიც საჭიროა ჩვენი i.MX Linux OS BSP გამოშვებების შესამოწმებლად.
რეკომენდირებულია თითოეულ მომხმარებელს შექმნას საკუთარი დისტრო file და გამოიყენეთ ეს პროვაიდერების, ვერსიების და მორგებული კონფიგურაციების დასაყენებლად მათი აშენების გარემოსთვის. დისტრო იქმნება არსებული დისტროს კოპირებით file, ან მათ შორის, როგორიცაა poky.conf და დამატებითი ცვლილებების დამატება, ან i.MX-ის ერთ-ერთი დისტროს ჩათვლით და მისი ამოსავალი წერტილის გამოყენება.

7.2 მორგებული დაფის კონფიგურაციის შექმნა
მომწოდებლებს, რომლებიც ამუშავებენ საცნობარო დაფებს, შეიძლება სურდეთ დაამატოთ თავიანთი დაფა FSL ​​Community BSP-ში.
FSL Community BSP-ის მიერ მხარდაჭერილი ახალი აპარატის არსებობა აადვილებს წყაროს კოდის საზოგადოებას გაზიარებას და საზოგადოებისგან გამოხმაურების საშუალებას.
Yocto Project აადვილებს BSP-ის შექმნას და გაზიარებას ახალი i.MX დაფისთვის. Upstreaming პროცესი უნდა დაიწყოს, როდესაც Linux OS ბირთვი და bootloader მუშაობს და ტესტირება ხდება ამ აპარატისთვის. ძალიან მნიშვნელოვანია გქონდეთ სტაბილური Linux ბირთვი და ჩამტვირთავი (მაგample, U-Boot) უნდა იყოს მითითებული მანქანის კონფიგურაციაში file, იყოს ნაგულისხმევი, რომელიც გამოიყენება ამ აპარატისთვის.
კიდევ ერთი მნიშვნელოვანი ნაბიჯი არის ახალი აპარატის შემნახველის განსაზღვრა. შემნახველი არის ის, ვინც პასუხისმგებელია ამ დაფისთვის მომუშავე ძირითადი პაკეტების ნაკრების შენარჩუნებაზე. აპარატის დამხმარემ უნდა განაახლოს ბირთვი და ჩამტვირთავი, ხოლო მომხმარებლის სივრცის პაკეტები შემოწმებული უნდა იყოს ამ აპარატისთვის.

საჭირო ნაბიჯები ჩამოთვლილია ქვემოთ.

  1. ბირთვის კონფიგურაციის მორგება fileროგორც საჭიროა. ბირთვის კონფიგურაცია file არის მდებარეობა arch/arm/configs-ში და გამყიდველის ბირთვის რეცეპტმა უნდა მოარგოს ბირთვის რეცეპტით ჩატვირთული ვერსია.
  2. საჭიროების შემთხვევაში დააკონფიგურირეთ U-Boot. ამის შესახებ დეტალებისთვის იხილეთ i.MX BSP პორტირების სახელმძღვანელო (IMXBSPPG).
  3. დანიშნეთ გამგეობის შემსრულებელი. ეს დამხმარე დარწმუნებულია, რომ files განახლებულია საჭიროებისამებრ, ასე რომ, build ყოველთვის მუშაობს.
  4. დააყენეთ Yocto Project build, როგორც ეს აღწერილია Yocto Project საზოგადოების ინსტრუქციებში, როგორც ნაჩვენებია ქვემოთ.
    გამოიყენეთ საზოგადოების სამაგისტრო ფილიალი.
    ა. ჩამოტვირთეთ საჭირო ჰოსტის პაკეტი, თქვენი ჰოსტის Linux OS დისტრიბუციიდან გამომდინარე Yocto Project სწრაფი დაწყება.
    ბ. ჩამოტვირთეთ რეპო ბრძანებით:
    $ გurl https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
    გ. შექმენით დირექტორია, რომ შეინახოთ ყველაფერი. ნებისმიერი დირექტორიას სახელი შეიძლება გამოყენებულ იქნას. ეს დოკუმენტი იყენებს imxcommunity-bsp.
    $ mkdir imx-community-bsp
    დ. შეასრულეთ შემდეგი ბრძანება:
    $ cd imx-community-bsp
    ე. განახორციელეთ რეპოს ინიცირება რეპოს მთავარ ფილიალთან.
    $ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -ბ ოსტატი
    ვ. მიიღეთ რეცეპტები, რომლებიც გამოყენებული იქნება ასაშენებლად.
    $ რეპო სინქრონიზაცია
    გ. დააყენეთ გარემო შემდეგი ბრძანებით:
    $ წყაროს დაყენება-გარემოს აგება
  5. აირჩიეთ მსგავსი მანქანა file fsl-community-bsp/sources/meta-freescale-3rdparty/conf/machine-ში და დააკოპირეთ თქვენი დაფის მითითების სახელის გამოყენებით. ახალი დაფის რედაქტირება file თქვენი დაფის შესახებ ინფორმაციასთან ერთად. შეცვალეთ სახელი და აღწერა მაინც. დაამატეთ MACHINE_FEATURE.
  6. შეამოწმეთ თქვენი ცვლილებები საზოგადოების უახლესი სამაგისტრო ფილიალში, დარწმუნდით, რომ ყველაფერი კარგად მუშაობს. გამოიყენეთ მინიმუმ core-image-minimal.
    $ bitbake core-image-მინიმალური
  7. მოამზადეთ პატჩები. მიჰყევით რეცეპტის სტილის სახელმძღვანელოს და git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/ tree/README განყოფილებაში სახელწოდებით "წვლილი".
  8. ზემოთ, მეტა-თავისუფალი მასშტაბის მესამე მხარისკენ. ზემოთ დინებაში, გაგზავნეთ პატჩები metafreescale@yoctoproject.org.

7.3 უსაფრთხოების ხარვეზების მონიტორინგი თქვენს BSP-ში
საერთო დაუცველობისა და ექსპოზიციების (CVE) მონიტორინგი შეიძლება განხორციელდეს Timesys-ის NXP ჩართული Vigiles ინსტრუმენტებით. Vigiles არის დაუცველობის მონიტორინგისა და მართვის ინსტრუმენტი, რომელიც უზრუნველყოფს სამიზნე სურათების Yocto CVE ანალიზს. ის ამას აკეთებს Yocto Project BSP-ში გამოყენებული პროგრამული უზრუნველყოფის მეტამონაცემების შეგროვებით და მისი შედარებით CVE მონაცემთა ბაზასთან, რომელიც აერთიანებს ინფორმაციას CVE-ებზე სხვადასხვა წყაროდან, მათ შორის NIST, Ubuntu და რამდენიმე სხვა.
მაღალი დონის დასრულდაview აღმოჩენილი დაუცველობა დაბრუნდება და შეიძლება ჩატარდეს სრული დეტალური ანალიზი CVE-ებზე ზემოქმედების შესახებ ინფორმაციის, მათი სიმძიმისა და ხელმისაწვდომი გამოსწორებების შესახებ. viewed ონლაინ.
მოხსენებაზე ონლაინ წვდომისთვის, დარეგისტრირდით თქვენს NXP Vigiles ანგარიშზე, მიჰყევით ბმულს:
https://www.timesys.com/register-nxp-vigiles/
დამატებითი ინფორმაცია Vigiles-ის დაყენებისა და შესრულების შესახებ შეგიძლიათ იხილოთ აქ:
https://github.com/TimesysGit/meta-timesys
https://www.nxp.com/vigiles

7.3.1 კონფიგურაცია
დაამატეთ meta-timesys conf/bblayers.conf თქვენი BSP build-ში.
მიჰყევით ფორმატს file და დაამატეთ meta-timesys:
BBLAYERS += „${BSPDIR}/sources/meta-timesys“
vigiles-ის დამატება INHERIT ცვლადში conf/local.conf-ში:
მემკვიდრეობა += „ფხიზლები“

7.3.2 შესრულება
მას შემდეგ, რაც მეტა-timesys დაემატება თქვენს build-ს, Vigiles ახორციელებს უსაფრთხოების ხარვეზების სკანირებას ყოველ ჯერზე, როცა Linux BSP აშენდება Yocto-სთან ერთად. დამატებითი ბრძანებები არ არის საჭირო. ყოველი კონსტრუქციის დასრულების შემდეგ, დაუცველობის სკანირების ინფორმაცია ინახება დირექტორიაში imx-yocto-bsp/ /ფხიზლებს.
შეგიძლია view უსაფრთხოების სკანირების დეტალები:

  • ბრძანების ხაზი (შეჯამება)
  • ონლაინ (დეტალები)
    უბრალოდ გახსენით file დაასახელა -report.txt, რომელიც მოიცავს დეტალური ონლაინ ანგარიშის ბმულს.

ხშირად დასმული კითხვები

8.1 სწრაფი დაწყება
ეს განყოფილება აჯამებს, თუ როგორ უნდა დააყენოთ Yocto Project Linux აპარატზე და შექმნათ სურათი. დეტალური განმარტებები იმის შესახებ, თუ რას ნიშნავს ეს, მოცემულია ზემოთ მოცემულ განყოფილებებში.

"რეპო" კომუნალური პროგრამის დაყენება
BSP-ის მისაღებად თქვენ უნდა გქონდეთ დაინსტალირებული „რეპო“. ეს მხოლოდ ერთხელ უნდა გაკეთდეს.

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

BSP Yocto Project Environment-ის ჩამოტვირთვა.
გამოიყენეთ სწორი სახელი გამოშვებისთვის სასურველი -b ოფციაში repo init-ისთვის. ეს უნდა გაკეთდეს ერთხელ ყოველ გამოშვებაზე და ადგენს განაწილებას პირველ ეტაპზე შექმნილი დირექტორიასთვის. რეპო სინქრონიზაციის გაშვება შესაძლებელია წყაროების რეცეპტების უახლესამდე განახლებისთვის.
$: mkdir imx-yocto-bsp
$: cd imx-yocto-bsp
$: რეპო init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-nanbild m imx-6.6.3-1.0.0.xml
: რეპო სინქრონიზაცია
შენიშვნა:
https://github.com/nxp-imx/imx-manifest/tree/imx-linux-nanbield აქვს ყველა მანიფესტის სია files მხარს უჭერს ამ გამოცემას.

დაყენება სპეციფიური ბექენდებისთვის
i.MX 8 და i.MX 9 Framebuffer არ არის მხარდაჭერილი. გამოიყენეთ ეს მხოლოდ i.MX 6 და i.MX 7 SoC-სთვის.

დაყენება Framebuffer-ისთვის:
$: DISTRO=fsl-imx-fb MACHINE= წყარო imx-setup-release.sh -b build-fb
დაყენება Wayland-ისთვის:
$: DISTRO=fsl-imx-wayland MACHINE= წყარო imx-setup-release.sh -b build-wayland
XWayland-ის დაყენება:
$: DISTRO=fsl-imx-xwayland MACHINE= წყარო imx-setup-release.sh -b build-xwayland

ავაშენოთ ყველა საზურგეებისთვის
აშენება Qt-ის გარეშე
$: bitbake imx-image-multimedia
აშენება Qt 6 და მანქანათმცოდნეობის ფუნქციებით
$: bitbake imx-imx-სრული

8.2 ადგილობრივი კონფიგურაციის დარეგულირება
Yocto Project build-ს შეუძლია მიიღოს მნიშვნელოვანი build რესურსები როგორც დროში, ასევე დისკის გამოყენებაში, განსაკუთრებით მაშინ, როდესაც შენდება მრავალი build დირექტორიაში. არსებობს ამის ოპტიმიზაციის მეთოდები, მაგალითადample, გამოიყენეთ გაზიარებული sstate ქეში (ქეში შეინახავს build-ის მდგომარეობას) და ჩამოტვირთვების დირექტორიას (ინახავს გადმოწერილ პაკეტებს). მათი დაყენება შესაძლებელია ადგილობრივ.conf-ის ნებისმიერ ადგილას file ასეთი განცხადებების დამატებით:
DL_DIR=”/opt/imx/yocto/imx/ჩამოტვირთვა”
SSTATE_DIR=”/opt/imx/yocto/imx/sstate-cache”
დირექტორიები უკვე უნდა არსებობდეს და ჰქონდეს შესაბამისი ნებართვები. გაზიარებული სახელმწიფო ეხმარება, როდესაც დაყენებულია მრავალი build დირექტორიები, რომელთაგან თითოეული იყენებს გაზიარებულ ქეშს, რათა შემცირდეს აშენების დრო. ჩამოტვირთვის საზიარო დირექტორია ამცირებს ჩამოტვირთვის დროს. ამ პარამეტრების გარეშე, Yocto Project-ს ნაგულისხმევი აქვს build დირექტორია sstate ქეშისა და ჩამოტვირთვებისთვის.
DL_DIR დირექტორიაში ჩამოტვირთული ყველა პაკეტი აღინიშნება a .შესრულებულია. თუ თქვენს ქსელს აქვს პაკეტის მიღების პრობლემა, შეგიძლიათ ხელით დააკოპიროთ პაკეტის სარეზერვო ვერსია DL_DIR დირექტორიაში და შექმნათ .შესრულებულია file შეხების ბრძანებით. შემდეგ გაუშვით bitbake ბრძანება:
ბიტბეიკი .
დამატებითი ინფორმაციისთვის იხილეთ Yocto Project Reference Manual — Yocto Project ® 5.0.1 დოკუმენტაცია.

8.3 რეცეპტი
თითოეული კომპონენტი აგებულია რეცეპტის გამოყენებით. ახალი კომპონენტებისთვის უნდა შეიქმნას რეცეპტი, რომელიც მიუთითებს წყაროზე (SRC_URI) და მიუთითებს პატჩებს, თუ ეს შესაძლებელია. Yocto Project გარემო აგებულია მწარმოებლისგანfile რეცეპტში SRC_URI მითითებულ ადგილას. როდესაც build ჩამოყალიბებულია ავტომატური ხელსაწყოებიდან, რეცეპტმა უნდა მემკვიდრეობით მიიღოს autotools და pkgconfig. Გააკეთოსfiles-მ უნდა დაუშვას CC-ის გადაფარვა Cross Compile ინსტრუმენტებით, რათა მიიღოთ პაკეტი Yocto Project-ით აშენებული.

ზოგიერთ კომპონენტს აქვს რეცეპტები, მაგრამ საჭიროებს დამატებით პატჩებს ან განახლებებს. ეს შეიძლება გაკეთდეს bbappend რეცეპტის გამოყენებით. ეს ემატება არსებული რეცეპტის დეტალებს განახლებული წყაროს შესახებ. მაგampასევე, bbappend-ის რეცეპტი, რომელიც შეიცავს ახალ პაჩს, უნდა შეიცავდეს შემდეგ შიგთავსს:
FILESEXTRAPATHS:prepend := „${THISDIR}/${PN}:“
SRC_URI += file:// .პაჩი
FILESEXTRAPATHS_prepend ეუბნება Yocto Project-ს, მოძებნოს ჩამოთვლილ დირექტორიაში SRC_URI-ში ჩამოთვლილი პატჩი.

შენიშვნა:
თუ bbappend-ის რეცეპტი არ არის აღებული, view მოტანის ჟურნალი file (log.do_fetch) სამუშაო საქაღალდის ქვეშ, რათა შეამოწმოთ, შედის თუ არა დაკავშირებული პატჩები. ზოგჯერ bbappend-ის ვერსიის ნაცვლად გამოიყენება რეცეპტის Git ვერსია files.

8.4 როგორ ავირჩიოთ დამატებითი პაკეტები
დამატებითი პაკეტები შეიძლება დაემატოს სურათებს, თუ არსებობს რეცეპტი გათვალისწინებული ამ პაკეტისთვის. საზოგადოების მიერ მოწოდებული რეცეპტების საძიებო სია შეგიძლიათ იხილოთ აქ layers.openembedded.org/. შეგიძლიათ მოძებნოთ, რომ ნახოთ, აქვს თუ არა აპლიკაციას უკვე Yocto Project რეცეპტი და იპოვოთ ის, საიდან გადმოწეროთ იგი.

8.4.1 სურათის განახლება
სურათი არის პაკეტების ნაკრები და გარემოს კონფიგურაცია.
გამოსახულება file (როგორიცაა imx-image-multimedia.bb) განსაზღვრავს პაკეტებს, რომლებიც შედიან შიგნით file სისტემა.
ფესვი file სისტემები, ბირთვები, მოდულები და U-Boot ორობითი ხელმისაწვდომია build/tmp/deploy/images/ .

შენიშვნა:
თქვენ შეგიძლიათ შექმნათ პაკეტები სურათში მისი ჩართვის გარეშე, მაგრამ თქვენ უნდა აღადგინოთ სურათი, თუ გსურთ პაკეტი ავტომატურად დაინსტალირდეს rootfs-ზე.

8.4.2 პაკეტის ჯგუფი
პაკეტის ჯგუფი არის პაკეტების ნაკრები, რომელიც შეიძლება იყოს ჩართული ნებისმიერ სურათზე.
პაკეტის ჯგუფი შეიძლება შეიცავდეს პაკეტების კომპლექტს. მაგampასევე, მულტიმედიური დავალება შეიძლება განსაზღვროს, აპარატის მიხედვით, არის თუ არა VPU პაკეტი აშენებული, ასე რომ, მულტიმედიური პაკეტების შერჩევა შეიძლება ავტომატიზირებული იყოს BSP-ის მიერ მხარდაჭერილი ყველა დაფისთვის და მხოლოდ მულტიმედიური პაკეტი შედის სურათში.
დამატებითი პაკეტების დაყენება შესაძლებელია შემდეგი ხაზის დამატებით /local.conf.
CORE_IMAGE_EXTRA_INSTALL: დამატება = ” ”
ბევრი პაკეტების ჯგუფია. ისინი არიან ქვედირექტორიებში, სახელწოდებით პაკეტის ჯგუფი ან პაკეტის ჯგუფები.

8.4.3 სასურველი ვერსია
სასურველი ვერსია გამოიყენება რეცეპტის სასურველი ვერსიის დასაზუსტებლად, რომელიც გამოიყენება კონკრეტული კომპონენტისთვის. კომპონენტს შეიძლება ჰქონდეს რამდენიმე რეცეპტი სხვადასხვა ფენაში და სასურველი ვერსია მიუთითებს კონკრეტულ ვერსიაზე გამოსაყენებლად.

meta-imx ფენაში, layer.conf-ში, სასურველი ვერსიები დაყენებულია ყველა რეცეპტისთვის, რათა უზრუნველყოს სტატიკური სისტემა საწარმოო გარემოსთვის. ეს სასურველი ვერსიის პარამეტრები გამოიყენება ფორმალური i.MX გამოშვებებისთვის, მაგრამ არ არის აუცილებელი მომავალი განვითარებისთვის.
სასურველი ვერსიები ასევე ეხმარება, როდესაც წინა ვერსიებმა შეიძლება გამოიწვიოს დაბნეულობა იმის შესახებ, თუ რომელი რეცეპტი უნდა იქნას გამოყენებული.
მაგampწინა რეცეპტებში imx-test და imx-lib გამოიყენებოდა ყოველთვიური ვერსია, რომელიც შეიცვალა ვერსიირება. სასურველი ვერსიის გარეშე, შეიძლება ძველი ვერსიის არჩევა. რეცეპტები, რომლებსაც აქვთ _git ვერსიები, ჩვეულებრივ არჩევენ სხვა რეცეპტებს, თუ სასურველი ვერსია არ არის მითითებული. სასურველი ვერსიის დასაყენებლად, განათავსეთ შემდეგი local.conf-ში.
PREFERRED_VERSION_ : = " ”
იხილეთ Yocto Project-ის სახელმძღვანელოები სასურველი ვერსიების გამოყენების შესახებ დამატებითი ინფორმაციისთვის.

8.4.4 სასურველი პროვაიდერი
სასურველი პროვაიდერი გამოიყენება კონკრეტული კომპონენტისთვის სასურველი პროვაიდერის დასადგენად. კომპონენტს შეიძლება ჰქონდეს მრავალი პროვაიდერი. მაგampასევე, Linux-ის ბირთვის მოწოდება შესაძლებელია i.MX-ის ან kernel.org-ის მიერ და სასურველი პროვაიდერი ასახელებს პროვაიდერს, რომელსაც გამოიყენებს.
მაგample, U-Boot უზრუნველყოფილია როგორც საზოგადოების მიერ denx.de-ს და i.MX-ის საშუალებით. საზოგადოების პროვაიდერი მითითებულია u-boot-fslc-ით. i.MX პროვაიდერი მითითებულია u-boot-imx-ით. სასურველი პროვაიდერის დასადგენად, განათავსეთ შემდეგი local.conf-ში:
PREFERRED_PROVIDER_ : = " ”
PREFERRED_PROVIDER_u-boot_mx6 = „u-boot-imx“

8.4.5 SoC ოჯახი
SoC ოჯახი ამტკიცებს ცვლილებების კლასს, რომელიც ვრცელდება სისტემის ჩიპების კონკრეტულ კომპლექტზე. თითოეული მანქანის კონფიგურაციაში file, მანქანა ჩამოთვლილია კონკრეტული SoC ოჯახით. მაგample, i.MX 6DualLite Sabre-SD ჩამოთვლილია i.MX 6 და i.MX 6DualLite SoC ოჯახებში. i.MX 6Solo Sabre-auto ჩამოთვლილია i.MX 6 და i.MX 6Solo SoC ოჯახებში. ზოგიერთი ცვლილება შეიძლება მიზანმიმართული იყოს SoC-ის კონკრეტულ ოჯახზე local.conf-ში, რათა თავიდან აიცილოს ცვლილება აპარატის კონფიგურაციაში. file. შემდეგი არის ყოფილიampmx6dlsabresd ბირთვის პარამეტრებში ცვლილების შესახებ.
KERNEL_DEVICETREE:mx6dl = „imx6dl-sabresd.dts“
SoC ოჯახები სასარგებლოა ცვლილების განხორციელებისას, რომელიც სპეციფიკურია მხოლოდ ტექნიკის კლასისთვის. მაგample, i.MX 28 EVK-ს არ აქვს ვიდეო დამუშავების განყოფილება (VPU), ამიტომ VPU-ს ყველა პარამეტრი უნდა გამოიყენოს i.MX 5 ან i.MX 6, რათა იყოს სპეციფიკური ჩიპების სწორი კლასისთვის.

8.4.6 BitBake ჟურნალები
BitBake აღრიცხავს build და პაკეტის პროცესებს temp დირექტორიაში tmp/work/ / /ტემპი.
თუ კომპონენტი ვერ ახერხებს პაკეტის მოპოვებას, შეცდომებს ასახავს ჟურნალი file log.do_fetch.
თუ კომპონენტი ვერ შედგენილია, ჟურნალი, რომელიც აჩვენებს შეცდომებს, არის file log.do_compile.
ზოგჯერ კომპონენტი არ განლაგდება ისე, როგორც მოსალოდნელია. შეამოწმეთ დირექტორიები build კომპონენტის დირექტორიაში (tmp/work/ / ). შეამოწმეთ თითოეული რეცეპტის პაკეტი, პაკეტები-სპლიტ და sysroot* დირექტორიები, რომ ნახოთ თუ არა files მოთავსებულია იქ (სადაც არიან stagგანლაგების დირექტორიაში კოპირებამდე).

8.4.7 როგორ დავამატოთ CVE მონიტორინგისა და შეტყობინების მექანიზმი
CVE თვალთვალის მექანიზმის მიღება შესაძლებელია GitHub-დან. გადადით დირექტორიაში imx-yocto-bsp/sources.

გაუშვით შემდეგი ბრძანება:
git კლონი https://github.com/TimesysGit/meta-timesys.git -ბ კირკსტოუნი
ეს ბრძანება ჩამოტვირთავს დამატებით მეტალეიერს, რომელიც უზრუნველყოფს სკრიპტებს გამოსახულების მანიფესტის გენერირებისთვის, რომელიც გამოიყენება უსაფრთხოების მონიტორინგისთვის და შეტყობინებებისთვის, როგორც NXP-ისა და Timesys-ის Vigiles პროდუქტის შეთავაზების ნაწილი. მიჰყევით 7.3 განყოფილებას ხსნარის გამოყენების შესახებ.
სრულ CVE მოხსენებაზე წვდომისთვის საჭიროა LinuxLink ლიცენზიის გასაღები. თქვენი განვითარების გარემოში გასაღების გარეშე, Vigiles აგრძელებს შესრულებას დემო რეჟიმში, აწარმოებს მხოლოდ შემაჯამებელ ანგარიშებს.
შედით თქვენს Vigiles ანგარიშში LinuxLink-ზე (ან შექმენით ერთი, თუ არ გაქვთ: https://www.timesys.com/registernxp-vigiles/). შედით თქვენს პრეფერენციებზე და შექმენით ახალი
Გასაღები. ჩამოტვირთეთ გასაღები file თქვენი განვითარების გარემოში. მიუთითეთ გასაღების ადგილმდებარეობა file თქვენი Yocto's conf/local.conf-ში file შემდეგი განცხადებით:
VIGILES_KEY_FILE = „/tools/timesys/linuxlink_key“

ცნობები

  • ჩატვირთვის გადამრთველების შესახებ დეტალებისთვის იხილეთ სექცია „როგორ ჩატვირთოთ i.MX დაფები“ i.MX Linux მომხმარებლის სახელმძღვანელოში (IMXLUG).
  • თუ როგორ გადმოწეროთ სურათები U-Boot-ის გამოყენებით, იხილეთ სექცია „სურათების ჩამოტვირთვა U-Boot-ის გამოყენებით“ i.MX Linux-ის მომხმარებლის სახელმძღვანელოში (IMXLUG).
  • თუ როგორ უნდა დააყენოთ SD/MMC ბარათი, იხილეთ სექცია „SD/MMC ბარათის ჩატვირთვისთვის მომზადება“ i.MX Linux-ის მომხმარებლის სახელმძღვანელოში (IMXLUG).

შენიშვნა დოკუმენტის წყაროს კოდის შესახებ

Exampამ დოკუმენტში ნაჩვენები le კოდს აქვს შემდეგი საავტორო უფლებები და BSD-3-clause ლიცენზია:
საავტორო უფლება 2024 NXP გადანაწილება და გამოყენება წყაროსა და ბინარულ ფორმებში, მოდიფიკაციით ან მის გარეშე, დასაშვებია შემდეგი პირობების დაკმაყოფილების შემთხვევაში:

  1. წყაროს კოდის გადანაწილებამ უნდა შეინარჩუნოს საავტორო უფლებების შესახებ ზემოაღნიშნული შეტყობინება, პირობების ეს სია და შემდეგი უარი პასუხისმგებლობაზე.
  2. ორობითი ფორმით ხელახალი გავრცელება უნდა ასახავდეს ზემოხსენებულ საავტორო უფლებების შესახებ შეტყობინებას, პირობების ამ ჩამონათვალს და შემდეგ უარყოფას დოკუმენტაციაში და/ან სხვა მასალებში, რომლებიც მოწოდებულია გავრცელებასთან ერთად.
  3. არც საავტორო უფლებების მფლობელის სახელი და არც მისი ავტორების სახელები არ შეიძლება გამოყენებულ იქნას ამ პროგრამული უზრუნველყოფიდან მიღებული პროდუქტების დასამტკიცებლად ან პოპულარიზაციისთვის, წინასწარი წერილობითი ნებართვის გარეშე.

ეს პროგრამული უზრუნველყოფა მოწოდებულია საავტორო უფლებების მფლობელებისა და კონტრიბუტორების მიერ „როგორც არის“ და ნებისმიერი მკაფიო ან ნაგულისხმევი გარანტიების ჩათვლით, მაგრამ არ შემოიფარგლება უსასყიდლო გარანტიებით . არავითარ შემთხვევაში არ იქნება პასუხისმგებელი საავტორო უფლების მფლობელი ან კონტრიბუტორი რაიმე პირდაპირი, არაპირდაპირი, შემთხვევითი, განსაკუთრებული, სამაგალითო ან თანმიმდევრული ზიანისათვის (მათ შორის, ცალსახად, მაგრამ არა შეზღუდული; გამოყენება, მონაცემები ან მოგება; ან საქმიანი შეფერხება) რაც არ უნდა იყოს გამოწვეული და პასუხისმგებლობის ნებისმიერ თეორიაზე, იქნება ეს კონტრაქტი, მკაცრი პასუხისმგებლობა თუ დანაშაული (მათ შორის, გაუფრთხილებლობით ან სხვაგვარად), რომელიც წარმოიქმნება ნებისმიერ შემთხვევაში F ასეთი ზიანის შესაძლებლობა.

გადასინჯვის ისტორია

ეს ცხრილი გთავაზობთ გადასინჯვის ისტორიას.
გადასინჯვის ისტორია

დოკუმენტის ID თარიღი არსებითი ცვლილებები
IMXLXYOCTOUG v.LF6.6.3_1.0.0 29 წლის 2024 მარტი განახლდა 6.6.3 ბირთვზე, ამოიღო i.MX 91P და დაემატა i.MX 95 როგორც Alpha Quality.
IMXLXYOCTOUG v.LF6.1.55_2.2.0 12/2023 განახლებულია 6.1.55 ბირთვამდე.
IMXLXYOCTOUG v.LF6.1.36_2.1.0 09/2023 განახლებულია 6.1.36 ბირთვზე და დაემატა I.MX 91P.
IMXLXYOCTOUG v.LF6.1.22_2.0.0 06/2023 განახლებულია 6.1.22 ბირთვამდე.
IMXLXYOCTOUG v.LF6.1.1_1.0.0 04/2023 შეცდომის კორექტირება ბრძანების სტრიქონებში 3.2 ნაწილში.
IMXLXYOCTOUG v.LF6.1.1_1.0.0 03/2023 განახლებულია 6.1.1 ბირთვამდე.
IMXLXYOCTOUG v.LF5.15.71_2.2.0 12/2022 განახლებულია 5.15.71 ბირთვამდე.
IMXLXYOCTOUG v.LF5.15.52_2.1.0 09/2022 განახლებულია 5.15.52 ბირთვზე და დაემატა i.MX 93.
IMXLXVOCTOUG v.LF5.15.32_2.0.0 06/2022 განახლებულია 5.15.32 ბირთვზე, U-Boot 2022.04 და Kirkstone Yocto.
IMXLXYOCTOUG v.LF5.15.5_1.0.0 03/2022 განახლებულია 5.15.5 ბირთვზე, Honister Yocto და Qt6.
IMXLXYOCTOUG v.LF5.10.72_2.2.0 12/2021 განაახლეთ ბირთვი 5.10.72-მდე და განაახლეთ BSP.
IMXLXYOCTOUG v.LF5.10.52_2.1.0 09/2021 განახლებულია i.MX GULP Alpha-სთვის და ბირთვი განახლებულია 5.10.52-მდე.
IMXLXYOCTOUG v.LF5.10.35_2.0.0 06/2021 განახლებულია 5.10.35 ბირთვამდე.
IMXLXYOCTOUG v.LF5.10.9_1.0.0 04/2021 გაასწორა შეცდომა ბრძანების სტრიქონებში განყოფილებაში 3.1 „ჰოსტის პაკეტები.
IMXLXYOCTOUG v.LF5.10.9_1.0.0 03/2021 განახლებულია 5.10.9 ბირთვამდე.
IMXLXYOCTOUG v.L5.4.70_2.3.0 01/2021 განახლებულია ბრძანების სტრიქონები განყოფილებაში "მკლავის Cortex-M4 გამოსახულების გაშვება".
IMXLXYOCTOUG v.L5.4.70_2.3.0 12/2020 i.MX 5.4 კონსოლიდირებული GA i.MX დაფების გამოსაშვებად, მათ შორის i. MX 8M Plus და i.MX 8DXL.
IMXLXYOCTOUG v.L5.4.47_2.2.0 09/2020 I.MX 5.4 Beta2 გამოშვება i.MX 8M Plus-ისთვის, ბეტა 8DXL-ისთვის და კონსოლიდირებული GA გამოშვებული I.MX დაფებისთვის.
IMXLXYOCTOUG v.L5.4.24_2.1.0 06/2020 i.MX 5.4 ბეტა გამოშვება i.MX 8M Plus-ისთვის, Aipha2 8DXL-ისთვის და კონსოლიდირებული GA გამოშვებული i.MX დაფებისთვის.
IMXLXYOCTOUG v.L5.4.3_2.0.0 04/2020 i.MX 5.4 Alpha გამოშვება i.MX 8M Plus და 8DXL EVK დაფებისთვის.
IMXLXYOCTOUG v.LF5A.3_1.0.0 03/2020 I.MX 5.4 Kernel და Yocto პროექტის განახლებები.
IMXLXYOCTOUG v.L4.19.35_1.1.0 10/2019 I.MX 4.19 Kernel და Yocto პროექტის განახლებები.
IMXLXYOCTOUG v.L4.19.35_1.0.0 07/2019 I.MX 4.19 ბეტა ბირთვისა და Yocto პროექტის განახლებები.
IMXLXYOCTOUG v.L4.14.98_2.0.0_ga 04/2019 i.MX 4.14 ბირთვის განახლება და დაფის განახლებები.
IMXLXYOCTOUG v.L4.14.78_1.0.0_ga 01/2019 I.MX 6, i.MX 7, i.MX 8 ოჯახის GA გამოშვება.
IMXLXYOCTOUG v14.14.62_1.0.0_ ბეტა 11/2018 i.MX 4.14 ბირთვის განახლება, Yocto Project Sumo განახლება.
IMXLXYOCTOUG v14.9.123_2.3.0_ 8 მმ 09/2018 i.MX 8M Mini GA გამოშვება.
IMXLXYOCTOUG v14.9.88_2.2.0_ 8qxp-beta2 07/2018 i.MX 8QuadXPlus Beta2 გამოშვება.
IMXLXYOCTOUG v14.9.88_2.1.0_ 8 მმ-ალფა 06/2018 i.MX 8M Mini Alpha გამოშვება.
IMXLXYOCTOUG v14.9.88_2.0.0-ga 05/2018 i.MX 7ULP და i.MX 8M Quad GA გამოშვება.
IMXLXYOCTOUG v14.9.51_imx8mq- ga 03/2018 დამატებულია i.MX 8M Quad GA.
IMXLXYOCTOUG v14.9.51_8qm- beta2/8qxp-beta 02/2018 დამატებულია i.MX 8QuadMax Beta2 და i.MX 8QuadXPlus Beta.
IMXLXYOCTOUG v.L4.9.51_imx8mq- ბეტა 12/2017 დამატებულია i.MX 8M Quad.
IMXLXYOCTOUG v14.9.51_imx8qm- ბეტა 1 12/2017 დამატებულია i.MX 8QuadMax.
IMXLXYOCTOUG v14.9.51_imx8qxp- ალფა 11/2017 თავდაპირველი გამოშვება.

იურიდიული ინფორმაცია

განმარტებები
მონახაზი - დოკუმენტის სტატუსის პროექტი მიუთითებს, რომ შინაარსი ჯერ კიდევ შიდა რეჟიმშიაview და ექვემდებარება ოფიციალურ დამტკიცებას, რამაც შეიძლება გამოიწვიოს ცვლილებები ან დამატებები. NXP Semiconductors არ იძლევა რაიმე სახის წარმოდგენას ან გარანტიას დოკუმენტის პროექტში შეტანილი ინფორმაციის სიზუსტესა და სისრულესთან დაკავშირებით და არ არის პასუხისმგებელი ამ ინფორმაციის გამოყენების შედეგებზე.
პასუხისმგებლობის უარყოფა
შეზღუდული გარანტია და პასუხისმგებლობა — ამ დოკუმენტში არსებული ინფორმაცია ითვლება ზუსტი და სანდო. თუმცა, NXP Semiconductors არ იძლევა რაიმე სახის წარმოდგენას ან გარანტიას, გამოხატულ ან ნაგულისხმევს, ასეთი ინფორმაციის სიზუსტესა და სისრულესთან დაკავშირებით და არ არის პასუხისმგებელი ამ ინფორმაციის გამოყენების შედეგებზე. NXP Semiconductors არ იღებს პასუხისმგებლობას ამ დოკუმენტის შინაარსზე, თუ იგი მოწოდებულია NXP Semiconductors-ის გარეთ არსებული ინფორმაციის წყაროს მიერ.
არავითარ შემთხვევაში NXP Semiconductors არ იქნება პასუხისმგებელი რაიმე არაპირდაპირი, შემთხვევითი, სადამსჯელო, სპეციალური ან თანმიმდევრული ზიანისთვის (მათ შორის - დაკარგული მოგების შეზღუდვის გარეშე, დაკარგული დანაზოგის, ბიზნესის შეფერხების, ნებისმიერი პროდუქტის ამოღებასთან ან ჩანაცვლებასთან ან გადამუშავების საფასურთან დაკავშირებული ხარჯები) ასეთი ზიანი არ არის დაფუძნებული დელიქტურობაზე (მათ შორის გაუფრთხილებლობაზე), გარანტიაზე, ხელშეკრულების დარღვევაზე ან რაიმე სხვა იურიდიულ თეორიაზე.
მიუხედავად ნებისმიერი ზიანისა, რომელიც მომხმარებელს შეიძლება მიადგეს რაიმე მიზეზით, NXP Semiconductors-ის ერთობლივი და კუმულაციური პასუხისმგებლობა კლიენტის წინაშე აქ აღწერილი პროდუქტებისთვის შეზღუდული იქნება NXP Semiconductors-ის კომერციული გაყიდვის წესებისა და პირობების შესაბამისად. ცვლილებების შეტანის უფლება - NXP Semiconductors იტოვებს უფლებას შეიტანოს ცვლილებები ამ დოკუმენტში გამოქვეყნებულ ინფორმაციაში, მათ შორის, სპეციფიკაციებისა და პროდუქტის აღწერილობების შეზღუდვის გარეშე, ნებისმიერ დროს და გაფრთხილების გარეშე. ეს დოკუმენტი ანაცვლებს და ცვლის ყველა ინფორმაციას, რომელიც მოწოდებულ იქნა ამ დოკუმენტის გამოქვეყნებამდე.
გამოსაყენებლად ვარგისიანობა — NXP Semiconductors-ის პროდუქტები არ არის შექმნილი, ავტორიზებული ან გარანტირებული, რომ იყოს გამოსაყენებლად სიცოცხლისათვის კრიტიკულ სისტემებში ან აღჭურვილობაში, არც იმ აპლიკაციებში, სადაც NXP Semiconductors პროდუქტის გაუმართაობამ ან გაუმართაობამ შეიძლება გამოიწვიოს პირადი დაზიანება, სიკვდილი ან მძიმე ქონებრივი ან გარემოს დაზიანება. NXP Semiconductors და მისი მომწოდებლები არ იღებენ პასუხისმგებლობას NXP Semiconductors-ის პროდუქციის ჩართვაზე და/ან გამოყენებაზე ასეთ აღჭურვილობასა თუ აპლიკაციებში და, შესაბამისად, ასეთი ჩართვა და/ან გამოყენება ხდება მომხმარებლის პასუხისმგებლობით.
აპლიკაციები - აპლიკაციები, რომლებიც აღწერილია აქ რომელიმე ამ პროდუქტისთვის, მხოლოდ საილუსტრაციო მიზნებისთვისაა. NXP Semiconductors არ იძლევა წარმოდგენას ან გარანტიას, რომ ასეთი აპლიკაციები შესაფერისი იქნება მითითებული გამოყენებისთვის შემდგომი ტესტირების ან ცვლილებების გარეშე.
კლიენტები პასუხისმგებელნი არიან თავიანთი აპლიკაციებისა და პროდუქტების დიზაინსა და ექსპლუატაციაზე NXP Semiconductors პროდუქტების გამოყენებით და NXP Semiconductors არ იღებს პასუხისმგებლობას აპლიკაციებთან ან მომხმარებლის პროდუქტის დიზაინთან რაიმე სახის დახმარებაზე. კლიენტის ერთპიროვნული პასუხისმგებლობაა განსაზღვროს, არის თუ არა NXP Semiconductors პროდუქტი შესაფერისი და შეესაბამება მომხმარებლის აპლიკაციებს და დაგეგმილ პროდუქტებს, ასევე მესამე მხარის კლიენტ(ებ)ის დაგეგმილი გამოყენებისა და გამოყენებისთვის. მომხმარებლებმა უნდა უზრუნველყონ შესაბამისი დიზაინი და ოპერაციული გარანტიები, რათა მინიმუმამდე დაიყვანონ მათ აპლიკაციებთან და პროდუქტებთან დაკავშირებული რისკები.
NXP Semiconductors არ იღებს პასუხისმგებლობას რაიმე ნაგულისხმევთან, დაზიანებასთან, ხარჯებთან ან პრობლემასთან დაკავშირებით, რომელიც დაფუძნებულია კლიენტის აპლიკაციებში ან პროდუქტებში არსებულ ნებისმიერ სისუსტეზე ან ნაგულისხმევზე, ​​ან კლიენტის მესამე მხარის კლიენტ(ებ)ის მიერ აპლიკაციაში ან გამოყენებაზე. კლიენტი პასუხისმგებელია მომხმარებლის აპლიკაციებისა და პროდუქტების ყველა საჭირო ტესტირების ჩატარებაზე NXP Semiconductors პროდუქტების გამოყენებით, რათა თავიდან აიცილოს აპლიკაციებისა და პროდუქტების ან აპლიკაციის ნაგულისხმევი გამოყენება ან მომხმარებლის მესამე მხარის კლიენტ(ებ)ის მიერ გამოყენება. NXP არ იღებს რაიმე პასუხისმგებლობას ამ კუთხით.
კომერციული გაყიდვის წესები და პირობები — NXP Semiconductors პროდუქცია იყიდება კომერციული გაყიდვის ზოგადი წესებისა და პირობების შესაბამისად, როგორც გამოქვეყნებულია მისამართზე: https://www.nxp.com/profile/terms, თუ სხვაგვარად არ არის შეთანხმებული მოქმედი წერილობითი ინდივიდუალური შეთანხმებით. ინდივიდუალური ხელშეკრულების გაფორმების შემთხვევაში გამოიყენება მხოლოდ შესაბამისი ხელშეკრულების პირობები. NXP Semiconductors ამით პირდაპირ აპროტესტებს მომხმარებლის ზოგადი პირობების გამოყენებას NXP Semiconductors-ის პროდუქციის შეძენასთან დაკავშირებით მომხმარებლის მიერ.
ექსპორტის კონტროლი — ეს დოკუმენტი, ისევე როგორც აქ აღწერილი ნივთ(ებ)ი შეიძლება ექვემდებარებოდეს ექსპორტის კონტროლის რეგულაციებს. ექსპორტს შესაძლოა დასჭირდეს კომპეტენტური ორგანოების წინასწარი ავტორიზაცია.
ვარგისიანობა არასაავტომობილო კვალიფიციურ პროდუქტებში გამოსაყენებლად — თუ ამ დოკუმენტში პირდაპირ არ არის მითითებული, რომ NXP Semiconductors-ის ეს კონკრეტული პროდუქტი საავტომობილო კვალიფიკაციას წარმოადგენს, პროდუქტი არ არის შესაფერისი საავტომობილო გამოყენებისთვის. ის არც კვალიფიცირებულია და არც ტესტირება საავტომობილო ტესტირების ან განაცხადის მოთხოვნების შესაბამისად. NXP Semiconductors არ იღებს პასუხისმგებლობას საავტომობილო აღჭურვილობაში ან აპლიკაციებში არასაავტომობილო კვალიფიციური პროდუქტების ჩართვაზე და/ან გამოყენებაზე.
იმ შემთხვევაში, როდესაც მომხმარებელი იყენებს პროდუქტს დიზაინისა და საავტომობილო აპლიკაციებში საავტომობილო სპეციფიკაციებისა და სტანდარტების შესაბამისად, მომხმარებელმა (ა) უნდა გამოიყენოს პროდუქტი NXP Semiconductors-ის პროდუქტის გარანტიის გარეშე, ასეთი საავტომობილო აპლიკაციებისთვის, გამოყენებისა და სპეციფიკაციებისთვის და ( ბ) როდესაც მომხმარებელი იყენებს პროდუქტს საავტომობილო აპლიკაციებისთვის NXP Semiconductors-ის სპეციფიკაციების მიღმა, ასეთი გამოყენება უნდა იყოს მხოლოდ მომხმარებლის პასუხისმგებლობით და (გ) კლიენტი სრულად ანაზღაურებს NXP Semiconductor-ს ნებისმიერი პასუხისმგებლობისთვის, ზიანისთვის ან პროდუქტის წარუმატებელი პრეტენზიებისთვის, რომლებიც გამოწვეულია მომხმარებლის დიზაინისა და გამოყენების შედეგად. პროდუქტი საავტომობილო აპლიკაციებისთვის NXP Semiconductors-ის სტანდარტული გარანტიისა და NXP Semiconductors-ის პროდუქტის სპეციფიკაციების მიღმა.
თარგმანები — დოკუმენტის არაინგლისური (თარგმნილი) ვერსია, ამ დოკუმენტის იურიდიული ინფორმაციის ჩათვლით, მხოლოდ მითითებისთვისაა. თარგმნილ და ინგლისურ ვერსიებს შორის რაიმე შეუსაბამობის შემთხვევაში უპირატესობა მიენიჭება ინგლისურ ვერსიას.
უსაფრთხოება — მომხმარებელს ესმის, რომ NXP-ის ყველა პროდუქტი შეიძლება ექვემდებარებოდეს ამოუცნობ დაუცველობას ან შეიძლება მხარი დაუჭიროს უსაფრთხოების დადგენილ სტანდარტებს ან სპეციფიკაციებს ცნობილი შეზღუდვებით. კლიენტი პასუხისმგებელია მისი აპლიკაციებისა და პროდუქტების დიზაინსა და ექსპლუატაციაზე მათი სიცოცხლის ციკლის განმავლობაში, რათა შეამციროს ამ მოწყვლადობის ეფექტი მომხმარებლის აპლიკაციებსა და პროდუქტებზე. კლიენტის პასუხისმგებლობა ასევე ვრცელდება სხვა ღია და/ან საკუთრებაში არსებულ ტექნოლოგიებზე, რომლებიც მხარდაჭერილია NXP პროდუქტებით მომხმარებლის აპლიკაციებში გამოსაყენებლად. NXP არ იღებს პასუხისმგებლობას რაიმე დაუცველობისთვის. მომხმარებელმა რეგულარულად უნდა შეამოწმოს უსაფრთხოების განახლებები NXP-დან და სათანადოდ დაიცვას.
მომხმარებელმა უნდა შეარჩიოს უსაფრთხოების მახასიათებლების მქონე პროდუქტები, რომლებიც საუკეთესოდ აკმაყოფილებენ განზრახ აპლიკაციის წესებს, რეგულაციებს და სტანდარტებს და მიიღოს საბოლოო დიზაინის გადაწყვეტილებები მის პროდუქტებთან დაკავშირებით და მხოლოდ პასუხისმგებელია მის პროდუქტებთან დაკავშირებული ყველა სამართლებრივი, მარეგულირებელი და უსაფრთხოებასთან დაკავშირებული მოთხოვნების დაცვაზე, მიუხედავად ნებისმიერი ინფორმაციის ან მხარდაჭერის შესახებ, რომელიც შეიძლება მოწოდებული იყოს NXP-ის მიერ.
NXP-ს ჰყავს პროდუქტის უსაფრთხოების ინციდენტების რეაგირების ჯგუფი (PSIRT) (ხელმისაწვდომობა აქ PSIRT@nxp.com) რომელიც მართავს NXP პროდუქტების უსაფრთხოების მოწყვლადობაზე გამოძიების, მოხსენების და გადაწყვეტის გათავისუფლებას.
NXP B.V. - NXP B.V. არ არის მოქმედი კომპანია და ის არ ავრცელებს ან ყიდის პროდუქტებს.

სავაჭრო ნიშნები
შენიშვნა: ყველა მითითებული ბრენდი, პროდუქტის სახელები, სერვისების სახელები და სავაჭრო ნიშნები მათი შესაბამისი მფლობელების საკუთრებაა.
NXP — სიტყვა და ლოგო არის 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, მრავალმხრივი — არის Arm Limited-ის (ან მისი შვილობილი ან შვილობილი კომპანიების) სავაჭრო ნიშნები და/ან რეგისტრირებული სავაჭრო ნიშნები აშშ-ში და/ან სხვაგან. დაკავშირებული ტექნოლოგია შეიძლება იყოს დაცული ნებისმიერი ან ყველა პატენტით, საავტორო უფლებებით, დიზაინით და სავაჭრო საიდუმლოებით. Ყველა უფლება დაცულია.
EdgeLock — არის NXP BV-ის სავაჭრო ნიშანი
eIQ — არის NXP BV-ის სავაჭრო ნიშანი
i.MX — არის NXP BV-ის სავაჭრო ნიშანი

IMXLXYOCTOUG
All information provided ამ დოკუმენტში ექვემდებარება იურიდიულ უარყოფას.
© 2024 NXP BV ყველა უფლება დაცულია.
Rev. LF6.6.3_1.0.0 — 29 წლის 2024 მარტი

დოკუმენტები / რესურსები

NXP IMXLXYOCTOUG i.MX Yocto Project [pdf] მომხმარებლის სახელმძღვანელო
IMXLXYOCTOUG i.MX Yocto Project, i.MX Yocto Project, Yocto Project, Project

ცნობები

დაკავშირებული პოსტები

დატოვე კომენტარი

თქვენი ელფოსტის მისამართი არ გამოქვეყნდება. მონიშნულია აუცილებელი ველები *